I recently had to assist a client with GPO development for applying various registry keys using LDAP filters for Group Policy Preferences targeting. A lack of information on the web about actually implementing LDAP filters led to this post. Microsoft’s own documentation on the topic is rather lacking, you can find it here. Hopefully the techniques I used will be helpful to others looking to do the same.
Background:
A client needed to apply Current User registry keys only to users with mailboxes running on Exchange 2010 as part of their Exchange 2003 to Exchange 2010 migration. Group Policy Preferences (“GPP”) targeting does not support powershell queries so I had to come up with another method of selecting only users with mailboxes on 2010 using the tools available in GPP targeting.
Solution:
It turns out the easiest way to determine if a user is on Exchange 2010, without using powershell, is by an LDAP query against the “msExchVersion” attribute on the user object in Active Directory. Microsoft increments this value with every version of Exchange. The value of an Exchange 2010 mailbox is “44220983382016” which correlates to “0.10 (14.0.100.0)” as the ExchangeVersion value from the “get-mailbox USERNAME | Select Name,ExchangeVersion” Exchange powershell command. Using an LDAP query I should be able to target specific group policy settings only to users with mailboxes on Exchange 2010.
Implementation:
This was the tricky part. Building a valid LDAP query and getting it to work with GPP was difficult because I am not an LDAP guru. Below are the steps I followed:
Building the LDAP query wasn’t as bad as I thought it would be. I found some handy posts about using “Search Folders” in the Active Directory Users & Computer Snap-in to build a query.
Open Active Directory Users and Computers and Right Click on the “Saved Queries” node, Select New, and Select Query as shown below.
In the New Query window, type in the name and description and then click on the Define Query button.
This brings up the Query builder wizard. We want to create a custom query. This will give us a clean LDAP filter to use. Click the Find drop down menu and select Custom Search.
Now we need to select some fields for our query. Select the Fields dropdown and then select User options. Now we can pick from most of the attributes the Active Directory Users and Computers snap-in is aware of. Unfortunately the MsExchVersion is not displayed so we will have to select another value and manually change the query down the road. For the time being I selected DistinguishedName.
I also select LogonName, for the time being to be added to the query as well, to limit the query to certain usernames. Eventually, I switched to the sAMAccountName value. Either way works, you’ll have to decide what is best for your environment. I also filled in temporary “VALUES” that I replaced later. Once finished, click OK.
Now you should have a query displayed in the “New Search” window. This is the filter we will use, with slight modification, in the GPP targeting configuration. Copy out the query and paste it into Notepad.
Looking at this LDAP filter, we can see what is happening. The filter is limited to User objects with the distinguishedName ‘TEMP’ and the userPrincipalName ‘TEMPUSER*’
(&(objectCategory=user)(objectClass=user)(distinguishedName=TEMP)(userPrincipalName=TEMPUSER*))
Now let’s modify the query with the values we want to use. Below is what I had as a test query:
(&(objectCategory=user)(objectClass=user)(msExchVersion=44220983382016)(sAMAccountName=DMaloney*))
This will look for user account, with Exchange 2010 mailboxes, and the SAM account with my username. If you edit the Search Query you can paste in the modified Query in the Advanced window. Afterwards save and close the query.
Afterwards you should be able to Refresh (“F5”) the newly created Search Query and see if you have any user accounts in the right hand screen. If you do, then you have a good query.
Now let’s edit our GPP targeting settings. Below is a screen shot of the first settings that I implemented into the filter. Notice the filter will apply only if the LDAP query “returns a value”. I also put in the %USERNAME% so that the query will return a value IF the mailbox is on 2010 and the current username returns as a value. Ensuring the username value is part of the query is important, otherwise, the query will return all mailboxes on 2010 and will always have a result. The Username addition limits the query to the currently logged on user.
The binding value is autmatically set to the default LDAP: and the Attribute value can be left blank.
Now that the LDAP targeting object is set, be sure to set the GPP option “Run in logged-in user’s security context” to “Enabled”. This will ensure the %USERNAME% variable used is actually that of the logged on user.
Results:
Now if you test out the setting you put in place, whether it is a registry key or file, will not be made. I found this out through a few hours of testing, the %USERNAME% variable is not available in LDAP queries. Insead, while in the query configuration window, hit F3 to see the GPP variables and use the %LogonUser% variable.
So my final working query was as follows:
(&(objectCategory=user)(objectClass=user)(msExchVersion=44220983382016)(sAMAccountName=%LogonUser%))
Hopefully this helps you implement LDAP filtering in your environment. Once you know the attributes on which to base your query, implementing the LDAP filter in GPP is relatively straight forward.
UPDATE: I used this exact LDAP filter at a client and was seeing some successful results and some failed results. After a few hours troubleshooting I paired down the filter to the bare bones. I also switched from quering the sAMAccountName value to userPrincipalName. SAMAccountName is the legacy logon name for users. The userPrincipalName (UPN) is the new logon name in FQDN format such as username@domainname.local. In order to make the filter work I used a wildcard since %LogonUser% variables are set to just the USERNAME. This provided much more reliable results.
Updated Filter:
(&(&(msExchVersion=44220983382016)(userPrincipalName=%LogonUser%*)))