Object Categories and TestScript

[dbeugger]

I have problems to get my own Object Categories working with TestScript. The logic in TestScript did not filter.

I tried your example

@{
    Name = 'DomainController'
    ObjectClass = 'computer'
    Property = @('PrimaryGroupID')
    TestScript = { $args[0].PrimaryGroupID -eq 516 }
    LDAPFilter = '(&(objectCategory=computer)(primaryGroupID=516))'
}

This way a got all DC's. Then i changed in TestScript the number to 517, I expected no DC, but i got all again. I changed it toTestScript = { $false }, the same result. Did I miss something?

[FriedrichWeinmann]

Sorry about the late response

That said, I cannot reproduce your issue. Did you make sure to reload the configuration? (The config files will not be automatically loaded again on Test- or Invoke- runs.

Either start a new console or run:

Import-Module ADMF -Force

[dbeugger]

My Object Categories

@{
    Name = 'DomainController'
    ObjectClass = 'computer'
    Property = @('PrimaryGroupID')
    TestScript = { $args[0].PrimaryGroupID -eq 517 }
    LDAPFilter = '(&(objectCategory=computer)(primaryGroupID=516))'
}

TestScript filters to group id 517 and LDAP to 516. This should result in no Computer Group Memberships definition

@(
    @{
        ObjectCategory = "DomainController"
        Group = "TestDc"
    }
)

Group 'TestDc' does exist and is empty

PS Output:

PS1> Import-Module ADMF -Force
PS1> Get-AdmfContext                                                                                 
Name    Version Weight Store Description
----    ------- ------ ----- -----------
Default 1.0.0   10     Adm   Default AD Settings for ADM

PS1> Test-AdmfDomain -Ctx adm
[12:34:48][Resolve-DomainController] Resolved domain controller to use. Operating against WBF-V0540.adm.isceco.admin.ch
[12:34:53][Test-AdmfDomain] Skipping tests to verify OrganizationalUnits as there is no configuration data available
[12:34:53][Test-AdmfDomain] Executing tests to verify Groups against WBF-V0540.adm.isceco.admin.ch
[12:34:54][Test-AdmfDomain] Skipping tests to verify Users as there is no configuration data available
[12:34:54][Test-AdmfDomain] Skipping tests to verify ServiceAccounts as there is no configuration data available
[12:34:54][Test-AdmfDomain] Executing tests to verify GroupMembership against WBF-V0540.adm.isceco.admin.ch

[12:34:54][Test-AdmfDomain] Skipping tests to verify Acls as there is no configuration data available
[12:34:54][Test-AdmfDomain] Executing tests to verify AccessRules against WBF-V0540.adm.isceco.admin.ch
[12:34:59][Get-SchemaGuidMapping] Processing Schema Guids for domain: WBF-V0540.adm.isceco.admin.ch (This may take a while)
[12:35:14][Get-PermissionGuidMapping] Processing Permission Guids for domain: WBF-V0540.adm.isceco.admin.ch (This may take a while)
[12:35:18][Test-AdmfDomain] Skipping tests to verify PasswordPolicies as there is no configuration data available
[12:35:18][Test-AdmfDomain] Skipping tests to verify Object as there is no configuration data available
[12:35:18][Test-AdmfDomain] Skipping tests to verify WmiFilter as there is no configuration data available
[12:35:18][Test-AdmfDomain] Skipping tests to verify GroupPolicies as there is no configuration data available
[12:35:18][Test-AdmfDomain] Executing tests to verify GroupPolicyPermissions against WBF-V0540.adm.isceco.admin.ch
[12:35:21][Test-AdmfDomain] Skipping tests to verify GroupPolicyOwners as there is no configuration data available
[12:35:21][Test-AdmfDomain] Skipping tests to verify GroupPolicyLinks as there is no configuration data available
[12:35:21][Test-AdmfDomain] Skipping tests to verify DomainLevel as there is no configuration data available
Server                        Type   ObjectType      Identity                        Changed
------                        ----   ----------      --------                        -------
WBF-V0540.adm.isceco.admin.ch Add    GroupMembership TestDc þ computer þ WBF-V0540$  {Add: WBF-V0540$ -> TestDc}
WBF-V0540.adm.isceco.admin.ch Update AccessRule      DC=adm,DC=isceco,DC=admin,DC=ch {Create: S-1-1-0}

[FriedrichWeinmann]

Heya @dbeugger , The TestScript and the LDAPFilter need to be applied in lockstep. Different components use ObjectCategories in a different matter, so some may use the TestScript while others use the LDAPFilter. It is not that both properties must be present, but so that the system can use whatever is more convenient from a performance perspective.

In case of group memberships, it uses the LDAPFilter to build a list of intended members, then compares it to the actual members, which is why you get that result.

[dbeugger]

Hi @FriedrichWeinmann I have found that you have to specify at least Name, ObjectClass and either Filter or LDAPFilter. My goal is to assign all users from different OU hierarchies to a single group. My ObjectCategory looks like this:

@{
    Name = 'OC-User-T0-All'
    ObjectClass = 'user'
    Property = @('distinguishedName')
    Filter = '*'
   TestScript = { $args[0].distinguishedName -match 'OU=(TA|T0),DC=' }
}

However, this will assign all (more than 360) AD objects (container, organizationalUnit, group,...) to the group. This looks like ObjectClass and TestScript have no influence.

I have set that of ObjectClass to 'xx'. This gives the same result.

I have changed the FIlter to'objectCategory -eq "CN=Person,CN=Schema,CN=Configuration,%DomainDN%"'. This results in 0 objects. If I replace %DomainDN% hardcoded, all user accounts (krbtgt, Guest, ....) are listed. TestScript still does not work.

I also tried a -LIKE with distinguishedName in the filter. But that doesn't seem to be supported by Get-AdObject.

• ObjectClass has no effect
• %DomainDN% does not seem to be replaced in filter

Am I doing something wrong?