Unable to authenticate with diradmin in Workgroup Manager

I take it back - I do recall what was broken the last time I had this problem. See this thread: https://discussions.apple.com/thread/3134790

However, that is not my problem this time as I do not have multiple DNS entries pointing to the same physicall address.

Piling on in my research, I found that if I disable all of the options on the Binding tab in Server Admin for Open Directory, I can log into Workgroup Manager and bind using my admin account.

I started rooting around and saw that these options often cause issues - but I concluded that this was because my diradmin account was not kerberized. This was confirmed in log files.

I archived my Open Directory, reset to standalone, rebooted, then promoted back to Master. During the promotion process it gave me a nastygram about single sign on because of either a DNS problem or because SSO was already configured. Having reconfirmed that DNS was correct, I concluded that the issue was from the previous trip as a Master and decided that maybe I needed to rebuild Kerberos. Except that sso_util would not recognize any of my administrator logins, including diradmin. I found that diradmin being unrecognizable was strange....

So back into Workgroup manager, figuring that I would change the password type for diramin from crypt then back to Open Directory using the dropdown on the Advanced tab - except the dropdown was greyed out!

I found this article about diradmin password setting:

https://discussions.apple.com/thread/2221573?start=0&tstart=0

But even after trying this, the dropdown still stays grey (and in grey is says Open Directory password).

The dropdown is usable for all of the other users in Workgroup Manager.

Any ideas on how to enable the User Password Type dropdown in Workgroup Manager if it is grey?

Continuing on my quest... I found this Technical note from Apple about re-kerberizing:

http://support.apple.com/kb/HT3655

Interestingly, in step 3 where it says to remove realm information from kdc.conf, there wasn't any of my realm information. Argh!

So I completed all of the steps and executed the slapconfig command. This resulted in:

bash-3.2# slapconfig -kerberize -f --allow_local_realm diradmin <MYREALM>

diradmin's Password:

Could not resolve hostname <MYDOMAIN>

Skipping Kerberos configuration

Sounds like a dreaded DNS problem. It had been working correctly, but changeip -checkhostname confirmed a problem. Turns out that there were EXTERNAL DNS servers in the Network preferences in System Preferences as well as on the router. With my Split-brained DNS this caused problems (thank you again MrHoffman). So I changed them both to my DNS server INTERNAL IP address and added the external ones to the Forwarder IP Address in DNS. Now checkhostname -changeip returns a favorable result.

So after rebooting ran the slapconfig command again and got the same result. Argh. Cleared DNS caches. Still nothing.

So I tried nslookup.

nslookup <mydomain>

Server: 10.0.8.2

Address: 10.0.8.2#53

** server can't find <mydomain>: SERVFAIL

Where 10.0.8.2 is the fixed INTERNAL IP address.

However, nslookup on using the fixed IP address yields:

bash-3.2# nslookup 10.0.8.2

Server: 10.0.8.2

Address: 10.0.8.2#53

2.8.0.10.in-addr.arpa name = <mydomain>.

Scratching head here... changeip -checkhostname works, nslookup on the IP address works, but nslookup on the host name fails.

Turned out that the nslookup problem was a rather simple one, and of course related to DNS. In my <MYDOMAIN>.com zone I had a CNAME record that aliased <MYDOMAIN>.com to my server <MYSERVER>.<MYDOMAIN>.com. Turns out that DNS does not like to see that alias.

I was then able to run the kerberize command and everything ran without problems.

However, if I reenable Authenticated Binding and the checkboxes under Security (except Allow Users to Edit Their Own Information) on the Policies -> Binding tab of Open Directory and try to bind diradmin in Workgroup Manager, I get an error, this time even though I see a successful Kerberos login for diradmin. None of the other Open Directory logs hint at a problem.

Still digging...