AD/LDAP Security Groups?

Feature Requests / Feedback
Log in to reply
  • T

    Obvious request (at least to me) but I'm not seeing this asked elsewhere. I was wondering what the stance was on including AD security group presence as a dynamic group criteria?

    I'd be the first to admit I don't know how problematic this would be to construct. I know listing is possible within powershell (and the right module in place), and for LDAP users a cmd line "whoami /groups" would get the job done, but isn't helpful for the machine membership...

    Just thinking of ways I could save touch-points for policy and have a bit more flexibility for change. Current workaround is to throw a purposeless user certificate out to the device with a specific friendly-name and have Toec watching for that. It's a bit circuitous, and I'm probably missing an obvious 'easier' way.

    T 1 Reply 0
  • T

    @thanatos8088 Replying to my own thread, but I do have to add that having come over from Clonedeploy and a mixed bag of other tools (including SCCM) I'm loving this management solution and deeply grateful for everything it has, security groups or not. 😀

    0
  • T

    This doesn't exist but can be added. I'm wondering what they best way to it would be. I'm thinking to just a create a group type that is based on ldap security groups, then it could also have some dynamic criteria attached to it, but then you wouldn't be able to use multiple groups in the criteria and I could see some other challenges. As I'm typing this it may end up being a little more challenging than first thought. Perhaps just as a criteria would work best.

    0
  • T

    I could see an ldap-based toems group with additional dynamic options being useful for some, but for my purposes, I don't see more than just criteria being a necessity (at least within my view of the horizon).... unless I wanted that group to then purge (NOT application,name) members that have finished installing or whatever other action applies... Either way its definitely a step saver. I've got a good workaround I tested out last night with an Adobe CC deploy using the cert trick. Even baked in a cleanup action (still not sure what housekeeping happens with the toec/appdata resources and adobe was a special case because of an obnoxious size) into the GPO, after toems does its thing... good 'ol item level targeting, brutal but effective.

    I could see it tripping up if it can't drill down, i.e. dynamic group looking for CN=Student-Computers which contains CN=High_School_Machines... with group members CN=2023, CN=2024 inside of that... with the computers in question being members among those bottom-rung groups. Worst case, an OR with the base direct-add groups gets the job done, and meeting a system halfway is more than fair. As you said, might prove a little challenging, but I'll gratefully work with whatever the structure provides. Thanks again very much for everything built so far; I'll definitely be name-dropping your resource around my little corner of the education industry, there are a few of us out here yet who aren't running an all-chromebook fleet 😆 .

    T 1 Reply 0
  • T

    Justs tacking this on in case others find the thread looking for a similar function. I've got a better workaround in place than my previous plan, and it mercifully doesn't need an additional PS module; doing this without Get-ADuser since it has to run on the end device was my happy place.

    Using the following as a conditional for a theopenem policy, replace the $group at the end with your match/search criteria:

    $machineDN = "(&(objectCategory=computer)(objectClass=computer)(cn=$env:COMPUTERNAME))"
$userdn = ([adsisearcher]$machineDN).FindOne().Properties.distinguishedname
$strFilter = "(member:1.2.840.113556.1.4.1941:=$userdn)"
$objDomain = New-Object System.DirectoryServices.DirectoryEntry("LDAP://rootDSE")
$objSearcher = New-Object System.DirectoryServices.DirectorySearcher
$objSearcher.SearchRoot = "LDAP://$($objDomain.rootDomainNamingContext)"
$objSearcher.PageSize = 1000
$objSearcher.Filter = $strFilter
$objSearcher.SearchScope = "Subtree"
$colProplist = "name"
foreach ($i in $colPropList){
   $objSearcher.PropertiesToLoad.Add($i) > $nul
   }
$colResults = $objSearcher.FindAll()
$results = foreach ($objResult in $colResults)
    {
      $objItem = $objResult.Properties
      $objItem.name
      }
$group = "PUT YOUR GROUP NAME HERE"

If ($results -contains $group)
{exit 0} else {exit 1}

All credit to the good folks over at stackoverflow for having the pieces for this among a few threads. It might not be as concise as it could be, but it does run quickly.
    0
  • T

    This is now available in 1.5.0.

    T 1 Reply 0
  • T

    @theopenem_admin
    Very very cool, I did run into an issue though, but it might be an edge case. I'm now getting "Failed" for a last run status on LDAP Sync (bind tests OK). It has ingested the security groups, by name, but membership is at 0 for all of them. It looks like this log message is the relevant exception occurring:

    System.Data.Entity.Infrastructure.DbUpdateException: An error occurred while updating the entries. See the inner exception for details. ---> System.Data.Entity.Core.UpdateException: An error occurred while updating the entries. See the inner exception for details. ---> MySql.Data.MySqlClient.MySqlException: Cannot add or update a child row: a foreign key constraint fails ("theopenem"."group_memberships", CONSTRAINT "GROUP_FK" FOREIGN KEY ("group_id") REFERENCES "groups" ("group_id") ON DELETE CASCADE ON UPDATE NO ACTION)

    I went through the update sequence as listed in the guide, any chance I dropped a stitch and this one's on me?

    0