Skip to main content

In the past I came up with a little EA that would look into AD and see all of the SG's that a user was a part of. I could then scope access to that based on the result. This worked great, but now that we are migrating away from bound mobile accounts and into standard local accounts, I see that accessing AD is not working.



Does anyone know if there is a way to still poll AD to see what groups a user might be apart of if they are on the network and on a local account? I've tried "ID" and "DSCL", but it says that the data source is no longer valid.



Here is the script I used to use. It pretty much lists all SG's a user is a member of and then I GREP out the one that I am looking for.



#!/bin/bash



# Let's set some variables

CURRENTUSER=$(/bin/ls -l /dev/console | /usr/bin/awk '{ print $3 }')

SG=$(comm -23 <(id -Gn $CURRENTUSER | sed 's/ /

/g' | sort) <(dscl . search /Groups GroupMembership USERNAME | grep = | awk '{print $1}' | sort))



COMPARE="SG_ACCOUNT"



if echo "$SG" | grep -q "$COMPARE"; then



    echo "<result>Yes</result>"

else

    echo "<result>No</result>"

fi

You would need to use ldapsearch for this, which allows for "on the fly" binding to AD to get information about AD resources. However, some things to know about ldapsearch.
a) It's not as easy to use as dscl when getting information. The format it needs is more complicated, but not so complicated as to be impossible. Just very different than what you may be used to.
b) Unless your organization has very relaxed controls around AD and allows anonymous bind (most don't), you will need to use a service account in the 'distinguished name' form with ldapsearch. When using dscl on an AD bound Mac, it doesn't require credentials because the machine itself is communicating with AD through it's domain bind. With ldapsearch you need to give it an account it can use that exists in AD to "search" the directory.



As for using this in an EA, keep the second point in mind if that applies to you. You would need a name/password in clear text in the EA script since EAs can't use script parameters unfortunately. For that reason, I might consider instead using a policy that runs once per day with a script that can use parameters for the credentials to make it more secure. It can pipe the info it looks for into local text files that can then be picked up by the recon.



For a little more info on using ldapsearch, here is a decent resource to start, but there are others:
https://www.splunk.com/blog/2009/07/30/ldapsearch-is-your-friend.html



If you need some more specific examples, I might be able to post something I've used with redacted info.



Edit: You may also want to read through this older similar discussion for some more ideas on using ldapsearch:
https://www.jamf.com/jamf-nation/discussions/15234/determining-what-activedirectory-ou-a-mac-computer-is-located-in

@danshaw Are you using Nomad? I'm wanting to think that you can pull that data through it but could be mistaken.

@mm2270 Thanks for the info. Never considered ldapsearch! Doing some initial research this looks like its going to take some trial and error to get exactly what I want. @jhuls we are using NoMAD. I did see this document on the Shares menu, but do you know how I can use it to gather the info I need?

@jhuls That's a good thought. I forgot that NoMAD actually does capture a bit of good information by default. Since it uses the users own credentials to get this out of AD, joined or not, there would perhaps not be a need for ldapsearch and separate credentials.



Looking at my own system with NoMAD installed, I see a "Groups" section of the plist (com.trusourcelabs.NoMAD.plist) that lists all the groups my AD account is part of it (it's a lot!), so that may be a good way to go, assuming it's also grabbing that info for your users.



defaults read /Users/${loggedInUser}/Library/Preferences/com.trusourcelabs.NoMAD.plist Groups | sed 's/"//g;s/,$//g;s/\\//g;s/^ *//g;1d;$d'


PlistBuddy might be able to get this list a little easier, but the above will work to grab all groups with no leading spaces or special characters in my tests. You have to define $loggedInUser in the script of course.

Wow! That's slick! @mm2270 I used your defaults read line and added a GREP at the end to filter for the SG I wanted. I then stored that into a variable as mentioned at the top and its working perfectly now. I'm going to do a bit more testing, but I think that is the solution!



Thanks guys!

@danshaw Glad that worked for you! You may want to also throw a solved tag onto @jhuls's post (just my thought) since they were the one to suggest looking at NoMAD. It didn't even occur to me to ask that, and I've known for a while now that NoMAD collected a lot of info on the user. I would have had you creating complicated ldapsearch scripts. :)

Truth be told I'm still in the process of evaluating and possibly using it. I think I had seen in a video that the info you wanted was available through it. Glad it worked out.

Terms & ConditionsCookie settings