Hello, I need to be able to take 150 mac book airs that have user with mobile accounts ran off ad turned into admins on only mac book airs. I want to keep them restricted on pc's
Answer
make ad user a local admin for 150 computers
+3Best answer by tlarkin
OK well I am stuck in my hotel room catching up on work and I am gonna toss you guys some free code. However, this is something I have most definitely posted on the old mailing list days, so if you searched for it you would probably find it.
So, this is what I would do:
1 - create a smart group in Casper by hardware model, scoped to this exact particular model of Macbook Air, since it is only going to apply to them.
2 - run a script at login, once per a computer that grabs all AD accounts and tosses them in the admin group. I actually have this script already written in my scripts repository (as I said I wrote this before I worked for JAMF).
#!/bin/bash
# generate local user account based on UID of greater than 1000, if multiple AD accounts exist this will grab all of them
userList=$(/usr/bin/dscl . list /Users UniqueID | /usr/bin/awk '$2 > 1000 { print $1 }')
for u in ${userList} ; do
/usr/sbin/dseditgroup -o edit -a ${u} -t user admin
done
exit 0Now, if you want to leverage LDAP group membership, you should do so in your scope in Casper. Create your AD nested group of users that get these specific admin rights, and through scope limit the script to only run on machines that have users of that LDAP group. That way you aren't trying to create super crazy logic in your scripts, and you can leverage your simple drag and drop OU/Groups in AD.
So, if you have mapped your LDAP server for lookups in the JSS this is possible. You would assign it to all Macbook Airs of that specific model, and then fine tune that scope to only users who are member of _ LDAP group.
I hope this makes sense. Jet lagged and trying to stay awake to adapt to local time better.
-Tom
+31Hi Cody,
Is this for all macbook airs, or just some macbook airs? If you can give as much detail as possible we can better help you achieve a useable solution.
Thanks,
Tom
+7I haven't done this for AD, but I did it for OD and I'm sure it would be a similar process. What I did was create a group on my directory server and then ran a script on each machine that added the network group to the local admin group. I can share it with you if you'd like.
+24I also have a script that will hardcode a username into the admin group. No matter where the username comes from (local/AD/OD) when it logs in it'll gain admin rights.
+24I would try to handle this the way Justin describes, adding all users to a group on the directory server and then adding that group into the local admin rights settings on the Macs.
If that's not possible, you can have a script run at login that will use the current user name and add it to the local admin group using 'dseditgroup' like what Jared describes.
But adding a group that contains the users may be the better method since later down the line you could add users to this group on the AD servers and they would have rights on the box. Its also easier to remove admin rights from users this way if you needed to.
+3that sounds reasonable and like best solution to add group to admin rights, I will have to look into it. if that is how I wanted to go what is the process for that can I do it through casper?
It is for all macbook airs (brand new), I work for school they deploying to students. and want admin rights on all of them.
if I add the group to the macs that only affects macs that I add group to not other macs or pcs etc.
+24In the AD plugin, in the Administrative tab set the "Allow administration by" option. Drop in the name of your group that should have admin rights. e.g. mydomainmyadmingroup
Careful, case sensitivity may matter. I just found out yesterday that it did in the environment I'm in now. At my last job, it didn't matter. Found that odd.
+31When you bind to AD are you creating mobile accounts? If so the account will be cached to the machine locally, and then you can use a simple script that only adds AD accounts to the local admin group and don't have to mess with LDAP groups and using dscl or dseditgroups to look up the full LDAP group to your server.
In my opinion, and I could very much be wrong since Jared posted here, that is the more efficient way. Opinion is stressed here, not fact! :-)
Thanks,
Tom
+24You're spot on, Tom. ha
If machines will always be in sight of the DC, adding the group in the AD plugin will suffice. However, if machines are offline, they'll lose their admin rights. At this point, if you're dealing with a group that should have admin rights instead of users, it can get difficult. I do not believe you can hardcode the AD group into the admin group, have an AD user in that group log in and then retain admin rights. I think you'd need to hardcode individual users as admin in the event that they're not in sight of your DC.
Doing that would look like:
dscl . -append /Groups/admin GroupMembership <AD username>After talking it over I think I would like to something like "tlarkin" said.
What would be ideal is for each student to only have admin rights on there own laptop is that what this script you are talking about would do?
+31OK well I am stuck in my hotel room catching up on work and I am gonna toss you guys some free code. However, this is something I have most definitely posted on the old mailing list days, so if you searched for it you would probably find it.
So, this is what I would do:
1 - create a smart group in Casper by hardware model, scoped to this exact particular model of Macbook Air, since it is only going to apply to them.
2 - run a script at login, once per a computer that grabs all AD accounts and tosses them in the admin group. I actually have this script already written in my scripts repository (as I said I wrote this before I worked for JAMF).
#!/bin/bash
# generate local user account based on UID of greater than 1000, if multiple AD accounts exist this will grab all of them
userList=$(/usr/bin/dscl . list /Users UniqueID | /usr/bin/awk '$2 > 1000 { print $1 }')
for u in ${userList} ; do
/usr/sbin/dseditgroup -o edit -a ${u} -t user admin
done
exit 0Now, if you want to leverage LDAP group membership, you should do so in your scope in Casper. Create your AD nested group of users that get these specific admin rights, and through scope limit the script to only run on machines that have users of that LDAP group. That way you aren't trying to create super crazy logic in your scripts, and you can leverage your simple drag and drop OU/Groups in AD.
So, if you have mapped your LDAP server for lookups in the JSS this is possible. You would assign it to all Macbook Airs of that specific model, and then fine tune that scope to only users who are member of _ LDAP group.
I hope this makes sense. Jet lagged and trying to stay awake to adapt to local time better.
-Tom
+3tom, will that add all user as admin on all of the airs? I would prefer to only have them be admins on there airs. which way does that script work? thank you
+24If you're looking for them to only be admins on their respective boxes, then Tom's script will do just that. A student logging in on another Mac after the script has run on said Mac will only create a mobile cached account for them as a Standard user, not an admin.
Edit: Just for clarification purposes, Tom's script will get any AD accounts for users that have already logged in on the Mac its being run on, not grabbing all AD users from your LDAP environment. Its only searching the local domain on the Mac, not the AD servers. If only one student has ever logged in on their respective MacBook Airs, then his script will work as is for what you're trying to do.
I can see where that part may have been confusing based on how the script comment is worded though.
+31tom, will that add all user as admin on all of the airs? I would prefer to only have them be admins on there airs. which way does that script work? thank you
I suggested you set the AD bind to create a mobile account, it will cache the AD credentials to the MBAs locally. Then have the script scoped to a smart group in Casper based on the hardware model of that Macbook Air only. Then limit the scope to an AD group of particular users that get those Macbook Airs.
Then it will only run on those Macbook Airs, and only on the specific LDAP users that log into them. Admin rghts will not carry over to any other machine.
I hope that makes sense.
Thanks,
Tom
+26HI Guys,
If I have a policy set to run Tom's Script once at login, scoped to an LDAP group of special users, and then also to specific computers, will this policy give the user admin rights when he initially creates his mobile profile at first login, or will it require an additional log out, back in?
If they have to log out and back in... then wouldn't the policy already have run?
Do not have the access to test this until tomorrow....
Thanks!
Sandy
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.