Scheduled task with launchd and a shell script may work

the launch agent:

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>com.mycompany.admin</string> <key>ProgramArguments</key> <array> <string>/path/to/myscript.sh</string> </array> </dict> </plist>

The script:

#!/bin/bash

# loop through /Users to get list of short names

for $localuser in `/bin/ls /Users | /usr/bin/grep -v "Shared"` ; do

/usr/sbin/dscl . append /Groups/admin GroupMembership $localuser

done

exit

Then set up a second script that runs every two hours or whenever you want it to kill the admin rights by changing the append to delete from the dscl command line. The other launchd item can have an interval or running every 2 seconds to every 2 hours to every 2 days if you want. I'd suggest you look at why you need to give temporary admin rights and if so, maybe just give a few people or a group of people admin rights.

Otherwise you will have some launchd items running which will work and I have used them before, but they may have a margin of error. Google Lingon, it is a nice GUI app for creating launchd items.

-Tom

Hey all,

Just my own two cents worth...

If I was asked to do this, first I'd argue against it on the basis that end users having admin rights effectively nullifies management, compliance, and could bring about the end of the world as we know it (ok. I'm exaggerating that last point a bit.)

If I lost that argument, I'd use a script, deployed via self-service.

The script would read in the current console user, by harvesting a bit of code from the "Last User" Extension attribute template.

Then I'd feed this variable to a dseditgroup command (or the dscl append command that Tom mentioned), adding it to the admin group.

To remove the user's admin rights, I might have a launchd item that demotes all nonstandard admin users at a specific interval, or have the policy deploy a package containing a self-destucting launchd item that will execute the admin purge after the designated time.

If I wanted to get really fancy (and to spend a lot of time testing), I might be able to have the initial script interact with the user via osascript to request the admin duration, then use that information plus the username to build the necessary self-destructive launchd item on the fly.

Of course, your user, whilst elevated to admin rights, could do all sorts of unapproved and detrimental things to their computer. I'd probably have the script touch a file, which is the subject of an extension attribute, which places the computer in a "No longer supported" smart group. I'd include language in the policy's Self Service description to the effect of "By executing this item, you agree that technical support for this computer will be limited to a reimage of the system. The IT group will make no unusual effort to preserve data. All software and settings will be reset to company standards. Once the reimage is executed the computer will again be subject to normal management and benefit from normal support procedures."

Again, that's just my own take on the matter. I hope it's helpful.

--

Miles Leacy

Technical Training Manager

Mobile +1 347 277 7321

miles at jamfsoftware.com<mailto:miles at jamfsoftware.com>

....................................................................

JAMF Software

1011 Washington Ave. S

Suite 350

Minneapolis, MN 55415

....................................................................

Office: (612) 605-6625

Facsimile: (612) 332-9054

....................................................................

US Support: (612) 216-1296

UK Support +44.(0)20.3002.3907

AU Support +61.(0)2.8014.7469

....................................................................

http://www.jamfsoftware.com<http://www.jamfsoftware.com/>

I kind of agree here. Either the user needs admin rights or they don't. Temporary just sounds like a huge mess. The reason Windows can do this is that they are not a POSIX compliant OS which has it's own set of caveats and every user essentially runs as root. They use policy to restrict access through their own sets of permissions.

Another option would be to create a shadowed account on the fly when they log in, that is their shortname + -admin. So, for example if I log in as tlarkin, the script would grab that and create an account called tlarkin-admin and it would just shadow my existing password. Then at log out, or whenever the launchd item kicks in all the *-admin accounts can be deleted.

Aah that will kill it….I have been trying to take the user account out off the admin group but I was having problems with our admin accounts even hidden casper ssh account…
I think this will be better solution without messing about with the existing account.
Example of the script will be brilliant though…
Thanks

How are your accounts set up? Do you hide user accounts by using a
UID lower than 500?

No, standard mobile account. AD plugin: force local home directory….no network homes.

i've taken a number of approaches to this problem but generally discourage granting temporary admin rights in the first place. if there are reasons for logging in as administrator level accounts, document them and determine if you can automate around them, using self service and other tools at your disposal. if there are software packages that require admin logins to run, bring this up with the vendors to see if they can provide other options for you. it's not a good idea if you want to maintain a managed fleet of machines.

that said, take a look at some of my stuff for ideas.

this removes local admin rights for all local accounts except the ones you define: https://github.com/tspgit/scripts/blob/master/accountmanagement/removelocaladmin.rb

this reinstates local admin rights for the accounts you "demoted" earlier: https://github.com/tspgit/scripts/blob/master/accountmanagement/restoreadmin.rb

i have another version of the removal routine that writes the results to a dummy receipt file and will have to check that in.

another approach is to define local admin rights for an existing AD group via the AD plugin on the client side, then add the user or a temp user to that group in AD. when the user logs in, he/she should have admin rights, and you can change the password or revoke rights without touching the clients.

something else i worked on takes a hybrid approach by creating mobile admin accounts derived from AD groups and OUs. this way, the local admin is separate from the user's regular login account, the admin access and password are managed centrally, and it will work with laptops off the network (the AD plugin admin group approach will require AD lookups to determine admin group membership, so that breaks down with mobile users).

it would be easy enough to use a timed launchd job to grant and remove local admin rights using some of these techniques.

still, i'd recommend not granting admin rights at all. it's a headache.

Definitely I agree…we have a computer usage policy written at the login point :)

I think I may have found a pretty elegant solution to this, well for scripting purposes. I still think temporary admin rights is not and should not be needed. With powerful tools like the command line and Casper you should be able to assess any situation with out giving your users admin rights. Unless you need to give them admin rights as they may need to modify the system a lot for their work.

I usually use loops through /Users to grab a list of local user names. Someone recently pointed out that my script is not a best practice because a home folder may not always exist in /users, as it may be put somewhere else. So that person is right, it probably is not best practices in case of a slight environment change. Like a computer that isn't imaged is introduced or new machines in a department that require different configurations. So, a method of grabbing any users with a UID greater than 500 may be a better solution.

dscl . -list /Users UniqueID |awk '$2 > 500 { print $1 }'

This command will print out a list of all users with UID greater than 500, which should be any local or network account created after imaging. If you use hidden admin accounts their UID is typically under 500 to hide them from the finder.

thanks that was me talking about home folders :) glad I helped!

Regards,
Ben Toms
IT Support Analyst GREY Group
The Johnson Building, 77 Hatton Garden, London, EC1N 8JS
T: +44 (0) 20-3037-3819 |
Main: +44 (0) 20 3037 3000 | IT Helpdesk: +44 (0) 20 3037 3883

Or my personal favorite, TCO (total cost of ownership). Companies eventually see there are hidden costs to allowing users to have admin rights and it becomes less of a fight... ;)

Don

Yep.. we're getting there (thanks to client requirements too)..

Self Service is really really useful for giving the power back to those users whom feel aggrieved but still remains managed.

Regards,
Ben Toms
IT Support Analyst GREY Group
The Johnson Building, 77 Hatton Garden, London, EC1N 8JS
T: +44 (0) 20-3037-3819 |  Main: +44 (0) 20 3037 3000 | IT Helpdesk: +44 (0) 20 3037 3883

Hi, I just joined the list, so I apologize for not actually replying to the email, but this will have to do.

The #1 issue with granting temporary admin rights is that there is no way to guarantee that it is temporary at all. Any admin can create a new admin account, any admin can remove a launchd item, etc. Nothing can be done about that, short of standing over the user's shoulder watching what they do.

Just thought I'd chime in before the topic completely died.

full disk encryption has it's own set of caveats though and in an academia environment I would not recommend it. Users hardly back up all their data on a regular basis and if that drive has any file system problems it could be bye bye to your data.

Physical access trumps security though, we all know that.

Staples is next door...padlocks are cheap. :)

Not sure what to do to secure laptops from being opened though...

Don

I haven't met a lock I couldn't break open with some bolt cutters. Though a desktop in your office is probably not going to have it's pad lock cut with bolt cutters. You cannot lock down laptops because they need to be opened to be worked on.

I like that...how do you do it?

If an admin rights being given to users, they should only allowed to use
their AD account. So we have a visibility of employees and their
activities (if comes to that).
MCX to lock the Accounts in System Prefs is good to prevent them from
creating a static account in some degree. This will make the user
anonymous (man with the mask).

I would like to have a notification email, if they are to create a static
account or enable root (so I know). Or even better if I can lock these
functions totally and maybe pop up window regards Computer Usage Policy.

Cem

Depending on the laptop, C4 may get you in quicker. :)

On the laptops, of course I meant opening the bottom to get to the RAM.

Don

The problem remains that there are many other ways for an admin to create a new admin account. The jamf binary's createAccount command comes to mind, for example. Restricting Terminal won't do the trick, because an admin can easily download and install any number of terminal programs (I'm fond of iTerm). And there's still the matter of being unable to ensure the launchd item is executed; an admin can remove it easily. Restricting app downloads might do the trick, except that I know how to build an app with nothing more than TextEdit and Finder.

Ultimately, if your users are determined enough, they can get around the time limit. I remember someone once told me that once an attacker has root, the game is over. And any admin who knows his or her password can get root.

Anyone with physical access can get root and thus create an admin account. Done it myself in a pinch when an existing account was hosed. Single user
mode, create a new one.

j
-- Jared F. Nichols
Desktop Engineer, Client Services
Information Services Department
MIT Lincoln Laboratory
244 Wood Street
Lexington, Massachusetts 02420
781.981.5436

That only works if the EFI password is not set.

My thoughts exactly. We lock down the EFI, but then if you remove memory and reset the PRAM... EFI password is gone.

James Fuller | Technology Application Services | application developer II | V: 206.318.7153

I wonder whether any full-disk encryption programs allow you to lock down startup modifiers...

Which is why I have my dummy receipt policy to detect any accounts being promoted to admin

We're testing sophos now..

It does block some.. I'll update when we get the release version to fully
test.

Regards,
Ben Toms
IT Support Analyst GREY Group
The Johnson Building, 77 Hatton Garden, London, EC1N 8JS
T: +44 (0) 20-3037-3819 |
Main: +44 (0) 20 3037 3000 | IT Helpdesk: +44 (0) 20 3037 3883