Re: PeopleSoft DBA Forum Managing LDAP integration
- Sorry for being unclear. By *test* I meant "not production*. As the
DBA I am responsible for doing the refreshes, but not being the
security admin, I don't make the policy on what happens to the data
when a database is refreshed. So currently when I refresh, I do
nothing to the security as it is set up in PeopleSoft. That is someone
When we use LDAP, though, I was not sure what, if anything, I might be
required to do in terms of preserving security tables, making changes
via scripts or whatever in order to set up any given non-production
environment (DEV, TEST, UAT, etc).
From some of the responses it seems like we have several options from
Setting up each environment, exporting tables and importing after a
refresh, to not using LDAP at all.
Many thanks for all the input. I will pass this on to the powers above
and see what my future holds. ;-)
--- In email@example.com, Robert Ellis <robert.ellis@...> wrote:
> Kevin, not sure of the question here.
> By test, do you mean unit or acceptance? If unit I presume you are
> removing or scrambling the production data so the main task would be
> pointing the LDAP integration to your test LDAP. You can maintain the
> existing LDAP setup in your unit test environment by exporting the
> relavent tables and then truncating and importing them as part of the
> If you are referring to your acceptance test instance, then you want
> developers to be restricted - don't you?
> kevin_slack wrote:
> > My company has decided to use the LDAP integration to maintain
> > security. Does anyone have any suggestions about managing refreshes,
> > etc when using LDAP to manage security? For example, what happens when
> > I refresh test from production and the developers are still restricted
> > in their access?
> > I am unclear as to *standard practices* when managing PeopleSoft in
> > this environment. Any tips/insights are appreciated.
> > Kevin