Conditional based on user group membership

[Bart Reardon]

I had a bit of a look around and while there is stuff for computer group membership I haven't seen one for user accounts (or maybe I didn't look very hard)

I've had a small crack at it here https://github.com/bartreardon/munki_conditions/blob/master/adgroups.sh  which works fine in my own AD environment (bones based of Tim Sutton's conditions scripts https://github.com/timsutton/munki-conditions)

Is there anything here I could be doing better? My thinking here is to determine the current user on the console and look up the group info using dscl. It would then be used as console_user_ad_group_member_of contains "group foo". I don't know if this would work in another environment as I don't have one to play with. 

Is there an easier way to get the domain for example? My environment the domain is foo.bar.com and dscl requires /Active Directory/FOO/All Domains but I don't know if that is representative of how this all works or if it's unique per environment. If there's an easier way than all the grep | awk then that would be nicer.

Bart

[Gregory Neagle]

I think any conditionals (directly or indirectly) based on the current GUI user have the potential of producing undesirable behavior, so be sure to test, test, test.  

-Greg

--
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Eric Holtam]

That script wouldn't work in our environment as our AD forest domain is named different than the dscl path to the AD information.

I did find that in /Library/Preferences/OpenDirectory/Configurations/Active\ Directory that there is a config file named FOO.plist.  

That file could be read with defaults to get the "node name" key which is what dscl needs by `defaults read /Library/Preferences/OpenDirectory/Configurations/Active\ Directory/FOO "node name"`

-Eric

[Bart Reardon]

That path is empty in my environment. /Library/OpenDirectory/ only contains empty Mappings, Modules and Templates folders.

I was hoping there was an easy way to determine the correct path but it may be environment specific (unless our environment is incomplete but I'm pretty sure everything is correct for OS X in an AD environment).

[Bart Reardon]

As always 😃

so far so good. In this case if the script fails then the user just doesn't see a particular application. Having said that, I'd like it to be as robust as possible such that a minor change somewhere else doesn't cause issues. 

If it's not trivial to do then I guess it becomes another site specific script but I'd like to be able to use standard ways to determine settings if I can.

[Gregory Neagle]

Point is that current GUI changes much more  often than other machine attributes -- it could even change in the middle of a Munki run. This could lead to unexpected results. 

Sent from my iPhone

[Eric Holtam]

The path is in the Preferences folder /Library/Preferences/OpenDirectory/

-Eric

[Bart Reardon]

ah, thanks for that.

I've updated my script with a few other things https://github.com/bartreardon/munki_conditions/blob/master/adgroups.sh

Still needs some sanity checking (what if FOO.plist doesn't exist for some reason) but I think the general gist is ok. It will fall back to the local user with the most system time (again, pinched from Tim Sutton) if there is no user on the console. This suits my needs.

It then writes to Conditions.plist so you can write a condition like "console_user_ad_group_member_of contains foo_group"

This is nice a generic and I can specify the group in the condition. The limitation here though it it only lists groups that you are directly a member of. 

For nested groups you have to do something different so I had a stab at using the dsmemberutil command https://github.com/bartreardon/munki_conditions/blob/master/group_check.sh

This is a bit different in that rather than check a user for their groups, it checks a group for user permissions. The nice thing is it get effective permissions so nested groups are not an issue. The downside is that you have to know in advance what groups you want to query. It would be nice in this instance to have dynamic input to the condition scripts (maybe there is, I don't know). My potential solution at this stage is to create a small no_pkg that populates a text file with a list of groups I might want to check. Performance may suffer if this list gets too big though. To write a condition though it's just "foo_group == true"

Bart

[Erik Gomez]

Cool stuff Bart. 

Sent from my iPhone

--