Posted on 06-13-2012 11:40 AM
So here is my situation... I have all 10.7.x systems, and I want to auto-mount a network share on login. Systems are NOT bound to any OD/AD account, and based on my highly distributed environment, won't be. I have a Lion server with OD running with some file shares. I need to have shares auto-mounted on all systems, with their individual OD credentials so access to various folders/files is restricted where necessary.
So what is the best way to do this?
My thought was to somehow add keychain entries for each user with their credentials. Since I only have about 25 users I need to do this for, I don't mind setting a policy for each one if necessary. My goal is that the end-user has as seamless an experience as possible. Then once the keychain entries were existing, mapping the network share would be easy (I think).
So that's my thought, though I don't know if that is even possible.
Any guidance or suggestions would be very much appreciated!
Solved! Go to Solution.
Posted on 06-13-2012 03:16 PM
Well, having network accounts or OD accounts would be best, but if you really don't plan on using them, then "security" from Terminal will be your friend in this case.
I was able to get the following general syntax to work in my tests with an AFP share, though YMMV. It will at least get you going in the right direction-
security add-internet-password -l ServerName -a <username> -w <password> -D "network password" -r "afp " -s <ip.add.re.ss> -T /System/Library/CoreServices/NetAuthAg
ent.app/Contents/MacOS/NetAuthSysAgent
Replace the relevant bits with your specific information. Also note that there is a space after the afp, as in "afp " (it needs to be a 4 character string)
The "ServerName" is just the label so use whatever you want, otherwise it just uses the ip address you specify.
This of course all requires knowing your users passwords, if you planned on having it work silently. I'm thinking if you left the password out, they would be prompted on first run and they could enter it and save to the keychain, but that doesn't seem to be what you're looking to do.
I have not thoroughly tested this, and there may be some missing elements in your specific case to make it actually work, so read the security man page-
man security
There's a lot of good stuff in there.
Also, this adds an entry into the current user's login.keychain, unless otherwise specified, Since Casper scripts run as root by default, you will likely need to modify any script to direct the command to the logged in user's keychain instead.
The next piece would be getting the auto mount to happen, but that's another story.
Posted on 06-13-2012 12:26 PM
So wait, they have network accounts but are not bound? So I take it they log in locally and then log into servers with their OD account?
Posted on 06-13-2012 03:14 PM
How about making an alias of the network share for each user with password in the keychain and adding it to the user as a Login Item?
Posted on 06-13-2012 03:16 PM
Well, having network accounts or OD accounts would be best, but if you really don't plan on using them, then "security" from Terminal will be your friend in this case.
I was able to get the following general syntax to work in my tests with an AFP share, though YMMV. It will at least get you going in the right direction-
security add-internet-password -l ServerName -a <username> -w <password> -D "network password" -r "afp " -s <ip.add.re.ss> -T /System/Library/CoreServices/NetAuthAg
ent.app/Contents/MacOS/NetAuthSysAgent
Replace the relevant bits with your specific information. Also note that there is a space after the afp, as in "afp " (it needs to be a 4 character string)
The "ServerName" is just the label so use whatever you want, otherwise it just uses the ip address you specify.
This of course all requires knowing your users passwords, if you planned on having it work silently. I'm thinking if you left the password out, they would be prompted on first run and they could enter it and save to the keychain, but that doesn't seem to be what you're looking to do.
I have not thoroughly tested this, and there may be some missing elements in your specific case to make it actually work, so read the security man page-
man security
There's a lot of good stuff in there.
Also, this adds an entry into the current user's login.keychain, unless otherwise specified, Since Casper scripts run as root by default, you will likely need to modify any script to direct the command to the logged in user's keychain instead.
The next piece would be getting the auto mount to happen, but that's another story.
Posted on 06-14-2012 05:51 AM
Jared, correct. Honestly this is a temporary solution. Most of our files/services are cloud-based. The files on our internal network are old files that haven't been moved yet, so they won't need to access this for long.
mm2270, I think that's exactly what I needed so thank you so much! Once that's done, the auto mount shouldn't be too difficult I don't think but we'll see. Thanks again for the help!
Posted on 06-14-2012 07:00 AM
mm2270, again thanks. This was perfect. I still have to test pushing it out through policy but it works. BTW auto-mounting is super easy since all my machines are 10.7.x, I just use Configuration Profiles under Login Items -> Network Mounts.
Posted on 06-14-2012 07:23 AM
@jwelsh - You're welcome. It was a good exercise for me, since although I've used the 'security' command before for different purposes, I'd never actually added a server password entry before.
Just remember that pushing via script/policy, you'll want to make sure it directs the new keychain entry to the current logged in user's keychain, or it may try to add it to the "root" account keychain. I think all you need to do is add the path to the users keychain at the end of the command, like "/Users/username/Library/Keychains/login.keychain" but I haven't tested that.
Posted on 11-07-2012 08:51 AM
FYI if you're sending this out via script/policy for the sake of adding a keychain item to a user's keychain and you're getting an error of "The authorization was denied since no user interaction was possible" you also need to run the following command before mm2270's syntax.
security unlock-keychain -p USERPASSWORD /Users/username/Library/Keychains/login.keychain
(or whatever the path to the user's keychain is)