000034355 - Guide to Microsoft Active Directory LDAP synchronization with RSA Authentication Manager

Document created by RSA Customer Support Employee on Nov 30, 2016Last modified by RSA Customer Support Employee on Apr 21, 2017
Version 3Show Document
  • View in full screen mode

Article Content

Article Number000034355
Applies ToRSA Product Set: SecurID
RSA Product/Service Type: Authentication Manager
IssueThis article provides information on Microsoft Active Directory LDAP synchronization with RSA Authentication Manager.

Determining the Base DN

The base DN  is the point from where a server will search for users.
  1. Open Active Directory Users and Computers from Administrative Tools
  2. Under the machine name is a plus with a suffix next to it; e.g., [ + ] northamerica.rsasecurity.com. This would make the base DN:

  1. If you wanted to start your search from the Users container, the base DN would be:

Understanding the Scope

The base only restricts the query to the exact record of the base DN, basically allowing you to sync one record. One level restricts the query to the base DN container and will not traverse. All sublevels will search recursively beneath the base DN's container.

Creating an LDAP Query Filter

The query filter accepts RFC compliant LDAP queries. There are many different syntaxes for this.  Our implementation is based on the Sun LDAP SDK. Microsoft Active Directory uses objectcategory as an indexed attribute, which means it is very fast to use this when searching. Here are some examples:
  • To query all users in AD, use:

  • To query records of users and members of the administrators group, use:

Defining the Binding DN

The binding DN is the fully distinguished name (DN), including common name (CN), of an Active Directory user account that has privileges to search for users.  This user account must have at least domain user privileges.  For example:


For Authentication Manager, the binding DN is the user that will be used to connect and run the query against AD. The binding DN of the user can be written one of two ways:



  1. Active Directory has a default limit called Maximum Page Size, to the amount of records it is willing to return:
  • Windows Server 2000 and 2003 has a 1,000 record limit.
  • Windows Server 2003 has a 1,500 record limit.
  • Windows Server 2008 has a 5,000 record limit.
  • Windows Server 2012 has a 5,000 record limit.
  • If you are trying to manage more than the above number of users, you have two options:
    • Split your single query into multiple queries, where each one only retrieves usernames that begin with certain letters (A - M and N - Z, for example or perhaps A - C, D - F, G - I, J - M, N - P, Q - S, T - Z for a very large organization), or
    • Use the Ntdsutil to change the limit in Active Directory.  Ntdsutil.exe is a command-line tool that provides management facilities for Active Directory Domain Services (AD DS) and Active Directory Lightweight Directory Services (AD LDS).
  • Both of the above solutions are covered in more depth in article 000025756 (How to write LDAP query filter in RSA authentication Manager for an LDAP Synchronization job).
  1. RSA can not traverse referrals; that is, if the AD doesn't hold all the users and refers the query to check additional servers. You can make the query force the server to traverse the whole AD forest by changing your query port from 389 to 3268.
  2. To resolve performance issues, such as the speed at which query results are returned, try the following tips:
  • Use a more specific base DN to search fewer folders,
  • Use more attributes to match in your query to limit the amount of records searched, or
  • Use global catalog port 3268 TCP, which is given a higher priority from AD than 389 TCP, the default LDAP port.
  1. If the number of records returned does not seem correct, please be aware that for Authentication Manager to import a user record, the record must have a value for both sn and samAccountName, if the record is missing these attributes, it will be omitted from the search results.

Query Building

A useful tool for building queries is the Sun LDAP SDK which includes the ldapsearch tool.  This utility is installed automatically on many Solaris 9 or Solaris 10 machines.
This utility allows you to test your query, without actually making any changes to the Authentication Manager.

The syntax for ldapsearch is:

ldapsearch -h <host name of domain controller> -D <binding DN> -w <password for binding DN user> -b <base DN> -s sub <sublevels> 


          -h = Hostname of domain controller
          -D  = Binding DN user
          -w = Binding DN user's password
          -b = Base DN (see above on how to determine BaseDN)
          -s sub = Sublevels for search, such as (objectcategory=person)


  • This ldapsearch will return every record for every user:
ldapsearch -h domaincontroller.northamerica.rsasecurity.com -D administrator@northamerica.rsasecurity.com 
-w password -b "dc=northamerica,dc=rsasecurity,dc=com" -s sub (objectcategory=person)

  • You can add an additional filter to scope the results. For instance, to see only relevant fields like sn, givenName, and samAccountName, run the following query: that would return information on the users' dn, sn, givenName and samAccountnName for all users included in the defined base DN.
ldapsearch -h domaincontroller.northamerica.rsasecurity.com -D administrator@northamerica.rsasecurity.com -w password 
-b "dc=northamerica,dc=rsasecurity,dc=com" -s sub (objectcategory=person) sn givenname samaccountname

  • To construct a query and retrieve all users that are in a group of which the user jdoe is a member when you do not know the memberOf syntax, run the following command:
ldapsearch -h domaincontroller.northamerica.rsasecurity.com -D administrator@northamerica.rsasecurity.com -w password 
-b "dc=northamerica,dc=rsasecurity,dc=com" -s sub (samAccountName) memberOf