Troubleshooting Open Directory with Panther Server

—by Joel Rennich, mactroll@afp548.com

16 November 2003

Note: several lines in this article are extremely long. In order to keep the article readable, we’ve broken them into multiple segments, each of which is terminated with “ \".

It has been my experience, especially with a upgrade installs of Mac OS X Server, that you can potentially run into a situation where you are unable to authenticate to the LDAP domain even though you exist in it as a user. You can look but you can’t touch. The kicker with this problem is that since you don’t have enough rights to change the LDAP database you can’t set yourself up for authentication.

So, what to do?

You might be able to easily overcome this. First you need to get the authentication information for the admin user that you think should be able to validate. Use Workgroup Manger (WGM) to connect to the LDAP domain. Now enable the Inspector, if you haven’t already in the WGM preferences. The Inspector shows up as the bulls eye icon in the tabs and will allow you to browse the entire LDAP datbase natively.

Select the user you want to make work and use the inspector to look at the Authentication Authority attribute. There should be one in here that starts with ;ApplePasswordServer;. This value tells Open Directory (OD) to authenticate this user using the SASL password server (SPS). Copy the value down somewhere. For example here’s a sample value.

;ApplePasswordServer; \
0x3fa7cd2177ffc9ee0000000200000002,1024 35131169760837896964443989720147060 \
269341807662581552016004295625710543622363725674879570378125222497598485431 \
381098386798556836691255284441980896942667431927355057474432120018056150978 \
023187598323738563876918151350059498761993360135892443334154251358551704753 \
564678473013272522904529443575099568676266766707971 root@panther.afp548.com:10.1.0.1

Pay careful attention to the first value after ;ApplePasswordServer;, in our case 0x3fa7cd2177ffc9ee0000000200000002. This is your SPS ID. This is what OD is going to try to use to authenticate you to the SPS when you log in. If it’s off, as it probably is if you are reading this, you won’t be able to authenticate.

Now you need to find out what your SPS ID should be. Head on down to the command line.

sudo mkpassdb -dump

This will return a listing of all your users and their password ids that have advanced passwords.

For example:

signature: pwfi
version: 1
entrySize: 0
sequenceNumber: 4
numberOfSlotsCurrentlyInFile: 512
deepestSlotUsed: 4
deepestSlotUsedByThisServer: 4

Access Features:
usingHistory=0 usingExpirationDate=0 usingHardExpirationDate=0 requiresAlpha=0 \
requiresNumeric=0 expirationDateGMT=4294967295 hardExpireDateGMT=4294967295 \
maxMinutesUntilChangePassword=0 maxMinutesUntilDisabled=0 maxMinutesOfNonUse=0 \
maxFailedLoginAttempts=0 minChars=0 maxChars=0 passwordCannotBeName=0

Weak Authentication Methods:
SMB-NT
SMB-LAN-MANAGER
CRYPT
APOP

Public Key: 1024 35 131169760837896964443989720147060269341807662581552016004295 \
62571054362236372567487957037812522249759848543138109838679855683669125528444198 \
08969426674319273550574744321200180561509780231875983237385638769181513500594987 \
61993360135892443334154251358551704753564678473013272522904529443575099568676266 \
766707971
root@jagserver.example.com


Replica Name: (Parent)

slot 0001: 0x00000000000000000000000000000001 admin 11/04/2003 04:51:10 PM
slot 0002: 0x3fa7cd2177ffc9ee0000000200000002 user1 11/04/2003 11:00:33 AM
slot 0003: 0x3fa7cd2d243c6f9e0000000300000003 user2 11/04/2003 11:00:45 AM
slot 0004: 0x3fa7cd3532b0a7d00000000400000004 user3 11/04/2003 11:00:53 AM

The key pieces here are the Public Key section and the entry at slot 0001.

First off take a look at slot 0001. This should reference a user, in the above case “admin,” that is a SASL admin and is able to make changes to the SASL database. You combine this with your Public Key for the SASL server to create the authentication authority attribute for the user. You should now begin to see your problem. The authentication authority value for your admin user that is stored in the LDAP database is not the same as the SPS ID that the SPS knows the user by. Therefore you can’t log in.

Now for the sneaky part. You know what the ID should be, but you can’t change the LDAP database, or can you?

If you look inside of the Mac OS X LDAP config file, you’ll need to be root to do this, you’ll see there is an entry for the LDAP root user. Look for the “rootdn” entry in /etc/openldap/slapd_macosxserver.conf file. Underneath this will be a password hash. You can use this to authenticate to the LDAP server and edit the admin user authentication authority entry to match the SPS ID that you got from the SPS. Chances are this references the root user and has the password you think the root user should have. However, if that isn’t the case you can reset the password here. The simpliest way, although by no means the most secure, is to swap the MD5 hash at “rootpw” with a plain text password.

You’ve got all the pieces. Now we just need to put them together. First make the SPS ID for the user. Take a look at the one you harvested out of WGM for reference, but essentially it’s ;ApplePasswordServer;, then the hex SPS ID for the user followed by the SPS Public Key. Finally you can add the server’s IP address which is used if DNS goes out. In our example this would work out to be:

;ApplePasswordServer; \
0x00000000000000000000000000000001,1024 35 1311697608378969644439897 \
20147060269341807662581552016004295625710543622363725674879570378125 \
22249759848543138109838679855683669125528444198089694266743192735505 \
74744321200180561509780231875983237385638769181513500594987619933601 \
35892443334154251358551704753564678473013272522904529443575099568676 \
266766707971 root@jagserver.example.com:10.1.0.1

You can put that into an ldif file. This is a standard file format used to load info into an ldap database. So open up a text editor and make it. All you need is two lines. The first is the DN of the user, in other words their full LDAP name, and then the SPS ID. For example:

dn: uid=admin,cn=users,dc=example,dc=com
AuthenticationAuthority: ;ApplePasswordServer; \
0x00000000000000000000000000000001,1024 35 1311697608378969644439897 \
20147060269341807662581552016004295625710543622363725674879570378125 \
22249759848543138109838679855683669125528444198089694266743192735505 \
74744321200180561509780231875983237385638769181513500594987619933601 \
35892443334154251358551704753564678473013272522904529443575099568676 \
266766707971 root@jagserver.example.com:10.1.0.1

Save this as a plain text file. In our example will call it goodinfo.ldif

Now you can load it in using the root DN that you pulled from the slapd_macosxserver.conf file.

ldapmodify -x -D “uid=root,cn=users,dc=example,dc=com” -W -f goodinfo.ldif

This will prompt you for your password which will be the one for the LDAP root user.

If all went well, you’ve reset the authentication authority for the admin user in the SPS. Reboot the machine and then log into WGM as that user and you should now be an authenticated SPS admin to the LDAP domain.