AD Users losing Admin rights when not connected to Domain

I would think you'd need to explicitly set mobile accounts for each admin
On 4/12/10 2:56 PM, "Swanson Noah" <SwansonNoah at JohnDeere.com> wrote:
user. Not sure you can apply mobile settings to a group.

Two users here are made admins for their local department's machines because
they support the software they develop. They have Standard accounts, which
we've made mobile on their laptops, and they have secondary Admin accounts,
which we've also made mobile. We tested that the admin accounts work by
pulling the network plug, logging in and then creating a text file in
/Applications. No problems.

--

William Smith
Technical Analyst
Merrill Communications LLC
(651) 632-1492

if you want permanent local admin access just add the mobile accounts to
the admin group

sudo dscl . append /Groups/admin GroupMembership tlarkin

you would want to put in the user in question, if you need a script just
loop through /Users and grab the names and do it that way.

Sorry for bringing up an old post but we have this issue as we add the "Staff" group to the admin users at bind time but when the login off site they have no admin access, Would a run once per user login script targeted at laptop computer and also targeted at the "Staff" group work with the following info in it?

dscl . append /Groups/admin GroupMembership $3

Adding Staff to every machine's admin group will make everyone an admin on every machine so long as they're on your network.

The dscl command will make everyone who logs in to a particular machine an admin on only his machine.

Is that what you're wanting to accomplish?

I'm so confused. So perhaps if I walk through our process, someone can clarify what I should do because unfortunately we are experiencing users losing admin rights off the network as well. We just started binding to our AD with the release of Mountain Lion, so this is new to me.

We bind a computer at imaging with a script.
We deliver the computer to the end user.
The user for the first time logs in, their account is created and because they are in a specified admin group in AD they are given admin rights.
User goes home, user loses admin rights.

How can i run a dscl . append command to add the user to the local admin group if at the time of imaging the user hasn't logged in and doesn't exist.

Sorry, i guess I just need pictures because the light bulb is not coming on. i feel so dumb.

Thanks, for any help

Even if a user is designated as an administrator in Active Directory that doesn't mean all of his privileges designated there are copied to his computer for offline use.

Mac OS X doesn't log in administrators with administrator privileges. It logs them in as Standard users. When a user attempts to do something that requires administrator privileges it first consults its local directory of users and groups to see if he has those privileges. If it doesn't find that the user is a local administrator then it tries to consult Active Directory to see what it says. If the computer can't reach Active Directory then his privileges don't get escalated.

This is why you must make a user an explicit administrator on the computer itself. His credentials and privileges must be stored in Mac OS X's local directory of users and groups to work while away from Active Directory.

Hope I'm making sense.

That makes perfect sense, I sort of knew that. But what I'm looking for is an easy way after the computer has been delivered, to add that user to the local directory as an admin user.

That's the part I don't understand. I mean I get, if I walked the computer over to the user myself had them login and then manually ran dscl. append with the new username to add that user to the local directory as an admin user it would fix this issue. However if I'm not walking it over and I don't know the username, how is it done. We have hundreds maybe thousands of potential AD admin users that will need to have this done

I'm sure it's being done a bit different, that's my missing piece of the puzzle.

Is there a JSS policy that you are creating? Perhap's see's an AD admin user has logged in now run this command to add that user to the local directory as an admin user.

You can create a script that does this and then set a policy to run the script depending on how it's most convenient for you.

In my environment, we have a "Once every week" policy that runs a script that loops through each Mobile user on the machine, checks their AD group membership, and adds them to the local admin group if they're in one of our AD groups to which local admin privileges are delegated. However, it sounds like you're looking for something more instantaneous in your environment so that a user immediately has the proper local admin rights while off the network. In that case, you could run a similar policy but on a different trigger and/or frequency (i.e. once per user at login, as I think someone suggested earlier in the discussion).

Another option might be to create a Self Service policy that adds the current user to the local admin group; scope this policy to your AD groups that should be allowed admin access and they can run the policy themselves after first login. This could probably even be done as a one-liner in "Run Command" under "Advanced" in the policy:

dscl . append /Groups/admin GroupMembership $3

That same line could be used in a login-triggered policy that's scoped to your AD admin groups.

I think which option is best - and I'm sure there's many other ways to do this too - will ultimately depend on who gets admin access, why they need it, and which machines they get it on.

Hope this helps!

Hmm, interesting. We allow our AD Mac Support group to administer the Mac and specify mobile accounts on every bound machine. I have no problems admining my laptop when off the company network, both 10.6.8 and 10.8.1.

Maybe I'm missing the obvious here from the posts above, but why is this not the solution?

Hi Jason,

I'm just getting around to implementing your idea. Unfortunately it didn't work. I thought maybe I needed a dash before append like this

dscl . -append /Groups/admin GroupMembership $3

but that didn't work either. When I run the command manually in terminal I'm getting a "Too few parameters for append" error. The policy runs successfully but my AD admin account is not made to a local admin account because the command is failing.

I must be missing something? I know Tom Larkin has posted a couple scripts that do this as well but I'm not having much luck with those either.

Thanks,
Chuck

dseditgroup -o edit -a $3 admin

is probably the better way to do it.

That is exactly the method we are using. I picked it up from this discussion: https://jamfnation.jamfsoftware.com/discussion.html?id=2337

Thanks, there are so many post and threads on this subject I'm having a tough time finding which one works! And I missed the 2337 thread altogether.

So when I put that line in my policy it returned an error saying no admin group provided. Are you still running it as one line in your policy or is this particular line being used in the script also on the link you sent?

I don't understand which admin group it wanted me to provide, my AD Admin groups or localadmin? Nor do I know the usage as to where in the line those groups should have been specified.

Thanks for the help!

/usr/sbin/jamf is version 8.6 Executing Policy PromoteAD... Running command dseditgroup -o edit -a $3 admin... Result of command: No group name provided

OK I figured out I needed the word "group" before admin, now the $3 how does that work? I know it's in the built in parameters, I haven't used these before with my scripts.

Does it automatically pull the currently logged in user? Or do I have to specify something. If it's suppose to pull the currently logged in user it doesn't seem to work. I ran the script manually on my test box and just replaced $3 with my username and I'm now admin offline BUT obviously I can't possibly specify individual users.

Thanks, sorry I'm a little new at this.

the $3 variable will pull the current user when the script is ran via a self service policy or with a policy triggered by a login event.

Hate to beat the dead horse, I'm trying to figure out why $3 is NOT gathering the username. So here's what I got.

I'd like some help troubleshooting. Here's my script, my policy and my log.

Script = AddUser.sh

dseditgroup -o edit -a $3 group admin

Policy

Name: Run Script AddUser.sh Active: Yes Frequency: Once per computer Trigger: login Priority: Before but I've also tried After Scope: 2 computers Plan: Run Script AddUser.sh

Log - My scope is for two test computers, the logs are identical.

/usr/sbin/jamf is version 8.6 Executing Policy Run Script AddUser.sh... Creating directory structure for /Library/Application Support/JAMF/Downloads/ Downloading http://xxxxxxxxxxx/CasperShare/Scripts/AddUser.sh... Running script AddUser.sh... Script exit code: 0 Script result:

I've also ran it as a logout and as a self service, here's the self service log.

/usr/sbin/jamf is version 8.6 Executing Policy Run Script AddUser.sh... [STEP 1 of 1] Creating directory structure for /Library/Application Support/JAMF/Downloads/ Downloading http://xxxxxxxxxxx/CasperShare/Scripts/AddUser.sh... Running script AddUser.sh... Script exit code: 200 Script result: Record was not found.

Thanks for any help,
Chuck

Try this as your script.

Script = AddUser.sh

/usr/sbin/dseditgroup -o edit -a $3 -t user admin

Another trick to try is stick an echo in your script to verify that the $3 variable is set correctly.

I'm guessing it will work if you use Thusitha's suggestion.

Adding the -T fixed this for me! Thanks all for the help JAMF support caught it. Doing the echo was part of the troubleshooting steps. Once they noticed it was getting the correct username, they then cam back with the missing T. So for all want ing to do this here's what I have that works

dseditgroup -o edit -a $3 -t group admin

Thanks again for all the help.

Hi

Im having the same issue as mentioned above. We have just deployed 10.8.2 machines and part of our bind it adds an ad group so any user in that group is an admin. When the users go home they lose admin.

I have tried running

#!/bin/sh
dseditgroup -o edit -a $3 -t group admin

Through the self service with no luck, i get the following error

/usr/sbin/jamf is version 8.62 Executing Policy Add User As Admin... [STEP 1 of 1] Creating directory structure for /Library/Application Support/JAMF/Downloads/ Downloading http://server.domain.net:80/CasperShare/Scripts/AddUserScript.sh... Running script AddUserScript.sh... Script exit code: 2 Script result: /private/tmp/AddUserScript.sh: line 1: syntax error near unexpected token `newline' /private/tmp/AddUserScript.sh: line 1: `<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">'

What am i doing wrong?

According to the Script result: It seems to be telling you there's a problem in the script you are running on line 1. I'm not an expert by any means but looks like your line 1 is `<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">', when it should be #!/bin/sh. I'd make sure whatever editor you are using to write the script in isn't throwing it's own format code in there. I typically use text edit for the simple stuff, but I change the format preference to "plain text"

Chuck

@CordlezToaster, are you running the script from a HTTP(s) distribution point?

I did write the script up in plain text edit.

Hi Bentoms

That is correct, i am running it from a http(s) point!. I thought self service can only be used if a http(s) distribution point exists?, is that right?.

cheers

CT

Self Service can use any protocol your distribution points support.

I've seen the same error you've given, & it requires verifying your distribution points settings : https://jamfnation.jamfsoftware.com/article.html?id=116