Previous 1 2 Next 15 Replies Latest reply: Feb 5, 2014 10:48 AM by Jeffy3Be
jrr316 Level 1 Level 1 (0 points)
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:replyspnegokerberos(340)
Failed to verify incoming ticket with error NTSTATUS_LOGONFAILURE!
[2010/10/23 10:08:00, 1, pid=1040] /SourceCache/samba/samba-235.4/samba/source/libads/kerberosverify.c:ads_verifyticket(428)
adsverifyticket: smbkrb5_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:replyspnegokerberos(340)
Failed to verify incoming ticket with error NTSTATUS_LOGONFAILURE!
[2010/10/23 10:10:04, 0, pid=1277] /SourceCache/samba/samba-235.4/samba/source/lib/opendirectory.c:getopendirectoryauthenticator(247)
failed to read DomainAdmin credentials, err=67 fd=15 errno=2


Any help would be appreciated....

Xserve, Mac OS X (10.6.4)
  • BoyHowdyDoo Level 2 Level 2 (380 points)
    Same here. Only POSIX has access. Not sure when it started as I was testing AFP/ SMB and Adobe issues and spoofed domain user. No access. Checked permissions and all are as expected.
  • BoyHowdyDoo Level 2 Level 2 (380 points)
    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".
  • Julian Daniel Level 1 Level 1 (80 points)
    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.
  • Julian Daniel Level 1 Level 1 (80 points)
    If I do "smbclient -L my.server.domain.name" it lists all the shares and printers, so it's just an AD authentication issue.
  • Julian Daniel Level 1 Level 1 (80 points)
    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...
  • Julian Daniel Level 1 Level 1 (80 points)
    Our Active Directory admin just ran the Microsoft Security Configuration Wizard, and now our Macs are again unable to use Mac OS X Server's SMB with AD authentication (but AFP with AD authentication is fine).
  • Julian Daniel Level 1 Level 1 (80 points)
    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.
  • morxxer Level 1 Level 1 (0 points)
    IS the AD an 2008 R2 ?
  • huberp Level 1 Level 1 (10 points)
    Has anyone made any progress with this issue? Still no SMB access with authentication through AD :\
  • Michael Wineke Level 1 Level 1 (5 points)

    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.

  • mohanfmgi Level 1 Level 1 (0 points)

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

  • Michael Wineke Level 1 Level 1 (5 points)

    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.

  • schlichter11 Level 1 Level 1 (0 points)

    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.   

  • Julian Daniel Level 1 Level 1 (80 points)

    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.

Previous 1 2 Next