Solaris, LDAP, and you (part 1)

I’ve been fighting this for ages, and finally got something to start working today. Here’s what I did.

First, I gave up on Sun’s LDAP server. It’s a huge thing, quite possibly great for large-scale implementations, but we just want to authenticate ~100 users across ~100 hosts.

So I installed OpenLDAP, followed the stuff in the Quick Start guide to get a basic top-level thing going, and then created appropriate OUs for users and groups, e.g.:


dn: ou=People,dc=example,dc=com
objectclass: organizationalUnit
ou: People

You need to load the cosine, inetorgperson, and nis schemas if you want to do account-fu. Here’s an example account:


dn: uid=someuser,ou=People,dc=example,dc=com
objectClass: person
objectClass: posixAccount
objectClass: shadowAccount
uid: someuser
uidNumber: 5226
gecos: Some User
homeDirectory: /home/someuser
loginShell: /bin/bash
cn: Some User
sn: User
userPassword:: crypted-password
gidNumber: 603

It’s helpful to have at least one user in the thing before you start fiddling with clients, as then you can tell it’s working.

Finally, you need a user for Solaris to authenticate as:


dn: ou=LDAPusers,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: LDAPUsers

And:

dn: cn=solaris,ou=LDAPusers,dc=example,dc=com
objectClass: top
objectClass: person
cn: solaris
sn: LDAP User
userPassword:: somecrypt

Now it’s time to fiddle with the client.

First, ignore Sun’s documentation. The absolute dead-easiest way to make this work is to ensure that the LDAP cache manager is off and then frob the config files by hand. They should look a bit like this:


# /var/ldap/ldap_client_file
NS_LDAP_FILE_VERSION= 1.0
NS_LDAP_SERVERS= 10.132.3.149:389
NS_LDAP_SEARCH_BASEDN= dc=example,dc=com
NS_LDAP_AUTH= NS_LDAP_AUTH_SIMPLE
NS_LDAP_SEARCH_REF= NS_LDAP_FOLLOWREF
NS_LDAP_DOMAIN= example.com
NS_LDAP_SEARCH_DN= passwd:(ou=People,dc=example,dc=com)
NS_LDAP_SEARCH_DN= shadow:(ou=People,dc=example,dc=com)
NS_LDAP_SEARCH_SCOPE= NS_LDAP_SCOPE_SUBTREE
NS_LDAP_SEARCH_TIME= 30 NS_LDAP_CACHETTL= 3600


# /var/ldap/ldap_client_cred
NS_LDAP_BINDDN= cn=solaris,ou=ldapusers,dc=example,dc=com
NS_LDAP_BINDPASSWD= {NS1}somecrypt

Now you can change nsswitch.conf’s passwd line to look like this:

passwd: files ldap

Kick nscd (svcadm restart name-service-cache) and you should start seeing LDAP content show up, e.g.:


# listusers
someuser Some User
...

If things are working this far, you can try making the accounts active for login. Edit pam.conf and where you see a line with required pam_unix_auth.so.1 change it to binding pam_unix_auth.so.1 server_policy and add a line of the form required pam_ldap.so.1 immediately after.

This got me to the point of being able to log in to the host with LDAP-based accounts, though it is far from being a complete picture. You should also be able to use ldapaddent to inject data, though if you try anything but the passwd or group map you’ll find you need to create the top-level container in the directory first.

Popularity: 100% [?]

Back on Windows

Horror of horrors, I’ve wound up having to run Windows again at home and work.

For work it’s because I’m now ClearCase-boy, which means supporting developers who are running the Windows client. Plus I pretty much have to use Outlook, as the Linux speakers-to-Exchange are all less than ideal. Having two different environments with incompatible clipboards was driving me nuts.

At home it’s entirely down to World of Warcraft, or more to the point the crappy way it’s been interacting with sound on Linux. I’ve tried everything I can think of and while the stuttering can be kept to a minimum it can’t be eliminated.

As most of my work — at home and the office — is done inside web browsers and terminal sessions the underlying OS isn’t a huge deal. My partner continues to be happily running Gutsy on her desktop, and if I were also deaf I most probably would be too.

Popularity: 89% [?]