Auto-approval of disabling accounts for users not working using Provisioning job WSRETRYJOB PROV

[Community_User]

Originally posted on January 24 2020 at 17:46 UTC

I have executed below steps:

· Created the User Update Rule to detect active users that are past their end date, deactivate them in SSM and disable their associated accounts. - Rule Working

· Running the detective rules job to run the rule created in step one against every user in SSM, and move users that are past their end date into the Pending Tasks queue in ARS to have their accounts removed - Working

Running the provisioning job (WSRETRY) to automatically action all the users in the pending tasks queue - Not Working. Tasks are still in pending state in ARS for manual approval, we want all requests to be auto approved i.e. user accounts disabled automatically.

Note - We are using SSM version 5.3.2

[Community_User]

Originally posted on January 27 2020 at 03:18 UTC

Hi Raman,

I understand that problem here is that wsretry i.e. provisioning job is not picking up the account disable tasks. Please let us know the target system and check that the security system is enable for automated provisioning.

Thanks

Ajay

[Community_User]

Originally posted on January 27 2020 at 11:01 UTC

Hi Ajay,

Thank you very much for taking your time to help me.

Target system is AD and yes, automated provisioning is enabled for the AD security system.

I did further investigation and found out that issue is with AD security systems only where as for non-AD security systems accounts are auto-disabled. We have 3 different AD instances(independent) and its the same behaviour for all AD accounts i.e. disable account requests for AD stays in ARS as Pending tasks waiting to be manually actioned.

Note - I have also updated AD security systems configuration to the same configuration as in non-AD security system but its still the same issue with AD accounts only.

So it looks like AD specific issue to me as of now.

Are you able to check please if its product bug or is it the expected behavior?

Note - We are using SSM version 5.3.2

Kind regards,

Raman

[Community_User]

Originally posted on January 27 2020 at 11:45 UTC

Hi Raman,

Greetings!!

I would like to know few pieces here:

1) What type of task is generated for disable Account operation in your pending tasks?

2) Do you have DISABLEACCOUNTJSON/REMOVEACCOUNTJSON available in your AD connector, if yes. Which configuration is available?Please share the sample JSON configuration as well.

3) Please share the debug log as well.

Thanks & Regards,

Anand Kumar Jha

[Community_User]

Originally posted on January 27 2020 at 15:18 UTC

Hi Anand,

Answers below:

1. Task type in ARS Pending tasks - Remove Access

2. No. I couldn't find attributes DISABLEACCOUNTJSON and REMOVEACCOUNTJSON in the connection details for AD. However, there are other attributes such as REMOVEACCOUNTACTION, CREATEACCOUNTJSON, UPDATEACCOUNTJSON, REUSEACCOUNTJSON, UPDATEUSERJSON, ENABLEACCOUNTJSON which are expecting JSON and all have empty values.

3. I'm using SSM version 5.3.2 which doesnt have option to show application logs in the UI under Admin - Admin Function. Whereas I checked another test instance which have version 5.4.1 and there is an option to see Application logs there. So unfortunately I don't have access to logs as of now.

Please let me know if you want more information regarding configuration, meanwhile I wait for application logs...

[Community_User]

Originally posted on January 28 2020 at 04:16 UTC

Hi Raman,

Thanks for your answers.

Could you please let me know, if you have any value defined in REMOVEACCOUNTACTION.

please share the JSON, if any.

[Community_User]

Originally posted on January 29 2020 at 11:51 UTC

Hi Ajay,

No, its empty.

[Community_User]

Originally posted on January 29 2020 at 15:46 UTC

Hi Raman,

You should define a JSON action within this field to trigger a desired action.

Otherwise, the current behaviour is a desired behaviour.

Thanks & Regards,

Anand Kumar Jha

[Community_User]

Originally posted on January 29 2020 at 17:20 UTC

I tried with below value of REMOVEACCOUNTACTION attribute and updated the connection:

{"removeAction":"SUSPEND","deleteAllGroups":"Yes", "userAccountControl": "514"}

Unfortunately, its still the same result 😞

It's weird that SSM creates 2 tasks for disable account request:

1. In Pending tasks - Task Type - Remove Access and Status - New

2. In Completed Tasks - Task Type - Disable Account and Status - Discontinued

Note - The User update rule which triggers this action is below:

If Users.enddate LESS THAN "sysdate()"
AND Users.statuskey EQUALS "1"
Then
(Disable User AND Disable User Accounts)

I don't know if its SSM version 5.3.2 specific issue or if there is something with configuration.

Please let me know if something is wrong with the rule, JSON value etc.

Thank you very much for the help.

[Community_User]

Originally posted on January 30 2020 at 04:30 UTC

Hi Raman,

Greetings!!

Please raise a freshdesk ticket. We would like to see the debugLog for this entire process to analyse it.

There could be multiple things associated to it. (SSL Connection, Connection Configuration at your AD endpoint, Availability of account at target, status of account in SSM and many more..)

we would also like to go through your connection parameters of AD connection as well.

Thanks & Regards,

Anand Kumar Jha

[Community_User]

Originally posted on January 30 2020 at 11:12 UTC

Hi Anand,

Thanks. I raised ticket last week already but its taking very long #205660

Problem is with 5.3.2 version I dont have an option to access application logs myself.

[Community_User]

Originally posted on February 4 2020 at 11:06 UTC

Hi Anand,

I still don't have access to the logs but I wanted to share my other findings with you.

So I updated the User update rule to just Disable all accounts and this works i.e. all accounts are auto-disabled for the users even the AD accounts.

If Users.enddate LESS THAN "sysdate()"
AND Users.statuskey EQUALS "1"
Then
(Disable User Accounts)

But if I add another condition in the User update rule to Disable User as well then auto-disabling accounts work for only non-AD accounts. AD accounts are still in Pending tasks in ARS.

When I run DETECTIVEPROVISIONINGRULESJOB user is disabled and then if run WSRETRYJOB only non-AD accounts are auto-disabled.

If Users.enddate LESS THAN "sysdate()"
AND Users.statuskey EQUALS "1"
Then
(Disable User AND Disable User Accounts)

So this proves that whatever the configuration is in Security systems or Connections it doesnt matter in this particular case, as AD accounts are disabled automatically for even AD accounts when we skip disabling user in the User Update Rule.

So when a user is disabled, SSM doesnt allow AD accounts to be disabled automatically.

Please let me know if its the expected behaviour or if I'm missing anything?

[Community_User]

Originally posted on February 19 2020 at 18:46 UTC

Hi Ramanpreet,

From my understanding of User Update Rules actions :

• "Disable User' is disabling the identity + setting a termDate to CURRENT_DATE() + triggers "Deprovision Access" tasks to applications on which user has an access to.
• "Disable User Accounts" triggers a "Disable Account" task for specified applications.

Both tasks' behaviour depends on the disconnected / connected application configuration.
Regarding Active Directory (AD) connector, "Deprovision Access" uses the "REMOVEACCOUNTACTION" parameter of your connector, while "Disable Account" uses "DISABLEACCOUNTJSON".If this last one is not available yet on the connector, support can give you a patch to make it visible and that action is taken on the target application.
One of my customers is running 5.3.2 as well and here is the DISABLEACCOUNTJSON we use :

{ "userAccountControl": "514", }

Feel free to let me know if any additional information is needed.
Regards,Adrien.

[Community_User]

Originally posted on February 20 2020 at 16:18 UTC

Hi Adrien,

Thanks very much. I will try and let you know.

Kind regards,

Raman

[Community_User · Accepted solution]

Originally posted on February 26 2020 at 13:48 UTC

Thanks for this info, it helped