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:
Domain Member: Digitally encrypt or sign secure channel data (always) = disabled
Domain Member: Digitally encrypt secure channel data (when available) = enabled
Domain Member: Digitally sign secure channel data (when available) = enabled
Microsoft network server: Digitally sign communications (always) = disabled
Microsoft network server: Digitally sign communications (if client agrees) = enabled
Microsoft network client: Digitally sign communications (always) = disabled
Microsoft network client: Digitally sign communications (if server agrees) = enabled
Microsoft network client: Send unencrypted password to third-party SMB servers = disabled
However, something seems to have broken in the past several days.
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...
Something's broken with SAMBA...
server:~ root# net rpc GETSID
Unable to find a suitable server
server:~ root# net rpc info
Unable to find a suitable server
server:~ root# net ads testjoin
Join is OK
...but Kerberos is working fine, AFP authenticates no problem, and "login" in Terminal authenticates to Active Directory too.
In my own case, it appears as though NTLM authentication got munged.
This is put forth as a potential solution under the following circumstances:
Mac users can authenticate using AD accounts for AFP connections,
Mac users cannot authenticate using AD accounts for SMB connections,
Windows users cannot authenticate using AD accounts.
The SMB settings on my server were set to use:
NTLMv2 & Kerberos
I disabled NTLM, saved, and found:
Mac users could authenticate using AD accounts for AFP and SMB,
Windows users got an odd message about their ...new password... (?!!)
I reenabled NTLM, saved, and found:
Mac users could still authenticate using AD accounts for AFP and SMB,
Windows users could authenticate using AD accounts.
It should be noted that I'm using OS X 10.5.8 on my server, but there it is.
I hope it helps someone.
I have also faced the same problem. But i found way for Mac OS X Server 10.6.8 SMB Share authendicate Windows 2008 AD accounts.
I done coming below steps:
1. Xserver i have connect to windows 2008 AD. Apple Menu-> System preference -> Users & Groups->Login Options->Join.
2. I have create New share folder "Macintosh HD/Test" I have enabled SMB and AFP prtocols.
3. I have give AD user for that folder.
4. Then i have tried on windows "\\192.168.1.2\test/" It asked user name and password i have give correct information, It's not authendicated.
5. Then i have tried \\macserver.example.com\test\
6. It works Fine....
Hmmm... Several months later, and the same problem cropped up.
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.
In my case, I had thre separate issues:
1. The AD domain (someone else's job!) wasn't properly configured, and several domain controllers weren't syncing up. Invariably (and inexplicably), my Macs would authenticate against the ancient unsynced DC. This was finally fixed.
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.