Paulie's World

Things I do ...

Configuring a Basic LDAP Server + Client in Solaris 11
by paulie
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/
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: 
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= \
-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  
auth binding   server_policy
After this line, add the following new line:
auth required 
That's it! Finally, reboot your system and see if you can login with your newly created user.
12:18 PST - February 21, 2013

Powered by Perl