Delete AD account from RSA

[SteveAlexandre1]

Hello everyone,

We have some policies in our company which require to delete AD Account automatically following some condition and after checking existing rules, I'm sure if it's possible in the product :

- Deleting account with a password not set since 6month and last logon since 6month too

- Deleting account if no entitlement anymore

- Deleting account if disabled since 6 month

At this moment, I have only found a rule to disable them if no entitlement presents but it's not our case.

Thank you.

[AlexGrant2]

Salut Steve,

I would also like to know if there is a simpler way to do this. We had a similar requirements for disabling after 30 days of not logging in and we resorted to using custom tasks running on a weekly basis. These are not supported by RSA themselves but can be very handy for running jobs that aren't yet supported centrally.

If you want to enable them, go to Admin > System and edit it. You should have the "Custom" section at the bottom - add a new record for:

custom.WFCustomTasks = True

You can then check out the Requests > Workflows > Custom Tasks tab and create new workflows that you can schedule. For our use case, we queried the IGL database public views (under AVUSER views, everything prefixed by PV_), got the accounts in scope and then performed provisioning commands against our AD business source. You could do similarly against your use cases.

The public schema is documented here.

Cheers,
Alex.

[MHelmy]

Hi Steve, Alex,

One slightly different approach I tested before was having the scheduled Custom Task not perform the provisioning, but instead use Oracle's XML-building SQL build up a Changes XML. You could then just submit that XML to RSA IGL's createChangeRequest webservice and that would submit an actual change request with all the details you need. The benefits of this are:

1. Very simple Custom Tasks (select an XML, throw it to IGL's webservices), which means less potential problems there hence better supportability.
2. More visibility of the changes since there would be a proper change request in the system.
3. You can get to use your normal approval/fulfilment paths as any other change request with this being a proper change request.

All you need for this is just to build up your SQL statement to fetch the accounts that need to be deleted/disabled, then transform the output of that SQL into an XML that is readable by the createChangeRequest webservice.

Starting 7.1.1 P02 (or P03 can't really remember), this will be even easier as you don't need to care about authentication for your webservices call or storing credentials in your custom task. The application would basically handle that for you, which is another reason to upgrade

Hope that helps!

[FrankSchubert · Accepted solution]

Hi,

Another potential way: use an account review to include all the accounts that match those criteria (some SQL required here...) and in an escalation workflow, revoke all review elements straight at day 0.

run this review daily.

Frank

[SteveAlexandre1]

Wow, what a great option hidden. Can be very usefull in some case ! Thank Alex, this will help our project a lot !

[SteveAlexandre1]

Hi Mostafa,

Always presents to help us, very usefull !

Your solution is a nice completion of Alex to keep trace of the compliance in the product.

By the way, we are always following last patch asap so we are already in 7.1.1P03 in our side

[SteveAlexandre1]

I think it's the best solution for our side and it's fucking stupid from us to not thinking about that simple solution ...

Will certainly use this systeme to do our needed but your solution is completed by Mostafa to create a CR because in workflow of review, you cannot call a provisioning/afx node/workflow.

[MHelmy]

I second you that we missed a pretty simple solution here as provided by Frank !!

The review escalation workflow would just mark all items to be revoked. This would in turn trigger a proper change request from the review, so no need to any customization.