Topics Map > University of Chicago > IT Services > Accounts, Identity, & Security

LDAP Authentication

This article explains a technical overview of the LDAP authentication service.


If you are running a web-based application, then you SHOULD NOT be using this service. Instead you should configure your service to use SAML2 / Shibboleth. More information is at Shibboleth Authentication Overview.

Essential Data


Port: 389 if using StartTLS, 636 with SSL

Base DN: dc=uchicago,dc=edu

Scope: subtree

Filter: (&(uid=<username>)(objectclass=inetOrgPerson))

Template: uid=<username>,ou=people,dc=uchicago,dc=edu


LDAP is a well-established technology that is used for authentication, on-line directory, and as a provider of user attributes to fuel authorization decisions or support integration needs. Many user attributes are available from LDAP. Some commonly used applications include:

  • eduPersonAffiliation: lists the user's primary affiliations with the University such as staff, faculty, student, alum, hospital, and several others
  • ChicagoID: used instead of the SSN to identify people in various University databases
  • cn: common name

See LDAP Attributes used at the University of Chicago for a complete list with definitions.

Many canned applications are billed as "LDAP-enabled". This may mean many things and often does, but need not imply that the application can authenticate using IT Services' LDAP service from - caveat emptor.

The LDAP host identified above is a load-balanced target to provide high availability for typical LDAP-reliant applications.

On-boarding and support

Identity Management provides LDAP support.

Some LDAP-enabled applications need to be issued a "service account" or "BINDDN", i.e., have their own username and password in the LDAP directory, just as users have CNetIDs. This is a custom support option.

The operator of an LDAP-enabled application may need to have their operating and security practices vetted since they'll be handling CNet passwords. IT Services may require corresponding contractual language with ASPs.

Note: Applications perform user authentication with LDAP by asking the user to enter their username and password. They use the supplied values to authenticate to the LDAP directory as the user. The way LDAP works, though, the application must first determine the location of the user's "LDAP entry". Some applications do so by first searching LDAP to find the entry matching the supplied username. Others rely on a template configuration that reflects where our operational practices put users' entries in our LDAP directory. Applications that search first can also make use of test accounts in LDAP. Since test accounts are located in a special area within the LDAP directory, applications that rely on a template approach cannot access them.

LDAP authentication moves plaintext passwords over the network. Hence, our LDAP servers are configured to refuse authentication attempts unless the connection is encrypted using either TLS or SSL. Note that an application that is not so configured will still send a plaintext password over the network, even though the authentication attempt will necessarily fail.

LDAP Lockout Policy

For users of Silver certification, there is an LDAP lockout policy. Each LDAP server is configured to block further login attempts for five (5) minutes after nine (9) incorrect login attempts in a five (5) minute period. After five minutes, the user's account will be automatically unlocked and login attempts may continue.

Keywords:chicagoid, edu.personalaffiliation, ldap-enabled, binddn, 5_after_9   Doc ID:15820
Owner:Dave L.Group:University of Chicago
Created:2010-11-29 19:00 CDTUpdated:2017-05-22 09:41 CDT
Sites:University of Chicago, University of Chicago - Sandbox
Feedback:  0   0