Category Archives: Active Directory

How to use the whenCreated and whenChanged attributes to search for objects in Active Directory

Sometimes it is useful to be able to search for objects in Active Directory based on when they were created or changed, or both. The two attributes that hold this information are whenCreated and whenChanged, and they are present on all AD objects.
You use these two attributes like any other in you LDAP queries, the only thing to watch is the syntax of the date/time value. The syntax of both attributes is like this:
YYYY MM DD HH mm ss.s Z
2008 08 12 00 00 00.0 Z
(The capital Z at the end is mandatory and denotes Zulu time, which is the same as GMT.)
So to search for all users created on or after 12 August 2008 you use this query:
(&(objectClass=User)(whenChanged>=20080812000000.0Z))

Availability of the Group Policy Hide drives calculator and associated template

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).

DCPROMO install problem

Trying to install a new child domain in an existing forest I received this error from DCPROMO:
—————————
Active Directory Installation Wizard
—————————
The wizard cannot gain access to the list of domains in the forest.
This condition may be caused by a DNS lookup problem. For information about troubleshooting common DNS lookup problems, please see the following Microsoft Web site: http://go.microsoft.com/fwlink/?LinkId=5171
The error is:
The RPC server is unavailable.
A trace of the network traffic during the dcpromo process revealed a connection attempt from the local computer to one of the DCs in the root domain using the computername and username of the local computer. This of course fails since the local computer is to become the first domain controller in the new child domain and thus is in a workgroup. I could not see exactly what the local server was trying to connect to, so I started authenticating to the most common ones: IPC$, C$ and ADMIN$. Turns out it was ADMIN$ and after I ran this command, I was able to continue the dcpromo process:
net use \<name of DC in root domain>admin$ /user:<root domain><administrator in root domain>
Just as dcpromo was starting (after the summary screen) I received another error:
Managing the network session with \<name of DC in root domain> failed
“Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again.”
Dcpromo failed after this.
I restarted dcpromo and ran it all the way up to the summary screen. Before I hit Finish I ran this command to delete all connections to remote servers:
net use * /delete
Dcpromo could now successfully complete.
The Dcpromo log was also valuable in troubleshooting this, it can be found in %systemroot%debug.

Working with Group Policy Restricted Groups policies

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.

DS Inconsistency?

DCDiag (included in Windows Server 2003 Support Tools) reported a stange error at a site the other day:
C:>dcdiag
Domain Controller Diagnosis
Performing initial setup:
***ERROR: There is an inconsistency in the DS, suggest you run dcdiag in a few moments, perhaps on a different DC.
This was accompanied by the following event in the Directory Services log on all DCs in the forest:
EntryType          : Error
EventID            : 1550
Message            : The following site has no NTDS Site Settings child object.
Site: CN=SITE1,CN=Sites,CN=Configuration,DC=domain,DC=com
User Action
Create an NTDS Site Settings object for this site using Active Directory Sites and Services.
Category           : Knowledge Consistency Checker
CategoryNumber     : 1
ReplacementStrings : {CN=SITE1,CN=Sites,CN=Configuration,DC=domain,DC=com}
Source             : NTDS KCC
TimeGenerated      : 11/28/2007 5:41:06 PM
TimeWritten        : 11/28/2007 5:41:06 PM
UserName           : NT AUTHORITYANONYMOUS LOGON
Sure enough, the NTDS Site Settings and, altough not reported in the log, the License Site Settings object were missing from the site. After I recreated them and replicated the forest, DCDiag ran successfully and the messages in the Event log dissapeared.
As a footnote, the missing NTDS Site Settings object also resulted in the site not having an ISTG server and thus not being able to create inter-site replication objects. The site could only replicate with the other sites because of the existing connection objects, new objects could not be created.

Requesting Web Server certificates from an Enterprise CA

One of the things I have never been able to figure out, is why you cannot request a certificate based on the Web Server template from a Windows Enterprise CA when you are using the CA web pages (<servername>/CertSrv). Ever since Windows 2000 I have occationally stumbeled on this problem but never had time to really investigate it. I still have not found out why the Web Server template is unavailabe, but I have found a workaround.
By using the certreq.exe utility you can successfully request and receive a certificate from an Enterprise CA. The command you use is:
certreq -submit -attrib “CertificateTemplate:WebServer” <request_file>
The request file is any text file (.cer, .req etc.) that contains the Base64 encoded certificate request generated by your server. Typically a web server. When you run this command you are prompted to select the CA from which you would like to request the certificate and the name of the file in which to save the issued certificate. You can also specify these options on the command line.
Since this works, the problem must lie in the CA web pages. If anyone has an explanations as to what may be the problem I would be very interested.
The reason that I went a little further in trying to crack this problem this time, was that I was setting up my Virtual Server host and was unable to get a certificate for the Virtual Machine Remote Console (VMRC). The administration web pages for Virtual Server cannot send a certificate request directly to an online CA, but rather have to generate a Base64 encoded request which you have to submit to your CA manually and then upload the issued certificate to Virtual Server. Using the above command I was finally able to get a certificate. For those of you wondering; no you cannot use one of the certificates that the computer running Virtual Server has in its certificate store. Virtual Server runs under the Network Serivce account which does not have access to those certificates. Some more information about the exact reason for this is availabe here:
Finally, the SSL certificate for the Virtual Server administration site itself can be retreived in IIS using the request new certificate option.

Returning Search Statistics from Active Directory

When you search Active Directory you have the option of asking the server to return search statistics for your query. This is done by adding an LDAP control to your query. The control is 1.2.840.113556.1.4.970. I was using LDP to test this out on my test forest. The forest runs Windows Server 2003 DCs and I use the W2K3 version of the Active Directory Administration Tool; LDP. In that version of LDP it is very easy to add the required LDAP control to the search, you just select it from a drop-down box from the Search Controls dialog.

I specifically wanted to see the expanded queries that the server extrapolates when using ANR searches, or LDAP Display Names in objectCategory searches. But to my surprise, the server never returned any statistics. I always got the same standard output; the result of my search and nothing more. After a little investigation I found the following text on the MSDN site:

To retrieve all of the above information [search statistics], the account that issues the LDAP request should have debug privileges in its token.

I remembered having tested PWDUMP on that particular server. PWDUMP requires the debug privilege to work. I had removed that from the Administrators group to test something with PWDUMP. When I gave it back and logged off and on again i could successfully see the search statistics from the domain controller.

Nice!

Linked attributes in Active Directory

In Active Directory there is something called linked attributes. They exist in pairs, consisting of a forward-link and a back-link. The linked attribute pair member, of Group objects, and memberOf, of User or Groups is an example. In this particular case member is the forward-link and memberOf is the back-link. Back-links are always calculated automatically by the system whenever an attribute that is a forward-link is modified. If you change the member attribute of a group and add another object, the groups DN is automatically added to the memberOf attribute of the object you added.

I wanted to find out a little more about how this worked so I created a couple of scripts to do some testing. Specifically I wanted to see if I could write directly to a back-link attribute.

The first script tried to do that. It connected to an object in the directory and tried to write the DN of a group into the memberOf attribute. That failed with the error:

Code: 80072035
Error: The server is unwilling to process the request.

The next script connected to a group and added a user to it. As expected, that worked. I examined the user I added to the group in ADSI Edit and the back-link memberOf had been correctly computed. From that I can draw the conclusion that the computing of back-links is implemented in the DSA itself and not in the Admin tools (I was using a script, not ADUC, remember).

Next, I tried to edit the memberOf attribute of the user I had just added to the group directly in ADSI Edit. That provided the last piece of the puzzle and a conclusive answer to my question. Because that failed with the following error:

Access to the attribute is not permitted because the attribute is owned by the Security Accounts Manager (SAM).

So that was it. You cannot write to the back-link of a linked attribute pair. The back link is always automatically calculated and added by the system.

Also, the calculation and updating of a back-link attribute does not qualify as a change of the object. When I added a user to a group, only the group’s whenChanged attribute was updated. The user’s remained unchanged. That means that it is always the group object that is modified when you add a user to it. This seems obvious, but consider that you can also do this from the user’s properties on the Member Of tab. What you are actually doing is editing the group object, not the user.

Ain’t Active Directory fun!