This hasn’t been much fun at all.
My research turned up something frustrating. I came across this in my migration from OSX 10.2->10.3 a few years back, and now it’s made an appearance in OpenDirectory.
Back in 10.2, if I wanted to get password hashes as root for migration, backups, whatever, I could use nidump passwd .] passwd.txt. It would look more or less like a FreeBSD master.passwd or a Linux /etc/shadow file. As of 10.3, using that gives you what would look like /etc/passwd, that is, instead of the password hash, you get an x. Of course you can’t do nidump shadow . or nidump master.passwd either. So I hosed the passwords of all of my imported users from FreeBSD. I wound up blowing away the box, installing 10.2, importing the users, then upgrading to 10.3. I got lucky back then.
Well, this time around they’ve hacked up OpenLDAP. If you attempt, even as a priveleged account, to pull the userPassword attribute, you will get asterisks. I logged in directly to the box, and did an ldapsearch like this:
ldapsearch -D ‘uid=root,cn=users,dc=oss-solutions,dc=com’ -b ‘cn=users,dc=oss-solutions,dc=com’ -x -W ‘objectclass=*’ uid userPassword
The response was frustrating to say the least:
dn: uid=tshadwick,cn=users,dc=oss-solutions,dc=com
userPassword:: KioqKioqKio=
uid: tshadwick
dn: uid=kshadwick,cn=users,dc=oss-solutions,dc=com
userPassword:: KioqKioqKio=
uid: kshadwick
dn: uid=lgriffith,cn=users,dc=oss-solutions,dc=com
userPassword:: KioqKioqKio=
uid: lgriffith
uid: lael
The userPassword field on all users is identical, this stupid KioqKioqKio=. Googling that string returns all sorts of people trying to debug LDAP issues on OSX, but I came across only one post that explains what is happening, which is that despite claiming to NOT use NetInfo (thus nidump, or NetInfo Dump), password hashes are stored in NetInfo, and CANNOT be accessed via LDAP in any way, shape, or form, not matter what user you are. What I have found in the past is that you can’t get at it via NetInfo either, so migrating users away from OpenDirectory becomes a sheer impossibility. You CAN auth users against straight up OpenLDAP on macs, I’ve done that before, but I didn’t realize Apple hid the userPassword attribute from everyone, including root.
This is where things get ugly though. When you set up OpenDirectory, you’ll set up your base dn, which defaults to dc=servername,dc=zone,dc=tld. If you’re wise, you changed this to be just dc=zone,dc=tld. You then have a pair of cn’s - cn=users, and cn=groups. If users are added via the Apple Workgroup Manager application, you get the setup described above, along with an apple-specific attribute named authAuthority, which will look something like this (edited to protect myself):
authAuthority: ;Kerberosv5;0x45fb046a76d88e290000000500000005;tshadwick@OSS-SO
LUTIONS.COM;OSS-SOLUTIONS.COM;1024 35 151065087552365604662078053629772612290
45125389744913980776132487212157823612004728815565315294408927808088960236758
82710557542789104971305777382703096824342050137771832808789442594222322573212
7494992662855xxxxxxxxxxxxxxxxxxxxxxxxxx4014428908067293849022
106544972630274236718090726484292219531 root@directory-server.oss-solutions.c
om:x.x.x.x
Apparently this is what Apple uses to tell OpenLDAP where to find the actual password hashes. What’s annoying however is that the utilities that generate this information are only available on OSX server, and secondly, presume that all users are going into cn=users,dc=zone,dc=tld. This is a problem because I want to keep company users separated from customers. I literally have cn=users,cn=customers,dc=zone,dc=tld, and a matching group entry. The apple utils won’t allow you to properly generate an account. Whenenver you go to remotely auth, EVEN IF you have the right hash in userPassword, if you didn’t go back and make it a ‘proper’ Open Directory account, the auth will fail. So the company accounts work for logging into webmin, or even into the Virtualmin box via ssh or login (once PAM was set up for said box), but the new accounts generated via LDAP Users and Groups fail. If you attempt to reset a password of a company user via LDAP Users and Groups, you will effectively lock that user out.
I’m looking at what I can do to right this situation, as I really only want to maintain a single LDAP structure, and by all rights what I’m doing should work. The fact that I’m having these issues is an act of idiocy. If there’s an authAuthority field, fine. If not, behave as LDAP should. What’s so hard about that? :