We recently upgraded our 10.4.11 server to 10.5.6 via a clean install of the os and an archive/restore of the LDAP database.

The server is part of a ‘magic triangle’ system with the AD supplying user accounts and the KDC, and the OD doing it’s mcx management thing via computer lists. DNS is supplied elsewhere on the network.

The server has not changed ip or hostname, and both forward and reverse DNS still resolve happily.

The server was created as a standalone server, then bound to the AD.
dsconfigad -enableSSO was run next, the server was promoted to an OD master, and the old database was restored via the archive and restore function.

Authenticated binding is required on the server, but SSL is disabled and cleartext authentication is allowed.
Binding and management work fine for existing and new 10.5 clients, however no 10.4 clients can be managed.

Although a new 10.4 client appears to bind successfully, and has a record added to the LDAP database, using dscl to navigate to the bound server from the client results in an ‘invalid path’ error.

All existing 10.4 clients that were bound previously exhibit the same behaviour

Enabling directory service debugging on the client shows an awful lot of output, however some highlights include:

CLDAPNode: Successful SASL Method Retrieval
CLDAPNode: Attempting GSSAPI Authentication
CLDAPNode: Error Getting TGT [i]/snip, kerberos server is shut down on the ldap server + not used for binding[/i]
CLDAPNode: Couldn’t get Kerberos credentials for GSSAPI
CLDAPNode: Failed GSSAPI Authentication for dn:cn=mycomputername,cn=computers ,dc= [i]/snip search base of server[/i]
CLDAPNode: Attempting CRAM-MD5 Authentication
CLDAPNode: Failed doing SASL Authentication in Replica retrieval [i]// Is this where it’s failing?[/i]
CLDAPNode: BindProc SETTING kConnectionUnsafe 1
CLDAPNode: checking failed node: ourServer returned bindStatus: -14006
Plugin call “dsOpenDirNode()” failed with error = -14002

On the server in the LDAP log i get

slapd[43499]: SASL [conn=72] Failure: no user in database mycomputername

however i can search from the client machine with ldapsearch -x for the cn matching mycomputername and it finds it successfully

doing a mkpassdb -dump

doesn’t throw up much, the IDs and key match the LDAP records – only odd thing i’ve noticed is there are duplicates for the directory admin user, server record and root user at the bottom as ‘overflow’ slots.

Any ideas?