Caveats with using LDAP Referrals in RSA Identity Governance and Lifecycle
Originally Published: 2015-10-29
Article Number
Applies To
RSA Version/Condition: All
Issue
Checking this box disables LDAP referrals. When should this box be checked and when should it be left unchecked?
Resolution
Referrals for Active Directory (AD) is a complicated subject. Remember that foremost AD is a proprietary datastore with an LDAP interface. Since it supports LDAP, AD must support LDAP referrals but that does not mean that leveraging referrals is the recommended method for accessing users in other AD domains.
If LDAP referrals are disabled (i.e. check the box), then LDAP bind will only return the users from the domain controller that you bind to. That is typically what you want for a small infrastructure.
For a larger infrastructure with multiple domains you typically want to use a Global Catalog (GC) bind that returns all of the users from the forest. For a GC bind, the recommendation is to also disable referrals. By far, a GC bind is orders of magnitude faster when retrieving a user than an LDAP referral.
If you are not using a Global Catalog, and you want to return users from multiple domains, then you must use referrals. This is the only time you should enable referrals. You should expect a performance hit when hitting remote domains.
Note there are hidden dangers to enabling referrals on the client without knowing why. The ability to follow referrals is controlled by settings on both the client and the server. Even if you have the client enabled to follow referrals, that does not occur unless the server currently has referrals. You can get into problems if later on, even if not on purpose the server starts serving referrals. This can not only cause performance problems but can cause the datatstore to start returning users you did not expect. So, our recommendation is, that even if you are not using referrals or planning to, or if you do not know what referrals are, you should proactively disable them.
Also note that the way referrals are commonly described is not exactly how it typically works. The implication is that when an object does not exist in the primary server a referral will be given to the server where it DOES exist. What actually occurs is that if the search fails, a referral is provided to an LDAP server where it MAY exist, and that may generate another referral. Each referral requires a new connection (and even a DNS lookup) so following referrals can get very expensive. This is a real problem if the object you are searching for does not exist because it may cause an exhaustive search of all the referrals before a negative result is returned. This can be the cause of some elusive performance issues.
