OSX SMB & AD Kerberos problem

[cormierjohn]

Hello,

I am having a problem with trying to authenticate to Windows services on OS X 10.3.6 Server using an Active Directory-based Kerberos ticket.

The error message that is being reported in the server SMB error log is:

[2004/12/04 18:14:47, 2] /SourceCache/samba/samba-59/samba/source/passdb/pdb_interface.c:make_pdb_methods_name(654)
No builtin backend found, trying to load plugin
[2004/12/04 18:14:47, 2] /SourceCache/samba/samba-59/samba/source/lib/module.c:do_smb_load_module(63)
Module ‘/etc/pdb/opendirectorysam.so’ loaded
[2004/12/04 18:14:47, 2] /SourceCache/samba/samba-59/samba/source/smbd/reply.c:reply_special(208)
netbios connect: name1=ODTEST name2=ODCLIENT
[2004/12/04 18:14:47, 2] /SourceCache/samba/samba-59/samba/source/smbd/reply.c:reply_special(215)
netbios connect: local=odtest remote=odclient, name type = 0
[2004/12/04 18:14:47, 1] /SourceCache/samba/samba-59/samba/source/libads/kerberos_verify.c:ads_verify_ticket(74)
ads_verify_ticket: failed to fetch machine password
[2004/12/04 18:14:47, 1] /SourceCache/samba/samba-59/samba/source/smbd/sesssetup.c:reply_spnego_kerberos(174)
Failed to verify incoming ticket!
[2004/12/04 18:14:47, 2] /SourceCache/samba/samba-59/samba/source/smbd/server.c:exit_server(568)
Closing connections

The error message that is being reported client-side is:
Invalid name or password.

I looked around and tried a few things from the macwindows.com site at

http://macwindows.com/AD.html

So far, I’ve have done the following:

1. On my client, I have recieved a valid Kerberos ticket from AD that I can use to authenticate to Windows 2000 severs on the domain. I’ve also bound the client to AD using the AD plugin and am able to log in as the user to the local machine.

2. I’ve successfully bound the server to AD, using the AD plugin and also using the dsconfigad command for the purposes of testing.

3. I am able to mount shares successfully as a domain user if I do not use a kerberos ticket and use straight non-Kerberos authenticaiton

4. The computer record for the server is being successfully created in the domain.

5. Both the AD Server and the OS X server are time synchronized.

6. DNS is valid both forward and backwards for the OS X server.

7. I’ve modified the smb.conf file to include:
security = ADS
realm = MYREALM.STUFF
use spnego = yes

8. In the smb.conf file, the WORKGROUP proprerty is set to my realm name and the netbios name is set to the non-fully qualified computer name.

This is my sanitized smb.conf file:

[global]
workgroup = MYREALM.STUFF
display charset = UTF-8-MAC
print command = /usr/sbin/PrintServiceAccess printps %p %s
lprm command = /usr/sbin/PrintServiceAccess remove %p %j
security = ADS
guest account = unknown
encrypt passwords = yes
printing = BSD
allow trusted domains = no
preferred master = no
lppause command = /usr/sbin/PrintServiceAccess hold %p %j
netbios name = odtest
wins support = no
max smbd processes = 0
printcap =
server string = Mac OS X
lpresume command = /usr/sbin/PrintServiceAccess release %p %j
client ntlmv2 auth = no
domain logons = no
lpq command = /usr/sbin/PrintServiceAccess jobs %p
passdb backend = opendirectorysam guest
dos charset = CP437
realm = MYREALM.STUFF
unix charset = UTF-8-MAC
auth methods = guest opendirectory
local master = no
use spnego = yes
map to guest = Never
domain master = no
printer admin = @admin, @staff
log level = 2
[homes]
read only = no
comment = User Home Directories
browseable = no
[Groups]
create mask = 0644
inherit permissions = no
path = /Groups
directory mask = 0755
map archive = no
guest ok = 1
read only = no
comment = macosx

Can anyone think of anything else I should check or do?

Thank you.

[s_groening]

This is probably due to faulty settings in your W2K3 Server’s domain controller group policy.

make sure the following options are enabled/disabled:

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 tird-party SMB servers = disabled

This helped me reaching SMB SSO within my domain…. Samba takes care of the win2mac part of it just nicely, however the Mac OS X SMB client works in a different maner than smbclient, which by the way works without the above mentioned changes… oddly enough…

Best regards

Søren Grønning Iversen

[s_groening]

hmmm having read yor post once again, it strikes me that you have entered your realm as your workgroup…. This is not the way to do it properly -at least not if you are working on a subnet…. Enter the NT name for your domain/workgroup in uppercase, eg for my domain – lierderbrau.de – I would enter ‘workgroup = LIEDERBRAU’ and enter my ‘realm = LIEDERBRAU.DE’ separately which is supposed to be the sane method.

By the way, in my last post,I think I might have answered a completely different question than the one I now think you are really asking….

I have had no problems doing SSO from a windows client to my Mac OS X Server with the common smb.conf modifications done as described in Michael Bartosh’s excellent slide handouts from the Macosxlabs.org web cast last year.

security = ADS
realm = FOO.BAR.COM
workgorup = FOO
use spnego = yes

Best regards,

Søren Grønning Iversen

[boardski]

I’m seeing the same problem with 10.3.7. Doing my head in. I’ve made the changes to smb.conf with no luck at all. So if anyone has any ideas I’d love to hear them.

[s_groening]

-Have you tried making the suggested changes to the AD domain group policies?

I got the ‘invalid user name or password’ error right until that point. I am running 10.3.7 as well — both server and client.

[Author]

Posts