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.

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.

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.

Using admx.exe to parse Group Policy .adm files


The Windows Server 2003 Resource Kit Tools contains a utility called ADM File Parser, aka admx.msi. 

According to Microsoft,

“(AdmX) is a command-line tool that enables an administrator to export Group Policy settings to a tab-delimited text file. The administrator can then use the text produced by ADM File Parser (AdmX) to find changes for the policy settings between different versions of the operating systems.”

and

“The AdmX.exe tool runs on Windows 2000, Windows Server 2003, and Windows XP Professional. AdmX.exe also requires the Microsoft .NET Framework 1.0.”

My Windows XP SP2 machine already had the .NET framework 2.0 installed, so I figured installation would be no problem.  I was wrong.

I installed the Windows Server 2003 Resource Kit Tools to their default location of C:\Program Files\Windows Resource Kits\Tools and then ran C:\Program Files\Windows Resource Kits\Tools\admx.msi to start the ADMx installer and received the following message:

To run this application, you must first install one of the following versions of the .NET Framework:

v1.0.5000

v1.0.3705

Contact your application publisher for instructions about obtaining the appropriate version of the .NET Framework.

I was majorly bummed, since my administrative machine was running perfectly and the last thing I wanted was to mess it up by installing some archaic version of the .NET framework that was released back in 2003.  I was desperate for a workaround.

The GPOGUY suggested using ORCA to remove the .NET version dependency check for a similar situation, but I didn’t have much luck in the ten minutes I tried to figure out where the dependency was at (btw, if anyone can help here, I’d love to know how to do it).

My next approach was to try to fool admx.msi into thinking .NET 1.0 was installed by modifying the registry.  KB 318785, How to determine which versions of the .NET Framework are installed and whether service packs have been applied showed that version 1.0.3705 was the original .NET 1.0 RTM revision. 

Next I checked out KB 315291, How to detect the installed version of the .NET Framework in a Visual Studio Setup and Deployment package, which showed the following registry keys were generally checked for determining the .NET version.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\policy\v1.0

I did not have the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\policy\v1.0 key, so I created it, then created a new string with a value name of 3705 with value data of 3321-3705 per KB 315291.

I was sure this method was going to work, so I started doing my Superior Dance prior to starting the admx.msi installation – only to see it fail once again, reporting it still needed .NET 1.0. 

Copying the C:\WINDOWS\Microsoft.NET\Framework\v1.0.3705 directory from a Windows XP SP2 machine that did have .NET 1.0 installed to my administrative machine didn’t make a difference either.

I finally decided I spent long enough trying to fool the installer into thinking I had .NET 1.0 installed, so I finally downloaded and installed it.  It’s coexisted with .NET 2.0 just fine so far, I’m happy to report.

Incidently, once admx.msi installed I was able to parse the .adm settings to a tab delimited text file using the following syntax:

Syntax:  admX <admfilename> [/Output:<filename>] [/DIFF:<filename>] [/All] [/TIT
LE:<title text>]

Value                      Description

<admfilename>              Specifies path to .adm tempate file to be parsed.
                           ‘.adm’ extension must be included.
                           This is a required parameter.

/Output:<filename>         Specifies path to text file to write output info
                           If no output parameter,
                           text is written to the console.

/DIFF:<filename>           Performs a diff between the admfile and the
                           specified diff .adm filename filename.
                           ‘.adm’ extension must be included.

/ALL                       Prints all parsed information for the policy to
                           the console or the output file

/TITLE:<title text>         Adds the title text to output file.
                           Title text must be inside double quotes.

Here’s an example of the syntax I used to parse the system.adm file located at s:\zenworks\policies\media\adm\ and saved the data to media.txt with a title of “media system.adm” (type as all one line)

admx.exe s:\zenworks\policies\media\adm\system.adm /output:media.txt /Title:”media system.adm”

Follow

Get every new post delivered to your Inbox.

Join 32 other followers