If you're a system administrator, system security is always on your mind - or at least it should be. Preventing unauthorized access to system resources is a critical part of your mission. And I'm willing to bet that the number one security problem that plagues your system is having an inaccurate picture of which users are supposed to have access. Learning who doesn't have access when they should is usually not a problem - users complain when they can't do something. But when workers leave the organization (or just transfer to a different department) and their computer access isn't removed, you've got a security hole waiting to be exploited.

So keeping track of users is a key component of providing security in a networked environment. The other necessary components are authentication, access control, and encryption. In this article I hope to persuade you that LDAP is just the tool you need in order to improve your system security on all these fronts. For more on basic LDAP concepts and how to make the transition to LDAP, see the View Source article A System Administrator's View of LDAP.

TRACKING YOUR USERS WITH LDAP

When you begin to look at the problems you face in tightening your security, you realize that you need a database system to manage your organization's directory. But not just any database system will do. Enter LDAP, which enables you to build a standardized, centrally managed data store that's easy to use and consistently available.

The LDAP server provides a directory service that's like a database but is optimized for read access and uses a hierarchical data model that resembles an organizational structure instead of storing information in rows of tables like a relational database does. With its flexible structured data system, an LDAP server can store just about anything you need to store. And by setting a standard for directory services that run over TCP/IP, the prevalent form of networking in use today, LDAP enables sharing of data with other systems.

LDAP also supports replication, which makes it easier to keep the directory available on a round-the-clock basis. This replication can be distributed across networks. You may have read about Cisco and Ford Motor Company using LDAP for product management. I know of a company that uses LDAP replication to keep its organizational data in sync between its headquarters in Texas and its ships at sea.

In short, LDAP provides you with a standardized system for tracking the workers in your organization. With LDAP, the organization's directory can be centrally managed and in the best case tied into the hiring/firing/transfer/promotion system. This way, when a person is hired into the organization, a user account is created for her, and when she leaves the organization, her account is closed. Your number one security headache has just been cured.

LDAP AND AUTHENTICATION

Authentication means identifying someone who wants to access a resource as an authorized user. We normally do this by requiring a user name (or ID) and a password. Some systems require a digital certificate or fingerprint. The most secure systems usually require both a password and a digital certificate or fingerprint.

A common security problem in organizations is that there's no way to match each account on the system with a real person. Even "system" accounts should ultimately be tied to a person (usually the system administrator) for accountability. By adopting an enterprise user ID (EUID) system when you make the transition to an LDAP server, you can tie each account to a particular user and thus immediately improve security. The EUID becomes a user's ID on each system he uses. If your users currently have to keep track of several user IDs, they'll no doubt be happy to switch to one EUID. And this is the crucial first step toward single sign-on.

When you change over to an LDAP server, you can concentrate on improving authentication in other ways as well. The View Source article Using LDAP With Netscape Application Server for User Authentication describes how to use LDAP to handle authenticating users of NAS applications. Except for authenticating users of an LDAP server so that they can perform LDAP operations, though, LDAP really isn't designed to handle authentication tasks. Still, the iPlanet (a.k.a. Netscape/Sun Alliance) servers use LDAP extensively for authentication, as do many other products out there. You must decide for yourself whether it's the protocol for you to use.

You can also decide to go with a third-party authentication system such as Kerberos or a system using digital certificates (for example, X.509 certificates) or biometrics (for instance, fingerprints). Even if you do decide to go with one of these systems, you can still use LDAP to store passwords or other information used for authentication. For example, you can use LDAP to store X.509 certificates (X.509 is part of the X.500 data model suite that LDAP is derived from), or you can extend the schema to store public keys, such as PGP public keys. (More on public keys in the later section on encryption.)

You can also set up a process that routinely checks the LDAP server to see if the user is still active in the organization. And you can have your LDAP server use your third-party authentication system to control LDAP authentication via the SASL (Simple Authentication and Security Layer) protocol.

LDAP AND ACCESS CONTROL

Access control means the ability to control the amount of access to a resource that someone is allowed, based on her user authentication. Usually when we talk about security, we're actually referring to access control.

Access control schemes can range from simple to complex. Often the most complex schemes result in the most secure systems, but sometimes complexity gets in the way of security. Security may be compromised just as much because users are discouraged by a scheme's complexity from using the system at all as because users are allowed to access data or applications that they're not authorized to access.

Let's explore access control by looking at what's provided in this way by common operating systems. Note that the access control described here is the default for each OS; it can be changed via various system settings or third-party products.

• Windows 95/98 - Either you have access to everything on the system or you don't.
• Standard Unix - Control is based on operations (read, write, or execute) and on general groupings (for example, by owner, group, or world).
• Windows NT with NTFS - Control is based on operations (read, write, or execute) and extended groupings - for example, owner, one or more groups (such as Everyone, Administrators, Domain Users), or world. The biggest difference between this and standard Unix is that in Windows NT, individual users or groups can have their own permissions (though I should point out that most modern Unix systems can support ACLs as well if you configure your system for them).

There's no standard for LDAP access control, but Netscape Directory Server uses a model similar to Windows NT. It extends this model by defaulting to no access (in other words, unless you specifically grant access to users, they can't read or modify directory entries, as discussed in my last article, Controlling Access to Server Data With ACIs) and by enabling you to "waterfall" control based on authentication.

I'm coming to believe more and more in waterfall access control. In a waterfall system, you grant certain levels of permission based on how a user is authenticated. For example, you might allow a minimal level of access to someone providing an ID and a password. Someone authenticated via a digital certificate would get more access. Finally, you would grant the highest level of access to a user authenticated via a biometric authentication system.

I also believe that although LDAP can be employed to authenticate users, access control should be local to each system. Think about it like this: Your place of work gives out ID badges to everyone who's authorized to be on the premises, but access to individual areas - in particular, sensitive areas - is controlled on a local level. If your access control is in the same place as your user authentication, you risk losing all security if that single item is compromised.

As an example of how you could use LDAP and local access controls, let's look at a Unix system that supports PAM (Pluggable Authentication Modules) and uses LDAP as its authentication database. (PAM is a standard supported by most recent Unix operating systems that enables you to change your user authentication database without having to recompile all of your applications.) In this instance, you're trusting LDAP instead of your local password file to provide you with the identity of the user. But it's still up to the system to determine what types of access the user has. For example, in her home directory the user might be allowed to read mail, create web pages, and run applications like Netscape Communicator and Star Office. But she might not have the ability to add users to or delete users from the system, or to read the mail or store files in anyone else's home directory.

LDAP AND ENCRYPTION

Encryption means encoding data. In the context of system security, we encode data for one of two purposes: so that we can send it over the Internet without the danger that it might be intercepted and read by some unauthorized party, or so that we can authenticate a user. My earlier article, Protecting Data Over the Wire, introduces one encryption scheme (the Secure Sockets Layer, or SSL) used by LDAP for the former purpose. Another encryption scheme for sending data over the wire that you can put in place with LDAP is the secure shell (ssh). I'll say a little bit here about the process of encryption before describing how encryption can be employed to authenticate a user.

There are two types of encryption (at least for our purposes): symmetric and asymmetric. In symmetric encryption, we use the same key to both encrypt and decrypt the data. In asymmetric encryption, we use two different keys, one to encrypt the data and the other to decrypt the data. Symmetric encryption is quicker, but asymmetric encryption is usually more secure, in particular for authentication systems. Usually we use a version of asymmetric encryption called public key encryption to exchange the symmetric key for use in a symmetric encryption scheme. This way we get the protection of an asymmetric encryption scheme but still get the benefit of improved speed (this is how SSL works).

Public key encryption uses two keys for encryption: a public key, which can be shared with the world, and a private key, which is kept secret by the owner. A message encrypted with a private key can only be decrypted with its corresponding public key, and a message encrypted with the public key can only be decrypted with the private key. Usually we want a trusted third party to "sign" the public key so that people who don't know us, but who trust the third party to verify that the public key is in fact ours, will trust our public key. In fact, this is why we use certificate authorities with SSL.

You can improve your authentication system by using public key encryption and digital signatures. Here's how this might work: Let's say that a server has the public keys for all of its authorized users. When a user wants to log in to the system, it will ask for a user ID and will present a random message for the user to encrypt. The user encrypts the message with his private key and sends the encrypted message back with his user ID. The server looks up the public key that corresponds to the user ID and decrypts the message. If the message is the same random message it sent, the user is authenticated.

As I mentioned earlier, you can use LDAP to store public keys. I'm not so sure that private keys should be stored in a network database, though. Those really should be secured separately, because if the LDAP server is compromised or even just broken, you stand to lose a whole lot of security in a single flash. If a public key is compromised, it can easily be revoked, but a private key is pretty hard to revoke.

SAFE AND SOUND

I've discussed four different aspects of using LDAP to improve your system security: tracking your users, authentication, access control, and encryption. I didn't include any code this time, as I usually do, but you should have plenty to think about without that. Let me know your thoughts on LDAP and security, preferably on the newsgroups so others can share in the discussion. Until next time.

FURTHER RESOURCES

• A System Administrator's View of LDAP, View Source
• Using LDAP With Netscape Application Server for User Authentication, View Source
• The LDAP Heavyweight: Controlling Access to Server Data With ACIs, View Source
• The LDAP Heavyweight: Protecting Data Over the Wire, View Source

I'd like to thank Paul Dreyfus for first giving me a chance at writing articles and Michelle Wyner for keeping up the work.

Mark Wilcox is the web administrator at the University of North Texas. He's the author of Implementing LDAP, published by Wrox Press. Mark has been involved with LDAP since the alpha-release days of Netscape Directory Server 1.0. When not working with web technologies, he likes to spend time with his wife.

Any sample code included above is provided for your use on an "AS IS" basis, under the Netscape License Agreement - Terms of Use