Remove Member Of

Think i have it unless there is a better way. 

So if I Deny Read \ Write to the Member of attribute on the user account, then it works. The person can still go through the process of adding a group, but as soon as they click apply, the change is not saved. Is this the best way or is there something better? 

Actually, not quite. Deny Read \ Write means I cant see the groups the account is a member of. If I allow Read but Deny write, I can still add and remove a user to a group. 

I just need to be able to see the group membership of an account but stop being able to add the account to a group

Hi craig mcfarlane 

You grant the ability to add or remove members (users, groups, computers etc) objects by apply permissions against the group you want to allow someone to change the members of, by providing them with the ability to write the members property. The members they can add to that group are made up of all object classes that they have the ability to list and are valid objects to be added to a group of that type.

You don't say if you have different admin accounts for managing T0 objects vs other tier objects?

If you do, and your only granting List and Read permissions to the objects each of those Tier objects should be able to manage, you should be good. If however you are granting permissions to List and Read all user, group and computer objects, in addition to the write member of the T0 group objects, they can add anyone to the T0 group.

Therefore if you're not using Tier Admin accounts (adm_cmcfarlane, adm_cmfarlane_T0 etc), then you might want to look into that. - This would be my preferred option, but would mean thinking your Delegation of Control Model

Adding Deny permissions is possible, however I tend to reserve deny for very particular use cases, as they can paint you into a corner down the line. I'd prefer not to grant the users permissions in the first place, opposed to blocking it. In this instance you'd need a deny group which you can add to all users would should be able to write members for the T0 groups. - This is my least preferred option.

Other options would also include using Workflow's to block the change, if the request crosses the tier boundary. However not that you'd need to write a script, which looks at the group membership change, and works out if any of the objects (1 or more) are crossing that boundary, the block the request (or remove the cross boundary add/remove from the request and silently succeed, even thought the request hasn't completed as was requested as programmatically its removed some objects). There is an example I'll try and dig out which blocked the creation of a universal group via workflow, similar logic would be used, but re-focused on group membership. This does work, but your still granting access to add to the group, your just resolving the issue in code, instead of denying permissions - This would be my second option, but would mean you'd need to write a script module, to check if there are cross boundary changes, the manage them as you need.

Thanks, Stu. Yes, we have a separate account used to manage T0 assets. 

The issue is not T0 accounts being able to add a T0 user to a group but a non-t0 admin account being able to add a T0 asset to a security group. The non t0 admin cant do anything to the t0 asset at all but it can add them to security groups still which is what I am trying to stop. 

We ended up using a policy script to block crossing tiers via group membership, here's our script:

function onInit($context) {
    $param = $Context.AddParameter("Tier")
    $param.Required = $true
    $param.DefaultValue = "3"
}

function onPreModify($Request) {
    if ($Request.Class -ne "group") { return }
    if ($null -eq $Request.Get("member")) { return }
    $Tier = $context.Parameter("Tier")
    $allowedOus = @{
        "Tier0" = @(
            "OU=Tier 0,OU=Admin,DC=somewhere,DC=local"
        )
        "Tier1" = @(
            "OU=Tier 1,OU=Admin,DC=somewhere,DC=local"
        )
        "Tier2" = @(
            "OU=Tier 2,OU=Admin,DC=somewhere,DC=local"
        )
        "Tier3" = @(
            "OU=Tier 3,OU=Admin,DC=somewhere,DC=local"
        )
    }

    for ($i = 0; $i -lt $Request.PropertyCount; $i++) {
        $item = $Request.Item($i)
        if ($item.Name -eq "member") {
            if ($item.ControlCode -eq $Constants.ADS_PROPERTY_APPEND) {
                foreach ($dn In $item.Values) {
                    $memberAllowed = switch ($allowedOus["Tier" + $Tier]) {
                        { $dn -like "*$($_)" } { $true; break }
                    }
                    if ($memberAllowed -ne $true) {
                        throw (
                            "Administrative Policy:",
                            [System.Environment]::NewLine,
                            "$($dn) is not a member of tier $($Tier)"
                        )
                        return
                    }
                }
            }
            break
        }
    }

}

There is a policy for each tier that all use the same script and use the parameter to define which tier to check.