Can no longer mount SMB Share using AD authentication

Hello, We are running 10.6.4 and have afp and smb shares on 1 Xserve. Our users authenticate via AD Auth. As of Right now AFP user can connect but windows users... SMB Users cannot. They get a You do not have permission to access the server message. Here is the Log

OK. May have a fix. Have not implemented but a previous forum poster mentioned Apples very old Samba version that ships with 10.6 server. It has problems with W2K's encryption settings. Change setting from "always" to "let server and client hash it out".

I'm having the same issue as of Oct 25 (we're closed on the weekend, so it's possible something happened on the weekend or earlier), however I'm using a 10.4.11 server bound to AD (Windows 2003 Server). Prior to this issue, SMB worked so long as I configured the AD controllers' group policy as follows:

When I do a kinit username and then klist, I definitely get a Kerberos ticket, and AFP and terminal/login works fine with my AD account -- it's just the SAMBA client that's failing (to be more precise, it's the SAMBA server on Mac OS X which is not dealing with authentication properly). If I create a sever local or Open Directory account, both of those work fine with SMB...it's just AD authentication which is suddenly broken again on all my servers.

When I came in Monday morning, everything was mysteriously working again. On Friday, I double-checked all the AD servers (9 secondary, 1 primary) were configured to negotiate encryption (as I outlined in a previous post), but didn't make any changes. I also restarted the primary domain controller, but despite all this I still was unable to use SAMBA on my Mac OS X Server with AD accounts when I left work on Friday.

Some timer obviously expired over the weekend, but I don't know which one...and that worries me...

No amount of jiggery-pokery with auth methods resolved it, so I decided to delve into the smb configuration file on the server.

I made a change that caused smb to fail to startup.

I reverted the change and smb launched and everyone could authenticate again. Odd. I wonder if there isn't some cached data that gets corrupted, but gets wiped out after launch failure............

I have in the past attempted to stop/start smb from the GUI and from the command line, with brutal ol' kill -9 and even HUPed a few times with no success. I guess further testing along the launch failure path will have to wait until the next auth problem.

mohanfmg Appears to have the correct answer. I have had the same problem as described in the first post. Neither Mac or Windows clinets can access the 10.6.x server using smb and our 2008 AD R2 auth server. However if you create a DNS record for your Apple server in the AD DNS and then login to the server using its network name instead of IP. the AD auth works. On Mac you log in as normal, on win 7 you can map a network drive using network discovery, with no issues. Hope this helps.

2. The SAMBA Secrets file was seriously messed up (in Terminal, do a "sudo tdbdump /var/db/samba/secrets.tdb" to see the contents of that file - it should contain a line for your AD domain), so I had to delete ("sudo slapconfig -destroyldapserver" then "sudo rm /var/db/samba/secrets.tdb" ) the file and rebind to AD (finish with "sudo dsconfigad -enablesso" and "tdbdump /var/db/samba/secrets.tdb" to verify the file's OK now).

3. DNS is crucial, and I'm not sure what happened but one day all the forward lookups in AD stopped working...but only for my bound Mac OS X servers. It's bizarre - the entry is there, but DNS doesn't know about it. I'm still working on this one since I don't administer my AD domain and this isn't a high priority for my AD admin.

More Like This

Retrieving data ...

This site contains user submitted content, comments and opinions and is for informational purposes only.
Apple may provide or recommend responses as a possible solution based on the information provided; every potential issue may involve several factors not detailed in the conversations captured in an electronic forum and Apple can therefore provide no guarantee as to the efficacy of any proposed solutions on the community forums.
Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. All postings and use of the content on this site are subject to the Apple Support Communities Terms of Use.