Welcome to the community forums for Theopenem. You are encouraged to not only ask questions but help others as well. If you have found Theopenem helpful in any way please consider purchasing a support contract. A support contract ensures the continued development of Theopenem as well as guaranteed responses to your questions in our helpdesk ticketing system.


  • 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.


  • @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. 😀


  • 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.


  • 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 😆 .


  • 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.