Information technology tools and resources at the UW
LDAP Authentication Configuration for NETID domain
If you are unfamiliar with LDAP authentication, you may want to first read the document ‘LDAP Authentication Primer’. You’ll find a link to it on the right.
This document first discusses design issues, then goes over common configuration settings you may need to implement.
Using the NETID domain via LDAP as the Authentication Mechanism for your Network Application
Many network applications provide authentication plug-ins for Active Directory, and you may want to use such a plug-in to integrate your application’s authentication with the UW NetID system. In other words, you’ll have clients connecting to your network application, providing credentials that are in turn authenticated for your application by the NETID domain.
If so, you’ll want to keep in mind a few things:
- There may be other, better ways to integrate with the UW NetID system. If appropriate, consider Shibboleth or ADFS.
- Choose the best authentication method supported by your application.
- Use session-level encryption to provide extra protection for passwords and directory information passed between your application and the NETID domain.
- Consider what the NETID directory information your application might need to consume, and if that directory information is sensitive (e.g. FERPA-related), then you’ll need to make sure you have adequate authorization to re-use that information.
Each of these items is addressed by the sections which follow.
UW NetID Integration and Authentication Methods
If your network application is web-based and doesn’t rely on authorization provided by the Windows platform, then it’s most likely that Shibboleth or ADFS will be a better way to integrate with the UW NetID system.
Additionally, the NETID domain is hosted on p172, so LDAP authentication is only an option for on-campus hosts, or via hosts using a VPN to the campus network.
For the purposes of LDAP authentication, the NETID domain supports AND recommends only two authentication methods:
- Simple Authentication Method, using the Name/Password Authentication Mechanism of Simple Bind, having first initiated session-level encryption
- SASL Authentication Method, using the GSSAPI Authentication Mechanism, employing Kerberos or NTLMv2
You should use the strongest possible method and mechanism supported by your operating system and application.
Connecting to the NETID domain
You’ll first need to connect to the NETID domain, using LDAPS.
Session-level encryption ensures that whatever data is passed, including password or other secrets, is encrypted. There are two general ways to achieve session-level encryption.
LDAPS is encrypted LDAP. There are two general ways that LDAPS is implemented. One approach has the client connecting, then at some point after the connection is established the client issues a StartTLS command to transition from LDAP to LDAPS. Another approach has the client connecting to a port that only supports encrypted sessions. Active Directory only supports the latter approach–to do LDAPS with Active Directory you must connect to the port 636. Most applications will hide this level of detail, and you simply configure the connection information to specify connecting to port 636, instead of the default port 389.
To use LDAPS with the NETID domain, you’ll first need to ensure that you have the UW CA certificate installed as a trusted CA on your client(s). the NETID domain’s certificates are signed by the UW CA. Then configure the connection information on your application to be:
hostname: netid.washington.edu port: 636
Additionally, some applications may ask whether they should use SSL. You should indicate yes.
Some applications don’t support LDAPS. An alternative option to achieving session-level encryption would be to employ ipsec. Properly configuring ipsec is outside the bounds of this document, so you’ll need to reference your operating system’s documentation on how to configure ipsec so that you can achieve encryption on any session with the NETID domain.
Other LDAP Settings
Some applications require you to enter other LDAP settings. Here is a list of possible other settings you might need.
timeout: 120 size limit: 0 (if the application doesn’t permit 0, then use 1000000) page size: 1000 base dn: dc=netid,dc=washington,dc=edu user base dn: dc=netid,dc=washington,dc=edu group base dn: dc=netid,dc=washington,dc=edu ldap version: 3 virtual list view (vlv) support: yes chase referrals: no
Querying Directory Information
After you’ve connected to the NETID domain, you may want to query the NETID directory information for use within your application.
You may want to reference the full set of all possible NETID user attributes, or the subset of all NETID user attributes in use and centrally managed.
Not all user attributes are visible by default. You may want to reference which NETID user attributes are not commonly visible. If you’d like to make use of these attributes, then you’ll need to request additional NETID directory access.
Some applications will use a single user account to query directory information, and so you’ll need to request an application netid or a shared netid for this purpose. Some applications require such an account for authentication only.
If you re-publish any NETID directory information, then you need to treat that information carefully. Most, if not all, the user information in the NETID domain is subject to individual privacy publishing controls that may change at any time. Should the information in the NETID domain change, you would need to ensure that your information also changes.
LDAP Controls for Added Functionality
Some applications may provide support to enable optional LDAP controls which enhance the search functionality. The following controls are supported by Active Directory and recommended for use with the NETID domain if the functionality meets your needs. You may need to enter a number (an OID) to enable that functionality.
Paged search: 1.2.840.113518.104.22.1689 Get Security Descriptor: 1.2.840.113522.214.171.1241 Sorted Search Request: 1.2.840.1135126.96.36.1993 DN search: 1.2.840.1135188.8.131.524 VLV: 2.16.840.1.1137184.108.40.206
Some Final Thoughts
Your application may not be able to handle the number of objects in the NETID domain. The NETID domain has over 600,000 user objects, over 100,000 group objects, etc. If this is the case, there may be alternative configuration options which will allow your application to still function correctly.
Other portions of this website may be invaluable in helping you to identify how your application might best take advantage of the NETID domain.
Your application may want other configuration details not listed here. Please feel free to contact the UW-IT Service Center for additional assistance in configuring your LDAP based application to work with the NETID domain.