Howto: Do not display the name of the user who has locked a Windows computer or server


Normally when a Windows workstation or server is locked, you’ll see something similar to the following Windows Security message:  

This computer is in use and has been locked.
 
Only DOMAIN\USER (user name) or an administrator can unlock this computer.
 
To not show the name of the user who has locked a computer, the following can be defined in a workstation level GPO
 
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Interactive logon: Display user information when the session is locked.
 
There are three choices if you enable this policy:
 
  • User display name, domain and user names (default setting)
  • User display name only
  • Do not display user information
 
Besides being able to apply this to Active Directory GPOs, this setting appears in the local security policy on my Windows XP SP3 VM.  The setting is not available on my XP SP2 laptop, but I see from KB837022  there is a hotfix that corrects this problem in XP SP2.


Alternatively, the following DWORD can be created in the registry of XP SP2, Windows Vista, and Windows Server 2008 machine to accomplish the same thing:
 
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system\DontDisplayLockedUserId
 
User display name, domain and user names = 1
User display name only = 2
Do not display user information =3
 
You need to restart the machine for the change to take effect.
 
You may also be interested in the related Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Interactive logon: Do not display last user name setting. This security setting determines whether the name of the last user to log on to the computer is displayed in the Windows logon screen.

If this policy is enabled, the name of the last user to successfully log on is not displayed in the Log On to Windows dialog box.  If this policy is disabled, the name of the last user to log on is displayed.

Fix: The error returned when trying to retrieve these settings from the local security policy database (%windir%\security\database\secedit.sdb) was: The parameter is incorrect


Howto fix error when opening Windows Server 2003 Local Security Policy:

The Group Policy security settings that apply to this machine could not be determined. The error returned when trying to retrieve these settings from the local security policy database (%windir%\security\database\secedit.sdb) was: The parameter is incorrect.

All local security settings will be displayed, but no indication will be given as to whether or not a given security setting is defined by Group Policy.

Any local security setting modified through this User Interface may subsequently be overriden by domain-level policies.

Windows cannot read template information.

Many documents suggest that renaming the %windir%\security\database\secedit.sdb file and rebooting the server will resolve this issue by recreating the security database. Unfortunately, this procedure never resulted in the secedit.sdb database file being re-created, even after a server reboot.

I also tried importing a new secedit.sdb database, but that failed with the following error:

An extended error has occurred. Import failed.

After much Googling I came across MS KB932461 You cannot determine Group Policy security settings on a Windows Server 2003, Enterprise Edition-based computer. Even though the OS of the offending servers is Windows Server 2003 R2 Standard (not Enterprise) the fix described in the KB document fixed this issue.

The cause of the problem is explained by the KB as

“This problem occurs if specific Group Policy security settings are changed from their default settings. These security settings specify the minimum required security setting of server-side and client-side network connections for programs that use the NTLM security support provider (SSP).”

The solution was to edit the registry key
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
Set the values of NtlmMinServerSec and NtlmMinClientSec to 0 (zero)

Wait about 15-30 minutes for the change to take effect and you should be able to view the Local Security Policy once again!

If you’re curious what these keys do, NtlmMinServerSec specifies the minimum required security setting of server-side network connections for applications using the NTLM security support provider (SSP).

NtlmMinClientSec specifies the minimum required security setting of client-side network connections for applications using the NTLM security support provider (SSP).

In my case both of these settings had previous values of 0×20080030 which enforces message integrity, confidentiality, use of NTLMv2 and 128-bit encryption.

Windows XP firewall service is enabled after installing XP SP3 – even if it was previously disabled


If Windows XP SP2 firewall service is set to manual or disabled when Windows XP SP3 is applied, the Windows Firewall/Internet Connection Sharing (ICS) service and Security Cetner service will be changed to automatic startup.  This behavior is by design, for the purpose of increasing the security of Windows XP.

This setting will remain in effect for computers that had the service startup manually altered.  
 
According to the Microsoft Enterprise Networking Team:
If the service is administratively disabled via domain Group Policy, it will again be disabled after subsequent application of Group Policy. The automatic service startup should only be seen on the first reboot after applying Service Pack 3. To cause GPO settings to be updated immediately on a client, run gpupdate /force from a command prompt.

Microsoft Advanced Group Policy Management (AGPM) 3.0 has been RTMd – and why you should care


The Microsoft Group Policy Team Blog has announced that Microsoft Advanced Group Policy Management (AGPM) 3.0 has been RTM’d.

Advanced Group Policy Management (AGPM) helps you better manage Group Policy objects (GPOs) in your environment by providing change control, offline editing, and role-based delegation. AGPM is a key component of the Microsoft Desktop Optimization Pack (MDOP). 

It helps customers overcome challenges that affect Group Policy management in any organization, particularly those with complex information technology (IT) environments. A robust delegation model, role-based administration, and change-request approval provide granular administrative control. For example, you can delegate Reviewer, Editor, and Approver roles to other administrators — even administrators who do not have access to production GPOs. The Editor role can edit GPOs but not deploy them; the Approver role can deploy GPO changes. AGPM also helps reduce the risk of widespread failures.

You can use AGPM to edit GPOs offline, outside of the production environment, and then audit changes and easily find differences between GPO versions. In addition, AGPM supports effective change control by providing version tracking, history capture, and quick rollback of deployed GPO changes. It also supports a management workflow by allowing you to create GPO template libraries and send GPO change e-mail notifications.

AGPM has a server component and a client component, each of which you install separately. First, you install the Group Policy Management Console (GPMC) and the server component on a server system that has access to the policies you want to manage. Then, you install GPMC and the AGPM client on any computer from which administrators will review, edit, and deploy policies. You can run the client on Windows Vista or Windows Server 2003.

The AGPM client integrates completely with GPMC. Administrators review, edit, and deploy GPOs within each domain’s Change Control folder. The GPOs you see in the Group Policy objects list on the Controlled tab are stored in the AGPM server’s archive. Changes made to these GPOs don’t affect the production environment until administrators with the Approver role deploy the GPOs to production.

AGPM provides advanced change control features that help you manage and control GPOs. Many of the AGPM change control concepts are already familiar to administrators with experience using common version-control tools, such as the version control feature in Microsoft Windows SharePoint Services. The steps necessary to change and deploy a GPO are as follows:

  1. Check out the GPO from the archive.
  2. Edit the GPO as necessary.
  3. Check in the GPO to the archive.
  4. Deploy the GPO to production.

Change control is more than checking files in and out of the archive, though. AGPM keeps a history of changes for each GPO. You can deploy any version of a GPO to production, so you can quickly roll back a GPO to an earlier version if you need to. AGPM can compare different versions of a GPO, and show settings that were added, changed, or deleted. This way, you can easily review changes before approving and deploying them to the production environment.

Group Policy already provides a rich delegation model. It allows you to delegate administration to regional and task-oriented administrators. It also, however, lets administrators approve their own changes. In contrast, AGPM provides a role-based delegation model that adds a review and approval step to the workflow.

To support this delegation model, AGPM defines three special roles:

  • Reviewer. Administrators assigned to the Reviewer role can view and compare GPOs. They cannot edit or deploy them.
  • Editor. Administrators assigned to the Editor role can view and compare GPOs. They can check out GPOs from the archive, edit them, and check them in to the archive. They can also request deployment of a GPO.
  • Approver. Administrators assigned to the Approver role can approve the creation and deployment of GPOs. (When administrators assigned to the Approver role create or deploy a GPO, approval is automatic.)

You can assign administrators and groups to these roles for all controlled GPOs within the domain. For example, you can assign administrators globally to the Reviewer role, which allows them to review any controlled GPO in the domain. You can also assign administrators to these roles for individual controlled GPOs. Rather than allow administrators to edit any controlled GPO in the domain, for example, you can give them specific permission to edit individual controlled GPOs by assigning to them the Editor role for those GPOs only.

See the Advanced Group Policy Management Training Guide at http://technet.microsoft.com/en-us/bb608283.aspx for additional details on what’s forthcoming.

Microsoft has finally fixed their methodology for disabling Autorun on Windows operating systems


Technet article 91525 describes a registry key that can be set to disable the Autorun feature in Windows operating systems. 

The registry key is NoDriveTypeAutoRun, which can be found at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer

This key disables the Autoplay feature on all drives of the type specified.  Autoplay begins reading from a drive as soon as media is inserted in the drive. As a result, the setup file of programs and the sound on audio media starts immediately.

Unfortunately, this key did not produce the desired result of disabling the Double Click and Contextual Menu features.  Microsoft just released KB 953252, which describes how to obtain updates that correct these broken registry key settings in the following Windows Operating Systems:

Windows 2000
Windows XP Service Pack 2
Windows Server 2003 Service Pack 1 and 2
Windows Vista

Note: Windows Server 2008 is not affected.

The main purpose of Autorun is to provide a software response to hardware actions that you start on a computer. Autorun has the following features:

• Double Click
• Contextual Menu
• AutoPlay

These features are typically called from removable media or from network shares. During AutoPlay, the Autorun.inf file from the media is parsed. This file specifies which commands the system runs. Many companies use this functionality to start their installers.

Please see KB 952252 for security updates to each applicable operating system to disable autorun capabilities.  This KB also describes Group Policy settings to disable all Autorun features, plus instructions on selectively disabling specific Autorun features.

If you’re still not sure why you’d want to disable Autorun, check out Scott’s article on Autorun attacks.

Blocking Apple software updates through Group Policy due to Safari for Windows security concerns


I’m a big fan of keeping my software applications up to date on client machines, but I hate the fact that Apple is trying to push new Safari installations whenever users update iTunes on my Windows machines.  I found Dan’s blog post specifics on how to edit the appropriate registry keys to forbid automatic installations of Apple software, but the post’s comments showed some differing results users experienced when implementing the registry changes.

Further down in the comments I came across Eric S’s suggestion for creating a software restriction policy that disallows Apple Software Update from running. 

“To disallow Apple Software Update in Group Policy:
- Computer Configuration > Windows Settings > Security Settings > Software Restriction Policies > Additional Rules
- Right-click or Action > New Path Rule…
- Path: C:\Program Files\Apple Software Update
- Security Level: Disallowed

This would prevent Apple Software Update from running, regardless of whether the user installed it, or what version was installed.”

In theory a network administrator could then push approved Apple updates to the client computers via Microsoft System Center Configuration Manager, Novell Zenworks, or other application deployment solution.

Also note that as of My 30 2008 Microsoft Security Advisory 953818 is warning of a “blended threat that allows remote code execution on all supported versions of Windows XP and Windows Vista when Apple’s Safari for Windows has been installed.  An attacker could trick users into visiting a specially crafted Web site that could download content to a user’s machine and execute the content locally using the same permissions as the logged-on user. “

This means that if the user is running with Administrator level privledges, the machine is easily owned by the bad guys.  According to Nitesh, who originally discovered the issue, the problem stems from the fact that the “Safari browser cannot be configured to obtain the user’s permission before it downloads a resource.  Safari downloads the resource without the user’s consent and places it in a default location (unless changed)”

Microsoft’s suggested action is to:

  1. Change the download location of content in Safari to a location other than ‘Desktop’
  2. Launch Safari. Under the Edit menu select Preferences.
  3. At the option where it states Save Downloaded Files to: select a different location on the local drive

Microsoft’s Group Policy Documentation Survival Guide


The Technet Group Policy Documentation Survival Guide contains all the information you will need to evaluate, plan, deploy, maintain, or support Group Policy.

The guide is available in HTML and PDF formats.  Note that this guide contains links to where to find the pertinent information – not the information itself.  Microsoft does a pretty good spreading the information around on different web sites, so this guide provides a central starting point to finding the various resources.

Howto: Disable Windows Simple File Sharing via the Registry and Local Security Policy


Microsoft KB 307874 describes how to disable Windows XP Professional’s simple file sharing. Why would you want to disable simple file sharing on your workstation? The KB explains:

By default, simple file sharing is enabled on a Microsoft Windows XP-based computer if the computer is not a member of a domain. With simple file sharing, you can share folders with everyone on your workgroup or network and make folders in your user profile private. However, if simple file sharing is enabled, you cannot prevent specific users and groups from accessing your shared folders. If you turn off simple file sharing, you can permit specific users and groups to access a shared folder. Those users must be logged on with the credentials of user accounts that you have granted access to your shared folder.

In a nutshell, if your machine is not a member of a domain, and you want to specify non-default ntfs or share permissions, you’ll need to disable simple file sharing.

To disable simple file sharing as explained in KB 304040, follow these steps:

1. Click Start - My Computer

2. On the Tools menu, click Folder Options – View

3. In the Advanced Settings section, clear the Use simple file sharing (Recommended) check box – OK

This method works just fine, but I wanted to disable simple file sharing on machines that had already been deployed, without any end user interaction. I figured the easiest way to do this was to edit the registry on the remote machines. KB 290403 explains that the registry value that needs to be changed to disable simple file sharing is:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\ForceGuest

Change the value from 1 (simple file sharing enabled) to 0 (simple file sharing disabled)

You can also disable simple file sharing by changing the following Local Security Policy:

Security Settings – Local Policies – Security Options – Network Access: Sharing and Security Model for local accounts

Change Guest Only – local users authenticate as guest to Classic – local users authenticate as themselves, then run gpupdate /force from a command prompt.

Please note that if you are running Windows XP Home, you will not have the option to disable simple file sharing through Windows Explorer unless you boot to safe mode.

Follow

Get every new post delivered to your Inbox.

Join 32 other followers