I haven’t had any success yet on generating a disabled account on creation when the account is a prehire. I try to set Enabled to false as a static value. I have tried to set a value using the before provisioning rule. I don’t see errors on the activity.
We are doing a move operation at the same time, could that be affecting the setting on at the time of the account creation?
Hi Fred,
Have you created the LCS state for Prehire and added the AD source in Disable account ?
We have the same use case and it is working fine using the above.
Thanks
Rakesh
I guess it should work as the two above people mentioned but in addition I believe this should work (if you set this in the create account provisioning policy
{
"name": "IIQDisabled",
"transform": {
"type": "static",
"attributes": {
"currentLCS": {
"type": "identityAttribute",
"attributes": {
"name": "cloudLifecycleState"
}
},
"value": "#if($currentLCS=='preHire')true#{else}false#end"
}
},
"attributes": {},
"isRequired": false,
"type": "string",
"isMultiValued": false
}
Regards
Hi Rakesh,
Yes, we are using a Prehire LCS. It creates the account, and the Account Configuration is set to Disable Accounts.
The Account Provisioning on AD is setting a static distinguishedName for placement. But then the before provisioning rule is also moving the account in case they are changing from Active or inactive, back to prehire, they will be put back into a staging container and be disabled.
The moving of containers looks to be working, but the disablement is not.
{
"eventActions": [
{
"Action": "ADMoveAccount",
"Attribute": "AC_NewParent",
"Value": "OU=TST_STAGE_OU,OU=SailPoint,OU=Testing,DC=example,DC=net"
}
],
"Identity Attribute Triggers": [
{
"Attribute": "cloudLifecycleState",
"Value": "prehire",
"Operation": "eq"
}
],
"Operation": "Disable"
},
If I remove the above logic for the move, it does now inactivate the account.
I’m still seeing issues with it being disabled with or without the before provisioning snippet above.
We have I around 7 lifecycle states. The above snippet is the only one for prehire. Would logging on the agent help? Is this being handed off to the agent to handle and would we possibly see errors or some logic to see why they aren’t disabled and or moved? Could another part of the Before provisioning rule be affecting the move or disablement? No Errors are seen on the Identity activity.
Hey @ts_fpatterson
You said the Prehire lifecycle state is creating and disabling the account? Can you explain how this is done?
If you are creating the account through the lifecycle state provisioning, it makes me thing you have an Access Profile being assigned to the Prehire lifecycle state that you are granting to the users to trigger the Account Create event. If this is the case and you are also using the Disable Accounts option in your Prehire lifecycle state to Disable the account, the UI has a note about this that says:
Disable accounts in these sources for this lifecycle state. Accounts won’t be disabled if the source also has access profiles in the Access Profiles to Grant list below.
This could be causing the issue with your accounts not being disabled if you are trying to just use the one lifecycle state for both operations.
Thank you,
Hi Fred,
Do the following and see if you aint seeing issue’s.
1.Have Lifecycle state of Prehire and add your AD source to get Disabled.
2. in your Create Account Provisioning policy add this for IIQDisabled attribute mark it as static and add the following code
#if($identity.attributes.cloudLifecycleState == ‘active’)false#
{else}true#end
3. Create and identity attribute as disabledou and have your OU populated using transform like below
{
“name”: “Calculate Disabled OU”,
“type”: “static”,
“attributes”: {
“value”: “OU=TST_STAGE_OU,OU=SailPoint,OU=Testing,DC=example,DC=net”
},
“internal”: false
}
Thanks
Rakesh Bhati
this helped, thanks.
We were still having issues.
used some logic like the below example.
{
"eventActions": [
{
"Action": "UpdateAttribute",
"Attribute": "carLicense",
"Value": "#{now.EPOCH_TIME_WIN32}"
},
{
"Action": "ADMoveAccount",
"Attribute": "AC_NewParent",
"Value": "#{identity.adou}"
}
],
"Identity Attribute Triggers": [
{
"Attribute": "cloudLifecycleState",
"Value": "active",
"Operation": "eq"
}
],
"Account Attribute Update Triggers": [
{
"Attribute": "carLicense",
"Value": "*",
"Operation": "eq"
}
],
"Operation": "Modify"
},
{
"eventActions": [
{
"Action": "UpdateAttribute",
"Attribute": "carLicense",
"Value": "#{now.EPOCH_TIME_WIN32}"
},
{
"Action": "ADMoveAccount",
"Attribute": "AC_NewParent",
"Value": "#{identity.adou}"
},
{
"Action": "ChangeOperation",
"Attribute": null,
"Value": "Enable"
}
],
"Identity Attribute Triggers": [
{
"Attribute": "cloudLifecycleState",
"Value": "active",
"Operation": "eq"
}
],
"Account Attribute Update Triggers": [
{
"Attribute": "roomNumber",
"Value": "*",
"Operation": "eq"
}
],
"Operation": "Modify"
}
I believe this helped some timing issues with other event lifecycles.
Is this common? Shouldn’t the connector detect a move event and hold other operations until it is completed?
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.