AC_NewParent and conditional OU

Identity Security Cloud (ISC) ISC Discussion and Questions
, ,
1

Hi,
Rather than create two different connectors (user & Admin) I’m trying to make the AC_NewParent conditional a based upon the first character of their CN.
I can’t get this to work, and I think its because you can only reference ID attributes, not source attributes. However, I have several hundred ADs to connect, so I don’t want to make ID attributes for each source. Anyone have any ideas?

            "name": "AC_NewParent",
            "transform": {
                "type": "conditional",
                "attributes": {
                    "expression": "$isAdmin eq A",
                    "positiveCondition": "OU=Deprovisioned,,OU=Admin,DC=abc,DC=net",
                    "negativeCondition": "OU=Disabled Users,OU=User Accounts,DC=abc,DC=net",
                    "isAdmin": {
                        "type": "substring",
                        "attributes": {
                            "start": 0,
                            "end": 1,
                            "input": {
                                "type": "accountAttribute",
                                "attributes": {
                                    "sourceName": "SourceName",
                                    "attributeName": "CN"
                                }
                            }
                        }
                    }
                }
            },

There was an error trying to disable the account

An unexpected error occurred: Invalid get reference: $isAdmin - seaspray[line 1, column 1]

Thanks

2

Assuming the use case is: when account gets disabled, set AC_Newparent based to one of the two OUs listed based on the identifier of the account being disabled:

the easiest way to handle it would be in a beforeProvision rule.

You can use something like this:

if (null != plan) {
	List acctReqs = plan.getAccountRequests();
	if (null != acctReqs) {
		for (AccountRequest acctReq: acctReqs) {
			if (null != acctReq) {
				if (acctReq.getOp().equals( ProvisioningPlan.ObjectOperation.Disable ) ) {
					String ou = "OU=Disabled Users,OU=User Accounts,DC=abc,DC=net";
					String nativeIdentity = acctReq.getNativeIdentity();
					if (null != nativeIdentity && nativeIdentity.startsWith("cn=A")){
						ou = "OU=Deprovisioned,,OU=Admin,DC=abc,DC=net";
					}		
					acctReq.add(new AttributeRequest("AC_NewName", ProvisioningPlan.Operation.Set, ou);
				} 
			} 
		} 
	}
}
3

Hi @phil_awlings ,
you can create a transform, and you can take the transform as a reference in the Disable provisioning policy, then it will work.

4

Both are good ideas.
@dopstrick I like the idea. However. we have multiple ADs per IQ server, I will have to experiment to see if that I can also parse the script through to the correct AD.
@Kiran001 Simple, but would involve an extra transform per AD, but they would only be around 30 lines so not much effort and very easy to replicate

Thanks

5

When you say you have multiple ADs, do you mean you have multiple AD sources configured? If that’s the issue, and you’d rather not manage multiple beforeProvision rules, you could make a modification to the services standard beforeProvision rule, and do something like this:

in the SSB:

add a line item to the case statements at the top:

case "DisableOuMove":disableOuMove(identity, accountRequest, value);break;

Then, in the section of helper methods, add this method:

pubic void disableOuMove (Identity identity, AccountRequest accountRequest, Object value){
	log.debug("Enter DisableOu: " + value);
	String ou = null;
	if(accountRequest == null) {
		log.error("DisableOu: Invalid Arguments: accountRequest is null");
		return;
	}
	if (value instanceof Map){
		ou = value.get("ou");
		String nativeIdentity = acctReq.getNativeIdentity();
		if (null != nativeIdentity && nativeIdentity.startsWith("cn=A")){
			ou = value.get("adminOu");
		}
	}
	
	if (null == ou || ou.isEmpty()){
		log.error("DisableOu: Invalid Arguments: ou is null or empty: " + ou);
		return;
	}
	moveADAccount(identity, accountRequest, ou);
}

Then in your source definition, you would add an event action under the cloudServicesIDNSetup:

"cloudServicesIDNSetup": {
	"eventConfigurations": [
		{
			"eventActions": [
				{
					"Action": "DisableOuMove",
					"Attribute": "AC_NewParent",
					"Value": {
						"ou": "OU=Disabled Users,OU=User Accounts,DC=abc,DC=net",
						"adminOu": "OU=Deprovisioned,,OU=Admin,DC=abc,DC=net";
					}
				}
			],
			"Operation": "Disable"
		}
	]
},

Not sure if that resolves your concern. If you meant something different by having multiple ADs, the above may not be what you’re looking for.

6

Hi @dopstrick
We need to connect 200+ AD, each with different requirements for user/admin/service accounts. Ideally it would be one connector for each source, with some coding to handle the variations.
Also, we are looking to have 5 ADs being service by one IQserver using a trust relationship between ADs to minimise the cost of operating 2 servers/source (1 active & 1 backup).

Its very messy, and trying to make a simple, clean and cheap to maintain is going to be a struggle.
Thanks for your thoughts on the subject

7

If you’re going with one connector per source, I would recommend the SSB approach I mentioned above. You would deploy one Before Provision rule, which all 200 sources would reference, so no code changes there. The only adjustments you would have to make are the ‘ou’ and ‘adminOu’ entries in the source definition itself.

In terms of deploying all of them, you can probably script creating spconfig files for all the sources. Just create a csv file that has the values specific to each source (source name, description, domain, service account, ou, adminOu, etc), then just use VSCode to import the SPConfig files.

1 Like