Domain Admin rights vs Local Admin rights

[donmontalvo]

So when a Domain Admin user logs on to a Mac for the first time the Mac automagically selects and greys out the [x] Allow user to administer this computer checkbox. They can sudo, etc.

When we check JSS, it shows that user as non-admin. We had the user run "sudo jamf recon" to refresh JSS, but still shows as non-admin user.

This is probably a moot issue, but we're curious. Should we be concerned that JSS doesn't recognize this user as an admin user? JSS is indeed bound to to the domain, as are all the Macs.

Thanks,
Don

[evarona]

I've seen this and figured "if it works, who cares". But I wonder if this is because the user is part of an AD group that is giving local admin rights and not a specific named user. Or maybe it's just a matter of recon not being able to correctly enumerate the users GUID. I know that when we're deploying a mac, we have a script that adds a user's short name to the local admin group but that doesn't match up to the AD GUID.

[Chris]

It's a bit obvious but i'll ask anyway:
Is the "Allow administration by:" field checked in Directory Utility's advanced AD options and does it show the correct groups?

[talkingmoose]

Where specifically are you looking? The JSS reports on local user accounts and will tell you if those are admins. If those accounts are mobile accounts then those are included.

Reports on directory accounts logged in as admins could easily become stale. For example, an admin user could leave but the JSS would never know that.

[jarednichols · Accepted solution]

It's important to note that the "Allow administration by" checkbox in the AD Plugin *ONLY* works when the machine is within sight of a DC.

If a machine goes offline, you will very likely not be an admin anymore even though you have a cached account.

I suspect, therefore, that the JSS will only see an account as admin if the account is listed in a

dscl . -read /Groups/admin GroupMembership

In effect, hardcoding their "admin-ness"

j

[donmontalvo]

@Chris Yes and yes.

@TalkingMoose JSS > find Mac > Details > Local User Accounts

@JaredNichols Good point, I can see how admin level rights would only be enforced if AD is "visible", from a security standpoint. Is this the same behavior as on the Wintel side? If so we're not going to want to futz with it, instead we'll let the user know they need to use a local admin account with a complex password (which they can easily create while they are connected to the LAN.

Thanks for all the responses. I'm off to Craigslist to sell my dusty old SonicWALL TZ170 while it's still worth a few bucks (damn you Dell!!!).

Don

[talkingmoose]

@TalkingMoose JSS > find Mac > Details > Local User Accounts

Directory accounts aren't local unless they're mobile accounts. Even then mobile accounts for admin users authenticated by a directory service only work when the machine's able to connect to that directory service. Take a machine off the network and the user is no longer an admin.

[evarona]

Is this the same behavior as on the Wintel side?

Windows automatically hardcodes their "admin-ness" (to paraphrase Jared) by adding the AD account GUID to the local admin group regardless if it's by GPO, script or manually. Unless local profile creation is disabled, your AD account is associated with the local groups so you're never really a "mobile user" as talkingmoose mentions. Just one of the minor but important distinctions of Mac/AD integration.

[asditsupport]

Is there any way we can make current AD users to the client machine become admin users via a script?

[LVISDJShip]

Is there a local admin group we can add the district accounts to?