tidBiTS
Informs and engages the UNB community on IT developments and news

Solaris 10 LDAP Authentication

Author: ITS

Posted on Sep 24, 2010

Category: Geek Speak

warning



solaris

With Directory Services (LDAP, eDirectory, Active Directory) being so prevalent in the Enterprise today, it is of little wonder why IT Departments would want to authenticate access to workstations via their primary Directory Service. Getting Windows to authenticate against Active Directory is trivial, as is authenticating Windows workstations against Novell's eDirectory with the proper client. Even configuring the various flavours of Linux to authenticate against Active Directory or LDAP is a simple task these days. Unfortunately, there is little documentation about configuring Solaris 10 systems to perform authentication actions against LDAP, and even less information is available when you are starting from scratch. That is the case we found ourselves in when ITS determined that it would begin configuring all servers to perform authentication actions against our LDAP service.

All of the documentation that I discovered on the web had to do with using the ldapclient commandline utility to configure the system, as long as your directory service had the appropriate NIS information already populated. When you are starting from scratch, that is not the case. I had to devise a way to get the ldapclient utility to properly configure the system without looking for certain NIS information that should be in the directory. The steps below are the best method I could find to configure Solaris 10 for LDAP authentication. As well, I have listed the small things I found that caught me up during my research.

LDAP Configuration

If you are planning on connecting to your ldap server via SSL or TLS, you will need the root signing certificate. Also, you will need to prep the certificate database that the ldapclient utility will use when connecting:

[root@system]# /usr/sfw/bin/certutil -N -d /var/ldap

Grab a copy of the root signing certificate (preferably DER encoded X.509), and import it into the certificate database. Let's assume the file is called cert.der, and is the root certificate for RapisSSL issued certificates. If you are using Verisign or GeoTrust certificates, then the name in the certificate will be different:

[root@system]# /usr/sfw/bin/certutil -A -n "Equifax Secure Global eBusiness CA-1 - Equifax Secure Inc." \ 
-i ./cert.der -t "CTu,u,u" -d /var/ldap/

With the signing certificate in the database, the client can successfully verify the servers SSL certificate. After importing the root certificate, I found that I had to verify the permissions on the cert files in /var/ldap, as the ldapclient failed to read them if they were not world readable:

[root@system]# ls -l /var/ldap/*.db
[root@system]# chmod a+r /var/ldap/cert8.db
[root@system]# chmod a+r /var/ldap/key3.db

Next, I found that I had to add an entry to the hosts file for the LDAP server. Once the ldapclient utility begins it's magic, it moves a new nsswitch.conf file into place that looks to LDAP for DNS resolutions.

With the hosts entry for the LDAP server in place, we can run the configuration. If the appropriate information was present in the directory, we could simply run the ldapclient utility with a few simple arguments, such as the address of the directory service, and an authentication method. Since we have to supply most of the information on the commandline, we use the ldapclient utility in manual mode:

[root@system]# ldapclient -v manual \
-a defaultServerList=ldap.unb.ca \
-a bindTimeLimit=5 \
-a authenticationMethod=tls:simple \
-a credentialLevel=proxy \
-a proxydn=uid=Authentication user,dc=unb,dc=ca \
-a proxypassword=SuperSecretPassword \
-a domainname=unb.ca \
-a defaultSearchBase=dc=unb,dc=ca \
-a defaultSearchScope=sub \
-a serviceSearchDescriptor=group:ou=posixGroups,dc=unb,dc=ca \
-a "serviceSearchDescriptor=shadow:ou=people,dc=unb,dc=ca?sub?objectClass=shadowAccount" \
-a "serviceSearchDescriptor=passwd:ou=people,dc=unb,dc=ca?sub?objectClass=posixAccount"

The attributes are pretty self-explanatory, but I will comment on a couple.

-a serviceSearchDescriptor=group:ou=posixGroups,dc=unb,dc=ca

A serviceSearchDescriptor allows you to remap where the ldapclient libraries look for certain information. For instance, we keep group information in the posixGroups OU, where other IT departments might keep it in the groups OU, which is the default. The argument seen above is simply the search base to use when searching for group information.

The serviceSearchDescriptor argument allows you to pass more that just a search base. For example:

-a "serviceSearchDescriptor=passwd:ou=people,dc=unb,dc=ca?sub?objectClass=posixAccount"

Here, the serviceSearchDescriptor is being directed to the people OU for a search base, but it will do a sub search (it could also be one or base), and the search filter to use is objectClass=posixAccount. We can lock this down even further to ensure that only certain people gain access to the system by adding an entitlement search to the filter:

-a "serviceSearchDescriptor=passwd:ou=people,dc=unb,dc=ca?sub?
(&(objectClass=posixAccount)(eduPersonEntitlement=urn:mace:unb.ca:unixadmin\?1)"

Note that I had to escape the ? In the search filter. The ldapclient utility will pick this up as a delimiter, and attempt to treat everything after the ? as the next argument.

At this point, it is safe to remove the hosts file entry for your LDAP server. You should also take a look at the nsswitch.conf file to ensure that dns resolutions are taking place against files and DNS, rather than LDAP.

PAM Configuration

Lastly, you will need to configure PAM to look at ldap for authorizing client logins. In /etc/pam.conf, find the lines that contain something like the following:

service auth required pam_unix_auth.so.1

and change them to read:

service auth binding pam_unix_auth.so.1 server_policy

and add this line immediately following each changed line:

service auth required pam_ldap.so.1

Once again, do the same as above for the lines containing account instead of auth.

Add server_policy to the end of the following line:

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/ for information about the nature of the problem. If you have any questions about certain entries in the pam.conf file, check the pam_ldap (5) manpage. As well, more information about the ldapclient utility can be found in the ldapclient (1M) manpage.