Restrict logon to specific Active Directory Groups

[frozenarse]

Goal: Only allow members of specific Active Directory (AD) groups to logon to certain computers.

Why: We want to keep students from being able to logon to Faculty/Staff computers. We also need to keep Prep school students from using University computers.

The Details of the problem: THIS WORKS: Manually going into System Preferences, Login Options, Allow network users to log in at login window (Options...), Only these network users. Entering in domain groups.

THIS DOESN'T WORK: Creating a Configuration Profile within JSS where the Login Window contains a payload with the groups specified under the Access tab. This doesn't work if the group contains > 1500 users.

Can anyone verify this?

Any workarounds?

This is a bugger.....

[daworley]

Centrify can do exactly what you are asking about through use of Zones. I think their free Centrify Express omits this feature, but it might be worth lookng into.

Casper and Centrify work together rather well.

[daworley]

Also, iIIRC you can set those allowed workgroups via a dsconfigad script.

You could use different versions of the script for various purposes and scope them to different groups in Casper.

[frozenarse]

Thanks for the suggestions.

Centrify - I'd rather not add another piece to the puzzle if at all possible. This should be able to be handled by Casper in my opinion.

dsconfigad - I think this is used to determine which groups are admins of the machine, not restricting who can logon. Unless I'm misreading one of the parameters.

[Brad_G]

We do something that's kind of reversed. We have a script that runs on login to see if a user is a member of a group (guest account, or restricted student). If so it denies the login. Maybe you could tweak something like this to get what you're after.

#!/bin/bash
result=dsmemberutil checkmembership -U $3 -G ADGroupYourChecking
compare="user is a member of the group"
if [ "$result" = "$compare" ]; then
echo `date '%b %d %T'` `hostname -s` "Login access denied for user:" $3 >> $1/var/log/secure.log
echo `date '%b %d %T'` `hostname -s` "Login access denied for user:" $3 >> $1/var/log/lstscript.log
kill `ps -ef | fgrep loginwindow | grep -v grep | awk '{print $2}'`
fi

[frozenarse]

Logon script is what we are currently using in our 'PreLion' environment and we are hoping to move away from that method.

Again.. It works manually for all groups and with policies it works for groups < 1500. We are soooo cloooose and that makes if frustrating.

[jaferguson]

Have you tried the Casper Managed Preference com.apple.loginwindow -> "Allowed Users" or Groups" OR "Denied Users or Groups"?

Management Tab in the JSS, Managed Preferences, Create Managed Preference, Create from Template -> select com.apple.loginwindow.

Seems the easiest way to me.

[frozenarse]

MCX- Yup, I tried that as well as part of my testing with JAMF support and it yielded the same results as the Configuration Profile method. Groups with > 1500 users didn't work.

We really want to avoid designing anything that uses MCX because that is being phased out (at least that's what we keep hearing....)

Best Scenario: Something gets fixed so we can use Configuration Profiles via JSS.

2nd Best: Somehow get a script to do what the manual process does. I'm having a hard time determining what exactly is required to get the "Only these network users" radio button ticked.

[jarednichols]

Not really an answer, but you can turn up your logging level a bit and may be able to glean some more info.

odutil set log <log level>

[frozenarse]

JAMFGurus are thinking that it is related to an LDAP limitation (http://msdn.microsoft.com/en-us/library/Aa367017). But I don't understand how the results are different when it is configured manually vs via MCX or Profile.

good idea with the logging... they were having me look in the system.log but it appears that /var/log/opendirectoryd.log is where all the goodies are.

[talkingmoose]

Through a little experimentation with dscl I see that when an Active Directory group is added manually under Accounts --> Login Options --> Allow network users to log in, the GeneratedUID from Active Directory is added to NestedGroups under /Local/Default/Groups/com.apple.loginwindow.netaccounts.

To read the Active Directory GUID for a group use:

dscl "/Active Directory/All Domains" -read /Groups/myADGroup GeneratedUID
GeneratedUID: E791344D-B19E-4AEE-A769-B7A2F6730203

To read the local group's nested groups use:

dscl . -read /Groups/com.apple.loginwindow.netaccounts NestedGroups
NestedGroups: E791344D-B19E-4AEE-A769-B7A2F6730203

This is the local file getting modified:

/private/var/db/dslocal/nodes/Default/groups/com.apple.loginwindow.netaccounts.plist

This adds the Active Directory group's GeneratedUID to that com.apple.loginwindow.netaccounts.plist file using the defaults command:

defaults write /private/var/db/dslocal/nodes/Default/groups/com.apple.loginwindow.netaccounts nestedgroups '( "E791344D-B19E-4AEE-A769-B7A2F6730203" )'

The group name as it appears in Active Directory "DOMAINmyADGroup" now appears in the window after clicking the Options... button.

Adding this group, however, doesn't flip the radio buttons from All network users to Only these network users. I'm not finding that preference to be able to set it. Possibly, someone else has an idea?

[matthew-c]

you need to nest the GUID of

/private/var/db/dslocal/nodes/Default/groups/com.apple.loginwindow.netaccounts.plist

into

/private/var/db/dslocal/nodes/Default/groups/com.apple.access_loginwindow.plist

then the preference is set.

You don't have to search for the GUIDs and then use defaults write you can just use the following commands

dseditgroup -o edit -n /Local/Default -u admin -p -a ADgroup -t group com.apple.loginwindow.netaccounts

dseditgroup -o edit -n /Local/Default -u admin -p -a com.apple.loginwindow.netaccounts -t group com.apple.access_loginwindow

where admin is your local admin account (you will be prompted for authentication) and ADgroup is the group you would like to add to the ACL from AD.

hope this helps

Matt

[frozenarse]

Matt- That certainly sounds promising but i'm seeing the following issues....

It appears that a newly imaged machine that is joined to the domain does not have the com.apple.loginwindow.netaccounts group. From my crude testing, that group appears to be created once you manually click the "Only these network users" and add in an account or group. When running the first command I was getting a response of "Group not found".

I did the manual steps to make sure the com.apple.loginwindow.netaccounts group existed before running that command and now i'm getting "Failed to set credentials".

Would it be possible for someone to verify that the original problem can be duplicated in their environment? Essentially try to restrict logons to only an Active Directory group that contains > 1500 users by using MCX or Policies?

[matthew-c · Accepted solution]

I can't test the MCX route as i don't have an AD group that large but you could try creating the loginwindow access groups yourself.

dscl . -create /Groups/com.apple.loginwindow.netaccounts
dscl . -create /Groups/com.apple.loginwindow.netaccounts PrimaryGroupID GID
dscl . -create /Groups/com.apple.loginwindow.netaccounts Password *
dscl . -create /Groups/com.apple.loginwindow.netaccounts RealName "Login Window's custom net accounts"

dscl . -create /Groups/com.apple.access_loginwindow
dscl . -create /Groups/com.apple.access_loginwindow PrimaryGroupID GID
dscl . -create /Groups/com.apple.access_loginwindow Password *
dscl . -create /Groups/com.apple.access_loginwindow RealName "Login Window ACL"

GID should be a unique number so you could use the following in a script to help you find a free one. On my test system the GIDs are 206 and 235.

dscl . -list /Groups PrimaryGroupID | grep $desiredGID

Additionally if you want to script the previous two commands I posted then remove the "-u admin -p " section (must then be run as root) as follows:

dseditgroup -o edit -n /Local/Default -a ADgroup -t group com.apple.loginwindow.netaccounts

dseditgroup -o edit -n /Local/Default -a com.apple.loginwindow.netaccounts -t group com.apple.access_loginwindow

This works on my system but i don't know if it will get past your >1500 user/group mark or not.

Let me know what you think.

Matt

[frozenarse]

Matt - That seems to be working! Thank you!

I was curious if the GIDs were random so I added some groups via System Preferences and on several machines they were consistent. I'm going to use 206 and 235 based on that info.

One other thing I found out is that my local administrator accounts could no longer logon. I had to add the 'localaccounts' group into the com.apple.access_loginwindow group. After that everything is working fine.

I'm able to logon with an account that is a member of a group containing over 1500 users now. Ideally we wouldn't have to use this scripted workaround (not sure why MCX or Profiles manages things differently than if you manually set things).

Thanks again for taking a look at this.

[nigelg]

i had the same problem when the number of AD users in our Mac access group went over 1000. OSX implentation of LDAP doesn't support paging and can't read all members of a group that numbers over 1000, I wrote an app in .Net that splits the mac access group into 4 groups on a schedule and those 4 are given access. I haven't implemented Casper yet in our environment but it wil be interesting to see if those groups are usuable via the MCX you mention as the OD managed preference for access in 10.8 fails to create a restricted group based on the access groups. I have had to write a script to kill the loginwindow if the user isn't part of the access group, as mentioned above.

As a side note, we also ran into a problem with the app I wrote when the main group reached 1500 where the .Net class I used couldn't pull more than 1500 records from the AD. I had to rewrite part of my app using the dsget command and some powershell to get above the 1500 limit. Seems quite a common limitation to have to get round.

[plawrence]

Hi previous posters @nigelg @frozenarse @matthew-c

Sorry to resurrect this thread. I am attempting to restrict login to a specific AD user group and I have been unsuccessful using configuration profiles in Casper. I saw this thread and setup the scripted method to take advantage of the com.apple.loginwindow.netaccounts group, but I appear to be having problems in Mavericks. After adding the required AD groups the login at the login window fails around five times before it lets the user in (using the same username and password each time).

Have any of you tested this solution on Mavericks yet?

[frozenarse]

I haven't done any testing on Mavericks yet but thanks for the heads up. I'll make sure and test this.

[drowe]

@jarednichols - In reference to your comment to the odutil command, how did you implement this via jamf, did you use a policy. Did you create a script to call this command? I've never used it and would like to implement in my environment to track a binding issue I'm experiencing.

[mrhollywoodgate]

I've tried this on Mavericks and ran into the same issue with users having to login 5 times before it would work. Also, maybe I'm missing something, but it disabled local users from being able to login, and only allowed the network users, but now that I say that, I'm guessing I need to add the local admins group to the login window pref file to get them to login. Also, I noticed that if I want to go in and manually add another group through system preferences at a later time, it won't work - I can add them and click Okay, but the setting doesn't stick. My goal is to add this step into my imaging workflow, so all my AD settings are already configured.

Has anyone found an answer to the Mavericks and 5-login issue?

[plawrence]

Hi @mrhollywoodgates

My last testing of this lead to me filing a bug with Mavericks as it doesnt appear to handle nested AD groups properly at the LoginWindow. I havent re-tried this with 10.9.2, but I dont recall seeing anything in the update changelog regarding the issue.

[mrhollywoodgate]

Thanks for the reply, @plawrence. I was testing in 10.9.2, so it seems to still be a bug. I won't hold my breath for a fix in 10.9.3, but maybe!

[JasonL01]

Hi plawrence

I was able to test it on 10.9.2 and it work. I was able to restrict a certain group in AD from log-in on certain Mac's.

1) Find out the GUID of the group -
This is easy to do using Active Directory Users and Computers.

Click View > Advanced Features

Drill down to the user you want to know about and open the Properties.

Click the Attribute Editor tab

Scroll down to the "ObjectSID" attribute.

2) Apply the GUID of the group in managed Preferences -> login window -> Denied Users or Groups. I added the GUID to the DenyList-Raw.
3) Just to make sure it is restricted -Configuration Profiles -> login window -> Access -> Added the GUID also to the Deny. I'm currently using JSS 9.24 and this Active Directory Group only has 50 users.

Give it a try to see if it works for you.

[nigelg]

Another problem with testing access is that even if you are returning 1000 results only, some users will still log in - I assume those users are lucky enough to be in the 1000 records that are returned.

[timsutton]

The script posted by @matthew-c of managing the nested groups manually has also worked for me up until 10.9.

As of 10.9, the users in my access groups list are still able to log in, but only after the third attempt. The first two attempts just give the head-shake. As a data point we do have more than 1K users in AD, but the groups themselves are much smaller. I get the same results when configuring the network access list manually through the Users & Groups preference pane.

[jaharmi]

If you’re seeing this problem — especially related to membership in nested directory groups in Mavericks — I would strongly suggest reporting it to Apple through AppleCare (if you have the means) and/or through a Developer bug report. More data, including impact data, could certainly help.

[jaharmi]

BTW, I didn’t see any mention of the use of Directory Utility, which I find useful for visualization. You can use this tool to view/add/edit/delete the local groups, although it’s not useful for that on a mass scale. I add it to my Dock.

It’s /System/Library/CoreServices/Directory Utility.app. Or, you can open it from the Users & Groups System Preferences (Login Options, method to access it varies depending on whether the system is bound to a network directory or not). Once you launch it, you can choose to Keep in Dock.

In Directory Utility, go to Directory Editor, view your Groups in the Local/Default node.

[rblaas]

Did anyone get this working under 10.10.x (of 10.11)

I can set the login to only a specific Domain group (AD) but when I restart I cannot logon. Not even with the local admin...

Will investigate further but maybe someone else has found the issue ?

[philcebutv]

Hi,

Sorry to resurrect this thread again. I am as well looking to restrict logon for specific groups in AD on all or our iMacs. We don't have a >1000 users but will be getting there in a few times.

Does com.apple.loginwindow works for this? and what attribute in AD should I be using objectSid?

Really appreciate any feedback on this

Phil.

[yadin]

I'm trying to figure this out as well. I can't find a setting in JSS that reflects System Preferences -> Users & Groups -> Login Options -> Options -> Only these network users -> add in some groups from the AD

The closest thing I find in JSS is Profile -> Login Window -> Access -> Allow. However, this seems to reference groups in JSS not AD, the purpose of which I can't quite figure out, but regardless is not what we need.

Anyone know what I'm missing? Please tell me this is a setting that can in fact be managed without more silly custom scripting...

[yadin]

Nevermind, I just discovered the central folks bound the JAMF server to an LDAP system not Active Directory, so we have user query but not groups.... le sigh.... I don't suppose anyone knows a way to address this outside of me convincing them to move the server....

[nigelg]

@ebonweaver the setting to restrict logins to AD groups is a configuration profile - restrictions. You can add AD groups there in the access tab and it doesn't matter if your JAMF server isn't bound to AD/LDAP as long as the client Macs are.

Unfortunately, the configuration profile still doesn't actually work and just lets everyone log in. I haven't tested in a while but that was my experience with Sierra.

[yadin]

@nigelg from what I can see it's as I said, it only works if your JSS is bound to the same domain as the clients, because it's resolving and sending down SID information, not some generic group name that the client resolves on its own. At some unknown time when our organization get things aligned I'll be able to confirm or deny that. I wish it was more generic and would allow just setting a group name that the client did a dynamic lookup on, but JSS has proven not so flexible.

[nigelg]

@ebonweaver

I was refering to this third party bug, listed in the release notes as recently as 10.5.0

[D-005532] macOS configuration profiles with a Login Window payload that is configured to deny users and groups the ability to log in fail to do so.

Its not listed for 10.5.0 either as a bug that was fixed or as a third party bug. Maybe its fixed.