Home › Forums › OS X Server and Client Discussion › Active Directory › Cannot logon to magic triangle mobile account when off network
- This topic has 5 replies, 2 voices, and was last updated 15 years, 1 month ago by
arekdreyer.
-
AuthorPosts
-
February 16, 2010 at 12:47 pm #377981
OmniBlade
ParticipantI’m implementing a magic triangle configuration to allow AD users to log onto the macs in our department and used the OD groups to manage access to an xsan and apply managed perferences as needed. The users mac home folders need to be on the xsan and I don’t have enough access to the AD side of things to change what AD specifies as the home folder so I have used augmented records to specify those attributes in the OD. That works fine and users can log on as a network users.
Next issue was creating mobile home folders locally for machines that have predominantly one user or laptops that might be used off site and to have those sync back to the xsan when connected. Initially this didn’t work, the mobile account would create, but all the folders still refered back to the network share and there was no syncing. To get round this I created a group in OD that had managed preferences that specified allowing the creation of mobile home folders and the importantly, the syncURL back to the xsan share that the created mobile accounts should use. Success, or so I thought. The accounts create and sync correctly (I mananged to get kerberos working with SSO but if not it asked for credentials when syncing) so when on the network, everything is fine. However if the machine is taken off the network (such as a laptop that is also used off site), attempting to log on to a mobile account created like this gives a shaking logon box. Any ideas how I make it store the credentials for the mobile account locally? Any other managed preferences I need to set?February 17, 2010 at 5:54 am #377992arekdreyer
MemberThere are a bunch of elements, and your descriptions don’t seem quite accurate.
Bottom line: if a user’s home folder is on the Xsan volume, then the user can’t log in if the Xsan volume isn’t available.
February 17, 2010 at 9:35 am #377994OmniBlade
ParticipantSorry, I probably haven’t been as clear as I needed. The home folders are on an xsan that the OD server is a part of and it shares the home folder location via afp and the home folder locations are augmented to reflect that (the same as if they were just specified uner the home tab in workgroup manager for a user). That all works fine and users can log on when they are connected to the network. What I am trying to do for the AD users (and can for an OD user) is create a portable home directory on the local machine that will sync to the server via afp and log on using directory authentication, but will cache the credentials so it can be used away from the network. I have everything working apart from that last part.
February 19, 2010 at 5:56 pm #378030arekdreyer
MemberOmniBlade that makes more sense.
What are your settings for the Active Directory connector (plug-in)?
February 22, 2010 at 10:40 am #378036OmniBlade
ParticipantI believe I’ve solved the issue. To get single sign on working, I followed a guide advising to change “builtin:authenticate,privileged” to “builtin:krb5authnoverify,privileged” under system.login.console in /etc/authorization. This works great as long as the computer is connected to the network as this change REQUIRES contact with the KDC to authenticate, a fact not pointed out by the people suggesting this as a solution. For those wanting mobile accounts that may be used offline, adding “builtin:krb5login” under system.login.done instead in /etc/authorization seems to have the desired effect of grabbing the tgt after authentication if the KDC is available but otherwise allowing login to proceed.
I figured it couldn’t be the AD plugin after I tried using a pure AD account without any augments and still having no luck.
February 23, 2010 at 3:19 am #378047arekdreyer
MemberThanks so much for circling back and following up with your solution!
-
AuthorPosts
- You must be logged in to reply to this topic.
Comments are closed