- NIS and NIS+ Overview
- LDAP as a Naming Service
- Solaris 8 OE LDAP Implementation
- Solaris 9 OE Secured LDAP Client and Server Configuration
- Acknowledgements
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Solaris 8 OE LDAP Implementation
Technically speaking, the Solaris 8 LDAP implementation is client side only. In theory, because it communicates over the standard LDAP v3 , any v3-compliant directory server should be able to support Solaris 8 OE LDAP clients. In practice, there are several required server features and configuration parameters that need to be set up. Because the set up is rather complex, scripts are available for the Netscape Directory Server 4.1x and Sun ONE Directory Server 5.1 software (formerly known as the iPlanet_ Directory Server). These are the only two directory servers that Sun Microsystems, Inc. supports.
Several design decisions were made in the development of the Solaris 8 OE LDAP Client that affect its implementation. The following sections detail some of these designs to illustrate why so many configuration changes on the directory server are necessary.
LDAP Client Profiles
There are a number of configuration parameters that a Solaris OE LDAP client needs to set before it can communicate with a directory server. Specific parameters include the address of the directory server(s) the client will attempt to get naming service data from and the name of a proxy account to bind to the server.
One approach you can use is to set these parameters in a local file on each client and update them locally. The obvious disadvantage to this approach is that more complex installations and cumbersome updates are required if the configuration parameters need to be changed. Alternatively, you can maintain the configuration data in a central repository, like the directory itself, so it can be easily retrieved during client installation and reconfiguration. This data is stored in client profiles.
Storing client configurations in the directory requires you to create schema definitions that define the object class and attributes that contain the client profile data. This requires the extension of the directory server's schema to include the client profile object class and associated attributes.
Support of RBAC and Projects
Role-based access control (RBAC) and projects that were introduced in the Solaris 8 OE relied on a naming service to operate efficiently. Because the RFC2307 schema did not include object classes and attributes that supported these features, schema extensions are required if you want to use the features with the LDAP Client.
nisdomain Object
The Solaris 8 OE clients have the notion of belonging to a naming service domain. NIS uses this domain name to locate an NIS server that supports the domain the client belongs to. To provide an equivalent, the directory server maintains the name of the domain it serves. Here again, an object class and associated attribute is required, making a schema extension necessary.
proxyagent Account
The Solaris 8 OE access the naming service during the boot process. For example, host names might need to be resolved to IP addresses by applications started in the Solaris 8 OEs run command (rc) scripts. At boot time, a user is not logged in and the OE needs to bind to the directory server as someone. Instead of setting up anonymous access and lessening security, create an account that the client uses during boot time and grant that account the appropriate permissions. Before a client can be initialized using this approach, the account must exist on the server. It must also be assigned a password for use during authentication.
pam_unix Support
The Solaris 8 OE provides two types of authentication methods that use LDAP as a naming service. Both of these are implemented as pluggable authentication modules (PAMs). The first, referred to as pam_unix, uses the traditional Solaris 8 OE method of authentication. This method stores passwords in a one-way hashing format called crypt. When a user logs in, the crypt representation of the password is retrieved from the naming service and compared with the password entered by the user after it is hashed using the same crypt algorithm. With this method, the authentication process takes place on the client and clear-text passwords are never sent over the network.
An issue with pam_unix support is that passwords stored on the server must be readable by someone so they can be retrieved. If the pam_unix style of authentication is deployed with LDAP as the naming service, a proxyagent account is used to retrieve the password. This means that this account must have the proper access rights to search for and retrieve passwords.
The other authentication method, called pam_ldap, performs the authentication on the directory server, so the password is never sent to the client in any form.
Self-Write Access Control
By default, directory servers assume that users should be able to modify the entry they use to bind to the directory. In most cases, this is a reasonable assumption. However, there are certain fields that a Solaris 8 OE user account entry contains that you would not want a user to modify. For example, you would not want users to change their uidNumber attribute to 0, effectively giving them root privileges. Therefore, the default access control instruction (ACI) requires modification.
Virtual List Controls
The virtual list view (VLV) is an extension for the LDAP v3 search operation. This extension is required to avoid overloading the client that makes a search request that returns a very large number of entries. For example, if you executed an ldaplist passwd command and had 10,000 users, 10,000 entries would be returned. Without browsing indexes, the maximum limit on the number of entries a server can return would most likely be exceeded.
Setting Up the Solaris 8 OE LDAP Client and Server Configuration
At the time the Solaris 8 OE was released, Netscape Directory Server 4.16.1 was the directory server version that Sun Microsystems, Inc. supported. This version of directory server software was co-packaged with the Solaris 8 OE media kit and could be downloaded from the Sun ONE/iPlanet Web site. In either case, it was contained in a single compressed tar file. The basic directory server installation steps were:
Uncompress and un-tar the file:
directory-4.16-domestic-us.sparc-sun-solaris2.6.tar.gz
Run the setup command from the installation directory.
Create an rc startup script to automatically start the directory server at boot time.
Once the directory server was installed, the setup_native_LDAP.sh script, which is available on the http://www.sun.com/blueprints Web site, was run to configure the server to support Solaris 8 OE LDAP Clients. The basic steps the script performed were:
Add the required schema definitions.
Create the directory information tree (DIT) structure.
Create the nisDomain object.
Set up appropriate access controls.
Generate an LDAP Client profile.
Create attribute indexes.
Create VLV indexes.
After the server was configured, you imported your NIS data by either running publicly available NIS migration scripts or by using the dsimport command, which was included in the NIS Extensions software.
When the directory server was configured and populated, you were able to initialize the Solaris 8 OE LDAP Clients. The easiest way to do this was by specifying the client profile that was created by the setup script on the command line when the ldapclient command is run. For example:
# ldapclient -P SolarisNative 192.9.200.1
One additional configuration step was required if you planned to use pam_ldap authentication instead of the default pam_unix. In this case, you also needed to modify the /etc/pam.conf file on the client. For example, you could replace the following lines:
login auth required /usr/lib/security/$ISA/pam_unix.so.1
with the following lines:
login auth sufficient /usr/lib/security/$ISA/pam_unix.so.1 login auth required /usr/lib/security/ $ISA/pam_ldap.so.1 try_first_pass
Additional lines, not shown here, would also need to be modified to allow remote logins and password management functions.