WebbBLOG
Michael Webb's Weblog

Access Control with LDAP in Naming Services

Purpose: Outline current compatibility issues and open discussions on current deployed access control methods in Native LDAP.

Compatibility in NIS

With the introduction of NSS (Name Switching Service) most of the services within UNIX were given the capability of storing and retrieving data from more than one database location. The file /etc/nsswitch.conf is used to list the available databases along with a hierarchical order of locations to search. Below is an example:

passwd files ldap

In this structure, data for the passwd database can be located in either files or ldap.

NIS, however, cannot search for data in more than one location using nsswitch.conf. Therefore, in order to provide legacy NIS support, basic UNIX libraries support a compatibility (“compat”) mode to allow NIS to search in more than one location:

passwd compat

passwd_compat files nis

In this structure, the passwd database is in compatibility mode, and by using the (+/-) symbol in the passwd and shadow files, servces will search for data in files, then NIS. Based on the Solaris 9 Basic Library Reference, compat is provided for NIS only. ¹

LDAP Naming Services

Recently, Sun introduced LDAP support for naming services through nsswitch.conf. “Native LDAP” as it is commonly called, is the replacement for NIS. A typical implementation would be most likely a transition from NIS to LDAP.

Because of their familiarity with NIS, many current customers continue to use compatibility in the nsswitch.conf, particular when using netgroups for access control.

The “compat” mode was never designed or intended for use with LDAP. As with any legacy support, the function for “compat” was for interoperability and not for performance. Since “compat” is a restriction/limitation placed on NSS, one could expect that services and application normally optimized for NSS would be impacted.

Access Control in LDAP Naming Services

As discussions regading access control are developed when developing an Architecture for Native LDAP, many of the following concepts are explored:

Search Filters in Service Search Descriptors

Since client searches should be optimized in an LDAP-based environment, native LDAP clients use Service Search Descriptors in order to facilitate retrieving data from a Directory.

passwd:ou=people,dc=yaddda,dc=yadda?one?&(!(hostsdeniedlogin=anadbprod1))(|(!(hostsallowedlogin=*))(hostsallowedlogin=anadbprod1))

In this example, each posixaccount has two multivalued attrbutes: 1), hostsdeniedlogin – a listing of hosts that are denied during authentication attempts; and 2) hostsallowedlogin – a listing of hosts that are allowed during authentication attempts.

The string passwd:ou=people,dc=yaddda,dc=yadda?one? Specificies the dn base and search scope;

The notation &(....) adds a conditional “and”

The string !(hostsdeniedlogin=anadbprod1) is a filter that excludes the denied host: as long as the posixaccount's hostsdeniedlogin does not contain anadbprod1, continue; otherwise search/read access to the subtree is denied;

The notation (|.....) adds a conditional “or”

The string (!(hostsallowedlogin=*))(hostsallowedlogin=anadbprod1) prevents global access from (hostsallowedlogin=*), but allows access based on the value anadbprod1 for the hostsallowedlogin attribute of the posixaccount attempting authentication.

Each ldapclient would be different for each client system to generate host level restriction. This SSD could be adjusted and created on group-based attributes for group-level SSDs.

Authorization

“Authorization” can be defined as the right to attempt authentication, whereas authentication represents the actual process.

For example, Secure Shell clients can be configured for group-based authorization by populating/migrating groups in the Directory, and enforcing AllowGroups in the sshd2.config. When an Secure Shell session is invoked, the client will conduct a basic anonymous read of the groups stored in the Directory, and will allow a login attempt only if the user is a member of one of the allowed groups.

This process provides both host and user-based restrictions, and could be configured for each client system.

PAM modules

PAM was designed to be a configurable service, in where customers could write C-based functions for authentication based on specific services. In fact, several third party software vendors provide PAM libraries and modules for the pam.conf.

The Sun Blueprint LDAP in the Solaris Operating Environment contains a chapter titled “Writing a PAM Service Module.”

Sun is currently evaluating a pam_netgroup authentication module that supports the migrated netgroups stored in the Directory. This module could be the direct alternative to the compat mode as discussed earlier. Although it not officially supported during testing (or until its inclusion with an OE release), the pam_netgroup module is available for customer testing.

Implementing custom PAM Service Modules is allowed in Native LDAP.

Summary

In implementing LDAP as a Naming Service, the “compat” mode designed for NIS is highly discouraged. Other methods of access restriction are equally available and currently deployed in customer environments. Customers should develop an architecture that includes needed restriction capabilities followed by thorough testing, development and implementation of the technology that best meets their requirements.

References

Basic Library Functions, Solaris 09/04 Reference Manual Collection, http://docs.sun.com/db/doc/817-3939/