AFP548 - Topic: SMB Shares and AD authentication

This topic has 17 replies, 4 voices, and was last updated 19 years, 4 months ago by Anonymous.

Viewing 15 posts - 1 through 15 (of 17 total)

1 2 →

Author

Posts
August 18, 2004 at 8:43 pm #358839

Anonymous
Guest

Hi,

Can someone point me in the right direction. I have an Xserve running 10.3.3 bound to an AD domain running on Windows 2000. It’s bound OK, picking up users and groups, and Mac users can access the server using AFP fine with their AD passwords and usernames. However, no one can access the server over SMB, it comes up with errors on the PC or Mac that either say that the password is wrong or that you are not authorized to log in from this station.

If I log in from a Windows machine with a local password (eg the Xserve’s admin account) it works fine, it just doesn’t seem to work with any accounts from AD. I’ve tried a re-install, and I’ve tried Kerberizing SMB, but the problem still remains.

Any help would be gratefully appreciated.

Thanks,

J.P.

PS (If I update the Xserve to 10.3.5 it doesn’t pick up the AD groups, 10.3.3 does so have left it at that at the moment).

August 24, 2004 at 6:15 pm #358885

Anonymous
Guest

-UPDATE-

I’ve now got a little further but still no joy. It’s something to do with the way the AD plugin is setting up Kerberos. If I bind to AD, then change the edu.mit.Kerberos file by doing:

sudo kerberosautoconfig -r REALM -m AD SERVER -u

then run:

sudo net ads join

then Windows clients in the AD domain can connect successfully over SMB. Temporarily. Next time I restart WGM the Xserve loses all it’s user data (but keeps the groups!). Restarting the machine throws things off completely and opening WGM just gives an error -14002 (I think that number is right).

Anyone any ideas? The kerberos config files look decidedly different depending on whether AD picks them up or I manually create one. It just doesn’t seem to work properly with the edu.mit.Kerberos file that the AD plugin creates, however doing it manually throws off the AD plugin!

August 25, 2004 at 8:19 am #358900

Anonymous
Guest

Hi there,

Thanks for the reply. I’ve added all the bits to smb.conf that need to be there (I think). The realm, workgroup, security = ads and use spnego = yes. However even after doing that Windows uses can’t connect and I get “failed to verify incoming ticket” in the Windows logs.

I was trying everything, and I came across this example:

http://homepage.mac.com/carib_mendez/iblog/C1335627654/E1420382929/

This nearly works. Changing the edu.mit.Kerberos file (either adding in default_domain or creating a fresh one using kerberosautoconfig) and then using net ads join does stop the “failed to verify incoming ticket” error, and I did have Windows users logging in. However, it messes up the AD plugin, so WGM loses all the AD users. After that I get “unknown user” in the Windows logs. If I re-bind it re-creates the normal edu.mit.Kerberos file and the errors go back to “failed to verify incoming ticket”.

Thanks for any help,

J.P.

August 25, 2004 at 10:44 am #358902

Anonymous
Guest

Just as a bit more info:

Open Directory is sst up as Connected to a Directory System

Windows services are setup as a Standalone Server, there isn’t a WINS server on the network.

August 27, 2004 at 9:14 pm #358938

Anonymous
Guest

I seem to be talking to myself a fair bit these days

I was wondering if anyone could confirm this. I’ve been reading the Kerberos docs and SAMBA lists, and wanted to know whether it is the case that Mac OS X can’t decrypt tickets encrypted with RC4-HMAC. If it can’t, then that could be the problem, if it is supposed to be able to decrypt RC4-HMAC then I’m no further along. Next thing to try is forcing the AD to use DES encryption, but won’t be able to test that until the AD guy gets back from his holiday…

September 9, 2004 at 9:55 pm #359088

Anonymous
Guest

I just wanted to let you know that I have run into the exact same problem that you are seeing. I spoke with apple about it briefly but the information I got from them didn’t get me any closer to a solution.

September 13, 2004 at 2:13 pm #359118

ozpass
Participant

Have you tried disabling “digitally signed communications” on the Windows Server?

In Administrative Tools –> [Domain Controller Security Policy] –> Local Policies –> Security Options

AND

Administrative Tools –> [Domain Security Policy] –> Local Policies –> Security Options

Set the following entries to “Disabled” before rebooting the server (or doing a POLICY /secrefresh doo-dah)

Domain member: Digitally encrypt or sign secure channel data (always)
Domain member: Digitally encrypt secure channel data (always)
Domain member: Digitally sign secure channel data (when possible)

Microsoft network client: Digitally sign communications (always)
Microsoft network client: Digitally sign communications (if server agrees)

Microsoft network server: Digitally sign communications (always)
Microsoft network server: Digitally sign communications (if server agrees)

I can’t claim to have had the *specific* problems that you’re describing, but the above has always helped when connecting to SMB shares from OS X to the point where I use them as default settings whenever an OS X client is involved.

Hope it helps,
Regards,
Austin.

September 20, 2004 at 1:45 pm #359228

Anonymous
Guest

W.J.,

Nice to know it’s not just me I actually bumped into the guy who deals with their IBM AS400s and he had EXACTLY the same problem trying to tie them into their Kerberos domain. He said that he tried for a fortnight and then just gave up because it wasn’t working. He said that Kerberos on the AD domain was just broken and talking to a few other people we’re starting to think that that might be the issue. All the Macs (server and clients) bind to the domain OK, but Kerberos just doesn’t seem to work. There’s also the issue with groups not being picked up on anything above 10.3.3. All very weird.

ozpass,

Thanks for that, I’ll pass the info on to the client and see if that gets us anyway but I’m becoming more and more convinced that it’s something on the AD side is wrong. Worth a try though.

September 23, 2004 at 10:53 am #359289

Anonymous
Guest

[QUOTE BY= J.P.] W.J.,

Nice to know it’s not just me 🙂 I actually bumped into the guy who deals with their IBM AS400s and he had EXACTLY the same problem trying to tie them into their Kerberos domain. He said that he tried for a fortnight and then just gave up because it wasn’t working. He said that Kerberos on the AD domain was just broken and talking to a few other people we’re starting to think that that might be the issue. All the Macs (server and clients) bind to the domain OK, but Kerberos just doesn’t seem to work. There’s also the issue with groups not being picked up on anything above 10.3.3. All very weird.

ozpass,

Thanks for that, I’ll pass the info on to the client and see if that gets us anyway but I’m becoming more and more convinced that it’s something on the AD side is wrong. Worth a try though.

[/QUOTE]

Hi there!
Yes, I think we are not alone. I’m struggling with the very same looking problem for a couple of days now. (Samba 3.0.2 and Mac OS X 10.3.5 in a W2K3 environment). Either I can authenticate AD users at the Mac login dialog or I can successfully auth smb users (after a net ads join), but no way to get both features running together. Without the ‘net ads join’ I always get ‘failed to verify incoming ticket’ in the log.smbd and an access denied on the PC, though a ‘kinit same_user’ at the Mac prompt works fine.

Are there any updates on this issue?

regards, hgw

September 27, 2004 at 1:07 pm #359326

Anonymous
Guest

hgw,

I get exactly the same behaviour and error messages as you and haven’t been able to find anyone with an answer. I’m an AppleSeed member so got to ask a few of the Apple peeps if they knew anything but no one came up with anything new. I need to find out if they’ve had chance to test ozpass’ idea because that’s the only new thing I’ve come across recently.

September 27, 2004 at 5:47 pm #359328

Anonymous
Guest

JP, I checked the proposal from ozpass – I got apparently no different behaviour. I even turned down the digitally signed communication in the default group policy of the AD domain – all but with no visible success.
My guess (may be not very educated) is, that samba and the mac os login process use different machine SIDs in the AD. On some occasions during my tests I observed duplicate machine accounts for the mac under test in the AD, after first joing the AD with Directory Services and then with ‘net ads join’.

regards, hgw

September 28, 2004 at 8:20 am #359333

Damien
Participant

Hello,

I have spent some considerable time to get the following working with great success. Hopefully this helps.

My situation is:
W2K AD for authentication
OS X 10.3.3 Server – I just have to confirm this as it could be higher…
Windows Clients connecting to SMB Shares on XRaid

the steps I followed were:
1. Set up OpenDirectory to use AD plug in
2. Add for authentication and Address Book
3. Bind to AD – this needs to be done once you edit the smb.conf file
4. For Windows Services – set as member server
5. Edit smb.conf
– confirm workgroup is in uppercase and is correct domain name
– set use spngo = yes
– set security = ADS
– domain logons = yes *** this is the one that will let smb shares use AD security. if this is not set errors occur.
– verify that the REALM is correct and in uppercase

I did notice that occasionally the smb.conf file would reset the domain logon setting back to no so I changed the file to be immutable using

sudo chflags uchg /etc/smb.conf

If you ever need to change it again you’ll need to unlock it with:

sudo chflags nouchg /etc/smb.conf

After any edit of the smb.conf file you need to rebind to the AD.

Theory has it that this is all you need to do.

I use lookupd -d userWithName : userID to validate that I can talk to AD. Also another thing to note is the security on the directory needs to be set to give the AD user access.

Hope this helps.

I had a tough time getting where I am and hope this helps some others.

cheers Damien

September 28, 2004 at 9:44 am #359335

Anonymous
Guest

Thanks for that but I’ve set smb.conf up like that and with various other configurations, SMB shares are actually trying to authenticate via AD it’s just that there is something screwy with the Kerberos authentication between the server and the AD domain. Could very easily be something to do with their AD domain talking to people there, it’s just very hard to be 100% positive and say “Yes, that’s what it is”.

October 1, 2004 at 7:11 am #359382

Anonymous
Guest

I have been having the same issue. 10.3.3 Server (after upgrading to 10.3.4 and .5 I lost my groups so I went back to 10.3.3)

After playing with directory services I was able to get the windows clients to authenticate using smb. It’s not pretty or extremely stable but it works.

First I bound to the domain using “domain.forest.company.com” in both the adforest and addomain (Authenticate in multiple domains). After binding successfully i was able to connect from afp but not smb. Next I unbound from AD changed the AD Forest to “company.com” unchecked the Authenticate in multiple domains box. Finally I rebound to the domain. After doing this I was able to connect from both afp and smb.

I do not know why this works?? It seams this is the only way I can connect from smb. If I skip the first part it does not work. Of course if the machine crashes (!?) I have to do it all over again after deleting the directory service prefs.

I am currently testing out admitmac 2 to see if this works.

I hope some answers turn up for this issue. I have 4 servers which do not build confidence in the AD area.

J

October 4, 2004 at 8:19 pm #359402

Anonymous
Participant

I have got mine to work although I am not sure of the security implications.

Inside the domain security options you want to enable “allow enencrypted passwords from 3rd party SMB servers”. Once I changed this setting everything started working.
Author

Posts