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.
[edit]
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.[edit]
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.
[edit]
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.
[edit]
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.Sun has documented the exact schemas used by Solaris. More information can be found here: http://docs.sun.com/app/docs/doc/806-5580/6jej518q2?a=view
[edit]
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.
dn: dc=example,dc=com
objectClass: top
objectClass: domain
objectClass: domainRelatedObject
objectClass: nisDomainObject
domainComponent: example
associatedDomain: example.com
nisDomain: example.com
[edit]
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.[edit]
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.
# Old: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.
hosts: ldap [NOTFOUND=return] files
ipnodes: ldap [NOTFOUND=return] files
# New:
hosts: files dns
ipnodes: files dns
I have also made availble my modified nsswitch.ldap
[edit]
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.
More Here
Courtesy:http://docs.lucidinteractive.ca/index.php/Solaris_LDAP_client_with_OpenLDAP_server