Home › Forums › OS X Server and Client Discussion › Active Directory › Server Side File Tracking: Only works when home dir is on the system disk
- This topic has 5 replies, 3 voices, and was last updated 14 years, 6 months ago by
dayglojesus.
-
AuthorPosts
-
July 19, 2010 at 7:45 pm #379123dayglojesusParticipant
We have found that Server Side File tracking for Mobile Home directories only works when the user’s network home resides on the Mac OS X Server system disk.
The apparent cause is that the SSH daemon looks for the user’s public key on a path like…
/Network/Servers/my.server.com/ShareName/username/Library/FileSync/FileSyncAgent_key_dir/FileSyncAgent_key.pub
In our specific case, the “ShareName” portion of that path refers to an AFP share named “PHD” which is actually on a RAID connected to the home dir server. However, shares on the home dir server are not visible in the /Network/Servers folder and, as a result, the public key cannot be found and Server Side tracking cannot be initialized.
Creating a symlink at the root of the system disk to the RAID volume “PHD” corrects this problem, but I am wondering if there isn’t a better solution.
Perhaps I am going about this the wrong way entirely?
July 22, 2010 at 7:39 pm #379159dayglojesusParticipant[QUOTE][u]Quote by: macshome[/u][p]I would file a bug on that with Apple![/p][/QUOTE]
Thanks for the reply.
Is it really a bug, or just the AD plugin coming up shorthanded? Maybe you can tell me?
If I specify the AD user’s homeDirectory attribute like, \\my.server.com\ShareName\username, that’s all the information the plugin has in order to devise the absolute path to the user’s home directory in the server’s own context. So, even if the absolute path to that share from the server’s context is…
/Volumes/SomeDisk/ShareName
The AD plugin is not going to know this, but will try and devise an NFSHomeDirectory attribute from the UNC path and wind up with something like…
/Network/Servers/my.server.com/ShareName/username
The Server Side File tracking is leveraging the user’s HFSHomeDirectory attribute to determine the path to the FileSyncAgent public key, and this fails because that path is not accessible from the server’s context.
Should the server be able to access its own network shares in /Network/Servers?
If so, then I guess this is a BUG!
July 26, 2010 at 5:33 pm #379183dayglojesusParticipantI just wanted to follow-up (close) this thread by saying that the creation of a symlink at the root of the share provides what I consider to be an adequate workaround — and the only one available at present.
The crux of the problem lies in the Active Directory user’s synthesized NFSHomeDirectory value.
When an Active Directory user’s profile path is set using a UNC path of…
\\server.foo.org\share\user
But the actual absolute path to the share in the server’s context is…
/Network/Servers/server.foo.org/Volumes/share
The AD plugin on the user’s workstation will synthesize the remaining home directory related attributes from this one string. For example…
HomeDirectory:
afp://server.foo.org/share user
SMBHome: \\server.foo.org\share\user
NFSHomeDirectory: /Network/Servers/server.foo.org/share/userHowever, if this synthetic value does not reflect the true absolute path in the server’s context, it would be unfair to call this a bug, as the derivation of said value could only ever be considered a “best effort”. Obviously, without being able to specify an NFSHomeDirectory value in an AD account without some form of schema mod, an alternative must be found.
Best practices suggests that this might be implemented by using static/variable mappings, but this feature is not available in the AD plugin (see Phil Rinehart’s article here http://www.mactech.com/articles/mactech/Vol.23/23.10/2310MacEnterprise-Strangersinaforeignland/index.html) as it is in the Apple LDAP plugin.
In this case however, knowing that is it simply the SSHD process for Server Side Tracking that requires the user’s NFSHomeDirectory value, creating a symlink at the root of the system disk should provide an adequate solution.
HTH somebody out there…
October 5, 2010 at 2:57 pm #379602Stephen BuckleyParticipantThanks to this thread I at least know that some people are getting this configuration working. However I am still having issues with server side tracking failing despite making the symlink as described. I can now get to my share using the path synthesised by the AD plug-in, but the server side tracking is still failing with my clients reporting in their logs that the public key authentication is failing.
I’ve set this up on a test server to verify what was happening on our production server wasn’t one off, and turned on debug loggin on the homsync server’s FileSyncAgent (as detailed in the very helpful post here http://tinyurl.com/384eg6u), I have confirmed that the path that FileSyncAgent is using to look for the public Key is correct (by looking at the FileSyncAgents debug logging in /private/var/log/secure.log) and is accessible to the testz home directory server (thanks to the symlink). However SST is [b]still[/b] failing.
Does anyone here have any bright ideas regarding what to try next? or what might be a useful thing to look for in my test servers /private/var/log/secure.log on the test server or elsewhere to try and determine why this is failing?
Thanks,
StephenOctober 6, 2010 at 4:24 am #379611dayglojesusParticipant[QUOTE][u]Quote by: Stephen+Buckley[/u][p]Does anyone here have any bright ideas regarding what to try next? or what might be a useful thing to look for in my test servers /private/var/log/secure.log on the test server or elsewhere to try and determine why this is failing?
[/p][/QUOTE]I have seen SST fail for the following reasons:
+++++++++++++++++++++++++++++
1. Insecure or inadequate permissions along the path to the user’s public or private key
At the server level, the entire path to the user’s public key needs to be root accessible, but not so insecure as to prevent SSH from working; SSH demands that private/public keys be “secure” (ie. only accessible to the user) before they can be leveraged. On the client side, the user’s private key and the directory in which it resides must be secure as well.
For example, at the server…
/Network/Servers/your.server.com/Users/your_user/Library/FileSync/FileSyncAgent_key_dir
Along this path the user’s Library/FileSync folder, and sub-folders need to be 0700, the public key should be 0644, and the private key 0600. Ownership along this tree should be solely the user’s.
At the client’s computer along the same relative path, the exact same permissions and ownership should be used. I am not sure why they would be created any differently, but if they are, it might have something to do with your sharing setup.
NOTE: In one case (way back on Mac OS X Server 10.6.0), I found that setting a user’s home dir (NHD, server-side) perms to 0700 fixed the problem. Just that directory though. You could try that I suppose.
2. A bad key pair resulting from a previous FileSyncAgent
Ensure that the key pair on the NHD and PHD are identical by comparing checksums or using diff. If they’re different, you may have found the problem.
3. A stale DirectoryServices cache on the server
Long shot: Try flushing the group membership cache and the like.
4. The client cannot connect to port 2336
Is there a firewall?
+++++++++++++++++++++++++++++
If you can’t get SST to work at all, and you have gone over all the above, I would start looking at your sharing setup very closely. If you are using a combination of posix and ACLs to control access, things can get complicated. Start with a simple perms model, open but secure.
It might also be worthwhile shutting off SST, destroying the FileSyncAgents’s self-generated rsa/dsa keys (/Library/FileSync), firing it back up, and begin your testing again. The keys will be regenerated when SST is re-activated.
That’s a about all I can think of…
HTH
-
AuthorPosts
- You must be logged in to reply to this topic.
Comments are closed