Conditional Transform

[P96337 (Marvin Grant)]

Hi Team,

I have written a conditional transform that I would like to apply but it is not applying the attribute correctly. I would like for it to check for compliance disable in one source and if it is true - disable the ad account using the user account control attribute. If it is not true do noting. What am I missing?

{
  "name": "AD account - disable when compliance disabled",
  "type": "conditional",
  "attributes": {
    "condition": {
      "attributes": {
        "sourceName": "PSHRPRD",
        "attributeName": "PH_COMPLIANCE_DISABLE"
      },
      "type": "accountAttribute",
      "operator": "eq",
      "primaryValue": "Y"
    },
    "consequent": {
      "type": "accountAttribute",
      "attributes": {
        "sourceName": "Active Directory",
        "attributeName": "userAccountControl"
      },
      "operation": "or",
      "value": 2
    },
    "alternative": {
      "type": "accountAttribute",
      "attributes": {
        "sourceName": "Active Directory",
        "attributeName": "userAccountControl"
      },
      "operation": "and",
      "value": -3
    },
    "expression": "$PH_COMPLIANCE_DISABLE eq Y",
    "positiveCondition": "true",
    "negativeCondition": "false"
  },
  "internal": false
}

[Carlatto (Carl Nelson)]

First off, a transform on it’s own will not disable an account. You could combine a transform with a Workflow or Rule and be able to disable accounts.

As for the Transform, I am not sure what you are trying to do with the alternative and consequent variables. Your expression is trying to call a variable that doesn’t exist in the transform.

The transform below should assign the value of PH_COMPLIANCE_DISABLE to condition. Then the expression checks that value to see if it equals Y. If it is equal, the transform returns True, otherwise it will return False.

{
  "name": "AD account - disable when compliance disabled",
  "type": "conditional",
  "attributes": {
    "condition": {
      "attributes": {
        "sourceName": "PSHRPRD",
        "attributeName": "PH_COMPLIANCE_DISABLE"
      },
      "type": "accountAttribute"
    },
    "expression": "$condition eq Y",
    "positiveCondition": "true",
    "negativeCondition": "false"
  }
}

[P96337 (Marvin Grant)]

Hi Carl, Thanks for the input. I would like to use the property flag calue of 2 (ACCOUNTDISABLE) to be placed in the useraccountcontrol value in AD if the condition is “true” and if it is false to return the account in ad to NORMAL_ACCOUNT value (512). Can a Transform do this?

[Carlatto (Carl Nelson)]

Not directly with a transform. One option would be to use the Transform data in an Identity Profile Attribute, then setup a Workflow to trigger when the Attribute changes. The workflow would then disable the account.

If you don’t have much experience with IdentityNow, you might want to talk with Professional Services to help set this up.

[P96337 (Marvin Grant)]

I have already added the identity attribute find the identity - disabling the account - to include sending an email.

Just curious if anyone has used or created a conditional transform that sets the AD Property Flags mentioned for this particular use case - in any way.

I’m gathering from your response that IDN is not able to set these AD attributes directly in the target system with transform logic alone without Workflows or some other logic to assist or reference.

[M_rtenH (Märten Hallik)]

We’re doing similar things (not with AD but other sources).
The only requirement you have is a source that supports Attribute Sync
Your transform would need to output the exact values you intend to send to the source (2 or 515?). The transform would need to output these depending on your conditions and you could either use a conditional or static transform for that.

For example -
A static transform that would read cloudLifecycleState identity attribute and output “true” if state = inactive and “false” for any other state.
That identity attribute is mapped to ‘archived’ account attribute within a source’s provisioning policy, with attribute sync enabled.
So any time an identity moves to an inactive lifecycle state, IDN would set the ‘archived’ attribute in that source to ‘true’.

Hope that’s helpful - I can share some examples as well if necessary.

[Carlatto (Carl Nelson)]

I would be cautious about updating userAccountControl via AttributeSync. Like Marten said, you need to have the Transform result in the correct values. userAccountControl can be set to a lot of different values besides 512 (normal user account) and 514 (disabled normal user account).

[P96337 (Marvin Grant)]

Hi Märten,

This is very helpful. I would only be interested in the account property flag of 2 -ACCOUNTDISABLE (Condition true) and 512 - NORMAL_ACCOUNT (Condition false) property flags. As long as the identity attribute for the account is true the property flag remains 2 - once it becomes false then it is set to 512. Some examples would be awesome!

[P96337 (Marvin Grant)]

Hi Carl,

I agree - these property flag need to be exact or the desired outcome would be the complete opposite of what I am trying to achieve with this use case. I am referencing this Microsoft Article for the list of Property flags.

UserAccountControl property flags - Windows Server

[M_rtenH (Märten Hallik)]

This example uses a conditional transform -

{
        "id": "f7809357-0b97-4531-8e45-bc4394273871",
        "name": "Google archival status",
        "type": "conditional",
        "attributes": {
            "lifecycle": {
                "attributes": {
                    "name": "cloudLifecycleState"
                },
                "type": "identityAttribute"
            },
            "expression": "$lifecycle eq inactive",
            "positiveCondition": true,
            "negativeCondition": false
        },
        "internal": false
    }

The output will be either true or false. We’re then mapping that transform to an identity attribute, mapping that identity attribute to an account attribute within the provisioning policy (Create Account in the UI) of a source and enabling attribute sync for that attribute.

One thing to bear in mind is that if you’re supporting rejoiner flows within your lifecycle management, then this example would also unarchive any accounts if the identity is no longer in an ‘inactive’ lifecycle state.

If you’ve more complex requirements than

if inactive = true, else = false

I’d look at a static transform instead as those allow you to map multiple identity/account attributes and output a value on very specific conditions.

[P96337 (Marvin Grant)]

Awesome! This is a great example and great input. You have a point about the static transform as well - specifically because the values I am looking for are exact. I’ll take a look and share my developments. More to come my friend.

Thanks for sharing this.

[kirkkenton]

Just keep in mind that the decimal value you read in for useraccountcontrol is just the decimal value of all the bit values that are enabled. to turn “on” the 2 bit value, you add that to 512. so actually 514 equals a disabled normal user where 512 is an enabled normal user.

Also keep in mind that if you use this method in attribute sync for the decimal value, you might remove other settings that are enabled like password never expires (65536). if a user has password never expires on (just as an example of any feature) for a normal user account the value would be 65536 + 512 = 66048and to disable that account would be 66048+ 2 = 66050. It can be done but is very difficult to manage all the different decimal representations of the bit values.

[P96337 (Marvin Grant)]

Hi Kirk,

This is a very good point. We will be using this just for normal user accounts. These accounts are never set to a “password never expires”. This is good information.