Using LDAP as a user-store for WebLogic Administrators

This was originally posted on my dev2dev blog December 13th, 2007.   Edited on 11/19/2008 based on feedback from a customer to add clarity for control flags in the authentication providers.

One of my customers that has hundreds of WLS instances recently asked me about moving towards a centralized model for managing WebLogic Administrators.  Currently they use the file-based out-of-the-box embedded LDAP that ships with WebLogic Server as an Administrator store.  This is great for getting started quickly, but it means that each instance has it's own local user store for Administrators.  Therefore, when one of their Administrators leaves the company they have to go to each server and change the Administrator password.  Now that can be a headache!  I have previously posted on how to set up WebLogic Server for use with OpenLDAP so that LDAP users can be used for authentication for web apps, etc.  In this post, I'll discuss how to extend that to WebLogic Administration, so that centralized administration of WebLogic Administrators can be enabled via external LDAP.

Review the documentation for Authentication Providers

E-docs has some great detail on how to configure more than one Authentication Provider and how to configure LDAP Authentication Providers, and specifically addresses the case in which LDAP is the only Authentication Provider.  One thing that is important to highlight if you go down the path of only having LDAP as the sole Authentication Provider is that it introduces a point of failure into your WebLogic Servers, meaning that if your WLS instances get network partitioned from your LDAP server(s) or your LDAP server(s) goes down, your WLS instances will not boot.  You can partially guard against this by configuring LDAP fail-over, but to keep the flexibility, you may want to keep the Default Authenticator around for emergencies and keep that user/password isolated to a master Administrator.  There are two ways to enable someone to be a WebLogic Administrator:

  1. Add the user to the Administrators group in LDAP (which is included in the Admin global role by default)
  2. Add the user to the Admin global role (you can do this by group, explicit user, etc)

As it is mentioned in the docs, your LDAP may already use the Administrators group for another purpose, or you may not want to put users in that group and give them Administrator access to all the domains in your environment.  In this case, the 2nd method allows you to be much more granular and even put users in groups that might correlate to their business unit.  So I could have an HRWebLogicAdmins group in LDAP for the Human Resources department, and when I create the domains for that department, make sure I add that group to the Admin Global Role.  If that approach is taken, users may be able to use their normal LDAP user and credentials instead of a special Administrative account that is shared because their personal user has group membership to HRWebLogicAdmins.  This provides you with an additional level of auditing since you are not using shared Administrator accounts.

Configure your base domain

Let's put this into practice.  First let's assume were starting from scratch with no domains at all.  We'll configure LDAP with it and confirm that we can have Administrators in LDAP, then create a domain template with LDAP preconfigured so that new domains don't have to do this LDAP setup at all.  I'm going to use WLS 10 MP1 for this, but the steps should be similar in other versions of WLS.  I'm using the same OpenLDAP configuration that I discussed in my previous post, so refer to that for more detail on this setup if you need it.

  1. Create a domain - D:\bea100MP1\wlserver_10.0\common\bin\config.cmd (sh)
  2. Keep the defaults, which will have weblogic/weblogic as your Administrator.
  3. Start the AdminServer and login with weblogic/weblogic.at http://localhost:7001/console
  4. Click the "Lock & Edit" button in the console and optionally then click the "Record" button if you are in WLS 10 or higher and want to record the WLST script
  5. Add the OpenLDAP Authenticator to your realm.  Remember to set the control flag of both the Default Authenticator and your LDAP Authenticator to OPTIONAL or SUFFICENT.  If you leave the control flag setting as is for the Default Authenticator, which is REQUIRED, then any user authenticating in the realm would need to be in embedded LDAP also, which is not what we want.  Restarting the server will be required for the security changes to take effect, even if the console doesn't remind you, so don't forget that step.
  6. Review the Admin role mapping to see that it maps to the users/groups you want.  In this example, I'm assuming that the using the Adminstrators group in LDAP is okay.

Roles [2]

Here is the default mapping for all users in the Admin role.  Notice that it includes all of the users in the Adminstrators group by default.  This is where I could add other groups.  Be aware that role changes you make are stored as XACML and have to be imported/exported.

groupMapping

Now click "Activate Changes" and notice the name of the WLST script if you did a recording and the notice that we need to restart the server for the changes to take affect since we modified the security subsystem.  At this point we can shut the server down.

Now let's review my LDAP configuration.  Using JXplorer I can both view and edit my OpenLDAP configuration.  Here are the settings that work with the LDAP config from my previous post:  Note that the password is "secret".

jxplorer

Note that I added an Administrators group and added the jbayer user as a member of that group.  To add a group, just right click on "groups" and select "New" and go through the prompts.

Explorer

Ok, now I should be able to boot WLS with the jbayer user and login to the console as an Administrator.  Let's try both.  First I need to update the boot.properties file that is located in the domain's <Server_Name>/security directory.  In my case, that is:  D:\bea100MP1\user_projects\domains\open_ldap_domain3\servers\AdminServer\security

Opening the file shows you that the username and password are encrypted, so now we need to replace the {3DES} encrypted values with plain text ones for my jbayer user.  The next time WLS boots, it will re-encrypt these values.  Note that we can also find out the domains encrypted values ourselves by using the encryption utility:

D:\bea100MP1\user_projects\domains\open_ldap_domain3\bin>setDomainEnv.cmd

D:\bea100MP1\user_projects\domains\open_ldap_domain3>java weblogic.security.Encrypt jbayer
{3DES}yunUy+yVmfY=

D:\bea100MP1\user_projects\domains\open_ldap_domain3>java weblogic.security.Encrypt weblogic
{3DES}PmZxnuL1akG6MzWSRo/g3w==


Now we can boot the domain.  If there is a problem, you'll see a stack trace that mentions the security sub-system, you'll probably have to change the boot.properties file back to the original values, weblogic/weblogic if you didn't change the defaults and see if you messed up anywhere.

 

If there is no problem and the server goes to a RUNNING state, then we have booted the server as jbayer, which is in the Admin role because that user is in the Administrators group in OpenLDAP.  Now try logging into the console and that should work as well.  Here is my screen-shot showing the successful jbayer user login as Administrator to the console.

jbayer [2]

Make it repeatable with WLST or a Domain Template

Doing all of this configuration each time you want to setup a new domain can monotonous and prone to typing mistakes.  This is where using WLST or domain templates can come in very handy.  First let's review the .py file that was created during our WLST recording as we created the OpenLDAP Authenticator.  Mine was saved to my domain's base directory with the name Script1197502551016.py.  For more on WLST see my intro to WLST post and the command reference for documentation on WLST commands.


cd('/SecurityConfiguration/open_ldap_domain/Realms/myrealm')
cmo.createAuthenticationProvider('openLdapAuthenticator', 'weblogic.security.providers.authentication.OpenLDAPAuthenticator')

cd('/SecurityConfiguration/open_ldap_domain/Realms/myrealm/AuthenticationProviders/openLdapAuthenticator')
cmo.setGroupBaseDN('ou=groups, dc=bea, dc=com')
cmo.setStaticGroupObjectClass('groupOfNames')
cmo.setUserBaseDN('ou=people, dc=bea, dc=com')
cmo.setUserObjectClass('inetOrgPerson')
cmo.setPrincipal('cn=Manager,dc=bea,dc=com')
setEncrypted('Credential', 'Credential_1197503008359', 'D:/bea100MP1/user_projects/domains/open_ldap_domain/Script1197502551016Config', 'D:/bea100MP1/user_projects/domains/open_ldap_domain/Script1197502551016Secret')
cmo.setStaticGroupDNsfromMemberDNFilter('(&(member=%M)(objectclass=groupOfNames))')
cmo.setUserFromNameFilter('(&(cn=%u)(objectclass=inetOrgPerson))')
cmo.setGroupFromNameFilter('(&(cn=%g)(objectclass=groupOfNames))')
cmo.setControlFlag('SUFFICIENT')

cd('/SecurityConfiguration/open_ldap_domain/Realms/myrealm/AuthenticationProviders/DefaultAuthenticator')
cmo.setControlFlag('SUFFICIENT')

activate()


I could simply use a script like this to configure my new domains to have LDAP support after they have been created.  However, I can go one step further and use the domain that has already been configured for LDAP and create a domain template using the Domain Template Builder D:\bea100MP1\wlserver_10.0\common\bin\config_builder.cmd.  Now when I create new Domains using the Config Wizard and base it off that template, authentication to OpenLDAP will be pre-configured.  Just launch the Domain Template Wizard, point it at the domain and follow all of the defaults.  I can even configure the Admin Role here to include other groups.

One Last Gotcha

One big gotcha that I encountered is that the new domains that I created based off that template still had the OpenLDAP password for the manager user set to the encrypted value of the first domain in the config.xml file in the new domain's config directory.  Each domain has a unique way of encrypting it's passwords so the encrypted values cannot be exchanged between domains.  I've highlighted the incorrect value below in the credential-encrypted element.  Make sure you replace that value with new domains correct {3DES} value that you can retrieve with technique illustrated earlier: java weblogic.security.Encrypt password.  I'm investigating whether this is working as designed or not as I expected the Config Wizard to take care of that for me. 


<sec:authentication-provider xsi:type="wls:open-ldap-authenticatorType">
<sec:name>openLdapAuthenticator</sec:name>
<sec:control-flag>SUFFICIENT</sec:control-flag>
<wls:propagate-cause-for-login-exception>false</wls:propagate-cause-for-login-exception>
<wls:user-object-class>inetOrgPerson</wls:user-object-class>
<wls:principal>cn=Manager,dc=bea,dc=com</wls:principal>
<wls:user-base-dn>ou=people, dc=bea, dc=com</wls:user-base-dn>
<wls:credential-encrypted>{3DES}68bCeqro3EA=</wls:credential-encrypted>
<wls:user-from-name-filter>(&amp;(cn=%u)(objectclass=inetOrgPerson))</wls:user-from-name-filter>
<wls:group-base-dn>ou=groups, dc=bea, dc=com</wls:group-base-dn>
<wls:group-from-name-filter>(&amp;(cn=%g)(objectclass=groupOfNames))</wls:group-from-name-filter>
<wls:static-group-object-class>groupOfNames</wls:static-group-object-class>
<wls:static-group-dns-from-member-dn-filter>(&amp;(member=%M)(objectclass=groupOfNames))</wls:static-group-dns-from-member-dn-filter>
</sec:authentication-provider>

Hopefully this illustrates how LDAP can provide a way to manage WebLogic Administration in a way that is more scalable than having individual user stores in embedded LDAP when many WLS instances are involved.

Comments:

Hi, Instead of: setEncrypted('Credential', 'Credential_1197503008359', 'D:/bea100MP1/user_projects/domains/open_ldap_domain/Script1197502551016Config', 'D:/bea100MP1/user_projects/domains/open_ldap_domain/Script1197502551016Secret') for setting the password in production mode, you can use: cmo.setCredentialEncrypted(encrypt('new_password'))

Posted by Mircea Vutcovici on March 23, 2011 at 04:58 AM PDT #

Here is my case, Let me know if you have any inputs:
1) only password validation is done by LDAP (backup LDAP)
2) However roles/Groups and policies are managed at the weblogic ?

Is it a possibility or is there any way it can be done?

Posted by Kapil Shukla on June 15, 2011 at 04:21 AM PDT #

Kapil, I'm not sure. Perhaps you could check out the JAAS Principal. In this diagram, notice they show a custom MyPrincipal of "foobar" added to the JAAS Subject, but separate from Users/Groups.
http://download.oracle.com/docs/cd/E17904_01/web.1111/e13710/concepts.htm#i1129105

I recommend you post in the OTN forum for WLS Security or Identity Managment.
http://forums.oracle.com/forums/forum.jspa?forumID=581
http://forums.oracle.com/forums/forum.jspa?forumID=47

James

Posted by james.bayer on June 15, 2011 at 04:41 AM PDT #

Post a Comment:
Comments are closed for this entry.
About

James Bayer Image
I was formerly a Product Manager on the WebLogic Server team based out of Oracle HQ. You can find my new blog at http://iamjambay.com.
Follow Me on Twitter
Oracle WebLogic

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today