Thomas J. Barton, Senior Director for Integration, University of Chicago described a project at the University Memphis where the Radius server, a protocol for supporting access authentication, was integrated with LDAP. At U. Memphis authentication is not equal to authorization. There are several virtual modem pools with different access controls; for example, one dial-in number is only for faculty/staff and there are different wireless zones with various access control policies. That is the critical when dealing with Radius, which is a simple thumbs up/thumbs down access server. The project requirement was not just to take the authentication credentials from an access server and pass them back via Radius through LDAP but to apply authorization policy as well. This was achieved by the Radius service going through a sequence of LDAP queries about the user to gather attributes about the person and then to apply policy stored in the LDAP directory for a yes/no answer on access. Radius can handle VPN, dial-in modem banks, Oracle, and WEP and WPA for wireless. While it's not a panacea, this kind of approach could also be applied to protecting data in Oracle databases that are supported by a Radius server.

Robert Banz, Middleware Architect, University of Maryland, Baltimore County talked about authenticating people who may not have account names, but may have passwords somewhere in the directories, such as alumni. They've implemented a method of authenticating where you type in your full name, Robert Banz, and your password and it does a search on the directory and finds all the people who match the name and runs the password against the stored passwords. The search returns true if it matches one and only one of those people.

Example: There are five Robert Banz's in the directory. Enter the name and password, the system then goes and runs a match against all five. If you managed to match more than one, a nasty error would be returned, system e-mail gets sent to check out the problem and the person doesn't get authenticated. To prevent this problem, the system checks that a new password doesn't match the stored password on any other Robert Banz. Password lockouts are not done because someone could easily lockout really important users just by systematically trying accounts.

For those that use Kerberos, is checking the password for multiple ids' a good practice? It depends. There is both making sure the system is hard to crack, but also detecting people trying to crack it. You have to figure out what the metrics are to evaluate if someone is cracking vs. trying to validate. This process makes it somewhat difficult to do that. It would have to be very clear on how the mechanism works so you could determine what's acceptable and what's not.

Keith D. Hazelton, Senior IT Architect, University of Wisconsin-Madison. The University of Wisconsin system has 13 member institutions; students, faculty and staff migrate between these institutions. Chronos is a web based timecard system that is supposed to roll out system wide to track time for an individual across all institutions. There is no system wide authentication scheme at this time. Only Madison has anything close to a fully functional enterprise wide directory system. Some smaller campuses have Active Directory. One early suggestion that was rejected was to create credentials for everyone in the system, and somehow issue them.

Instead it was decided to act to the Chronos software as if there were a system wide authentication approach and link back into what does exist, a system wide payroll application. The approach was to put up an authentication hub to Chronos that redirected in a WebISO-like fashion. If someone came in from Madison to record time, the hub knows to read the code that does the authentication service that uses LDAP as a repository. So it does LDAP authentication for Madison. The ugliest solution was for a campus with no campus wide identifier except their IMAP e-mail service. People on those campuses enter their e-mail username and password and the authentication hub tries to log onto their e-mail account. If it succeeds they are authenticated. Chronos doesn't see that part. It just sees that that they are authenticated and for what campus. Chronos looks them up in the system wide payroll application, which passes the payroll ID back to Chronos, which can use that ID to store information. Ungainly work-arounds like this will hopefully build momentum for Shibboleth with a thin shim of WebISO.

Some campuses have generic and departmental accounts such as feedback e-mail accounts for webmasters etc. Authentication against that would be valid but there's no actual person associated with it. In a directory related environment this might be handled by giving a yes answer only when there is a person authenticated.

Is a directory really an authentication server? What are the definitions for the characteristics of an authentication server and which ones do a directory meet? From a security perspective what are the important attributes about an authentication server? LDAP can be an authentication system. But you have to be careful with it. There has to be technology to support it, the right people to implement it, the right policies in place. The central IT department should not let a department run an application that does LDAP based authentication because it can’t be assumed the department has implemented it properly and they can’t be fired for poor security. So if an application is going to authenticate to the central directory server only stuff coming over SSL can be authenticated, if not SSL sorry. You can't shut down a non-SSL port because there are many applications that need anonymous access to freely distributable data, such as mail clients. The critical thing is to ensure that the password doesn’t go over the wire in the clear.

Kerberos is a system designed so it's hard to do things wrong in a way that will open you up to threats. An approach that involves LDAP and credentials has many ways to go wrong that need to be fenced off. The thing of value is the store of credentials. The threat for LDAP is that traffic will leak out because people don't obey rules. The way most use Kerberos is pretty much equivalent to LDAP authentication. The Kerberos KDC is a very simple piece of software compared to an LDAP server. It does one thing and does it very securely. It's in a box with only one port that accepts packets and is physically secure. The application doesn’t have the password so it can’t mess it up. If you can secure your LDAP server as a password store for host space security, and you’re not going to use any Kerberized services such as NFS, or cross-realm authentication for active directory than use LDAP.

Is there a document outlining how to authenticate against LDAP correctly/securely? On the Notre Dame enterprise directory service website: http://www.nd.edu/~eds/docs/ there is a developer's guide which was written with the intent to provide third party vendors information on how they should authenticate to the system and it describes the authentication steps through LDAP. There is also discussion in the LDAP recipe, which is part of the NSF middleware initiative distribution. A link is available at: http://middleware.internet2.edu/core/directories.html.

As LDAP is used for more things, the operational availability of the data becomes more important. There are institutions where if the LDAP directory went down many other enterprise systems depending upon it to authenticate would become unavailable. So in addition to storing passwords securing the operational strategy is critical also.

It all comes down to what services you want to provide. Is Kerberos important to your institution in terms of Microsoft Win2K active directory integration, gaining access to grid stuff, etc? There are things to consider in addition to just security. If LDAP is compromised you apologize and work to prevent re-occurrence. If the KDC is compromised all 25,000 users have to change their password so LDAP is a little less critical if not as secure.

Brendan Bellina, Senior Systems Engineer, University of Notre Dame spoke about how to work with vendors to incorporate LDAP bindings that meet campus requirements for LDAP authentication. When Notre Dame started putting up LDAP authentication a selling point for them was being able to extend services through application service providers (ASP's) and not always have to run the software in house. They thought an enterprise directory would be the way to authenticate through rather than through the Kerberos environment. They implemented this with IPS, a learning management system product for things like HR training courses etc. and not actual classes associated with degrees, HigherMarkets, a higher education procurement system, and are working on NACE-Link, which handles career-offering services.

Notre Dame was very emphatic that they did not want vendors to create additional user ID's and passwords, and that they would not provide vendors with lists of user ID's and passwords authorized for the application or unrestricted access to databases containing that information. This way there is no concern people use the same passwords in both places, over how the vendor secures the lists, or access controls on vendor side to database information. Notre Dame retains control and doesn't have to worry about changing passwords multiple places to stay synchronized. Vendors talk to Notre Dame's systems via LDAP and SSL. Often the vendors aren't familiar with LDAP but once they learn about LDAP they realize that LDAP enabled is a good selling point for their product to other universities.

The university has to be clear on how the vendor will bind to an LDAP directory. When someone logs into one of the enabled applications the vendor needs to query the directory service over SSL to see if the password is correct and by positive authentication is authorized for the application. The downside is the vendor does handle the entered password. Because of that the security officer has to work out a very specific agreement around what they will and will not do with that password, such as they will not store it.

Notre Dame has structured this so the vendor only gets an authentication for an authorized user of the application. The vendor has the password and userid, it queries the directory and gets back the DN, the designated name. The vendor is not allowed to construct the DN from the userid since those are name based and change often. DN's are not named based and the structure is based on legacy x.500 structure not on domain component naming. Requiring the vendor to query the directory for the DN allows Notre Dame to make any changes without the application breaking.

The application takes the retrieved DN and password and tries to bind to the directory. If it succeeds it is a valid password, if it fails it's not. Notre Dame will only return the DN if the person is authorized for the application. This is to ensure that not just anyone who has a directory entry can access the application and Notre Dame retains that control and the ability to change it. This is done through an attribute called ndAuthEligible, which contains the DN associated with the application. When the application binds to the directory over SSL, all it knows is it has to do a search for that userid and get back the DN. It doesn't know that the access control instruction (ACI) in the directory service says "only display active entries in the directory and only return entries that have the ndAuthEligible set to the value of their applications service DN". That way they can only get back people authorized to use the application. They can't get back any inactive entries or entries of people not authorized for the service. The vendor binds with the user's DN, authenticates with the user's password, and if they're authorized they login. This could also have been implemented through groups by making authorized users a member of a particular group.

Since developers are often focused on getting the application up it is important for the university to focus on who uses the application and how to retain control of the mechanism for granting that access.

Todd Piket, Analyst/Programmer, Michigan Technological University
Michigan Tech does not use Kerberos. They tie everything they can to the directory server. They have a very homogenous environment with all Linux on the server side. The directory servers run Solaris because there is a free 200,000-user license when you use their directory server. They use Sun 1.5.1 with SSL-LDAP and PAM-LDAP as the main means of authenticating users via LDAP. They do this since the email system was centralized with IMAP, POP, SMTP, NNTP, and Radius all running on UNIX machines and looking to a single place to get the userid and password. The PAM and NSS implementations on Solaris were replaced with libraries from www.padl.com to get desired performance. All email servers point at one directory server that is composed of three machines for load balancing. This worked well until they had to interact with Active Directory. Active Directory doesn't really know what an authentication module is or understands name service switching. So they are working on those authentication issues to enable department lab machines, which are often PC's, to use the central directory server to authenticate.

Michigan Tech is waiting for Sun 1.5.2 to be released shortly because it comes with Sun identity synchronization for windows, which is said to automatically synchronize with a directory. Then windows machines can authenticate against the Active Directory, which is nice. That is an external authentication so all the local departmental policies and home directories and drive mappings can be managed on the local Active Directory and the centralized university level doesn't have to be involved other than storing and synchronizing passwords at an enterprise level. The active directory synchronization tool will be a plug-in.