LDAP - Lightweight Protocol Does Heavy Lifting

VanLUG February 2002 Meeting Presentation
By Dale McGladdery
March 12, 2002

Luca Filipozzi shares his experience implementing LDAP

How do you manage user passwords and access control across Microsoft and Unix operating systems? If you're Luca Filipozzi, IT Manager at the UBC Department of Electrical and Computer Engineering, you use Lightweight Directory Access Protocol (LDAP). Filipozzi presented the why and how of his implementation at the Vancouver Linux User Group's February 2002 meeting.

The Electrical & Computer Engineering Department's old configuration used NIS and a home grown scheme to stage passwords between their Microsoft Windows and UNIX systems. Some of the problems with NIS included information raveling in clear text, a manual process for pushing NIS maps to target computers, and a problematic coupling between operating system security domains.

Filipozzi explored a number of possible solutions which included Kerberos, LDAP, and 3rd party software. Questions he considered included the software mix being supported, primary OS being used to administer the configuration and the kind of information being stored (for example, username/passwords, home directories, access control information). Kerberos offers single sign-on but requires Kerberos aware clients. Microsoft based management schemes require Microsoft domain controllers and other tight couplings. Ultimately he choose LDAP. Not necessarily because it was the best ultimate solution, though it might be, but because it was the bit fit for his environment.

The Lightweight Directory Access Protocol is often mistaken for a database, it's not. It's a protocol for accessing a database in much the same way as ODBC/SQL is. Unlike SQL, LDAP supports a hierarchical branch view of the world, not a row/column view. It was originally designed to work with the X.500 directory standard but has moved beyond this. LDAP is database agnostic, sitting in front of any number of different entities. It's designed to transport arbitrary data as defined in schema. The schema is ugly but there's a lot of them designed, so the chances of having to make one yourself are fairly small. LDAP supports access control and automatic replication from a master server to slave servers.

LDAP can be used in a lot of different situations: serving data from a central address book, hosting configuration files for HTTP and SMTP, or providing a directory service for user accounts. It can require LDAP aware client programs but can also be implemented "behind the scenes" in a manner transparent to the clients. LDAP is supplanting NIS, NIS+ and Kerberos in many sites.

Since LDAP is just a protocol an implementation was needed. There are many choices, Filipozzi picked the open source solution from www.openldap.org. There are two daemons, the LDAP daemon: slapd, and the replication daemon: slurpd. slapd comes with a database, programmable modules that let you access other databases and APIs that let you write your own access modules. LDAP schema definitions are used to name the fields in the database. Though they would be tedious to create yourself schemas have been created to perfectly match MS Windows and NIS. Communication security is not defined in the LDAP protocol but handled in the implementation.

The slapd daemon configuration consists of including the appropriate directives in the configuration file. Directives are required for schema files, TLS (Transport Layer Security)/SSL (Secure Socket Layer) specification, database set up and access control, and database replication. The clients must then be configured to seek their data from slapd. This can be achieved by LDAP aware PAMs (Plugable Authentication Modules), NSS (Name Service Switch) modules and gateway products. In the MS Windows world file and security services are provided by Samba, which is LDAP aware.

How hard was this to figure out? According to Filipozzi it was easy, but working out the data mappings took a while. Integration was relatively straightforward with the hardest part being the PAM configuration.

Single sign on and centralized user management across different operating systems is desired by system maintainers and users, alike. While a general "plug and play" answer doesn't currently exist, LDAP implementations like the one at UBC's Department of Electrical and Computer Engineering demonstrate it can be achieved. The icing on the cake, it can be achieved with non-propriety open source technology.

Mr. Filipozzi's presentation and sample configuration files are available on the web at www.ece.ubc.ca/~lucaf. Other useful web sites include:

Open LDAP Project: www.openldap.org
Samba TNG Project: www.samba-tng.org
PADL Software: www.padl.com (Open Source Software Link)
Syndicate content