LDAP
From Peyton Hall Documentation
 | This article is actively undergoing a major edit for a little while --huston 12:43, 20 June 2007 (EDT). As a courtesy, please do not edit this page while this message is displayed. The person who added this notice will be listed in its edit history or has placed their signature above. If this page has not been edited recently (several hours!), please remove this template (or replace it with {{underconstruction}}). This message is intended to help reduce edit conflicts; please remove it between editing sessions to allow others to improve this page. |
LDAP stands for Lightweight Directory Access Protocol. We use it in Peyton Hall to replace NIS (Network Information Service), which holds all the user names and encrypted passwords for logging in. It also can store a lot more, including information on the hardware in the building, and more information on each account and group.
Contents |
Introduction
Why LDAP?
LDAP is more secure than NIS, since you have to have the right credentials to be able to read the encrypted passwords from the directory. The old NIS system which it replaced was highly insecure, since anyone could run a command and instantly get a list of all the user names in the building and their encrypted passwords, and later run a program to try to crack the passwords on those accounts. In fact, not that long ago we were given a list of Peyton Hall users and encrypted passwords (some of which were cracked) which had been collected by an attacker in the past.
Instead of having authentication programs compare the given password with the stored password directly, they can try to "bind" to the directory as a user to test if the given password is correct. While this still would allow for a single password to be brute-force attacked, it does limit the ability to attack all accounts at once, and makes it impossible to try to crack an account without leaving a trace of the attempt (since it has to be done against our directory, which logs failed attempts).
Also because LDAP is widely supported for authentication, we can use it for other applications than just logging in. These pages are an example, where the web server uses your normal user name and password to authenticate to LDAP and verify your identity.
How does it work?
All the computers are told a list of LDAP servers to try for authentication, and should one of them fail the computer will "fail over" to one of the others on the list. In this way, a server can be taken offline for updates without affecting the rest of the building. There is one "master" server, which allows writes to the directory with proper authorization - for example, users can update their passwords, and certain pseudo-users can create new accounts or other directory entries. The remaining servers are "slaves", and have a local copy of the directory which they can use but not write to. When the master receives an update, it will record it in the local directory and then notify the slaves that there is an update to apply to their copies, which happens almost instantaneously (changes are also cached, so should a directory fall out of sync due to being offline it can be brought back to current when it is again up and running). The directory itself is based on X.500, known as the Directory Access Protocol. LDAP implements a subset of this functionality (therefore, the "Lightweight Directory Access Protocol").
If a client wishes to get information from the directory, such as a user's real name, it connects to one of the servers and issues a request. Assuming that anonymous clients are allowed to see that information, the server will return a list of matching entries. If the information is protected (requires some kind of password to view) then the server will usually return that nothing matched the request. The client should instead bind to the directory - provide a distinguished name which is allowed to view the information requested and the password associated with that name.
To check for authentication - in the case of logging in with a password, for example - the authentication mechanism will bind to the directory using the provided user name, and the password given. If the bind succeeds, then the mechanism knows that the password given was correct for the user name given, and it can allow access to whatever it is protecting. The advantage of this system is that the LDAP server can have multiple methods of authenticating, and the mechanism requesting authentication can just pass that information along to the server in hopes of a match. This makes authentication less restrictive, since passwords are then only one of the possible methods to bind to the directory.
What else is in there?
As of right now, we have some information about computers - such as where they're installed, serial numbers, etc - but not much else. The directory can be used to hold things such as phone numbers, addresses, and much more. In theory, we could have all the information about every user in the network stored there, and it could be used as a department phone book; in practice, it hasn't been a high priority and therefore hasn't been implemented. However, you can setup the LDAP directory as-is to use as an address book in Thunderbird and Pine for an easy way to look up email addresses.
See also
