Best Practices for LDAP Client Applications
Table of Contents
- 1. LDAP Authorization and Populations
- 2. Public Attributes
- 3. Private Attributes
- 4. LDAP Searching
- 5. Example Search Filters
- 6. Use Secure Connections
- 7. Reuse Connections
- 8. Use Paged Searches
- 9. Apply Resource Limits
- 10. Request Only What You Need
- 11. Use Specific Filters
- 12. Use Indexed Searches
- 13. Query Server Capabilities
- 14. Trust Result Codes
- 15. Avoid Server-Side Sorting
- 16. Check Result Codes
- 17. Indexed Properties (Appendix)
- 18. LDAP Developer Notes
- 19. Resources
1. LDAP Authorization and Populations
If access to a service should be limited to a particular population, LDAP contains both public and private fields (LDAP attributes) that can be used to identify that population. Access to any LDAP attributes require a privileged LDAP bind.
LDAP is divided into several containers called Organizational Units (OUs). Active employees, students, and affiliates, as well as those who are expired but are still within their grace period, are in the People OU. There is also a PreSIR People OU for admitted students, an ADVCON People OU for alumni, and an Expired People OU for those with no active affiliation.
2. Public Attributes
berkeleyEduTestIDFlag: contains true if the record is a test record.berkeleyEduAffiliations: a multivalued attribute that contains which affiliations a person has and whether or not any have expired.departmentNumber: contains the department code listed in UCPath.
3. Private Attributes
berkeleyEduEmpApptType: staff, faculty, or student employee.berkeleyEduEmpTitleCode: job category code.berkeleyEduStuMajorCode: student major.berkeleyEduStuRegStatCode: registration status.
4. LDAP Searching
The search base for many searches will be ou=people,dc=berkeley,dc=edu. If you need to search all OUs, the base should be dc=berkeley,dc=edu, though this will take longer.
5. Example LDAP Search Filter Expressions
| Search Objective | LDAP Filter Expression |
|---|---|
| All active employees | (&(objectclass=person)(!(berkeleyEduTestIDFlag=true))(berkeleyEduAffiliations=EMPLOYEE-TYPE-*)(!(berkeleyeduAffiliations=EMPLOYEE-STATUS-EXPIRED))) |
6. Use Secure Connections
Always use secure connections (LDAPS port 636 or StartTLS port 389). See LDAP Client Examples on GitHub.
7. Reuse Connections
LDAP is stateful. Your application should reuse connections via connection pooling to reduce overhead and server load.
8. Use Paged Searches
CalNet LDAP has a server-side limit of 1000 entries per request. Use the Simple Paged Result control to retrieve larger result sets.
9. Apply Resource Limits
Use --sizeLimit and --timeLimit to avoid overusing server resources, especially with user-generated input.
10. Request Only What You Need
Request specific attributes (e.g., uid, givenName) rather than using a wildcard ("*").
11. Use Specific LDAP Filters
Prefer equality filters over substring filters. Combine & with ! to restrict potential result sets early.
12. Use Indexed Searches
The CalNet directory currently allows unindexed searches, but this may change. Work with the CalNet team if you require a new index.
13. Ask the Directory Server What It Supports
Query the root DSE for namingContexts and supported features rather than hard-coding configurations.
14. Trust Result Codes
If you receive ResultCode.SUCCESS, the operation was successful; do not immediately re-query the server to verify.
15. Avoid Server-Side Sorting
Server-side sorting is resource-intensive. Sort data within your application whenever possible.
16. Check Result Codes
Always log and evaluate result codes to determine the appropriate application action.
17. Indexed Properties (Appendix)
aci: equality, presenceberkeleyEduAffID: equality, presenceuid: equality
18. LDAP Developer Notes
The OpenDJ test environment is reached at ldap-test.berkeley.edu (Ports 389/636). Production is at ldap.berkeley.edu.
Historical Context: April 2013 Consolidation
In April 2013, CalNet consolidated multiple LDAP entries for the same person into a single entry. As part of this "LDAP Simplification" project:
- The
uidattribute was changed from a unique number to the user's CalNet ID (Kerberos Principal String). - The previous numeric UID was moved to the
berkeleyEduCalNetUIDattribute. - Developers should ensure their applications are using
uidas the primary login identifier andberkeleyEduCalNetUIDif they require the legacy numeric identifier.
19. Resources
Please send any questions and comments to CalNet Support at calnet-admin@berkeley.edu.