The following are issues, encountered by some deployers, related to specific LDAP server products used in conjunction with username/password authentication or the attribute resolvers LDAP data connector.
If all users reside under the same single-depth object (e.g.,
CN=Users,DC=example,DC=edu), the standard ports can likely be used:
Searches using the above connection information may encounter and need to handle referrals (see Referrals below).
If users are spread across multiple object (e.g.,
CN=Faculty,DC=example,DC=edu) or if the standard connection method (above) doesn't work, the global catalog ports can be used:
As a general note, the global catalog supports searches across the entire forest. Attributes that should be accessible to the Shibboleth IdP will have to be specified as part of the Partial Attribute Set (PAS) in Active Directory.
Active Directory authenticates users against its internal Kerberos realm. Therefore the principal name used for the
bindDn configuration option should be a Kerberos principal name,
user@domain, not a DN,
When performing a standard LDAP search on port 389/636, under some circumstances Active Directory will return LDAP referrals as a part of the LDAP result set. For example, this is known to occur when when using a domain DN as the LDAP search base (e.g.
dc=example, dc=org) as opposed to a lower level container (e.g.
cn=Users,dc=example,dc=org). These referrals must be followed for successful completion of the query by the connector. This entails adding a configuration parameter to the LDAP data connector configuration:
<LDAPProperty name="java.naming.referral" value="follow"/>
The default value of
Note that the referrals themselves often contain LDAP server hostnames which differ from the original Active Directory LDAP server (domain controller) hostname. These hostnames must be resolveable via DNS in order for successful resolution. The referral service port must also be reachable via the network through firewalls, etc. If these conditions don't hold, a connection error will result, possibly reflected by either a javax.naming.CommunicationException or a java.net.UnknownHostException error message in the IdP log. In this case there are 2 options:
ldapsearchto perform the same LDAP query as the data connector, with the appropriate verbose output option to display the actual referral(s) that are being returned. In test environments or other environments where Microsoft DNS is not being used, it often turns out that the LDAP server hostname returned is not available to the IdP via DNS.
Some deployments attempt to use the
objectGUID attributes and either release them directly or use them as a dependency in other attributes, such as persistent identifiers. Microsoft's documentation on these attributes is contradictory as to the type of the values of these attributes. Part of the documentation claims the values are binary (e.g. byte arrays) while another part claims the values are strings. If you are using these attribute and your Active Directory server treats these values a binary content you must configure the appropriate LDAP property to indicate that the values of these attributes are, in fact, binary data.
Failure to set this, in the case where these are binary values, is likely to cause the same 'unique' value to be returned for multiple accounts.
It is difficult to get definitive statements about StartTLSsupport in Windows Server operating systems
This summary by no means covers all of the potential issues with using Sun DirectoryServer. This page describes the issues which were encountered during the upgrade from DirectoryServer 5.2 to DirectoryServer 6.3. Several issues caused service outages and had to be fixed before Shibboleth could continuously access the directory data without encountering occasional pauses.
DirectoryServer 6.3 has a bug which causes a 10x increase in the amount of time required to instantiate the StartTLS portion of a port 389 LDAP connection. Sun has a hotfix available for this issue (link to be added...).
There is another bug, for which there is no hotfix as of this writing, which causes the LDAP server to "freak out" when it encounters a large number of connections suddenly made stale. This can happen for instance when a loadbalancer reaches a timeout and cuts off a large number of connections from various sources.
Shibboleth IdP 2.1 creates a new connection for every authentication request and leaves it open until garbage collection. This is soon to be fixed in an upgraded LDAP library, but prior to the fix, the problem is definitely noticeable. This, perhaps combined with other misbehaved applications, can result in large numbers of connections timed out at the same time. When this happens, the LDAP server takes a break to clean out all of these broken connections. Delays of 8 solid minutes of outage have been observed where hundreds of connections were being cleaned out.
The solution for this issue, at least prior to the fix from Sun, is to enable the idle timeout in the LDAP server. This idle timeout should be shorter than other timeouts on the connection path such as those configured in a loadbalancer. When the connections are closed by the LDAP server, large numbers of connections can be timed out simultaneously within a second.
This bug is described in the sun forums here: http://forums.sun.com/thread.jspa?threadID=5322201
These changes were applied at USC and resulted in a 4x improvement in the use of DirectoryServer 5.2:
- Added "nsslapd-searchtune=57" to dse.ldif
- Applied a hotfix for bug 6508188
- Added "nsslapd-dncachesize: 350000" to dse.ldif