Using LDAP to Authenticate and Perform RBAC of Management Services

• Overview
• Step 1: Create an Active Directory Group
• Step 2: Create an Active Directory User
• Step 3: Create an LDAP Connection
• Step 4: Create an LDAP Repository
• Step 5: Create a Test Policy for LDAP Authentication and RBAC
• Step 6: Use the LDAP Policy to Protect Management Services
• Step 7: Use the LDAP Policy to Protect the Service Manager Login Page
• Adding an LDAP User with Limited Access to Management Services
• Adding an LDAP User with Access to SOAP-Based Management Services
• System Administrators Role in LDAP
• Policy Director Super User Role in LDAP
• Using an LDAP Repository with Policy Center

Overview

This topic explains how to use Local Directory Access Protocol (LDAP) to authenticate and perform Role-Based Access Control (RBAC) of Management Services. You can use the sample Protect Management and Policy Director Interfaces (LDAP) policy instead of the Protect Management and Policy Director Interfaces policy. This means that an LDAP repository is used instead of the local Policy Director (PD) user store for authentication and RBAC of users attempting to access Management Services. This topic describes how to configure the server to use an example Microsoft Active Directory LDAP repository.

The following sections assume you are creating an admin user in the LDAP directory. A user of the same name must also exist in the local PD user store. The password contained in the PD user store does not need to match the LDAP password. If you are creating an LDAP user that does not does not already exist in the local PD user store, see the topic on Managing Policy Studio Users.

Note:
To access the policies and settings described in this topic, you must have the Show Management Services setting enabled in the Preferences in the Policy Studio.

Step 1: Create an Active Directory Group

To create a new user group in Active Directory, perform the following steps:

1. Click Start -> Administrative Tools -> Active Directory Users and Computers.
2. On the Users directory, right-click, and select New -> Group.
3. Enter the Group name (for example, GatewayAdministrators).

You can view the new group using an LDAP Browser. For example:

Step 2: Create an Active Directory User

You will most likely be unable to create an admin user with a password of changeme because this password is not strong enough to be accepted by Active Directory. Using Active Directory Users and Computers, perform the following steps:

1. On the Users directory, right-click, and select New -> User.
2. Enter a user name (for example, admin).

   Creating an Active Directory LDAP User

3. Click Next.
4. Enter a password (for example, Vordel123).
5. Select User cannot change password and Password never expires.
6. Ensure User must change password at next logon is not selected.
7. Click Next.
8. Click Finish.

   Creating an Active Directory LDAP User Password

Adding the User to the Group
To make the user a member of the group using Active Directory Users and Computers, perform the following steps:

1. Select the GatewayAdministrators group, right-click, and select Properties.
2. Click the Members tab.
3. Click Add.
4. Click Advanced.
5. Click Find Now.
6. Select the admin user.
7. Click OK.

   Adding the User to the LDAP Group

You can view the new user using an LDAP Browser. For example:

Note:
The memberOf attribute points to the Active Directory group. The user has an instance of this attribute for each group they are a member of.

Step 3: Create an LDAP Connection

To create an new LDAP Connection, perform the following steps:

1. In the Policy Studio, connect to the server, and edit the server’s configuration.
2. In the Policy Studio tree, select External Connections -> LDAP Connections.
3. Right-click, and select Create an LDAP Connection.
4. Complete the fields in the dialog as appropriate. The specified User Name should be an LDAP administrator that has access to search the full directory for users. For example:

   Creating an LDAP Connection

5. Click Test Connection to ensure the connection details are correct.

Step 4: Create an LDAP Repository

To create an new LDAP Repository, perform the following steps:

1. In the Policy Studio tree, select External Connections -> Authentication Repository Profiles -> LDAP Repositories.
2. Right-click, and select Add a new Repository.
3. Complete the following fields in the dialog:

   Repository Name	Enter an appropriate name for the repository.
   LDAP Directory	Use the LDAP directory created in Step 3.
   Base Criteria	Enter the LDAP node that contains the users (for example, see the LDAP Browser screen shot in Step 2).
   User Search Attribute	Enter cn. This is the username entered at login time (in this case, admin).
   Authorization Attribute	Enter distinguishedName. This is the username entered at login time (admin). The authentication.subject.id message attribute is set to the value of this LDAP attribute (for example, CN=admin,CN=Users,DC=kerberos3,DC=qa,DC=vordel,DC=com. The authentication.subject.id is used as the base criteria in the filter that loads the LDAP groups (the user’s roles). This enables you to narrow the search to a particular user node in the LDAP tree. For more details, see the Retrieve Attributes from Directory Server filter in Step 5.

Connecting to Other LDAP Repositories
This topic uses Microsoft Active Directory as an example LDAP repository. Other LDAP repositories such as Oracle Directory Server (formerly iPlanet and Sun Directory Server) are also supported. For an example of querying an Oracle Directory Server repository, see the Retrieve Attributes from Directory Server filter in Step 5.

Step 5: Create a Test Policy for LDAP Authentication and RBAC

To avoid locking yourself out of the Policy Studio, you can create a test policy for LDAP authentication and RBAC, which is invoked when a test URI is called on the server (and not a Management Services URI). For an example policy, select Policies -> Management Services -> Sample LDAP Policies -> Protect Management and Policy Director Interfaces (LDAP) in the Policy Studio tree.

You can create a blank test policy, and create a /test Relative Path under Default Services in the Policy Studio tree. For more details, see the topic on Creating Policies Manually.

Configure the test policy with the following filters:

HTTP Basic Authentication Filter
This filter uses the LDAP repository configured in Step 4, and includes the following settings:

The HTTP Basic Authentication filter performs the following tasks:

1. Connect to the LDAP directory using the connection details specified in the LDAP directory.
2. Find the user using the specified base criteria and search filter.
3. If authentication fails, always throw a 401. This allows retry for browser users.
4. The distinguishedName (DName) is held in the authentication.subject.id message attribute. This is specified by the Authorization Attribute field in the LDAP repository configuration.
5. The user’s roles (LDAP groups) are not available yet.

Retrieve Attributes from Directory Server Filter
This filter uses the LDAP directory configured in Step 3, and includes the following settings:

The Retrieve Attributes from Directory Server filter performs the following tasks:

1. Using the user’s DName as the search start point, find the user’s memberOf attribute (load LDAP groups for the user).
2. If the user is in one group, the group name is contained in the user.memberOf message attribute. If the user is in multiple (n) LDAP groups, the group names are held in user.memberOf.1...user.memberOf.n message attributes.

Alternatively, the following screen shows an example of querying an Oracle Directory Server repository, where the query returns the authenticated user’s groups instead of the user object:

You should be able to query any LDAP directory in this way. Assuming that the user’s groups or roles can be retrieved as attributes of an object, the query does not need to be for the user object.

RBAC Filter
This filter includes a the following setting:

The RBAC filter performs the following tasks:

1. The RBAC filter reads the roles from the user.memberOf.* message attribute. It understands the meaning of the wildcard, and loads the roles as required. It creates a string version of the roles, and places it in the authentication.subject.role message attribute for consumption by the Call internal service filter, which receives the roles as an HTTP header value.
2. The RBAC filter determines which management service is currently being invoked (which URI, SOAP operation, and namespace where applicable).
3. The RBAC filter returns true if one of the roles has access to the management service currently being invoked, as defined in the acl.policy file.
4. Otherwise, it returns false and the Return HTTP Error 403: Access Denied (Forbidden) policy is called. This message content of this filter is shown when a valid user has logged into the browser, but their role(s) does not give them access to the URI they have invoked. For example, this occurs if a new user is created and they have not yet been assigned any roles.

Reflect Filter
This filter is used for test purposes only. This will be replaced by a Call internal service filter.

Test the Policy Configuration
To test this policy configuration, perform the following steps:

1. Deploy the configuration changes to the server.
2. Update the acl.policy file with the new LDAP group as follows:

   grant principal com.vordel.circuit.rbac.VordelPrincipal "CN=GatewayAdministrators,CN=Users,DC=kerberos3,DC=qa,DC=vordel,DC=com" { permission com.vordel.circuit.rbac.MgmtServicePermission "/*"; };

3. Reboot the server so it reads the new acl.policy file.
4. Use Service Explorer to call http://localhost:8080/test.
5. Enter HTTP Basic credentials (username admin and password Vordel123).

Step 6: Use the LDAP Policy to Protect Management Services

If the authentication and RBAC filters pass, you can now use this circuit to protect the management interfaces. To ensure that you do not lock yourself out of the server, perform the following steps:

1. Make a copy of the conf/fed directory contents from the server installation, and put it into a directory accessible from the Policy Studio.
2. Make another backup copy of the conf/fed directory, which remains unmodified.
3. In the Policy Studio, select File -> Open, and browse to configs.xml in the first copy of the fed directory.
4. Modify the test policy created in Step 5 by removing the Reflect filter and replacing with a Call internal service filter as follows:

   Protecting Management Services

5. After dragging and dropping the Call internal service filter, click the Add button to add headers to send to the internal service.
6. Complete the following fields in the dialog:

   HTTP Header Name	authentication.subject.id.
   HTTP Header Value	${authentication.subject.orig.id}.

   Note:
   authentication.subject.orig.id is used here because the authentication.subject.id holds the full DName, and the cn only needs to be passed to the services.
7. Click Add button to add another header.
8. Complete the following fields in the dialog:

   HTTP Header Name	authentication.subject.role.
   HTTP Header Value	${authentication.subject.role}.

9. Under the Listeners node, select the / and the /configuration/deployments relative paths, and set the policy to be the LDAP authentication and RBAC policy with the Call internal service filter.
10. Close the connection to the file.
11. Copy the fed directory back to the server’s conf directory.
12. Reboot the server.
13. Start the Policy Studio, and connect using admin with password Vordel123 (the LDAP user credentials).
14. Click the Connection Details tab for the Enterprise Gateway server process.
15. Set the password to the LDAP password (Vordel123), and click Save. You should now be able to edit the server’s configuration as usual.

Step 7: Use the LDAP Policy to Protect the Service Manager Login Page

You should also modify the Login Form AuthN policy under Management Services to use LDAP so that access to the Service Manager login page is controlled using the LDAP repository. For an example policy, select Policies -> Management Services -> Sample LDAP Policies -> Login Form AuthN (LDAP) in the Policy Studio tree.

Configure the Login Form AuthN policy as follows:

HTML Form Based Authentication Filter
This filter includes a the following settings:

The Retrieve Attributes from Directory Server and RBAC filters include the same settings as those specified in Step 5. The Call internal service filter includes a single authentication.subject.id HTTP header.

When you deploy these updates, access to all management services is now protected using LDAP users and groups. The roles contained in the PD user store are no longer used.

Adding an LDAP User with Limited Access to Management Services

You can add an LDAP user with limited access to Management Services (exclude access to SOAP APIs). For example, assume there is already a user named Fred defined in Active Directory. Fred has a DName of CN=Fred,CN=Users,DC=kerberos3,DC=qa,DC=vordel,DC=com, and belongs to an existing LDAP group called TraceAnalyzers. Fred may also belong to other LDAP groups that have no meaning for RBAC in the Enterprise Gateway server. The TraceAnalyzers LDAP group has a DName of CN=TraceAnalyzers,CN=Users,DC=kerberos3,DC=qa,DC=vordel,DC=com. The user Fred should be able to read server trace files in a browser. No other access to Management Services should be given to Fred.

You must perform the following steps to allow Fred to view the trace files:

1. Add the following entry into the acl.policy file:

   grant principal com.vordel.circuit.rbac.VordelPrincipal "CN=TraceAnalyzers,CN=Users,DC=kerberos3,DC=qa,DC=vordel,DC=com" { permission com.vordel.circuit.rbac.MgmtServicePermission "/"; permission com.vordel.circuit.rbac.MgmtServicePermission "/index.html"; permission com.vordel.circuit.rbac.MgmtServicePermission "/images/*"; permission com.vordel.circuit.rbac.MgmtServicePermission "/css/*"; permission com.vordel.circuit.rbac.MgmtServicePermission "/favicon.ico"; permission com.vordel.circuit.rbac.MgmtServicePermission "/file/view?type=trace&format=html"; permission com.vordel.circuit.rbac.MgmtServicePermission "/file/view*?type=trace"; };

2. Reboot the server so that the acl.policy file updates are picked up.
3. In the browser, request the following URL:
   http://localhost:8090/
4. Enter user credentials for Fred when prompted in the browser.
5. The index page should show a link to access the trace files that Fred can view.

Fred is not allowed to access the server APIs used by the Policy Studio. If an attempt is made to connect to the server using the Policy Studio with his credentials, an Access denied error is displayed. No other configuration is required to give user Fred the above access to the server’s Management Services. Other users in the same LDAP group can also view trace files without further configuration changes because the LDAP group is already defined in the acl.policy file.

Adding an LDAP User with Access to SOAP-Based Management Services

Assume there is already a user named Tom defined in Active Directory. Tom has a DName of CN=Tom,CN=Users,DC=kerberos3,DC=qa,DC=vordel,DC=com. Tom belongs to an existing LDAP group called ConfigViewers. The ConfigViewers LDAP group has a DName of CN= ConfigViewers,CN=Users,DC=kerberos3,DC=qa,DC=vordel,DC=com. Tom should have read-only access to the server configuration in the Policy Studio. This means that he can invoke the read-only operations of the Management API and the Policy Director API.

You must perform the following steps to allow Fred to view the trace files:

1. Add the following entry into the acl.policy file:

   grant principal com.vordel.circuit.rbac.VordelPrincipal "CN=ConfigViewers,CN=Users,DC=kerberos3,DC=qa,DC=vordel,DC=com" { permission com.vordel.circuit.rbac.MgmtServicePermission "/runtime/management/ManagementAgent reloadConfiguration http://www.vordel.com/2006/07/22/pd/ManagementAgent"; permission com.vordel.circuit.rbac.MgmtServicePermission "/runtime/management/ManagementAgent getHostName http://www.vordel.com/2006/07/22/pd/ManagementAgent"; permission com.vordel.circuit.rbac.MgmtServicePermission "/runtime/management/ManagementAgent getProductKey http://www.vordel.com/2006/07/22/pd/ManagementAgent"; permission com.vordel.circuit.rbac.MgmtServicePermission "/runtime/management/ManagementAgent getProductName http://www.vordel.com/2006/07/22/pd/ManagementAgent"; permission com.vordel.circuit.rbac.MgmtServicePermission "/runtime/management/ManagementAgent getProductVersion http://www.vordel.com/2006/07/22/pd/ManagementAgent"; permission com.vordel.circuit.rbac.MgmtServicePermission "/runtime/management/ManagementAgent getActiveDeploymentInfo http://www.vordel.com/2006/07/22/pd/ManagementAgent"; permission com.vordel.circuit.rbac.MgmtServicePermission "/runtime/management/ManagementAgent getStoreContents http://www.vordel.com/2006/07/22/pd/ManagementAgent"; permission com.vordel.circuit.rbac.MgmtServicePermission "/configuration/deployments/DeploymentService createProcess http://www.vordel.com/2006/07/22/pd/PolicyDirector"; permission com.vordel.circuit.rbac.MgmtServicePermission "/configuration/deployments/DeploymentService getActiveConfiguration http://www.vordel.com/2006/07/22/pd/PolicyDirector"; permission com.vordel.circuit.rbac.MgmtServicePermission "/configuration/deployments/DeploymentService getActiveConfigurationFingerprint http://www.vordel.com/2006/07/22/pd/PolicyDirector"; permission com.vordel.circuit.rbac.MgmtServicePermission "/configuration/deployments/DeploymentService getConnectionCredentials http://www.vordel.com/2006/07/22/pd/PolicyDirector"; permission com.vordel.circuit.rbac.MgmtServicePermission "/configuration/deployments/DeploymentService getConfigurationDetails http://www.vordel.com/2006/07/22/pd/PolicyDirector"; permission com.vordel.circuit.rbac.MgmtServicePermission "/configuration/deployments/DeploymentService getConfigurationDetailsForID http://www.vordel.com/2006/07/22/pd/PolicyDirector"; permission com.vordel.circuit.rbac.MgmtServicePermission "/configuration/deployments/DeploymentService getConfiguration http://www.vordel.com/2006/07/22/pd/PolicyDirector"; permission com.vordel.circuit.rbac.MgmtServicePermission "/configuration/deployments/DeploymentService getLatestVersion http://www.vordel.com/2006/07/22/pd/PolicyDirector"; permission com.vordel.circuit.rbac.MgmtServicePermission "/configuration/deployments/DeploymentService getProcessDetails http://www.vordel.com/2006/07/22/pd/PolicyDirector"; permission com.vordel.circuit.rbac.MgmtServicePermission "/configuration/deployments/DeploymentService getProcessDetailsForID http://www.vordel.com/2006/07/22/pd/PolicyDirector"; permission com.vordel.circuit.rbac.MgmtServicePermission "/configuration/deployments/DeploymentService getRoleDetails http://www.vordel.com/2006/07/22/pd/PolicyDirector"; permission com.vordel.circuit.rbac.MgmtServicePermission "/configuration/deployments/DeploymentService getUserDetails http://www.vordel.com/2006/07/22/pd/PolicyDirector"; permission com.vordel.circuit.rbac.MgmtServicePermission "/configuration/deployments/DeploymentService getUserRoles http://www.vordel.com/2006/07/22/pd/PolicyDirector"; permission com.vordel.circuit.rbac.MgmtServicePermission "/configuration/deployments/DeploymentService getVersionDetails http://www.vordel.com/2006/07/22/pd/PolicyDirector"; permission com.vordel.circuit.rbac.MgmtServicePermission "/configuration/deployments/DeploymentService hasAccess http://www.vordel.com/2006/07/22/pd/PolicyDirector"; permission com.vordel.circuit.rbac.MgmtServicePermission "/configuration/deployments/DeploymentService hasAdminRole http://www.vordel.com/2006/07/22/pd/PolicyDirector"; permission com.vordel.circuit.rbac.MgmtServicePermission "/configuration/deployments/DeploymentService login http://www.vordel.com/2006/07/22/pd/PolicyDirector"; permission com.vordel.circuit.rbac.MgmtServicePermission "/configuration/deployments/DeploymentService logout http://www.vordel.com/2006/07/22/pd/PolicyDirector"; permission com.vordel.circuit.rbac.MgmtServicePermission "/configuration/deployments/DeploymentService listConfigurationFlavors http://www.vordel.com/2006/07/22/pd/PolicyDirector"; permission com.vordel.circuit.rbac.MgmtServicePermission "/configuration/deployments/DeploymentService listConfigurationGroups http://www.vordel.com/2006/07/22/pd/PolicyDirector"; permission com.vordel.circuit.rbac.MgmtServicePermission "/configuration/deployments/DeploymentService listConfigurations http://www.vordel.com/2006/07/22/pd/PolicyDirector"; permission com.vordel.circuit.rbac.MgmtServicePermission "/configuration/deployments/DeploymentService listProcessGroups http://www.vordel.com/2006/07/22/pd/PolicyDirector"; permission com.vordel.circuit.rbac.MgmtServicePermission "/configuration/deployments/DeploymentService listProcesses http://www.vordel.com/2006/07/22/pd/PolicyDirector"; permission com.vordel.circuit.rbac.MgmtServicePermission "/configuration/deployments/DeploymentService listRoles http://www.vordel.com/2006/07/22/pd/PolicyDirector"; permission com.vordel.circuit.rbac.MgmtServicePermission "/configuration/deployments/DeploymentService listUsers http://www.vordel.com/2006/07/22/pd/PolicyDirector"; permission com.vordel.circuit.rbac.MgmtServicePermission "/configuration/deployments/DeploymentService listVersions http://www.vordel.com/2006/07/22/pd/PolicyDirector"; permission com.vordel.circuit.rbac.MgmtServicePermission "/configuration/deployments/DeploymentService modifyProcess http://www.vordel.com/2006/07/22/pd/PolicyDirector"; permission com.vordel.circuit.rbac.MgmtServicePermission "/configuration/deployments/DeploymentService removeProcess http://www.vordel.com/2006/07/22/pd/PolicyDirector"; permission com.vordel.circuit.rbac.MgmtServicePermission "/configuration/deployments/DeploymentService setUserPassword http://www.vordel.com/2006/07/22/pd/PolicyDirector"; };

2. Reboot the server so that the acl.policy file changes are picked up.
3. Start the Policy Studio, and connect as a user with the rights to invoke (at the minimum) read-only SOAP-Based management service methods and the createUser method on the Policy Director API (for example, use the admin user).
   Note:
   You must enter the LDAP credentials when connecting using the Policy Studio.
4. In the Policy Studio tree, and select Users and Groups -> Users to .
5. Click Add, and create a user named Tom.
6. Set the password for Tom to anything because it is not checked.
7. Restart the Policy Studio, and enter credentials for Tom, using Tom's LDAP password to connect.
8. Tom must create a process to view the configuration for that process.
9. Load the configuration.
10. If Tom attempts to perform any write operations, he does not have access, or an Access Denied error is displayed.

To summarize, if an LDAP repository is used to authenticate and control access to management services, then the following conditions apply:

• If an LDAP user can access the SOAP-based management services (connect to the server using Policy Studio), that user must be defined in the local PD user store. The user name must match the name of the LDAP User Search Attribute defined in the LDAP repository configuration settings (normally the cn of the LDAP matches). The local PD users are still used for session tracking, and are owners of the configurations and processes. The user’s LDAP groups do not need to be defined as roles in the local PD user store. The replicated user may exist in the PD user store with no associated roles. When you create a new user, it defaults to having no associated roles, unless they are manually selected.
• If an LDAP user is not allowed to use the Policy Studio to connect to the server (for example, they may only view trace/audit files in a browser), the user does not need to exist in the local PD user store.
• For an LDAP user’s groups to have any meaning in the server’s RBAC checks, each LDAP group must be defined in the acl.policy file.

System Administrators Role in LDAP

If LDAP is used as the repository to protect the management services, you do not need to update the system Administrator Role setting to the value of an equivalent admin LDAP group name. The server cannot ensure that at least one user remains in the LDAP group with the equivalent admin access because this is managed outside the server.

Note:
Do not use the User List dialog in the Policy Studio to manage user roles because these are managed in LDAP.

Policy Director Super User Role in LDAP

If LDAP is used as the repository to protect the management services, the Policy Director Super User Role is still used to determine if a user has super user access to the Policy Director API. The value of this setting should be an LDAP group. Perform the following steps:

1. Edit the server configuration in the Policy Studio.
2. In the Policy Studio tree, select Settings -> Default Settings.
3. Set the value of the Policy Director Super User Role to the name of the LDAP group that determines if the user has the PD superuser privilege (for example, CN=GatewayAdministrators,CN=Users,DC=kerberos3,DC=qa,DC=vordel,DC=com).
4. Deploy the configuration.

To test the configuration, log into the Policy Studio with LDAP credentials of a user that is a member of CN=GatewayAdministrators,CN=Users,DC=kerberos3,DC=qa,DC=vordel,DC=com, and has no roles assigned to it in the PD local user store. The dashboard displays whether the user is a superuser.

Note:
Do not use the User List dialog in the Policy Studio to manage user roles because these are managed in LDAP.

Using an LDAP Repository with Policy Center

For example, assume that you have the following servers:

• Development Enterprise Gateway
• QA Enterprise Gateway
• Policy Center that manages both Enterprise Gateways

This section explains how to use an LDAP repository to manage access to these servers.

Adding LDAP Users and Groups
Each server uses an LDAP repository to protect its Management Services. You must add the following configuration for each server:

• Add the LDAP users that access the Policy Studio to the PD local user store of the server.
• Update the acl.policy file to include the LDAP groups, and reboot the server. For example, your LDAP admin group could be added as follows:

  grant principal com.vordel.circuit.rbac.VordelPrincipal "CN=GatewayAdministrators,CN=Users,DC=kerberos3,DC=qa,DC=vordel,DC=com" { permission com.vordel.circuit.rbac.MgmtServicePermission "/*"; };

Updating the Server to use the LDAP Repository
You must update each server configuration as follows to use the LDAP repository. Update each configuration offline to avoid locking the admin user out of the server:

1. Make a copy of the conf/fed directory contents from the server installation, and put it into a directory accessible to the Policy Studio.
2. Make another backup copy of the conf/fed directory that remains unmodified.
3. Using the Policy Studio, connect using File -> Open, and select configs.xml in the first copied version of the conf/fed directory.
4. Update the Management Services Protect Management and Policy Director Interfaces policy to use an LDAP repository as follows:
   • Under External Connections -> LDAP Connections, edit the Sample Active Directory Connection policy to use a valid LDAP directory.
   • Under External Connections -> Authentication Repository Profiles -> LDAP Repositories, edit the Sample Active Directory Repository to use your LDAP directory.
   • Under Listeners -> Oracle Enterprise Gateway -> Management Services, select Path /, and select the Protect Management and Policy Director Interfaces (LDAP) policy.
   • Under Listeners -> Oracle Enterprise Gateway -> Management Services, select Path /configuration/deployments, and select the Protect Management and Policy Director Interfaces (LDAP) policy.
5. Close the connection to the file.
6. Copy the fed directory back to the server’s conf directory.
7. Reboot the server.
8. Start the Policy Studio, and connect to the server using admin with password Vordel123 (the LDAP user credentials).
9. Click the Connection Details tab for the Enterprise Gateway process.
10. Set the password to the LDAP password Vordel123, and click Save.

Perform these steps for the Development Enterprise Gateway, QA Enterprise Gateway, and Policy Center. All three servers now share the same central LDAP repository for protecting their management services.

Updating the Policy Director Super User Role
Perform the following steps:

1. Log into Policy Center, and add the Development Gateway and QA Gateway processes. Use connection credentials of admin/Vordel123.
2. Edit the active configuration of the Policy Center server.
3. Set the Policy Director Super User Role to CN=GatewayAdministrators,CN=Users,DC=kerberos3,DC=qa,DC=vordel,DC=com.
4. Deploy this update.
5. Repeat for the Development and QA Enterprise Gateways.

Testing New LDAP Users
To ensure a new LDAP user can access Policy Center and the managed Enterprise Gateways in the same way as the admin user, perform the following steps. Assume you have a user called LdapAdmin who is a member of CN=GatewayAdministrators,CN=Users,DC=kerberos3,DC=qa,DC=vordel,DC=com.

1. Log into Policy Center as admin/changeme.
2. Add user LdapAdmin to the PD local user store (password does not matter). Do not assign any roles.
3. Log into Policy Center as LdapAdmin.
4. LdapAdmin should be able to see admin’s processes because they have the superuser role.
5. Add the Development and QA processes, connect as LdapAdmin/Vordel123.
   Note:
   LdapAdmin has not been added to the PD local user stores on these servers. They do not need to be because any access to these servers is from the Policy Center server Enterprise Gateway management API. This access uses LdapAdmin/Vordel123 credentials, which are checked against the LDAP repository.

Conclusion:
If a user’s Policy Studio access to a server is performed using Policy Center, that user must only be replicated in the Policy Center local PD user store. You do not need to replicate in each server that the user accesses using Policy Center. If the user accesses the server directly using Policy Studio, the user name must exist in the PD user store of that server.