OS X SMB auth failure on 10.4 and 10.5 OD via AD (vs Windows Server 2007?)

[xenedar]

I realize there’s a bunch of other SMB/AD-related topics here, and I’ve been through most of them, but not seen anything quite like what I’m experiencing, and a lot of the situations, eg: user home directories, PDCs, etc don’t apply here.

Okay, background:

We have an AD infrastruction, which was recently replaced and a new domain created. We’ve just had the fun of moving everything from one domain to another. The PCs seem to be able to go over easy enough as they can pick up more than one domain at a time, whereas Macs need to be either in one domain or the other. Anyway, got that sorted on client machines, less so on servers.

We don’t use Xserves/Mac OS X Server to host home directories – they’re all on Linux infrastructure via SMB. The Mac OS X Servers are not being used as PDCs or anything.

Our 3 Mac OS X Server 10.4.11 boxes are configured with one as an OD Master, the other two as replicas. All 3 were bound into the old domain, some shared areas were set up on those for some special needs. Users were able to mount on a Mac via AFP, or on a Mac or PC via SMB.

However, I’ve recently had to move the OS X Servers over to the new domain. Now that they’re over, SMB’s not working, from any machine – PC in the domain, Mac not in the domain, Mac in the domain… From the OD Master’s CLI:

dirt -u username -p password returns success
dirt -a nt -u username -p password returns “Error : eDSAuthFailed : (-14090)”

On the OD Master I can even kinit username and confirm that there’s a service principal for the AD domain, and then kdestroy to destroy it.

smb.conf has:
workgroup = [the domain]
realm = DOMAIN.COMPANY.COM
security = ads
auth methods = guest opendirectory
use spnego = yes
passdb backend = opendirectorysam guest

I’ve read other articles relating to 10.3 which indicate different attributes to these, and I’m reluctant to start inserting attributes borrowed from 10.3 into a 10.4 install, since they may well be deprecated.

There is also:
client ntlmv2 auth = no

I stopped SMB, manually changed it to yes, started SMB – no change. Server Admin has SMB configured for NTLM and NTLMv2/Kerberos, with LAN Manager off.

I’ve also observed the same behavior on a Mac OS X 10.4.11 box that is not part of this 3-server arrangement. It’s configured as an OD Master, but doesn’t have any replicas hanging off it, and is really just an AFP/SMB fileserver for temporarily dumping image files and so forth. Again, AFP but no SMB, and the following logged:

“… failed to authenticate with “dsAuthMethodStandard:dsAuthSMBNTKey” (-14090) :(”

Ditto for kinit and dirt – everything but dirt -a nt works.

All these servers indicate that they’re members of the domain in the Windows bubble of Server Admin. ie: Domain = DOMAIN, Realm = DOMAIN.COMPANY.COM.

The initial setup was done thusly:

1. Role: OD Master, created the OD domain
2. sso_util remove -k -a -p 3. rm /etc/krb5.keytab /Library/Preferences/edu.mit.Kerberos
4. Bind to domain
5. dsconfigad -enablesso

To change domains I simply unbound from the old domain, rebound to the new domain, ran dsconfigad -enablesso again.

Thing is, I’ve also observed this on a completely fresh Mac OS X Server 10.5.6 machine, a test server that has been bound directly to the new domain, without ever going into the old one. Again, configure as OD Master, and as is my understanding of 10.5.x, able to bind directly to AD as the OS is smart enough to shut off the OD KDC. Then, dsconfigad -enablesso.

On that very clean machine, dirt -u username still works, while dirt -a nt -u username still returns

Error : eDSAuthFailed : (-14090)

On the 10.5.6 test server, it also indicates, yes it’s a Domain Member, of the right Domain and the right Realm. I’ve heard Workgroup Master Browser being on can be a problem, so that’s (partially) off – the box has a ‘-” in it, and regardless of whether I tick it or untick it, it reverts back to a “-“. nmbd and smbd are both running.

And that’s literally all I’ve done on the server. Which kind of leads me to wonder if the new domain itself is to blame. The new domain infrastructure is apparently running on Windows Server 2007.

So, I’m baffled and stumped. The 3 Xserve Master/Replica and the standalone test box all set up so easily on our old domain (which is unfortunately now disallowing new machines trying to join, as they’re preparing to shut it down), but under the new domain, SMB just refuses to work.

Unfortunately it’s usually the case that I have to empirically prove the exact fault of the Active Directory infrastructure before anyone will look at it, so I guess the questions are:

* have I done anything ridiculously stupid here, or missed something that is supposed to get this running
* is it possible or even probable my gut feeling is right and it’s something in the new domain, that Windows 2007 behaves differently, and it’s not necessarily Mac OS X
* any suggestions for getting this working?

[xenedar]

Couple of extra bits of info:

1. I have changed my AD password, several times.
2. Users created in the OD domain have no problems, just AD users.
3. The AD domain is listed above the OD domain in the Directory Access/Directory Utility Authentication tab.
4. I’ve also tried this, with no success:

http://lists.apple.com/archives/macos-x-server/2007/Jan/msg00337.html

[jasonP]

I wish I had more to add to help you out but unfortunately I am chiming in that I have the exact same problem! This week we upgraded to AD 2008 from 2003. Mac clients that are bound to AD (all of them) can authenticate just fine. The problem is that all of our OS X servers sharing SMB stopped working. I ran through the exact same scenarios as you did except that ours are not OD masters. We simply bind our servers to AD and we have extended the AD schema for OS X. I think at this point I might need to contact Apple to see if they have any ideas.

[Tom H]

Its worth mentioning that :

– dirt -a nt -u user doesnt test NTLMv2

– Latest round of Windows OS’s only support NTLMv2 (out of the box) so its perfectly normal that dirt -a nt will fail.

Not much help… but maybe the dirt -a failing is a bit of a red herring.

Also SMB stored the machine password in a separate place to the Active Directory plugin, i would check that both places have the correct password, we know the AD plugin one is correct as proven by the dirt command.

sudo tdbdump /var/db/samba/secrets.tdb

should give you the samba machine password… you can compare this with the one in the ActiveDirectory.plist after converting it with the following command :

echo “thecopiedmachinepassword” | openssl enc -base64 -d

The two should match… without the correct machine password AD queries will fail and the user wont be authenticated.

Maybe during the rebind the samba machine password was not updated?

in 10.5 the machine password is changed every 14 days by default to fall inline with default M$ policys, 10.4 i believe does not support this.

[Tom H]

Just seen exactly the same problem… 😕

I cannot connect to any SMB shared by supplying a username and password, the same errors are seen in the logs…

However if i get a kerberos ticket for the user it works perfectly. Strange… i am also testing using a 2008 AD Domain.

[mcnaugha]

Did anyone ever solve this? I’m seeing the problem now as we’re moving all of our schools to 2008 R2. 10.6 and 10.7 work fine. 10.5.8 gets Kerberos ticket but seems unable to access the SMB service coming from the Windows servers. All Macs bound to AD. Kerberos working perfectly it seems.

[Author]

Posts