Tag Archives: Group Policy

Windows Server

SHA1 Thumbprints for trusted .rdp publishers

Leave a comment

Remote Desktop Connection (RDC) has a Group Policy setting that determines which publishers are to be considered trusted when launching connections (typically .rdp files served in various ways).

The publisher is identified by the SHA1 thumbprint of the certificate of the publisher (the certificate used to sign the .rdp file). You get the thumbprint from the certificate:

image

The setting is located under:
Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Connection Client

Setting:
Specify SHA1 thumbprints of certificates representing trusted .rdp publishers

Description:
This policy setting allows you to specify a list of Secure Hash Algorithm 1 (SHA1) certificate thumbprints that represent trusted Remote Desktop Protocol (.rdp) file publishers.

If you enable this policy setting, any certificate with an SHA1 thumbprint that matches a thumbprint on the list is trusted. If a user tries to start an .rdp file that is signed by a trusted certificate, the user does not receive any warning messages when they start the file. To obtain the thumbprint, view the certificate details, and then click the Thumbprint field.

If you disable or do not configure this policy setting, no publisher is treated as a trusted .rdp publisher.

Notes:

You can define this policy setting in the Computer Configuration node or in the User Configuration node. If you configure this policy setting for the computer, the list of certificate thumbprints trusted for a user is a combination of the list defined for the computer and the list defined for the user.

This policy setting overrides the behavior of the “Allow .rdp files from valid publishers and user’s default .rdp settings” policy setting.

If the list contains a string that is not a certificate thumbprint, it is ignored.

As you can see; no mention of how the thumbprint is to be entered!

I found out the hard way that you have to remove all spaces and convert all letters to uppercase for the thumbprint to be valid. You are not informed if the format you enter is incorrect, it is just silently ignored if not recognized as a valid thumbprint.

This quick PowerShell command will do these two operations:

(“<your thumbprint here>”).ToUpper().Replace(” “,””)

If this Group Policy setting is not in effect, either because you have not set it or the thumbprint is incorrect/invalid, your users will get a warning when connecting, even if the certificate used to sign the .rdp file is trusted:

image

Error: A website wants to run a RemoteApp program. Make sure that you trust the publisher before you connect to run the program.

It is interesting to note that the rdpsign.exe command line utility that is used to sign .rdp files manually, requires that the thumbprint of the certificate must be provided in just this way: http://technet.microsoft.com/en-us/library/cc753982(WS.10).aspx

More info:

A note on copying the thumbprint

If you look at the highlighted/selected thumbprint in the image above you will see what looks like a leading whitespace. If you select the whole string (not as above), you will get a strange leading character in your thumbprint. Have a look at this zoomed image:

image

I do not know what character this is, but it invalidates the thumbprint string if you paste it into the SHA1 thumbprint field in your GPO. Even stranger is that it does not show up in the pasted text in the GPO object; it just “looks” right. As I said, I have no explanation, but remember to skip the leading whitespace when you copy your thumbprint.

This is how it should look:

image

Active Directory, Group Policy

Viewing the contents of Group Policy Registry.pol files

Leave a comment

While investigating some EFS settings I needed to look at the raw data in Group Policy settings files, usually called Registry.pol and located in the SYSVOL share for each GPO. First I tried to load it as any other hive in Registry Editor, but that did not work, indicating that .pol files do not use the same format as the Registry does.

After a bit of searching I found this excellent utility at the gpoguy.com website: Registry.pol Viewer Utility.

With it I could read (but not change) the information in my Registry.pol file.

The Registry.pol format is documented at MSDN.

Active Directory, Group Policy

Group Policy WMI filters

Leave a comment

WMI filters are useful to further filter Group Policy Objects (GPOs), beyond what is possible/convenient with groups.

Distinguish between x86 and x64 computers:

x86

Select AddressWidth from Win32_Processor where (AddressWidth=”32″)

x64

Select AddressWidth from Win32_Processor where (AddressWidth=”64″)

Determine Windows version:

Use this filter to determine the Windows version and role:

select * from Win32_OperatingSystem where Version like “6.%” and ProductType = “1”

  • The Version property returns values that begin with the following characters (the % symbol is a wildcard character that represents other characters that can follow, but do not help distinguish the version number):
    Windows Server 2008 R2 or Windows 7 6.1%
    Windows Server 2008 or Windows Vista 6.0%
    Windows Server 2003 5.2%
    Windows XP 5.1%
    Windows 2000 5.0%
  • The ProductType property returns the following values:
    Client versions of Windows 1
    Server versions of Windows that are operating as a domain controller 2
    Server versions of Windows that are not operating as a domain controller (typically referred to as member servers) 3

Determine computer type (laptop, desktop etc.)

NOTE: The PCSystemType property in only available on Windows Vista and later OSs.

SELECT * FROM Win32_ComputerSystem WHERE PCSystemType = 1

These are the possible values for PCSystemType:

Value Meaning
0 Unspecified
1 Desktop
2 Mobile
3 Workstation
4 Enterprise Server
5 Small Office and Home Office (SOHO) Server
6 Appliance PC
7 Performance Server
8 Maximum

(I’d really like a computer with type 8, please!)

Active Directory, Group Policy, Windows Server

Microsoft Security Essentials, Sysprep and Group Policy

3 Comments

In smaller deployments Microsoft Security Essentials (MSE) is a good, free alternative for anti-malware. If you decide to use MSE in your images, you will discover that sysprep resets the Out Of Box Experience (OOBE) settings for MSE. In other words; every user that logs on to a machine deployed from your image will see the MSE OOBE Wizard (Figure 1-2), until someone with Administrator privileges completes the wizard. Sometimes you might not want to expose your users to that. Fortunately for us, we can use Group Policy Preferences to bypass the OOBE wizard.

Steps to disable MSE OOBE with Group Policy Preferences:

  1. Create a new Group Policy Object (GPO) or use an existing one.
  2. Create a new Registry preference for computers (Figure 3).
  3. Update the key HKLMSOFTWAREMicrosoftMicrosoft Security EssentialsOOBE DWORD to 0.
  4. Update policy on the client.

The OOBE value has two (known) values:

  • 1: Yes, run OOBE please
  • 0: No thanks, OOBE has already run for this computer

Having shown you how to do this I would like to call attention to the following excerpt from the Microsoft Security Essentials EULA:

  1. INSTALLATION AND USE RIGHTS.
    1. Home Use. If you are a home user, then you may install and use any number of copies of the software on your personal devices for use by people who reside in your household. As a home user, you may not use the software in any commercial, non-profit, or revenue generating business activities.
    2. Small Business. If you operate a small business, then you may install and use the software on up to ten (10) devices in your business.
    3. Restrictions.
      1. The software may not be used on a device running an enterprise version of a Microsoft Windows operating system.
      2. The software may not be used on devices owned by government or academic institutions.
    4. Separation of Components. The components of the software are licensed as a single unit. You may not separate the components and install them on different devices.
    5. Included Microsoft Programs. The software may contain other Microsoft programs. The license terms with those programs apply to your use of them.
Active Directory, Group Policy

Availability of the Group Policy Hide drives calculator and associated template

Leave a comment
A long time ago I created an HTML based application to calculate the numeric values required to hide specific combinations of drive letters through Group Policy. I also made a custom template file where you could enter the numeric value directly instead of editing the templates that came with Windows.
I used to host these files directly on my website, but now I have made them available as a download instead. The link to the download is:
The package contains these files:
  • CustomDrives.adm: The template that lets you enter the numeric values directly.
  • HideDrivesSelector.hta: The HTML based application to calculate the numeric values, as well as doing a “reverse” lookup of existing values.

When I have the time I plan to update the custom template to the new ADMX/ADML format for Windows Server 2008, but I do not think that will be anytime soon (Tempus fugit).

Active Directory, Group Policy

Working with Group Policy Restricted Groups policies

Leave a comment

What are Restricted Groups?

The Restricted Groups security setting in Group Policy allows an administrator to define two properties for security-sensitive groups (“restricted” groups). The two properties are Members and Member Of. In short it lets an Administrator decide which security principals are members of a restricted group, and which groups the restricted group is a member of. The Restricted Groups security setting can be found under Computer Configuration\Windows Settings\Security Settings\Restricted Groups in any Domain based GPO. The Members section enforces the membership of a group. Any existing members of the restricted group are removed and only the security principals listed in the Members section are members of the restricted group. Conversely, the Member Of section simply ensures that the restricted group is added to the groups listed in Member Of. It does not remove the group from other groups of which it is a member. This means that if you use the Members section; only the security principals you select will be members of a restricted group, all existing members of the group will be removed. If you use the Member Ofsection your group is only added to the restricted group.

Let’s say you want to add the domain group Domain Users to the local Administrators group on a set of computers. With Restricted Groups there are two approaches; using the Members section or using the Member Ofsection. In the first case, the restricted group is Administrators, and we add Domain Users as a member.

052508_2246_Workingwith1

Figure 1: Using the Members section of Restricted Groups

When using the Memberssection like this, all existing members of the Administrators group will be removed for all computers where this policy is applied.

In the second case the Restricted Group is Domain Users, and we specify that it should be a member of Administrators.

052508_2246_Workingwith2

Figure 2: Using the Member Of section of restricted Groups

When using the Member Ofsection like this, the existing membership of the Administrators group is preserved and Domain Users is simply added on all computers where this policy is applied.

In either case your policy should be linked to an OU where the computers on which you want the policy applied are located.

GptTmpl.inf

The Restricted Groups information, along with every other setting under the Security Settings container in a GPO, is stored in an INF file called GptTmpl.inf. Each GPO with security settings has one GptTmpl.inf file and its path is always:

%systemroot%\SYSVOL\sysvol\<DNS domain name>\Policies\<GUID of GPO>\Machine\Microsoft\Windows NT\SecEdit\GptTmpl.inf

The section where the Restricted Groups info is stored is called Group Membership.

[Unicode]
Unicode=yes
[Version]
signature=”$CHICAGO$”
Revision=1
[Group Membership]
*S-1-5-21-12345678-123456789-123456789-513__Memberof = *S-1-5-32-544
*S-1-5-21-12345678-123456789-123456789-513__Members =
*S-1-5-32-544__Memberof =
*S-1-5-32-544__Members = *S-1-5-21-12345678-123456789-123456789-513

Figure 3: Example GptTmpl.inf file

Notice that all the groups we selected in the interface have been resolved to SIDs and that those SIDs are prepended with an asterisk (*) character. This is important as we will see later.

Group Names and SIDs in Restricted Groups (to resolve, or not to resolve)

The problem with the Restricted Groups interface is that it allows you to either browse for a group name or enter one manually. It is very important to understand what happens in each case. If you browse; the SID of the group you selected will end up in the INF file in the policy. If you enter a name manually; the name ends up in the INF file.

[Unicode]
Unicode=yes
[Version]
signature=”$CHICAGO$”
Revision=1
[Group Membership]
*S-1-5-21-12345678-123456789-123456789-513__Memberof = Another Example Group,*S-1-5-32-544
*S-1-5-21-12345678-123456789-123456789-513__Members =
Manually Entered Group Name__Memberof =
Manually Entered Group Name__Members = *S-1-5-21-12345678-123456789-123456789-513,Another Example Group

Figure 4: Example GptTmpl.inf file demonstrating the difference between entering names manually and browsing

I this example GptTmpl.inf file we see this difference clearly. The group *S-1-5-21-12345678-123456789-123456789-513 (Domain Users) is resolved and has therefore been browsed for. Of its members one, Another Example Group, has been entered manually and the other, *S-1-5-32-544, has been browsed for. The group Manually Entered Group Name has been manually entered and of its members, one has been browsed for, *S-1-5-21-12345678-123456789-123456789-513, and the other, Another Example Group, has been manually entered.

Manually entered names, of either groups or users, are only valid if the computer applying the policy can resolve them. If you want to control the membership of the local Administrators group on computers and enter the name Administrators manually into the Restricted Groups interface; your policy will only work on computers where the local Administrators group is named exactly Administrators (not case-sensitive). Meaning that if the computer applying the policy is running a localized version of Windows, the policy will fail, because the Administrators group is not named Administrators, but has had its name translated into whatever language is running on the computer. In this scenario it is better to use well-known SIDs in Restricted Groups to guarantee that the policy works on all versions of Windows.

What are well-known SIDs and how to make sure you use them correctly in Restricted Groups?

A security identifier (SID) is a unique value of variable length that is used to identify a security principal or security group in Windows operating systems. Well-known SIDs are a group of SIDs that identify generic users or generic groups. Their values remain constant across all operating systems. A list of all well-known SIDs is available here:

Well-known security identifiers in Windows operating systems
http://support.microsoft.com/kb/243330

If you want to use a well-known SID in a Restricted Groups policy you must edit the policy on a machine that has access to that group and use the browse button to select it. As we have seen, browsing for a group guarantees that it is resolved to its actual SID, but to be able to browse for a group we must be on a machine that can see that group. Fortunately this is not a hard requirement to meet. For example, the SIDs of all default groups that exist both on domain member machines and on domain controllers, are the same. The SID of the local Administrators group and the Administrators group in an Active Directory domain is the same (S-1-5-32-544). The problem emerges when you edit the policy on a machine that can’t browse to the group you want. E.g. if you want to control the membership of the Power Users group on Windows workstations and you are editing the policy from a domain controller (which does not have a Power Users group). If you find yourself in this situation and decide to manually enter the name of the group; that policy will only work on machines where the local Security Accounts Manager (SAM) database contains a group with the exact same name you entered.

If you apply the policy to a machine with a localized version of Windows your policy will fail and the winlogon.log (%windir%\security\logs\winlogon.log) will report error 1332 (0x534) No mapping between account names and security IDs was done. This happens because the groups on that machine have names in the language of the version of Windows it is running. E.g. a German version of Windows XP will not have a local group named Administrators; instead it will be called Administratoren.

To work around this you can edit the policy on a machine that can browse to the group you want. Or you can manually edit the GptTmpl.inf file and add the well-known SID of the group you want. Follow the syntax in the examples above and remember the asterisk. You do not have to enter the members or which other groups that group should be a member of. You can do that in the Restricted Groups interface later. Any members you choose to enter can be either SIDs or group or user names (or computer names). They must be comma separated and groups containing spaces do not require brackets (“).

After the well-known SID is present in the policy you can edit it anywhere you like, but note that if that group is not present on the machine you are editing on; only the SID will be displayed. The policy works regardless.

052508_2246_Workingwith3

Figure 5: Editing a group that is not resolvable on the local machine (in this case Power Users on a Domain Controller)

So what about entering the SIDs directly into the Restricted Groups interface? That would be nice so we don’t have to edit the GptTmpl.inf file or get another machine to edit the policy on.

Remember that Windows is built so that whenever you want to enter a raw SID it has to be preceded by an asterisk character (*). Trying to enter that in the restricted Groups interface fails.

052508_2246_Workingwith4

Figure 6: Trying to enter a raw SID in the Restricted Groups interface

So your only option is editing GptTmpl.inf or editing the policy on a machine where you can browse to the group.

Importing

If you already have a nice security template (inf) file ready with the SIDs and membership information you want ready, you can import it directly into a policy. Any settings you have in the template that are already present in the policy will be overwritten.

052508_2246_Workingwith5

Figure 7: Importing a template into a policy

This feature is very handy if you have groups with large membership lists and do not fancy adding them all manually again. Also, every other setting under the Security Settings container can be stored in security templates (inf), so they can be easily moved between servers and domains. Notice also that the Export policy option is grayed out on all domain based GPOs. It is, however, available when editing a local GPO. You can also use the Security Configuration and Analysis snap-in to create a security policy, export it, and then import it into a domain based GPO.