replication/password problems 10.4.11 ODmaster

[mosx86]

While looking into the issue that our replica fails to authenticate users if the OD Master it replicates is down, I discovered that the password database on the replica did not match that of the master. Essentially, password slots were filled on the replica that weren’t filled on the master and vice-versa (about 44 mismatches in total).

I also found between 40-50 user and host entries that no longer existed in our ldap database in the master file, as well as some overflow files.

I decided that I should trim out the offending slots and rebuild the replica. The master and replica are 10.4.11.

So here is what I did (after making an archive of the master using server admin):

On the OD master I ssh’d in and sudo’d to root.

Stopped slapd:

[i]launchctl unload /System/Library/LaunchDaemons/org.openldap.slapd.xml
[/i]
Stopped slurpd:

[i]launchctl unload /System/Library/LaunchDaemons/org.openldap.slurpd.xml[/i]

Stopped password server:

[i]NeST -stoppasswordserver[/i]

Once I verified that the above services had shutdown, I deleted the offending slots using:

[i]/usr/sbin/mkpassdb -deleteslot [b]0xslotID[/b][/i]

Once the slots were deleted, I restarted the password server and restarted slapd:

[i]passSTART=”NeST -startpasswordserver”
ldapSTART=”launchctl load /System/Library/LaunchDaemons/org.openldap.slapd.xml”[/i]

I didn’t restart slurpd because I was intending to rebuild the replica.

At this point, password server didn’t come up and I had to restart it. There was a strange issue where I could authenticate in as the diradmin, but I didn’t have rights to modify accounts. Possibly Directory Services related? I ended up restarting and everything came up clean. I was able to authenticate with my account and several of my test accounts.

I then logged into the replica and using Server Admin, I demoted the replica to standalone server. Once that completed, I switched it back to replica and entered my diradmin info and associated passwords.

The system sync’d with no errors reported, but now suddenly I could no longer authenticate as my user or test accounts. The password service logs showed password errors and a password reset corrected the issues.

We’ve got roughly 2600 accounts. Not all the passwords were affected, but out of my test accounts about 80% were borked. I decided to shut the replica down (demoted back to standalone) and restored the master from the archive I had made earlier that evening. Password issue persisted.

Right now, our only solution is to reset passwords to get people back up and running, and the initial problem of the replica is still out there…

What I don’t understand is how the replication process killed a good percentage of passwords on the server. Beyond that, why are the password databases on the master and replica getting out of sync? Can I up the log levels for replication, directory services and the password server?

[Author]

Posts