Hi,
Something odd happened in production yesterday, and I’m wondering if anyone has witness similar behaviour.
I created a role that if the criteria was met, then it would provision an entitlement (standard stuff).
The criteria was:
if the lifecycle is ACTIVE,
AND
The account attribute ‘accountFlags’ of the AD source does not contain the word ‘Disabled’.
Again fairly basic stuff, active lifecycle, and enabled source account present on cube.
What Sailpoint did instead was for every user that didn’t have a AD account, it provisioned one. Which is not what the logic says. The Role shouldn’t have created accounts for users who didn’t meet the criteria
Brand new role just created for the purpose of giving birthright entitlements to users who have the privilege AD account (or get it via Access request). It was created to save having to raise a 2nd request to get the entitlements after the account has been created.
It appears to be following the logic that the attribute doesn’t contain ‘Disabled’ as it doesn’t exist and therefore meets the criteria of the Role, rather than failing because the source account is not there
I meant, do you maybe have any access profiles (from the same AD source) that will be granted to users in “active“ lifecycle state, that you overlooked.
For the non-existent accounts, I’m wondering why criteria is still met, when it should’ve failed logically (unless it’s intention from the SailPoint for some reason to simply refuse to evaluate account criteria if account is not present)
Also, have you maybe alternatively tried the criteria of userAccountControl → Equals → 512 ?
This appears to be more stable, but that is terrible logic handling otherwise.
I’m just going to have to undo a load of account creation on Monday, thank G that this was done under an approved and peer review CHG.
might be packing my bags otherwise…
I think, it worked as designed, i guess, as does not contains disabled check returned identities not only the identities with accounts which does not have disabled but also the identities that does not have account because they do not have disabled or the attr itself.
I rather see it as there is an implicit check that the account needs to exist for it to be able to check that the value is not ‘disabled’:
’Is your car not green?’ shouldn’t fail because you don’t have a car
