Profile Manager mounting DFS Share

Question

Level 1

10 points

Profile Manager mounting DFS Share

OSX version 10.11.4; Server version 5.1

Although stated as being possible to mount a Windows DFS share using Profile Manager, I have been unable to make this work in the Login Items payload settings.

To start, I checked what works locally on a MacBook that is bound to AD and logged in with domain credentials.

In Finder -> Go -> Connect to Server, I can enter this: smb://mydomain.local/DFSRoot

I am prompted for credentials (why? - I am already logged in as domain admin/user who all have access to DFS share...) and the connection is made. Shows up in Finder -> Go -> Computer.

Now, in Profile Manager, I add settings for Login Items -> Authenticated Network Mounts and add: smb://mydomain.local/DFSRoot. (same as what worked locally) However, when user logs in there are just warnings that 'There was a problem connecting to server mydomain'.

Additionally, if I remove this from PM Login Items and push settings successfully to MacBook, the warning still comes up (?!)

I've followed several tutorials and forum posts that say this configuration should work, but it doesn't.

Any ideas?

TIA

Rick

Mac mini (Late 2014), OS X El Capitan (10.11.4), Server app (5.1)

Posted on Mar 24, 2016 10:58 AM

Reply

Answer 1

Mar 24, 2016 11:22 AM in response to scdladmin

In theory if you have logged in to your Mac using an AD account then yes you should get an automatic login to the DFS file server. This is normally achieved via Kerberos single sign-on.

However Kerberos is a very sensitive beast, it absolutely requires DNS settings be 100% correct amongst other things. As a first step double check both forward and reverse DNS lookups work for the relevant servers i.e. AD, and the Windows file servers from the client Mac.

Based on your message it seems you have unfortunately made one huge mistake which will not help matters. The .local domain is a special one at least in the Mac world. It is reserved for use by Bonjour aka. mDNS aka. MultiCast DNS. In the past a significant number of sites have 'appropriated' this domain for use as the internal only domain for Active Directory setups. This obviously then causes a massive conflict. It seems in more recent times Microsoft do now try and auto-suggest a domain other than .local as even Microsoft have seen this being a problem.

Further reading your post it sounds like you may have already spotted this and your reference to the SOA is probably based in this Apple article - Mac OS X v10.4, 10.5, 10.6: How to look up ".local" hostnames via both Bonjour and standard DNS - Apple Support

I could not find a newer version but would expect this article to still be applicable. I would suggest the first step is to do simpler testing as follows.

Login using an AD account to a Mac
On the Mac login try connecting to a Windows share - preferably not a DFS one but one still using AD authentication

The purpose of the above is to eliminate a) DFS, and b) Profile Manager from the equation leaving just the testing of AD authentication to a Windows share. Once this is established as working you can then try extending things by either trying the same to a DFS share - without the involvement of Profile Manager, or vice-versa use Profile Manager to test a non-DFS share.

We should then eventually be able to see if all AD authentication is broken, or DFS is broken or Profile Manager is broken or whether it is a combination.

Obviously the ideal situation would be to get rid of the hijacking of the .local domain but I can understand that is not going to be practical for most sites as it would involve a full-blown AD migration.

Reply

Answer 2

scdladmin Author

Level 1

10 points

Mar 26, 2016 8:25 AM in response to scdladmin

Thanks for the reply.

I have been struggling with many aspects of Server and Profile Manager and started to suspect that the .local tld is part of the problem.

Our MS .local domain has been in place for over 15 years.

From what I am experiencing here, it looks more like the Apple Server isn't using DNS for its resolutions.

Since posting, I did - in fact - get the DFS share to map on the client when I changed the profile entry to smb://mydomain/DFSRoot (instead of smb://mydomain.local/DFSRoot) but that would lead me to believe it works when using NetBIOS resolution and not DNS.

I did log onto a Macbook and successfully map a shared folder on a Windows server using AD credentials, as suggested.

The supplied link suggests that clients with OS X version 10.6 (and higher?) shouldn't need to change anything about search domains.

I am going to try adding both search domains to the client, but as of this morning I am unable to push profile updates to clients so will be unable to test the Login Item change.

I was also wondering if changing the setting in the Directory payload for AD -> Administration tab -> Namespace from domain to forest would have the same effect. Again, can't test this without being able to push updates.

Reply

Answer 3

scdladmin Author

Level 1

10 points

Mar 26, 2016 9:34 AM in response to scdladmin

I've restored profile push to the client.

While the linked web page suggests that adding domains to the search domains on the client should not be necessary for this version of the OS, I tried it anyway, adding both local and mydomain.local to the list.

I added the original entry to the profile in Login Items - smb://mydomain.local/DFSRoot.

This still did not map the share on the client after a successful profile push.

In System Preferences -> user -> Login Items tab the entry displays as smb://mydomain._smb._tcp.local/DFSRoot

Reply

Answer 4

Mar 26, 2016 10:29 AM in response to scdladmin

scdladmin wrote:

I've restored profile push to the client.

While the linked web page suggests that adding domains to the search domains on the client should not be necessary for this version of the OS, I tried it anyway, adding both local and mydomain.local to the list.

I added the original entry to the profile in Login Items - smb://mydomain.local/DFSRoot.

This still did not map the share on the client after a successful profile push.

In System Preferences -> user -> Login Items tab the entry displays as smb://mydomain._smb._tcp.local/DFSRoot

Interesting.

_smb._tcp.local is a normally hidden Bonjour record format. You can test this in Terminal.app using the following command

dns-sd -B _smb._tcp local

You need to do Control-C to end the search.

Clearly it is still being upset by the hijacking of the .local domain.

Perhaps another approach that gives you some more control for testing would be to create effectively the same Profile but do so using Apple Configurator. If you save/export this profile 'unsigned' you can view and edit the XML instrucitons. You could then view and if needed edit the SMB path and retest. Apple Configurator is free on the App Store, you can manually install one of these resulting mobileconfig files by double-clicking on it on the Mac and delete/remove it by deleting it in System Preferences -> Profiles.

Reply