Active Directory Account Moves

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

I am using the exact code with slight modifications on paths and it works fine on the original source but I have created a new source and it is broken? What happens is that the user gets moved to a deprovisioned OU and is trapped upon active lifecycle change. Once it moves to the deprovisioned ou the user stays disabled and does not move back to the active ou? Is this the cause ? Before Provisioning Rules can only be updated through SailPoint Professional Services. Best Practices: Active Directory Account Moves - Compass

2 
"eventConfigurations": [{
    "eventActions": [{
        "Action": "ScramblePassword",
        "Attribute": "password",
        "Value": null
    }, {
        "Action": "ADMoveAccount",
        "Attribute": "AC_NewParent",
        "Value": "OU=Deprovisioned,OU=TestOU,OU=Test Accounts,OU=KOP,DC=cov,DC=Pennsylvania,DC=gov"
    }, {
        "Action": "RemoveADEntitlements",
        "Attribute": "memberOf",
        "Value": "OU=Groups,OU=TestOU,OU=Test Accounts,OU=KOP,DC=cov,DC=Pennsylvania,DC=gov"
    }, {
        "Action": "RemoveStickyEntitlements",
        "Attribute": "memberOf",
        "Value": null
    }],
    "Identity Attribute Triggers": [{
        "Attribute": "cloudLifecycleState",
        "Value": "deprovisioned",
        "Operation": "eq"
    }],
    "Operation": "Disable"
}, {
    "eventActions": [{
        "Action": "ScramblePassword",
        "Attribute": "password",
        "Value": null
    }],
    "Identity Attribute Triggers": [{
        "Attribute": "cloudLifecycleState",
        "Value": "suspended",
        "Operation": "eq"
    }],
    "Operation": "Disable"
}, {
    "eventActions": [{
        "Action": "ADMoveAccount",
        "Attribute": "AC_NewParent",
        "Value": "#{identity.testoudn}"
    }],
    "Identity Attribute Triggers": [{
        "Attribute": "cloudLifecycleState",
        "Value": "active",
        "Operation": "eq"
    }],
    "Operation": "Enable"
}]
3

Hi @TJ211 ,
Every time account moves to any OU because of a lifecyclestate change, aggregation should happen.
If lifecycle state changes and account moves to deprovisioned OU, but aggregation does not happen and again the lifecyclestate changes, then SailPoint’s behavior becomes unpredictable.

I have seen SailPoint creating duplicate accounts when such a scenario happens.

I also suggest you run an unoptimized aggregation on the AD source using SailPoint API.

Making sure that source full account aggregation happens every time the OU movement happens is essential, without it, SailPoint cannot verify if the actual account movement has happened at the Target source.

Let me know if the insight helps.

Thanks,
Vaibhav

1 Like
4

Right but something else is missing because IDN shows active and in the active ou but the account is remaining in the disabled ou and the user is still disabled.

5

Hi @TJ211 . Are you sure that SailPoint is able to read the deprovisioning OU? Seems that the reason. As sailpoint is not able to read the deprov OU, it’s not changing the account ststus.

1 Like
6

If it can move it in t the deprovisioned OU then yes it can see it but the disconnect is that it can’t see it once it gets in that OU to move it out and enable? But what is weird is sometimes it works and sometimes it doesn’t.

7

It was a permissions issue with iqsservice