temporary admin rights

Cem
Valued Contributor

Just wanted to pick your brains.

Our Win7 guys came up with a feature as user can choose have admin rights
for 1 hour, 2 hours, 4 hours, 24 hours or 30 days. After the period ends
admin rights taken off as automated.

Can this be achieved? For AD bound Macs with local mobile homes, using
Self Service or any other method

Thanks in advance

Cem

38 REPLIES 38

tlarkin
Honored Contributor

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

milesleacy
Valued Contributor

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/>

tlarkin
Honored Contributor

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.

Cem
Valued Contributor

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

tlarkin
Honored Contributor

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

Cem
Valued Contributor

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

rockpapergoat
Contributor III

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.

Cem
Valued Contributor

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

tlarkin
Honored Contributor

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.

bentoms
Release Candidate Programs Tester

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

donmontalvo
Esteemed Contributor III

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

--
https://donmontalvo.com

bentoms
Release Candidate Programs Tester

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

Not applicable

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.

tlarkin
Honored Contributor

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.

donmontalvo
Esteemed Contributor III

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

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

Don

--
https://donmontalvo.com

tlarkin
Honored Contributor

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.

Cem
Valued Contributor

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

donmontalvo
Esteemed Contributor III

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

--
https://donmontalvo.com

Not applicable

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.

jarednichols
Honored Contributor

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

Not applicable

That only works if the EFI password is not set.

jafuller
Contributor

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

Not applicable

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

tlarkin
Honored Contributor

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

bentoms
Release Candidate Programs Tester

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

donmontalvo
Esteemed Contributor III

I didn't think full disk encryption was possible with Mac OS X, at least that's what the vendors have been telling us.

Don

--
https://donmontalvo.com

bentoms
Release Candidate Programs Tester

We've not heard that yet.. mind you I've not been in the meetings discussing it!

We've tested alertsec (nasty little product) & am now about to test sophos

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

jarednichols
Honored Contributor

There's quite a few FDE vendors. We're using WinMagic. You're talking to
the wrong vendors.
-- Jared F. Nichols
Desktop Engineer, Client Services
Information Services Department
MIT Lincoln Laboratory
244 Wood Street
Lexington, Massachusetts 02420
781.981.5436

stevewood
Honored Contributor II
Honored Contributor II

We're using PGP 10.1 here and it works fine.
On Fri, Jan 21, 2011 at 8:53 AM, Nichols, Jared - 1170 - MITLL <jared.nichols at ll.mit.edu> wrote:

Steve Wood
Director of IT
swood at integer.com

The Integer Group | 1999 Bryan St. | Ste. 1700 | Dallas, TX 75201
T 214.758.6813 | F 214.758.6901 | C 940.312.2475

ernstcs
Contributor III

I BETA tested Sophos' Disk Encryption. I think it will be good, but some
of the features and integration with Enterprise Console need to mature.

Craig E

Not applicable

Technically, you're probably right. I doubt there's enough space in EFI to contain the entire decryption program (nor would I recommend trying - it would be far too risky). Checkpoint (what we use, reluctantly) encrypts the main volume, and creates a small partition whose job is to boot just enough to have the user log in, and decrypt the main volume, then it passes control to the main volume's OS, which then boots normally.

I have two gripes about that mini-OS that it loads from that partition: it looks exactly like Windows XP, and it doesn't seem robust enough to make encryption useful for any computer on a domain. Meaning, if multiple users have to share the same encrypted laptop, the only way to permit that is to have them all use the same login information for the decryption. I have no idea what it might take to change the passwords remotely, either, but I doubt it's easy (or even possible).

I hear Checkpoint does a better job on PCs...

jarednichols
Honored Contributor

RE the multiple users authorized to decrypt... At least with WinMagic, you
can assign as many users as you want who are authorized to decrypt and
boot a drive. You add the user on the server console and then the next
time the machine checks in it adds that user to the authorized list of
users to decrypt and boot. No need to share any sort of credentials. If
that were the case, our security department would have put the kibosh on
it immediately. Any sort of common credentials is a bit no-no in my parts.

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

Not applicable

Indeed, I believe the PC version of Checkpoint has something similar. The Mac version does not. There is no server, it's all on the client. Frankly, I'd be happy with using FileVault instead. (I know, I know, but it's better than this crap...)

bentoms
Release Candidate Programs Tester

Yep like not being able to use the console sucks.. but the casper scripts seem to work nice.. it does just mean all you're getting is more an EFI type username & password combo.

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

donmontalvo
Esteemed Contributor III

Wow, It would appear so! :)

** Sent from my iPhone **

--
https://donmontalvo.com

donmontalvo
Esteemed Contributor III

Ok, looks like I'm 2-3 years behind the curve on the full disk encryption side of things. I found a link to show that Checkpoint was the first available solution, released in 2008:

http://www.checkpoint.com/press/2008/fdemac052808.html

Redwood City, CA — May 28, 2008

"Check Point® Software Technologies Ltd. (Nasdaq: CHKP), the worldwide leader in securing the Internet, today announced the release of Check PointFull Disk Encryption™ for Mac OS X, the industry’s first full-disk encryption solution with pre-boot authentication to support the Mac OS."

I do remember exploring this a few years ago and being told by the vendors that the only encryption solution/method available (at the time) was to encrypt the user directories, which wasn't acceptable to us. Haven't had a need to revisit since then. I guess I should have signed on the JAMF encryption web demo... :)

http://www.jamfsoftware.com/solutions/full-disk-encryption/

Thanks,
Don

--
https://donmontalvo.com

jafuller
Contributor

Don,
We use PGP WDE and have very few "gripes" about it. It can centrally manage the encryption keys and is cross platform since we have a ton of Windows here.

I've often wondered what the purpose of WDE is when you can lock users down to the Users directory and keep the out of the rest of the HD. Any potentially secret information could be encrypted in the Users directory and WDE wouldn't be needed. But we had it first on the WinXP/Win7 side and thus were required to implement it on the OS X side.

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

Not applicable

We have been using PGP for the last year now.