smb mount issues

swaroopmj
New Contributor

We have JSS 9.81 running on windows 2012 R2. The problem we have is I'm able to deploy policies and mount the distribution server(windows 2012 R2) when running as the local admin on the mac machines. However when the machine is AD bound and I login with my AD credentials, I cannot push any policies because smb mount of the distribution server is failing. It is trying to use the kerberos ticket generated upon login to mount the drive. We have local accounts on the distribution server and have set up in JSS to use the local accounts.

Is there a way to make sure when the policies are pushed to a AD bound mac user to not use the users Kerberos ticket to mount the distribution server?

10 REPLIES 10

thoule
Valued Contributor II

The setup you describe is what we use here, but I couldn't even guess why it fails for you and works for me. If I put the URL in Connect To Server, it mounts the volume, no password required. I can disconnect that, then run a Self Service install policy and it mounts the share without problem as well. The 'mount' command shows the connected user. I don't see anything special we did to create that config, but it was working before I started here. On another note, I do recommend switching to http downloads, but I imagine you'll still need smb for Casper Imaging.

swaroopmj
New Contributor

If I do a connect to server, I get a "You do not have the permission to access the server" error. Regarding the share itself, do you have a local account or an AD account for read-write and read only accounts?

davidacland
Honored Contributor II
Honored Contributor II

Hi,

I've seen this in a few environments. It was also a bug affecting Casper Admin.

What OS are you currently running? I've heard some people saying the issue goes away on 10.11?

thoule
Valued Contributor II

SelfService/CasperAdmin connect with local accounts. My AD account also has RW access, but my users do not. When I connect with CasperAdmin, type 'mount' at the command prompt, and I can see it's connecting with the server's local account. I haven't tried connecting using the Finder and my account while Casper Admin is open; I just assumed everything would explode and the world would end.

EDIT: I'm using 10.10 and JSS 9.81, though it was working with with JSS 9.73 as well.

swaroopmj
New Contributor

I'm running 10.11.1

One test I did was to remove all kerberos ticket after I login to the AD bound mac. Then I tried to connect to server. I get prompted to enter the credentials for a Registered User and once I enter the credentials of the service account which is domain service account, I can mount it. If I use the local service account which is local admin it fails with the same error. The test is with cmd+K and smb.

charles_hitch
Contributor II

We ran into this same scenario with our Mac servers. What we had to do was configure the server not to register the CIFS SPN in Active Directory. I am not sure exactly how to do that on Windows, but it worked perfectly by editing that setting on the Mac.

sean
Valued Contributor

For testing you can connect to server as any user and bypass the Kerberos Ticket. Connecting to server use the format:

smb://[username]:*@[servername]

This will prompt for the password.

charles_hitch
Contributor II

One other thing that i am pretty sure will resolve this is to use the IP address for your server rather than hostname. Without using the hostname kerberos doesn't know how to look up the SPN and it will thus fall back to username/password auth.

swaroopmj
New Contributor

Charles,

I will try the IP address instead of hostname. I do see the cifs entry when I run the klist command. I tried doing a kdestroy action post script. It clears the ticket but it also deletes the user ticket. Is there a way to run the kdestory and delete only the cifs for the distribution server and not the other tickets if present?

charles_hitch
Contributor II

I haven't tried but you could do a kdestroy -principal=principal (see the man page for kdestroy). But that will be a real pain to have to run every time. In my opinion the better way is to configure the server not to register a CIFS SPN in AD or to use the IP.