Remove Member Of

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. 

Then, the $Request and $DirObj objects should exist.

Test that and confirm. Write them to a file and make sure that they have what you need:

$Request | Out-file C:\Temp\Request.txt

$Request | Get-Member |Out-file C:\Temp\Request.txt -append

$DirObj | Out-file C:\Temp\DirObj.txt

$DirObj | Get-Member | Out-file C:\Temp\DirObj.txt -append

You'll likely need to dig into several attributes of the objects in order to see and confirm the attributes and methods.

Thanks. I now have the output from the commands. While I can see the security group the account is being added to, its not display what username from the dirobj

I assume this should be in the output? 

No, most of the real attributes won't be in the $DirObj object. It's essentially a pointer to the directory object which you can use as a springboard to get what you need.

If it has any attributes and it has the necessary methods, then it should work.

I'll run a sanity check in my lab with a small script and I'll confirm expected functionality.

Can you provide a screenshot of the Workflow so that I can see how you are calling the script?

I did also think/try to grab the username from the workflow saved object properties and then try to grab that via 

$Username = $workflow.SavedObjectProperties("T0").get("SamAccountName")

Same issue through, its not firing 

Ooooh.

Okay, I see where you may be having some issue.

The $Request object is created with an object that is related to the Active Directory operation being performed. This operation is "Add member to a group". In this context, the $Request object and $DirObj will have references to the group, not to the added member.

I think that this could be implemented without a script at all, honestly. I configured a Change Workflow in my lab to prevent adding users to a group if those users were present in a Managed Unit, and it seems to work properly.

https://imgur.com/a/BVbA2qW

Boom. Now, on the face of it, that works fantastically. I need to do some more testing, but it did block me from adding groups to users who are in that Managed Unit.

Thanks mate. I really appreciate you taking the time here today

Hi. So this setup seems to work great when searching for Users in a MU and am able to block stop a user being added to a group. 

The issue I have now which is along the same track is that I need to stop Member Of in the same way. I can open a Group and then add that group to another group. No matter how I try to get this working along the same lines nothing seems to work. 

Any suggestions on stopping member of in the same way? 

I seem to have got this working with Groups now. 

I have one OU where I am searching for users and the work flow just does not fire at all. if I change the OU to somewhere else that contains users then it does block the request. i am pulling my hair out with it. 

Ok a bit more info.

Lets Say i have the following OU structure

OU-A
  OU-B
  OU-C

I have the work flow search try to fund users starting from OU-A the block never happens. If I change the work flow to start at OU-B or OU-C then the block does happen. No matter what options I select on the Search activity, nothing runs from a top Level OU down.

Even If I change this to a MU it still does not fire. Am I doing something wrong here? 

FFS!!!!!!!

IT was to terminate this search activity if the search returned more than....., and it was set to 100. There was more than 100 objects in the OU

Jesus I have been banging my head against the wall on this one. 

FFS!!!!!!!

IT was to terminate this search activity if the search returned more than....., and it was set to 100. There was more than 100 objects in the OU

Jesus I have been banging my head against the wall on this one.