Best Practice for Production IDM setup

[Former Member]

Hi, what is the best practice for setting up prodcution IDM:

1. Connect IDM prod to ECC DEV,QA and Prod or

2. Connect IDM prod to ECC prod only and Connect IDM dev to ECC Dev and QA.

Please also specify pros and cons for both options if possible.

Thanks in advance,

Farhan

[Former Member]

We are using option two, with three IdM instances (Dev/Test/Prod) and zero interconnection between the three.

That said, we have been receiving audit requirements now to terminate DEV AND TEST ACCOUNTS in a timely manner on terminations... This means we will need to have Prod also provisioning to Dev and Test soon.

You should probably check with people in your audit department (if you have one) and find out if they will require timely terminations in Dev/Test, and if they do, you will probably need to go with option one. Option one is unfortunately quite a bit more complicated, and makes testing IdM changes "complicated", since you can't test user hires/terminations in Dev/Test anymore since they are controlled by Production IdM. We still haven't solved that one.

[Former Member]

Interesting thread, as we are just planning our deployment. I'm leaning towards option 2 and keep a separate test/qa/prod environment. Yet, I can see that it would be nice to provision our IT support/programmer teams through one production instance into the dev/test environments. I wanted to follow-up on your post, because it seemed to indicate that you could have two IdM environments (let's say IdM Production and IdM QA) both pointed at your R/3 QA environment? Is that so? That doesn't sound correct, so I'm guessing I read that wrong. If you point the IdM Production instance at your QA and DEV environments, how would you test workflow changes, support pack upgrades, etc?

[Former Member]

We run our IDM installation as per your option 2 (Prod and non-prod on separate instances)

We use HCM for the source of truth in production and have a strict policy regarding not allowing non HCM based user accounts. HCM creates the SU01 record and details are downloaded to IDM through the LDAP extract. Access is provision based on Roles attached to the HCM Position in IDM. In Dev/test/uat we create user logins in IDM and push the details out.

Our thinking was that we definitely needed a testing environment for development and patch testing, and it needs to be separate to production. It was also ideal to use this second environment for dev/test/uat since we are in the middle of a major SAP project rollout and are creating hundreds of test and training users with various roles and prefer to keep this out of a production instance.

Lately we also created a sandpit environment since I found that I could not do destructive testing or development in the dev/test/uat instance because we were becoming reliant on this environment being available. Almost a second production instance - since we also set the policy that all changes are made through IDM and no direct SU01 changes are permitted.

Have a close look at your usage requirements before deciding which structure works best for you.

[former_member2987]

Farhan,

I don't know that there is a correct answer to your question.

It all depends on what you need to do.

If you strictly need test data, you should be refreshing your DEV and TEST environments from PROD on an as needed basis.

Otherwise, I'd have dedicated instances of IDM for all environments for workflow testing.

If you're looking for using IDM for provisioning developer accounts in these environment, I'd assume you'd use production, I've heard of this use case before, but have never worked with it so I cannot give authoritative aqdvice, but I'd offer an opinion if you need one.

Cheers,

Matt