Separate user profile/security for Test and Production environment

[demi]

Hi.
We are trying to separate the creating of complete user profile and its security for Test and Production Environment. I have created a separate data source for Test and Production environment. I am able to create user just in Test environment PS811 database separately, but when I apply user security using P98OWSEC its always update production PS811 database table F98OWSEC, however I have mapped this table to the test data source for test environment. Anyone have done this to separate complete user profile/security for test and production, please let me know or give some suggestion how to accomplish this task.

Demi
E811 SP1
Tool Release 8.97
Windows 2003
MS SQL 2005

 

[jjanowski]

There are tables in JDE that OCM mapping will not work on, I believe (90% confident) F95921 is one example. I also think F98OWSEC is the same. I would advise you contact Oracle to verify. A real CNC here can probably give better technical details for the why and possibly a work-around.

What is the issue with just segregating the F00950? This would be completely transparent to the users and validate independent security models in separate environments. I don’t see the value in also doing P98OWSEC, F95921, F0092, etc…

 

[cncjunior1]

I believe the data source that is specified in the server JDE.INI under the SECURITY section is what is used to get the data from instead of OCM since the security kernel is doing all the actual work. If you have separte installs for Test and Production, make sure they are pointing to the different data sources. If you have everything running under a single installation it may not be possible. It's been a long time since I played around with this setup though.

 

[demi]

Thanks for the advice, reason we are separating it, because when we create any test user or users just for test environments it will update the system table and when we run our audit reports for auditors for production, all test users shows up, also to keep test environment from production for better user management for production, we know once we so this separation there will be more work for CNC.

 

[jjanowski]

A SOX Policy Exception Form/Special User List for the set of dedicated users is much easier for ongoing maintenance. This is reasonably justified for the technical requirements otherwise with auditors. I would make this suggestion to your internal audit team to help coordinate appropriately for external.

 

[demi]

Thanks. Yes we have a separate installation for test and production. have you separated this in the past? if yes can yo u please share the steps.

 

[gregglarkin]

Demi

Can I suggest a different approach? For your test users, use a naming convention that clearly identifies them as a non-production ID. Write a policy that describes the naming convention and put some controls around that policy that enforce that a training ID does not have production access.

For example, our IDs have the following format:

usagml2 - production ID
usa - for the country
gml - the person's initials
2 - a numeric sequence for users with gml in their initials.

For a test ID, we add in an X in the fourth position - usaxgml2 would be a test ID. Our agreed upon standard is that auditors can ignore any ID with X in the fourth position.

It also makes it easier for us. When we do a dump of user IDs to Excel for audit reports, its easy to pick out and remove the test IDs. We have a written policy that our internal and external auditors have approved.

Gregg