Configuring a Basic LDAP Server + Client in Solaris 11

Configuring the Server
Solaris 11 ships with OpenLDAP to use as an LDAP server. To configure, you're going to need a simple slapd.conf file and an LDIF schema file to populate the database. First, let's look at the slapd.conf configuration:

# cat /etc/openldap/slapd.conf
include         /etc/openldap/schema/core.schema
include         /etc/openldap/schema/cosine.schema
include         /etc/openldap/schema/inetorgperson.schema
include         /etc/openldap/schema/nis.schema

pidfile         /var/openldap/run/slapd.pid
argsfile        /var/openldap/run/slapd.args

database        bdb
suffix          "dc=buford,dc=hillvalley"
rootdn          "cn=admin,dc=buford,dc=hillvalley"
rootpw          secret
directory       /var/openldap/openldap-data
index           objectClass     eq

You may want to change the lines suffix and rootdn to better represent your network naming schema. My LDAP server's hostname is buford and domain name is hillvalley. You will need to add additional domain components (dc=) if the name is longer. This schema assumes the LDAP manager will be called admin. Its password is 'secret'. This is in clear-text just as an example, but you can generate a new one using slappasswd:

[paulie@buford ~]$ slappasswd
New password: 
Re-enter new password: 
{SSHA}MlyFaZxG6YIQ0d/Vw6fIGhAXZiaogk0G

Replace 'secret' with the entire hash, {SSHA}MlyFaZxG6YIQ0d/Vw6fIGhAXZiaogk0G, for the rootpw line. Now, let's create a basic schema for my network.

# cat /etc/openldap/schema/hillvalley.ldif
dn: dc=buford,dc=hillvalley
objectClass: dcObject
objectClass: organization
o: bufford.hillvalley
dc: buford

dn: ou=groups,dc=buford,dc=hillvalley
objectCLass: top
objectClass: organizationalunit
ou: groups

dn: ou=users,dc=buford,dc=hillvalley
objectClass: top
objectClass: organizationalunit
ou: users

dn: cn=world,ou=groups,dc=buford,dc=hillvalley
objectClass: top
objectClass: posixGroup
cn: world
gidNumber: 1001

dn: uid=paulie,ou=users,dc=buford,dc=hillvalley
objectClass: top
objectClass: account
objectClass: posixAccount
objectClass: shadowAccount
cn: Paul Johnson
uid: paulie
uidNumber: 1001
gidNumber: 1001
homeDirectory: /paulie/
loginShell: /usr/bin/bash
userPassword: secret

I've created a single group, world, and a single user, paulie. Both share the uid and gid of 1001. LDAP supports lots of additional variables for configuring a user and group account, but I've kept it basic in this example. Once again, be sure to change the domain components to match your network. Feel free to also change the user and group details. I've left the userPassword field in clear-text as 'secret'. The same slappasswd method above applies here as well. It's time to turn on the server, but first, let's change some ownership permissions:

[paulie@buford ~]$ sudo chown -R openldap:openldap /var/openldap/

... and now ...

[paulie@buford ~]$ sudo svcadm enable ldap/server

Check that it worked:

[paulie@buford ~]$ svcs | grep ldap
online         12:13:49 svc:/network/ldap/server:openldap_24

Neat, now let's add our schema file to the database:

[paulie@buford ~]$ ldapadd -D "cn=admin,dc=buford,dc=hillvalley" -f /etc/openldap/schema/hillvalley.ldif
Enter bind password: 
adding new entry dc=buford,dc=hillvalley
adding new entry ou=groups,dc=buford,dc=hillvalley
adding new entry ou=users,dc=buford,dc=hillvalley
adding new entry cn=world,ou=groups,dc=buford,dc=hillvalley
adding new entry uid=paulie,ou=users,dc=buford,dc=hillvalley

That's it! Our LDAP server is up, populated, and ready to authenticate against.

Configuring the Client
I'm going to turn my example server, buford.hillvalley, into an LDAP client as well. To do this, we need to run the `ldapclient` command to map our new user and group data:

[paulie@buford ~]$ ldapclient manual \
-a credentialLevel=proxy \
-a authenticationMethod=simple \
-a defaultSearchBase=dc=buford,dc=hillvalley \
-a domainName=buford.hillvalley \
-a defaultServerList=192.168.1.103 \
-a proxyDN=cn=admin,dc=buford,dc=hillvalley \
-a proxyPassword=secret \
-a attributeMap=group:gidnumber=gidNumber \
-a attributeMap=passwd:gidnumber=gidNumber \
-a attributeMap=passwd:uidnumber=uidNumber \
-a attributeMap=passwd:homedirectory=homeDirectory \
-a attributeMap=passwd:loginshell=loginShell \
-a attributeMap=shadow:userpassword=userPassword \
-a objectClassMap=group:posixGroup=posixgroup \
-a objectClassMap=passwd:posixAccount=posixaccount \
-a objectClassMap=shadow:shadowAccount=posixaccount \
-a serviceSearchDescriptor=passwd:ou=users,dc=buford,dc=hillvalley \
-a serviceSearchDescriptor=group:ou=groups,dc=buford,dc=hillvalley \
-a serviceSearchDescriptor=shadow:ou=users,dc=buford,dc=hillvalley

As usual, change the host and domain names as well as the IP address held in defaultServerList and the proxyPassword. The command should respond back that the system was configured properly, however, additional changes will need to be made if you use DNS for hostname lookups (most people use DNS, so run these commands).

svccfg -s name-service/switch setprop config/host = astring: \"files dns ldap\"
svccfg -s name-service/switch:default refresh
svcadm restart name-service/cache

Now, we need to change how users login so that the client knows that there is an extra LDAP server to authenticate against. This should not lockout local worries. Examine the two files /etc/pam.d/login and /etc/pam.d/other. Change any instance of

auth required            pam_unix_auth.so.1

to

auth binding            pam_unix_auth.so.1 server_policy

After this line, add the following new line:

auth required           pam_ldap.so.1

That's it! Finally, reboot your system and see if you can login with your newly created user.