Video Screencast Help

directory sync with Windows 2003 DC

Created: 03 Apr 2011 | 5 comments


Just a quick question about directory sync.

I created a group and define group' s membership via attribute: "memberof" and value: "CN=istgrup,OU=IST,DC=acar,DC=com"

Correct policy assigned users in the group, it works.

But when I define membership via attriute: "OU" and value: "OU=IST,DC=acar,DC=com" client has got everyone policy - not defined one.

And then I test with  membership via attriute: "DN" and value: "CN=testuser,OU=IST USERS,OU=IST,DC=acar,DC=com" client has got everyone policy again - not defined one.

Group memberships work with groups but not OU or users. Any idea???


Comments 5 CommentsJump to latest comment

Andreas Zengel's picture


please note that OU is not an ttribute in the Active Directory. If you want to match group membership based on an OU you need to perform a regular expression match on the attribute named 'distinguishedName

This also explains the second issue you are seeing when trying to match to the non-existing attribute 'DN', this attribute is named 'distinguishedName' and if you change the attribute name to match a single user to 'distinguishedName' then it will work.

On Windows Active Directory you can also use the attribute 'samAccoutname' to match against a user's login name (e.g. ajones or bob)

see for more detail

korhan's picture


I tried the two ways.

For USER and OU I defined membership via attiribute: "distinguishedName"  and "samAccoutname"  I marked to regular expression. Client has got everyone policy again. It does not work. Im sending  pictures of configurations.


Andreas Zengel's picture


lets take an example. In a domain, named '' a user named 'Alice Jones', logs on to the computer using the username 'ajones'. She is also a member of a group named 'Human Ressources', which has the distinguishedName 'CN=Human Resources,OU=Groups,OU=SenderDomain,DC=senderdomain,DC=com'. Her user object in Active Directory is in an Organizational Unit named "HR" which is below another OU named 'SenderDomain'.

This user then has the following attributes in LDAP:

distinguishedName : 'CN=Alice Jones,OU=HR,OU=SenderDomain,DC=senderdomain,DC=com'
sAMAccountName : '  ajones' 
memberOf : 'CN=Human Resources,OU=Groups,OU=SenderDomain,DC=senderdomain,DC=com'
userPrincipalName :
name : Alice Jones
cn : Alice Jones
givenName: Alice
sn: Jones

So let's match her into a PGP Universal Server group.

1. Match by user name only, chose one of the following:

  • Attribute 'sAMAccountName ' - Value 'ajones'
    Regular Expression: no
  • Attribute 'userPrincipalName' - Value ''
    Regular Expression: no
  • Attribute 'distinguishedName' - Value 'CN=Alice Jones,OU=HR,OU=SenderDomain,DC=senderdomain,DC=com'
    Regular Expression: no

2. Match by group membership, all users in the group 'Human Resources' should be matched:

  • Attribute 'memberOf' - Value: 'CN=Human Resources,OU=Groups,OU=SenderDomain,DC=senderdomain,DC=com'
    Regular Expression: no

3. Match by OU, all users in the OUs SenderDomain and HR should be matched

  • Attribute '' - Value '.*,OU=HR,OU=SenderDomain,DC=senderdomain,DC=com'
    Regular Expression: yes

You might want to have a look at the following page which explains how Active Directory properties are shown as LDAP attributes:

Also check out Softerra's LDAP browser, that allows you to browse your Active Directory through LDAP and see what attributes belong to which users.


paulhen's picture

There are a couple of things that I have found most helpful when tryiing to configure grouping rules based on information in LDAP (whether Active Directory or not). The first is to get the ldif for the user (or for a sample user.) This can be done using tools like ldapsearch from a unix or linux machine or Softerra's LDAP browser. Most open LDAP services also provide a way for you to obtain/see this information. In contrast AD does not have a simple, direct tool for seeing this. (At least not that I know of.) It does however, have the dsquery command line tool. We have a knowledge base article which discusses how to use dsquery to obtain usable syntax for BaseDNs and BindDNs. You can also use the tool to pull information for a user so you can see which groups and/or OUs will match.

While LDAP queries are supposed to be case insensitive, I have found that there are less problems when the casing on the attribute entered in the PGP Universal server is an exact match to the casing in AD. I have seen memberOf work when memberof did not (with the same information in the value field).

 Governments keep a lot of secrets from their people . . . Why aren't the people in return allowed to keep secrets from the government? --Philip Zimmerman, Der Spiegel

debugme's picture


in your Universal Server, in Consumers -> Directory Synchronization, what BaseDN did you take? if your group is in the OU OU=IST,DC=acar,DC=com, your user in OU=xxx,DC=acar,DC=com and your BaseDN is OU=IST,DC=acar,DC=com, Universal Server would not find any users matching the group. Thats because the user objects are not under the OU IST, and the US cannot connect the member attributes of the group to user objects, it cannot find it under OU=IST,DC=acar,DC=com

maybe thats your problem?