Casper enrollment without admin rights?

[znilsson]

You need local admin rights on a Mac in order to run the QuickAdd package to enroll a Mac into Casper, regardless of which method you use - invitation, or self-enroll or whatever, it always comes doing to needing local admin rights in order to install the QuickAdd package.

Is there any way around this? I know it's OS X's built in security settings asking for admin permission, but it's a pain for our users that don't have admin rights.

[mm2270 · Accepted solution]

If you have no access to these Macs at all, not even say, SSH access to a local administrator account on the box, then there aren't many options. Probably best to just re-image them since who knows how they are even configured anyway.

However, another option might be to reset the admin account (I assume there's at least some admin account on them) by booting to Recovery HD and using the password reset function. Once that's done, you or the user or whomever, should be able to log into that local admin account and download and run the QuickAdd pkg. It probably would be best to have a policy later that would remove that local admin account if detected, assuming its something you don't actually want on them, or don't want the users to know of and have access to.

[mm2270]

Silly question, but... if they are unmanaged by any product like Casper to start with, and they also don't have admin rights on their Mac, what exactly are they doing with their Macs? I assume they are just running the applications that came with it and nothing else, since they can't install anything new?
The whole model of 'user self enrollment' is designed around the idea of BYO, but not necessarily restricted to that of course. But generally speaking its intended for users that have some level of admin control over their Mac to even initiate enrollment into a management solution, otherwise they shouldn't be trying to do that at all.

I'm not sure there's any real solution here. My initial thought was to modify the authorization db or mess with the sudoers file, but you'd still need to be able to manage the Macs somehow to even push any kind of change to them to affect that. If they aren't already enrolled, you won't have any access to them, unless you're using something like ARD also?

[znilsson]

Well new Macs go through our depot and get imaged with Casper so that's not an issue, this is more about when Macs change hands within the company, and sometimes when that happens it's a Mac that's been sitting in a closet for a couple years and was never enrolled in Casper. Granted this is not something that happens all the time, but it does happen.

And yes, we have no remote access to these Macs when something like this happens. They're from the dark days of pre-management. If the answer is just "you can't enroll without admin rights", that's fine. I just wanted to ask because it came up.

[davidacland]

Same from me, it would be a bit of a worry if there was a way for the user to get around it. The JAMF binary has root level access so it would be similar to installing a root kit as a non-admin user.

I think you'll have to go down the recon or ARD route to get them enrolled unfortunately.

[mm2270 · Accepted solution]

If you have no access to these Macs at all, not even say, SSH access to a local administrator account on the box, then there aren't many options. Probably best to just re-image them since who knows how they are even configured anyway.

However, another option might be to reset the admin account (I assume there's at least some admin account on them) by booting to Recovery HD and using the password reset function. Once that's done, you or the user or whomever, should be able to log into that local admin account and download and run the QuickAdd pkg. It probably would be best to have a policy later that would remove that local admin account if detected, assuming its something you don't actually want on them, or don't want the users to know of and have access to.

[znilsson]

In our organization, the practical solution is just to have the end user put in a help desk ticket, and one of our deskside techs will go out to his machine and enroll it. I mean that's generally how it's supposed to work anyway, but this is one of those weird cases where a Mac wasn't imaged with Casper, and isn't enrolled either, and the end user doesn't have admin rights.

Sort of related question - what's the best way to, once the Mac is enrolled, give the end user local admin rights? We don't do this for all our users, but there are some engineers and programmers that actually need admin access. I didn't see anything in the JSS that allows me to give a given user admin rights, so I'm wondering if I missed something obvious, or if there's no built-in way to do it.

[mm2270 · Accepted solution]

Use dseditgroup to give a user account admin rights.

There are probably a dozen script examples here on JN you can use for this purpose. Some that simply give the logged in user admin access, some that may prompt for a username or take a parameter ($4) that can be used for the username, etc.

A basic syntax example of giving a user admin rights. Assume the username is "joe"

/usr/sbin/dseditgroup -o edit -a joe -t user admin

[alexjdale]

I personally wouldn't want a rogue system to be enrolled in whatever random state it is in, if someone did pull an old Mac out of a closet I would want them to work with our desktop support team to get it baselined. There is so much more than Casper that would be broken and not up to code.

[znilsson]

@mm2270 Thanks for your responses. That script line worked perfectly. And I cloned it and changed the -a flag to -d to remove admin access, which is also going to be useful.

[bentoms]

@znilsson, I'm with @alexjdale. I'd reimage all the in cupboard Mac's so they are managed by the JSS.

Another benefit is that the Macs will then have a record in the JSS, so you know exactly what you have & where (possibly).

You can then amend the users or location details to mark it as a spare/loaner.

[mm2270]

Although I'm glad I was able to help, I guess, I just want to say I do agree with @alexjdale and @bentoms. I would seriously reconsider and just re-image those Macs.
The concern for me would be, any Mac that sits in a closet or drawer for even a few months falls way out of date on patch compliance, assuming that's of any concern to you. Products like Flash Player, Oracle Java, Silverlight and most browsers are being revved so rapidly now to address security flaws that there will be multiple security issues with any Mac not being actively kept up to date. Just enrolling them in your JSS and getting them back on a network seems pretty risky to me. The days of no exploits for OS X are gone. We have to face the reality that any Mac not kept patched regularly is a risk. Maybe not as much of a risk as Windows, but still a risk.

Its your choice how you want to manage these going forward of course, but I did want to just put that out there.

[znilsson]

As the legendary Sledge Hammer used to say: "Trust me... I know what I'm doing."

I may be a Casper noob but I'm not an entire idiot. Only part of one. The Mac in question was originally in use by our digital security department, and the new user is also in digital security. They understand the risks, and in addition I have policies for everything you mentioned in Casper already. We had a discussion about it internally, I just didn't bother mentioning that here because it wasn't relevant.

We're big on patch compliance here, and in fact with Casper I'm able to get it done faster than our Windows side is. Like these recent Flash releases, it's nice to be able to go into a conference call with our security people and tell them I already have it covered, before they've even built a package for the Windows side.

Anyway thanks again for the help, command line is clearly one of my weak points and I appreciate the help.