Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

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

sesssetup.c:reply spnegokerberos(340)
Failed to verify incoming ticket with error NT STATUS_LOGONFAILURE!
[2010/10/23 10:08:00, 1, pid=1040] /SourceCache/samba/samba-235.4/samba/source/libads/kerberos verify.c:ads_verifyticket(428)
ads verifyticket: smb krb5_parsename(faculty$) failed (Configuration file does not specify default realm)
[2010/10/23 10:08:00, 1, pid=1040] /SourceCache/samba/samba-235.4/samba/source/smbd/sesssetup.c:reply spnegokerberos(340)
Failed to verify incoming ticket with error NT STATUS_LOGONFAILURE!
[2010/10/23 10:10:04, 0, pid=1277] /SourceCache/samba/samba-235.4/samba/source/lib/opendirectory.c:get opendirectoryauthenticator(247)
failed to read DomainAdmin credentials, err=67 fd=15 errno=2


Any help would be appreciated....

Xserve, Mac OS X (10.6.4)

Posted on Oct 23, 2010 7:10 AM

Reply
15 replies

Oct 29, 2010 1:08 PM in response to jrr316

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.

Nov 2, 2010 7:59 AM in response to Julian Daniel

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...

Jul 13, 2011 12:26 PM in response to jrr316

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

and

NTLM


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.

Feb 15, 2012 2:02 AM in response to jrr316

Hi,

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.... 🙂

Feb 15, 2012 9:13 AM in response to Michael Wineke

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. 😐

Mar 10, 2012 3:59 PM in response to mohanfmgi

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.

Mar 12, 2012 9:09 AM in response to jrr316

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.

Feb 5, 2014 10:48 AM in response to mohanfmgi

Your awesome, I searched very long time for an alternate answer to our situation. We have a Mac OS X (Snow Leaopard 10.6.8) server which PC users connect to for SMB shares. And the server is tied in to AD. It does not use Open Directory. It worked for the longest time, then the DNS server got all messed up and nobody could connect to the server at all. After the DNS was straightened out, everyone could connect again and then a couple days later Window users coudn't connect. Nothing has changed on the Mac OS X server side all all, so I am sure something again is up with the DNS or the Domain Controller. So instead of fighting with DNS again I wanted to find an alternative to connecting the window machines that would work. And then I read your post about using the full network server name (not just the name of the server), and to my amazement it worked instantly. I am not sure why all of a sudden the window machines using the IP address or just the server name could not connect anymore. Does anyone think it really does have to do with a faulty DNS or domain controller? But at least the full server name works, even we were fine for years with using the full name. Thanks again.

Can no longer mount SMB Share using AD authentication

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.