How to Configure LDAP so your Application Works with UWWI

If you are unfamiliar with LDAP authentication, we recommend you first read the document 'How LDAP Authentication works with Active Directory and UWWI'. 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 UWWI 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 UWWI.

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, Pubcookie, or Kerberos (u.washington.edu).
•  Choose the best authentication method supported by your application.
• Carefully consider using session-level encryption to provide extra protection for passwords and directory information passed between your application and UWWI.
• Consider what UWWI 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 Pubcookie or Shibboleth will be a better way to integrate with the UW NetID system.

Additionally, UWWI 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, UWWI 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, NTLMv2, or NTLM

You should use the strongest possible method and mechanism supported by your operating system and application.

Connecting to UWWI

You'll first need to connect to UWWI, using either LDAP or LDAPS.

Session-Level Encryption

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. In applications that support elemental LDAP operations, to employ LDAPS you first connect to the LDAP directory, then issue a StartTLS command, then finally bind. However, 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 UWWI, you'll first need to ensure that you have the UW CA certificate installed as a trusted CA on your client(s). UWWI'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 UWWI.

No LDAPS, just LDAP

If you do not need to employ LDAPS, then you'd configure the connection information on your application to be:

hostname: netid.washington.edu
port: 389

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 UWWI, you may want to query UWWI directory information for use within your application.

You may want to reference the full set of all UWWI possible user attributes, or the subset of all UWWI user attributes in use and centrally managed.

Not all user attributes are visible by default. You may want to reference which UWWI user attributes are not commonly visible. If you'd like to make use of these attributes, then you'll need to request additional UWWI 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 UWWI directory information, then you need to treat that information carefully. Most, if not all, the user information in UWWI is subject to individual privacy publishing controls that may change at any time. Should the information in UWWI 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 UWWI if the functionality meets your needs. You may need to enter a number (an OID) to enable that functionality.

Paged search: 1.2.840.113556.1.4.319
Get Security Descriptor: 1.2.840.113556.1.4.801
Sorted Search Request: 1.2.840.113556.1.4.473
DN search: 1.2.840.113556.1.4.1504
VLV: 2.16.840.1.113730.3.4.9

Some Final Thoughts

Your application may not be able to handle the number of objects in UWWI. UWWI has over 350,000 user objects, over 150,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 UWWI.

Additional Help

Your application may want other configuration details not listed here. Please feel free to contact the UW Technology Service Center for additional assistance in configuring your LDAP based application to work with UWWI.