Solaris LDAP client with OpenLDAP server
From Docupedia
Note: This page was imported from an old HTML source. It will be cleaned up and wikified as time permits. -- bklang
Contents |
Introduction
This guide is my attempt to document the configuration of Solaris 10 clients with an OpenLDAP server. While researching the topic on the internet, I found plenty of information on how to configure PADL's LDAP clients (nss_ldap and pam_ldap) and good documentation on getting OpenLDAP server to run on Solaris. Howver I did not find much on configuring Solaris' NATIVE LDAP client for use with OpenLDAP server. The purpose of this document is to attempt to fill that void.
This document works under the premise that the reader is familiar with the operation of LDAP and already has a working LDAP tree in place. The tree should have user data in a form that works with nss_ldap and pam_ldap. If you're already using LDAP in an environment with Linux clients, you should be all set. If not, you may wish to find other HowTos first and come back to this one when you're ready.
These instructions were written for Solaris 10. In theory they should work with Solaris 9 and even Solaris 8, but there will likely be semantic differences. For more information, see the Links section at the bottom of this document.
Overview
The Solaris LDAP client differs in some key ways from the PADL LDAP client which comes bundled with nearly every modern Linux distribution. The most visible difference is Sun's dedication to the NIS-stype domain convention. When configuring a Solaris host for LDAP you must also change the system's domain name to match the information stored in LDAP. Regardless of this and other differences, the basic schema for storing the name service databases is consistent enough that Linux and Solaris can co-exist happily.
Prepare the LDAP server
To make OpenLDAP play nicely with Solaris 10, three changes need to be made. The first is to fix an interoperability problem between Solaris' ldapclient and OpenLDAP server. A patch may be applied to OpenLDAP which enables the use of Solaris' ldapclient init function. Note that this change is not strictly necessary, however it will make your life easier. The second, relatively painless change, is to add two schema files necessary for storing the data Solaris needs to manage user accounts. Finally the directory needs to be seeded with data to make it do something useful.
If you elect to skip the first step, make sure you follow the instructions for configuring Solaris with "ldapclient manual" syntax as the "ldapclient init" mechanism will not work. You may also then skip the third step of this section that deals with initializing profile information.
Patching OpenLDAP
As has been well documented on other sites, Solaris' ldapclient init utility fails to configure itself unless the OpenLDAP server it converses with has been patched. The original patch was from bolthole.com and applies to OpenLDAP 2.0 (local mirror). Gary Tay updated the patch for OpenLDAP 2.2 (local mirror). Since my work environment uses Red Hat Enterprise Linux ES and AS for our LDAP servers, I have also created updated RPMS that contain this patch. The RPMS are available for RHEL 2.1 (src) and RHEL 3 (src). Naturally they come with no warranty whatsoever. I have no idea, but I bet they also disqualify you for official Red Hat support.
Installing the schema
Solaris relies on objectclasses and attributes from two schema, DUAConfigProfile and solaris, in addition to the schema that come bundled with OpenLDAP. From what I have read, DUAConfigProfile is based on draft internet standards (I believe that SuSE Linux and HP-UX also support this standard, but I have not verified that) while solaris.schema is based on work to reverse engineer the objectclasses and attributes that Solaris uses to store user account information. To use the new schema, just drop the schema files in your schema directory, add the two appropriate lines to slapd.conf and restart slapd.
Initializing the directory structure
Assuming you followed the directions to get a patched version of the OpenLDAP server in place, you can use a neat feature of ldapclient which allows the administrator to store all the information necessary to configure the LDAP client in LDAP. This may sound chicken-and-egg, but as you'll see in the steps below it does make quickly and consistently provisioning and reprovisioning LDAP clients easy. I have provided a sample LDIF file which creates the ou=profiles hierarchy with one example profile underneath example.com domain. You will need to substitute the base DN throught the LDIF before adding it to your directory.
# Example profile LDIF: dn: ou=profile,dc=example,dc=com objectClass: top objectClass: organizationalUnit ou: profile dn: cn=Solaris,ou=profile,dc=example,dc=com objectClass: top objectClass: DUAConfigProfile cn: Solaris defaultServerList: ldap1.example.com ldap2.example.com defaultSearchBase: dc=example,dc=com defaultSearchScope: one searchTimeLimit: 30 bindTimeLimit: 2 credentialLevel: anonymous authenticationMethod: simple followReferrals: TRUE profileTTL: 43200
- NOTE* These should be considered "convenient defaults." By convenient I DO NOT MEAN SECURE. There is no encryption and the directory searches are done anonymously. However this configuration adds the fewest complexities and can be used while testing Solaris LDAP.
Whether or not you choose to create profiles, one more important change is necessary. In order for Solaris to process domain searches, it expects the base DN to have the objectclasses "domain" and "domainRelatedObject" and the attribute "associatedDomain". The "associatedDomain" attribute must contain the name of the domain for the Solaris environment. A good idea would expect it to be the conventional version of the domain name/base DN that you are using. For example, if you are Example Company using the domain example.com, your base DN might be dc=example,dc=com and your associatedDomain entry would be "example.com".
dn: dc=example,dc=com objectClass: top objectClass: domain objectClass: domainRelatedObject objectClass: nisDomainObject domainComponent: example associatedDomain: example.com nisDomain: example.com
Configure the client
Now that you have prepared the server with Solaris specific tweaks, the client needs to be brought online. Note that for at least Solaris 10, this can all be done without the need for a reboot. That's not to say that it won't be disruptive; it will be. If the machine is not already part of a NIS/NIS+ domain, this should go smoothly. In my case we were not configured for any domain so I do not know what extra steps, if any, are necessary.
Prepare Configuration Files
Unfortunately for us, Sun made some (in my humble opinion) poor decisions when laying out the defaults for an LDAP configured system. The biggest trouble stems from the way they try to use LDAP to resolve hosts. In most configurations, this leads to an immediate infinite loop, where the name service switch goes to look up the LDAP host to connect with, which makes a call into the name service switch to find the LDAP server which would know the IP address for the LDAP server.... All environments I have worked in use DNS as their primary host naming system with a fallback to /etc/hosts files. If your system ever hangs on boot or when logging in, check this first.
The second issue is far less critical, but one I find bothersome anyway. Sun's default configuration attempts ALL name service lookups through LDAP first, and failing that, it looks to files. I'm a firm believer personally of having local overrides checked first. In the even that LDAP is ever unreachable (and pray that it isn't!) hopefully the system will stay afloat.
- NOTE* When editing the file make sure you are editing nsswitch.ldap and NOT nsswitch.conf. The reason for this is ldapclient will overwrite nsswitch.conf with nsswitch.ldap during the conversion process. By making your edits in nsswitch.ldap, you can ensure the appropriate defaults will be used when the client is fully configured, and not before.
If your only concern is the first issue, then the following change will get you on your way. For the "hosts" and "ipnodes" lines in /etc/nsswitch.ldap make the following changes:
# Old: hosts: ldap [NOTFOUND=return] files ipnodes: ldap [NOTFOUND=return] files # New: hosts: files dns ipnodes: files dns
The other change I make is to reset all the other name service definitions to "files ldap". This forces lookups to check local overrides first (ex. /etc/passwd; /etc/group). DNS is configured the same way in my example (ex. /etc/hosts). The Solaris defaults will work for the most part so this change is entirely at the administrators discretion.
I have also made availble my modified nsswitch.ldap
Verify Required Packages
Through some trial-and-error, I have determined that the following packages are required to be installed for Sun's LDAP client to work. In the case of sendmail and autofs, it leaves more questions unanswered than it solves*, but this configuration Worked For Me.
The following packages are required to make ldapclient happy:
SUNWnisu # provides ldapclient SUNWnisr SUNWspnego # gss-api related libs SUNWsndmr # see note below SUNWatfsr # see note below SUNWlldap
- Note: sendmail and autofs packages appear to be necessary as ldapclient calls those services to be restarted as it configures the host. They can likely be removed after running ldapclient but I can't be sure. They seem to have nothing to do with LDAP functionality, but by simply not being present ldapclient detects the error stopping/starting the services and bails out before making the changes to the system.
Configure the client using a profile
If you installed a patched version of OpenLDAP above, and installed the profile template, you will be able to use a much simplified method of configuring the host for LDAP. As noted above, however, the LDAP client seems to have some strange behaviors. In the configuration profile shown above, anonymous access is used to search the directory. However, unless a proxyDN and a proxyPassword are specified, the ldap service refuses to start! A simple way to make ldapclient and the cache manager happy is to provide those credentials, even if they aren't valid. In my configuration ldapclient did enough syntax checking to make sure that the DN was at least syntactically valid. However it never attempted to bind as the credentials I gave were not valid for the LDAP server with which I was connecting. If your directory allows for anonymous searches of the ou=profile branch, you will be able to execute the following:
# Make sure the domainname is set before running ldapclient host# domainname example.com host# ldapclient -v init -a proxyDN=cn=fake,ou=People,dc=example,dc=com \ -a proxyPassword=xxxx ldap1.example.com # lots of output snipped here start: system/filesystem/autofs:default... success start: sleep 100000 microseconds start: sleep 200000 microseconds start: system/name-service-cache:default... success start: sleep 100000 microseconds start: sleep 200000 microseconds start: network/smtp:sendmail... success restart: sleep 100000 microseconds restart: sleep 200000 microseconds restart: sleep 400000 microseconds restart: milestone/name-services:default... success System successfully configured host#
When you see the line that reads "System successfully configured" you should be good to go. Skip to the pam configuration section. If you don't get that line look at the output above and try to determine the nature of the failure.
Configure a client manually
Refer to the manpage or Gary Tay's page for more extensive documentation on using ldapclient manual.
Authentication Options
The instructions to this point are to enable the name service switch (NSS) to locate user information from LDAP instead of flat files. To complete the centralization, an authentication mechanism will need to be selected. For simplicty, LDAP can be used directly to authenticate users. Environments which prefer to take advantage of the advanced functionality in Kerberos can integrate with that service instead. Choose only one of the following two sections:
Authentication Option #1: LDAP PAM configuration
Per the pam_ldap(5) manpage, the following changes will need to be made to /etc/pam.conf:
Find lines that read (there will be several):
<service name> auth required pam_unix_auth.so.1
and change them to read:
<service name> auth binding pam_unix_auth.so.1 server_policy
and add this line immediately following each changed line:
<service name> auth required pam_ldap.so.1
Do the same as above except for "account" instead of "auth" Add "server_policy" to the end of the line that reads:
other password required pam_authtok_store.so.1
Save the changes and exit. PAM changes should not require the restart of any processes so try to ssh to localhost with an LDAP account to test it. If you have trouble, try checking /var/log/all for information about the nature of the problem.
Authentication Option #2: Kerberos Integration
If you prefer to use Kerberos as your authentication service, you will need to configure PAM to use pam_krb5.so instead of pam_ldap.so. Additionally, the host will need to have the Kerberos service properly configured and functional. For more information on Kerberos integration with Solaris, please see Solaris Kerberos Client Configuration.
Refer to the pam_krb5(5) manpage for more details and alternate examples on using Kerberos via PAM.
Find lines that read (there will be several):
<service name> auth required pam_unix_cred.so.1
and add this line immediately following:
<service name> auth sufficient pam_krb5.so
Kerberos should now be working via PAM. Since Sun's ssh server ships with GSSAPI enabled by default, no additional ssh configuration should be necessary to enable single sign-on. For reference, here are the sshd_config options that affect GSSAPI:
GSSAPIAuthentication yes GSSAPIKeyExchange yes GSSAPIStoreDelegatedCredentials yes
Conclusion
Hopefully all went well above. I'll be adding a troubleshooting section which should help if errors are encountered during the ldapclient stage. If you still have trouble, try some of the following links:
Links and References
Gary Tay's Home Page: Gary has compiled information on configuring Solaris 8 and 9 with both OpenLDAP and Sun LDAP clients and OpenLDAP and iPlanet LDAP servers. Much more information than I even tried to put here.
bolthole.com: An older but still helpful document describing how to work with Sun's LDAP client. Bolthole also contains lots of other Solaris specific information.
