Botched AD directory migration – can get KRBTGT but no further tickets for other servers etc…

[mgb123]

Last night, and against my better judgement, I migrated a 10.5.6 server from one AD domain to another.

The original domain was corp.domain, the new one, bosapparel.net.

The migration was going well, or so I thought. I’d unbound from the directory, demoted to a standalone server, run changeip to switch the fqdn, re-bound to the new domain, enabled SSO and then promoted to an OD master.

Then I noticed that Kerberos wasn’t running, so I unbound, restarted, rebound, and poof, it was running – all was good.

I proceeded to test and found that single sign on wasn’t working on the clients that I was test binding to the new AD domain, and OD server.

I suspected that old entries from the old corp.domain server iteration of the server shouldn’t exist in the DSCL – so I foolishly did all of this:

You must be ‘root’ to do this:

slapconfig -destroyldapserver

rm -rf /private/var/db/krb5kdc

mkdir -m 700 /private/var/db/krb5kdc

rm -rf /etc/krb5.keytab

rm -rf /Library/Preferences/edu.mit.kerberos

rm -rf /Library/Preferences/com.apple.AppleFileServer.plist

dscl

>cd /Local/Default/Config

>delete Kerberos:SERVER.DOMAIN.TLD

>quit

Then run all on one line (may be wrapped here):

slapconfig -createldapmasterandadmin diradmin “Directory Administrator” 1000 dc=server,dc=domain,dc=tld SERVER.DOMAIN.TLD

Where ‘SERVER.DOMAIN.TLD’ is the FQDN of the server.

Which ensured that my server would no longer get Kerberos up and running.

I restored those few files from Time Machine, but have a number of log entries that don’t seem to jive, and client machines that though bound, aren’t able to take advantage of SSO.

From KDC:
Aug 26 08:19:22 mawsmacfp1.bosapparel.net krb5kdc[101](info): TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 10.30.241.10: UNKNOWN_SERVER: authtime 1251289162, [email protected] for krbtgt/[email protected], Server not found in Kerberos database

From Slapconfig.log
WARNING: no policy specified for fcsvr/[email protected]; defaulting to no policy
WARNING: no policy specified for pcast/[email protected]; defaulting to no policy
WARNING: no policy specified for vnc/[email protected]; defaulting to no policy
WARNING: no policy specified for cifs/[email protected]; defaulting to no policy
WARNING: no policy specified for ldap/[email protected]; defaulting to no policy
WARNING: no policy specified for xgrid/[email protected]; defaulting to no policy
WARNING: no policy specified for vpn/[email protected]; defaulting to no policy
WARNING: no policy specified for ipp/[email protected]; defaulting to no policy
WARNING: no policy specified for xmpp/[email protected]; defaulting to no policy
WARNING: no policy specified for XMPP/[email protected]; defaulting to no policy
WARNING: no policy specified for host/[email protected]; defaulting to no policy
WARNING: no policy specified for smtp/[email protected]; defaulting to no policy
WARNING: no policy specified for nfs/[email protected]; defaulting to no policy
WARNING: no policy specified for http/[email protected]; defaulting to no policy
WARNING: no policy specified for HTTP/[email protected]; defaulting to no policy
WARNING: no policy specified for pop/[email protected]; defaulting to no policy
WARNING: no policy specified for imap/[email protected]; defaulting to no policy
WARNING: no policy specified for ftp/[email protected]; defaulting to no policy
WARNING: no policy specified for afpserver/[email protected]; defaulting to no policy

From Single Sign on tools log
Kerberos configuration is up to date
Kerberos configuration is up to date
Kerberos configuration not updated, cannot contact all nodes on search path
Kerberos configuration not updated, cannot contact all nodes on search path
Kerberos configuration not updated, cannot contact all nodes on search path

The result of all this mess, is that I am given a ticket for the bosapparel.net domain, but that TGT doesn’t actually get me any more tickets. It’s odd.

I’m clueless here – my specialty is not directory services, and it’s certainly not domain migrations. Help?!

[mosa]

I had a similar issue, where I was able to get an initial ticket, but trying to connect to further servers did not work with SSO.

It did however work with a hand full of our File servers. After trying everything, I remembered someone telling me “DNS, DNS, DNS, DNS, DNS”, so I looked through the DNS an voila! There was no reverse look up entry for some of the file servers. After adding the entry SSO worked fine.

[samsungcon]

You have to give the reverse lookup value for the DNS server and i am sure your problem will be solved.i also faced the same provblem 3 months back i just gave the reverse lookup value and my problem got solved.

__________________
[URL=http://www.webtrends.com/Products/Optimize.aspx]Multivariate Testing[/URL] | [URL=http://www.inin.com/ProductSolutions/Pages/Interaction-Dialer.aspx]Predictive Dialer[/URL]

[Author]

Posts