Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I'll try to keep this short, but informative.

I'm currently unable to bind OSX lion (10.7.4) machines to our AD. OSX kerberos (heimdal) is unable to locate the KDC service.

However i can bind linux & windows machines to the AD without any problems in the same network

AD controls the domain DNS and all the relevant _kerberos._tcp.x.domain.com and _kpasswd SRV DNS records are there and resolve fine when tried from OSX machines. Defined ports are open for service and manually accessible from OSX.

When i try kinit in the OSX, i can get the first auth through (wrong passwords fail instantly), but when supplied with correct password, kinit fails after some waiting with "unable to reach KDC".

  • All machines run NTP and have correct time.
  • During testing, network is not firewalled between the machines
  • Linux and windows machines have no problems whatsoever
  • I have tried with and without /etc/krb5.conf - OSX by default does not need it
    • in the krb5.conf i used a working config from one of our linux machines.
  • dsconfigad fails with simple "connection failed to the directory server"

I'm a bit baffled with this. OSX is like the KDC is nowhere to be found and at the same time my test machines with windows 7 and some linux (centos 6 & debian 6) machines have no problems whatsoever. Same network, same configurations.

I'm missing some vital piece of configuration somewhere, and i can't find out what it is.

share|improve this question
    
This question might be a better fit for Server Fault, as it sounds like a corporate network/infrastructure issue. If you agree, just respond to this comment and I'll move this question over. (Don't cross-post) –  Daniel Beck Aug 31 '12 at 15:00
    
Does your AD domain name end in ".local"? If so, you may be having trouble with OS X using Bonjour instead of regular DNS to look up the servers. –  Gordon Davisson Sep 1 '12 at 2:32
    
@DanielBeck Yes, it's a corporate infra-related question. I posted it to superuser due to AD involvement. –  Temotodochi Sep 3 '12 at 5:45
    
@GordonDavisson No, we don't use .local as domain. I know some of the issues related to .local and didn't implement it. –  Temotodochi Sep 3 '12 at 5:46

2 Answers 2

There are many possibilities for why that's happening, although it seems to be AD related as you've mentioned. I would try a few simple things initially, since sometimes it's not always obvious that might actually be the cause of the issue.

Try re-generating your AD preferences file:

cd /Library/Preferences/DirectoryService
sudo mv ActiveDirectoryDynamicData.plist ActiveDirectoryDynamicData.plist.old
sudo killall DirectoryService

That will backup and recreate the preferences. If that doesn't work then check to see what AD info you get from this command:

dscl /Active\ Directory/All\ Domains -list /Users

Lastly, you can get much better idea of the cause of your issue from the debug log:

tail –f /Library/Logs/DirectoryService/DirectoryService.debug.log | grep 
share|improve this answer
up vote 0 down vote accepted

Thanks for the suggestions, however in the end this resulted to be a routing error. AD has several interfaces to different networks to carry out different tasks within them.

Connecting from network A to network B where AD service interface is wont work if the AD also has a interface to network A, since connection tracking apparently does not work in such way by default.

So, user error, i guess.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.