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.
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.
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.
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
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.
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.
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.
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>
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.
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?
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
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?
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
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.
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.
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?
I haven't done any testing on Mavericks yet but thanks for the heads up. I'll make sure and test this.
@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.
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?
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.
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!
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.
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.
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.
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.
