WLS 8.1 - LDAP

 

 


Configuring

The Authentication, Authorization, Credential Mapping, and Role Mapping providers use the embedded LDAP server as their database.

To configure, click thru...

Security --> Embedded LDAP
...and set the following attributes...

Attribute Description
Credential The credential, generally a password, used to connect to the LDAP server.

If password has not been set, WLS generates a password at startup, initializes the attribute, and saves the result to config.xml.

To connect to the LDAP server using a browser and the admin account (cn=Admin), change this attribute from the generated value.

Backup Hour The hour at which to backup the LDAP server data files. At the specified time, WLS suspends writes to the LDAP server, backs up the data files into a zip file in the ldap/backup directory, and then resumes writes. Default is 23.
Backup Minute The minute at which to backup the LDAP server data files. Default is 5 minutes.
Backup Copies Limits the number of zip files in the ldap/backup directory. Default is 7.
Cache Enabled This cache is used when a managed server is reading or writing to the master LDAP server that is running on the Admin server.
Cache Size The size of the cache in kilobyptes. Default is 32K.
Cache TTL The time-to-live (TTL) of the cache in seconds. Default is 60 seconds.
Refresh Replica At Startup Specifies whether or not a Managed server should refresh all replicated data at boot time.
Master First Specifies that connections to the master LDAP server should always be made instead of connections to the local replicated LDAP server.

To have your changes take effect, cycle WLS.

Updates are sent to the master LDAP server on the admin server, which maintains a log of all changes and a list of all replicated servers their current change status. It may take several seconds or more for the change to be replicated from the master LDAP server to each local LDAP server on the Managed Server.

Deleting and modifying the configured security providers using the console may require manual clean up of the LDAP server. Use an external LDAP browser to delete unnecessary information.

 


LDAP Browser

To view the contents of the LDAP server through an LDAP browser:

  1. Change the LDAP credentials.

    1. Expand the Domain node (for example, Examples).
    2. Select the Security-->Embedded LDAP tab.
    3. Change the Credential attribute.
    4. Click Apply.
    5. Reboot WLS.

  2. To start the LDAP browser run: lbe.sh

    If lbe.sh is not on your system, you can download a copy from:

    www-unix.mcs.anl.gov/~gawor/ldap

  3. Configure a new connection in the LDAP browser:

    1. Set the host field to localhost.
    2. Set the port field to 7001 (7002 if SSL is being used).
    3. Set the Base DN field to dc=domainname where domainname is the name of the WLS domain you are using.
    4. Uncheck the Anonymous Bind option.
    5. Set the User DN field to cn=Admin.
    6. Set the Password field to the password you specified in Step 1.

  4. Click the new connection.

 


Export and Import

The following information can be exported and imported from the LDAP server:

Security Data Embedded LDAP Server DN
Users ou=people,ou=realmname,dc=domainname
Groups ou=groups,ou=realmname,dc=domainname
Security roles ou=ERole,ou=realmname,dc=domainname
Security policies ou=EResource,ou=realmname,dc=domainname

 

To export security data from the LDAP server:

  1. Enter the following command at a command prompt to start the LDAP browser run: lbe.sh

  2. Specify the data to be exported (for example, to export users specify:

    ou=people,ou=realmname,dc=domainname

  3. Select the LDIF --> Export option --> Export all children.

  4. Specify the name of the file into which the data will be exported.

To import security data from the LDAP server:

  1. Start the LDAP browser by running lbe.sh

  2. Specify the data to be imported. For example, to import users:

    specify ou=people,ou=realmname,dc=domainname

  3. Select:

    LDIF--> Import option --> Update/Add.

  4. Specify the name of the file from which the data will be imported.

 


Access Control Syntax

The LDAP server supports the IETF LDAP Access Control Model for LDAPv3 (March 2, 2001 draft). The following rules can be applied directly to entries within the directory as intended by the standard or can be configured and maintained by editing the access control file (acls.prop).

 

Access Control File acls.prop

The access control file (acls.prop) contains access control lists (ACLs) for an entire LDAP directory.

The default behavior of the LDAP server is to only allow access from the Admin account in WLS. If you are planning only to use an external LDAP browser, you do not need to edit acls.prop file. Each line in the access control file contains a single access control rule. An access control rule is made up of the following components:

  • The location in the LDAP directory where the rule applies
  • The scope within that location to which the rule applies
  • The access rights (either grant or deny)
  • The permissions (either grant or deny)
  • The attributes to which the rule applies
  • The subject being granted or denied access
Here is an example acl.props file:
[root]|entry#grant:r,b,t#[all]#public
ou=Employees,dc=octetstring,dc=com|subtree#grant:r,c#[all]#public:
ou=Employees,dc=octetstring,dc=com|subtree#grant:b,t#[entry]#public:
ou=Employees,dc=octetstring,dc=com|subtree#deny:r,c#userpassword#public:
ou=Employees,dc=octetstring,dc=com|subtree#grant:r#userpassword#this:
ou=Employees,dc=octetstring,dc=com|subtree#grant:w,o#userpassword,title,
description,
postaladdress,telephonenumber#this:
cn=schema|entry#grant:r#[all]#public:

The special location [root] applies to the entire directory.

The following access control scopes are defined:

Entry Evaluated if the entry in the LDAP directory shares the same DN as the location of the access control rule. Such rules are useful when a single entry contains more sensitive information than parallel or subentries entries.
Subtree Evaluated if the entry in the LDAP directory equals or ends with the location of this access control.

If an entry in the directory is covered by conflicting access control rules (for example, where one rule is an Entry rule and the other is a Subtree rule), the Entry rule takes precedence over rules that apply because of the Subtree rule.

 

Access Rights and Permissions

Access rights apply to an entire object or to attributes of the object. Access can be granted or denied. Either of the actions grant or deny may be used when creating or updating the access control rule.

Each of the LDAP access permissions are discrete. One permission does not imply another permission. The permissions specify the type of LDAP operations that can be performed.

 

Attribute Permissions

The following permissions apply to actions involving attributes.

Permission Description
r Read Read attributes. If granted, permits attributes and values to be returned in a Read or Search operation.
w Write Modify or add attributes. If granted, permits attributes and values to be added in a Modify operation.
o Obliterate Modify and delete attributes. If granted, permits attributes and values to be deleted in a Modify operation.
s Search Search entries with specified attributes. If granted, permits attributes and values to be included in a Search operation.
c Compare Compare attribute values. If granted, permits attributes and values to be included in a Compare operation.
m Make Make attributes on a new entry below this entry. Required for all attributes placed on an object when it is created. Just as the w and o permissions are used in the Modify operation, the m permission is used in the Add operation.

To replace values with the Modify operation, a user must have both the w and o permissions.

 

Entry Permissions

The following permissions apply entire LDAP entries.

Permission Description
a Add Add an entry below this entry. If granted, permits creation of an entry in the DIT subject to control on all attributes and values placed on the new entry at the time of creation. In order to add an entry, permission must also be granted to add at least the mandatory attributes.
d Delete Delete this entry. If granted, permits the entry to be removed from the DIT regardless of controls on attributes within the entry.
e Export Export entry and all sub entries to new location. If granted, permits an entry and its sub entries (if any) to be exported; that is, removed from the current location and placed in a new location subject to the granting of suitable permission at the destination. If the last RDN is changed, Rename permission is also required at the current location. In order to export an entry or its subentries, there are no prerequisite permissions to the contained attributes, including the RDN attribute. This is true even when the operation causes new attribute values to be added or removed as the result of the changes of RDN.
i Import Import entry and subordinates from specified location. If granted, permits an entry and its subentries (if any) to be imported; that is, removed from one other location and placed at the specified location (if suitable permissions for the new location are granted). When importing an entry or its subentries, there are no prerequisite permissions for the contained attributes, including the RDN attributes. This is true even when the operation causes new attribute values to be added or removed as the result of the changes of RDN.
n RenameDN Change the DN of an LDAP entry. Granting the Rename permission is necessary for an entry to be renamed with a new RDN, taking into account consequential changes to the DN of subentries. If the name of the superior entry is unchanged, the grant is sufficient. When renaming an entry, there are no prerequisite permissions to contained attributes, including the RDN attributes. This is true even when the operation causes new attribute values to be added or removed as the result of the changes of RDN.
b BrowseDN Browse the DN of an entry. If granted, permits entries to be accessed using directory operations that do not explicitly provide the name of the entry.
t ReturnDN Allows DN of entry to be disclosed in an operation result. If granted, allows the distinguished name of the entry to be disclosed in the operation result.

 

 

Attributes Types

The attribute type(s) to which an access control rule applies should be listed where necessary. The following keywords are available:

  • [entry] indicates the permissions apply to the entire object. This could mean actions such as delete the object, or add a child object.
  • [all] indicates the permissions apply to all attributes of the entry.

If the keyword [all] and another attribute are both specified within an ACL, the more specific permission for the attribute overrides the less specific permission specified by the [all] keyword.

 

Subject Types

Access control rules can be associated with a number of subject types. The subject of an access control rule determines whether the access control rule applies to the currently connected session.

The following subject types are defined:

AuthzID Applies to a single user that can be specified as part of the subject definition. The identity of that user in the LDAP directory is typically defined as a DN.
Group Applies to a group of users specified by one of the following object classes:

The first two types of groups contain lists of users, while the third type allows users to be included in the group automatically based on defined criteria.

Subtree Applies to the DN specified as part of the subject and all subentries in the LDAP directory tree.
IP Address Applies to a particular Internet address. This subject type is useful when all access must come through a proxy or other server. Applies only to a particular host, not to a range or subnet.
Public Applies to anyone connected to the directory, whether they are authenticated or not.
This Applies to the user whose DN matches that of the entry being accessed.

 

Grant/Deny Evaluation Rules

The decision whether to grant or deny a client access to a information in an entry is based on many factors related to the access control rules and the entry being protected. Throughout the decision making process, there are guiding principles.

  • More specific rules override less specific ones (for example, individual user entries in an ACL take precedence over a group entry).
  • When there are conflicting ACL values, Deny takes precedence over Grant.
  • Deny is the default when there is no access control information. Additionally, an entry scope takes precedence over a subtree scope.

If a conflict still exists after looking at the specificity of the rule, the subject of the rule determines which rule will be applied. Rules based on an IP Address subject are given the most precedence, followed by rules that are applied to a specific AuthzID or This subject. Next in priority are rules that apply to Group subjects. Final priority is given to rules that apply to Subtree and Public subjects.


  Home