User management and authentication

Red Hat Directory Server 12

Managing users, groups, roles, and authentication-related settings

Red Hat Customer Content Services

Abstract

Learn how to manage user access permissions, resource limits, user groups, and user roles. You can configure a password and account lockout policy, deny access for a group of users, and limit system resources depending on their bind distinguished name (bind DN).

Providing feedback on Red Hat documentation

We appreciate your input on our documentation. Please let us know how we could make it better. To do so:

  • For submitting feedback through Jira (account required):

    1. Log in to the Jira website.
    2. Click Create in the top navigation bar
    3. Enter a descriptive title in the Summary field.
    4. Enter your suggestion for improvement in the Description field. Include links to the relevant parts of the documentation.
    5. Click Create at the bottom of the dialogue.

  • For submitting feedback through Bugzilla (account required):

    1. Go to the Bugzilla website.
    2. As the Component, use Documentation.
    3. Fill in the Description field with your suggestion for improvement. Include a link to the relevant part(s) of documentation.
    4. Click Submit Bug.

Chapter 1. Changing the Directory Manager password

The Directory Manager is the privileged database administrator, comparable to the root user in a Linux operating system. The Directory Manager entry and the corresponding password are set during the instance installation. As an administrator, you can change the Directory Manager password to use a different one.

1.1. Changing the Directory Manager password using the command line

You can set a new password for the Directory Manager using the dsconf command line utility or manually by setting the nsslapd-rootpw parameter.

Important

Set the password using an encrypted connection only. Using an unencrypted connection can expose the password to the network. If your server does not support encrypted connections, use the web console to update the Directory Manager password.

Procedure

  • Set the Directory Manager password using one of the following options:

    • To encrypt the password automatically: 

      # dsconf -D "cn=Directory Manager" ldaps://server.example.com config replace nsslapd-rootpw=password

      Directory Server automatically encrypts the plain text value that you set in the nsslapd-rootpw parameter.

      Warning

      Do not use curly braces {} in the password. Directory Server stores the password in the {password-storage-scheme}hashed_password format. The server interprets characters in curly braces as the password storage scheme. If the string is an invalid storage scheme or if the password is not correctly hashed, the Directory Manager cannot connect to the server.

    • To encrypt the password manually:

      1. Generate a new password hash. For example: 

        # pwdhash -D /etc/dirsrv/slapd-instance_name password
{PBKDF2_SHA256}AAAgAMwPYIhEkQozTagoX6RGG5E7d6/6oOJ8TVty...

        The password is encrypted using the password storage scheme set in the nsslapd-rootpwstoragescheme attribute of the Directory Server instance configuration.

      2. Using a STARTTLS connection, set the nsslapd-rootpw attribute to the value displayed in the previous step: 

        # dsconf -D "cn=Directory Manager" ldaps://server.example.com config replace nsslapd-rootpw="{PBKDF2_SHA256}AAAgAMwPYIhEkQozTagoX6RGG5E7d6/6oOJ8TVty..."

Additional resources

1.2. Changing the Directory Manager password using the web console

You can set a new password for the Directory Manager using the web console.

Prerequisites

  • You are logged in to the instance in the web console.

Procedure

  1. Open the Server → Server Settings → Directory Manager menu.
  2. Enter the new password into the Directory Manager Password and Confirm Password fields.
  3. Optional: Set a different password storage scheme.
  4. Click Save.

Chapter 2. Resetting the Directory Manager password

The Directory Manager is the privileged database administrator, comparable to the root user in a Linux operating system. The Directory Manager password is set during the instance installation. If you lose the password, you can reset it to regain privileged access to the directory.

2.1. Resetting the Directory Manager password using the command line

If you have the root access to the Directory Server instance, you can reset the password of the Directory Manager.

Procedure

  1. Generate a new password hash. For example: 

    # pwdhash -D /etc/dirsrv/slapd-instance_name new_password
{PBKDF2_SHA256}AAAgABU0bKhyjY53NcxY33ueoPjOUWtl4iyYN5uW...

    Because you specified the path to the Directory Server instance configuration, the pwdhash generator automatically uses the password storage scheme set in the nsslapd-rootpwstoragescheme attribute to encrypt the new password.

  2. Stop the Directory Server instance: 

    # dsctl instance_name stop

  3. Edit the /etc/dirsrv/slapd-instance_name/dse.ldif file and set the nsslapd-rootpw attribute to the value displayed in the first step: 

    nsslapd-rootpw: {PBKDF2_SHA256}AAAgABU0bKhyjY53NcxY33ueoPjOUWtl4iyYN5uW...

  4. Start the Directory Server instance: 

    # dsctl instance_name start

Chapter 3. Configuring password policies

A password policy minimizes the risks associated with using passwords by enforcing a certain level of security. For example, you can define a password policy to ensure that:

  • Users must change their passwords according to a schedule
  • Users must provide non-trivial passwords
  • The password syntax must meet certain complexity requirements

3.1. How password policies work

Directory Server supports fine-grained password policies, which work in an inverted pyramid, from general to specific. A global password policy is superseded by a subtree-level password policy, which is superseded by a user-level password policy.

You can define:

  • Global password policy, applied to the entire directory

  • Local password policy

    • Subtree-level policy, applied to a particular subtree
    • User-level policy, applied to a particular user

Password policies are not additive: only one password policy applies to an entry. For example, when you configure a particular attribute in the global or subtree-level password policy, but not in the user-level password policy, this attribute does not apply to the user. In this case, when the user attempts to log in, only the user-level policy is active.

Warning

When using a password administrator account or the Directory Manager (root DN) to set a password, you bypass the password policies. Do not use these accounts for regular user password management. Use them only to perform password administration tasks that require bypassing the password policies, such as adding a prehashed password, or purposefully overriding current password constraints for setting temporary passwords after a reset.

The complete password policy that applies to a user account consists of the following elements:

  • The type or level of password policy checks. This information indicates whether the server should check for and enforce a global password policy or local password policies.
  • Password add and modify information. The password information includes password syntax and password history details.
  • Bind information. The bind information includes the number of grace logins permitted, password aging attributes, and tracking bind failures.
Note

After establishing a password policy, you can protect user passwords from potential threats by configuring an account lockout policy. Account lockout protects against attempts to break into the directory by repeatedly guessing a user’s password.

Additional resources

3.2. Configuring the global password policy using the command line

By default, global password policy settings are disabled. You can configure the global password policy using the dsconf command line utility.

Procedure

  1. Display the current settings: 

    # dsconf -D "cn=Directory Manager" ldap://server.example.com pwpolicy get
Global Password Policy: cn=config
------------------------------------
passwordstoragescheme: PBKDF2_SHA256
passwordChange: on
passwordMustChange: off
passwordHistory: off
passwordInHistory: 6
...

  2. Adjust the password policy settings. For a full list of available settings, enter: 

    # dsconf -D "cn=Directory Manager" ldap://server.example.com pwpolicy set --help

    For example, to enable password syntax checking and set the minimum length of passwords to 12 characters, enter: 

    # dsconf -D "cn=Directory Manager" ldap://server.example.com pwpolicy set --pwdchecksyntax on --pwdmintokenlen 12

  3. Enable the the account lockout feature for the password policy: 

    # dsconf -D "cn=Directory Manager" ldap://server.example.com pwpolicy set --pwdlockout on

3.3. Configuring the global password policy using the web console

By default, global password policy settings are disabled. You can configure the global password policy using the web console.

Prerequisites

  • You are logged in to the instance in the web console.

Procedure

  1. Open the Database → Password Policies → Global Policy menu.

  2. Set the global password policy settings. You can set parameters in the following categories:

    • General settings, such as the password storage scheme
    • Password expiration settings, such as the time when a password expires
    • Account lockout settings, such as after how many failed login attempts an account should be locked

    • Password syntax settings, such as the minimum password length

      To display a tool tip and the corresponding attribute name in the cn=config entry for a parameter, hover the mouse cursor over the setting.

  3. Click Save.

3.4. Local password policy entries

When you use the dsconf localpwp addsubtree or dsconf localpwp adduser commands, Directory Server automatically creates an entry to store the local password policy attributes.

For a subtree, the following entries are added:

Table 3.1. Local password policy entries for a subtree

Entry nameDescriptionContents

nsPwPolicyContainer

A container entry at the subtree level

Various password policy-related entries for the subtree and all its children

nsPwPolicyEntry

The actual password policy specification entry

All the password policy attributes that are specific to the subtree

nsPwTemplateEntry

The CoS Template Entry

The pwdpolicysubentry value pointing to the nsPwPolicyEntry entry

<CoS definition entry DN>

The CoS definition entry at the subtree level

CoS definition entry

Example 3.1. The nsPwPolicyContainer entry for a subtree ou=people,dc=example,dc=com

dn: cn=nsPwPolicyContainer,ou=people,dc=example,dc=com
objectClass: top
objectClass: nsContainer
cn: nsPwPolicyContainer

Example 3.2. The nsPwPolicyEntry entry for a subtree ou=people,dc=example,dc=com

dn: cn="cn=nsPwPolicyEntry,ou=people,dc=example,dc=com",
 cn=nsPwPolicyContainer,ou=people,dc=example,dc=com
objectclass: top
objectclass: extensibleObject
objectclass: ldapsubentry
objectclass: passwordpolicy

Example 3.3. The nsPwTemplateEntry entry for a subtree ou=people,dc=example,dc=com

dn: cn="cn=nsPwTemplateEntry,ou=people,dc=example,dc=com",
 cn=nsPwPolicyContainer,ou=people,dc=example,dc=com
objectclass: top
objectclass: extensibleObject
objectclass: costemplate
objectclass: ldapsubentry
cosPriority: 1
pwdpolicysubentry: cn="cn=nsPwPolicyEntry,ou=people,dc=example,dc=com",
     cn=nsPwPolicyContainer,ou=people,dc=example,dc=com

Example 3.4. The CoS specification entry for a subtree ou=people,dc=example,dc=com

dn: cn=newpwdpolicy_cos,ou=people,dc=example,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: cosSuperDefinition
objectclass: cosPointerDefinition
cosTemplateDn: cn=cn=nsPwTemplateEntry\,ou=people\,dc=example,dc=com,
 cn=nsPwPolicyContainer,ou=people,dc=example,dc=com
cosAttribute: pwdpolicysubentry default operational

For a user, the following entries are added:

Table 3.2. Local password policy entries for a user

Entry nameDescriptionContents

nsPwPolicyContainer

A container entry at the parent level

Various password policy-related entries for the user and all its children

nsPwPolicyEntry

The actual password policy specification entry

All the password policy attributes that are specific to the user

Example 3.5. The nsPwPolicyContainer entry for a user uid=user_name,ou=people,dc=example,dc=com

dn: cn=nsPwPolicyContainer,ou=people,dc=example,dc=com
objectClass: top
objectClass: nsContainer
cn: nsPwPolicyContainer

Example 3.6. The nsPwPolicyEntry entry for a user uid=user_name,ou=people,dc=example,dc=com

dn: cn="cn=nsPwPolicyEntry,uid=user_name,ou=people,dc=example,dc=com",
 cn=nsPwPolicyContainer,ou=people,dc=example,dc=com
objectclass: top
objectclass: extensibleObject
objectclass: ldapsubentry
objectclass: passwordpolicy

3.5. Configuring a local password policy using the command line

In contrast to a global password policy, which defines settings for the entire directory, a local password policy is a policy for a specific user or subtree. Currently, you can only set up a local password policy using the command line.

Prerequisites

  • User or subtree entries that you want to create the policy for already exist in the directory.

Procedure

  1. Verify if a local password policy already exists for the subtree or user entry. For example: 

    # dsconf -D "cn=Directory Manager" ldap://server.example.com localpwp get "ou=People,dc=example,dc=com"
Enter password for cn=Directory Manager on ldap://server.example.com:
Error: No password policy was found for this entry

    If no local policy exists, create one:

    • To create a subtree password policy: 

      # dsconf -D "cn=Directory Manager" ldap://server.example.com localpwp addsubtree "ou=People,dc=example,dc=com"

    • To create a user password policy: 

      # dsconf -D "cn=Directory Manager" ldap://server.example.com localpwp adduser "uid=user_name,ou=People,dc=example,dc=com"

  2. Set local policy attributes. For a full list of available settings, enter: 

    # dsconf -D "cn=Directory Manager" ldap://server.example.com localpwp set --help

    For example, to enable password expiration and set the maximum password age to 14 days (1209600 seconds):

    • On a subtree password policy: 

      # dsconf -D "cn=Directory Manager" ldap://server.example.com localpwp set --pwdexpire on --pwdmaxage 1209600 "ou=People,dc=example,dc=com"

    • On a user password policy: 

      # dsconf -D "cn=Directory Manager" ldap://server.example.com localpwp set --pwdexpire on --pwdmaxage 1209600 "uid=user_name,ou=People,dc=example,dc=com"

3.6. Disabling a local password policy using the command line

When you create a new local policy, the nsslapd-pwpolicy-local parameter in the cn=config entry is automatically set to on. If the local password policy should not be enabled, you can disable it manually using the command line.

Procedure

  • Disable all local policies or remove a particular local policy:

    • To disable all local password policies: 

      # dsconf -D "cn=Directory Manager" ldap://server.example.com pwpolicy set --pwdlocal off

    • To remove a single existing subtree password policy: 

      # dsconf -D "cn=Directory Manager" ldap://server.example.com localpwp remove "ou=People,dc=example,dc=com"

    • To remove a single existing user password policy: 

      # dsconf -D "cn=Directory Manager" ldap://server.example.com localpwp remove "uid=user_name,ou=People,dc=example,dc=com"

Chapter 4. Configuring temporary password rules

Directory Server password policies support setting temporary passwords on user accounts. If you assign a temporary password to a user, Directory Server rejects any other operation than a password change until the user changes its password.

The following are the features of temporary passwords:

  • Only the cn=Directory Manager account can assign temporary passwords.
  • Directory Server allows authentication attempts only for a fixed number of times to avoid that an attacker probes the password.
  • Directory Server allows authentication attempts after a specified delay to configure that the temporary passwords are not usable directly after you set them.
  • Directory Server allows authentication attempts only for a specified time so that the temporary password expires if a user does not use or reset it.
  • If the authentication was successful, Directory Server requires that the user resets the password before the server performs any other operation.

By default, temporary password rules are disabled. You can configure them in global or local password policies.

4.1. Enabling temporary password rules in the global password policy

To enable the temporary password feature for the whole Directory Server instance:

  1. Enable that users must change their password if an administrator resets it.
  2. Configure the feature in the global password policy.

If an administrator updates the userPassword attribute of a user and sets the passwordMustChange attribute to on, Directory Server applies the temporary password rules.

Procedure

  1. Configure that a user must change its password after an administrator resets it: 

    # dsconf -D "cn=Directory Manager" ldap://server.example.com  pwpolicy set --pwdmustchange on

  2. Configure the temporary password rules settings in a global password policy: 

    # dsconf -D "cn=Directory Manager" ldap://server.example.com pwpolicy set --pwptprmaxuse 5 --pwptprdelayexpireat 3600 --pwptprdelayvalidfrom 60

    In this example:

    • The --pwptprmaxuse option sets the maximum number of attempts a user can use the temporary password to 5.
    • The --pwptprdelayexpireat option sets the time before the temporary password expires to 3600 seconds (1 hour).
    • The --pwptprdelayvalidfrom option configures that the time set in --pwptprdelayexpireat starts 60 seconds after an administrator reset the password of a user.

Verification

  • Display the attributes that store the temporary password rules: 

    # dsconf -D "cn=Directory Manager" ldap://server.example.com pwpolicy get | grep -i TPR
passwordTPRMaxUse: 5
passwordTPRDelayExpireAt: 3600
passwordTPRDelayValidFrom: 60

4.2. Enabling temporary password rules in a local password policy

To enable the temporary password feature for a specific user or sub-tree, enable that users must change their password if an administrator resets it, and configure the feature in a local password policy.

If an administrator updates the userPassword attribute of a user and sets the passwordMustChange attribute to on, Directory Server applies the temporary password rules if the user:

  • Has the local password policy enabled
  • Is stored in a sub-tree that has the local password policy enabled

Procedure

  1. Configure that a user must change its password after an administrator resets it: 

    # dsconf -D "cn=Directory Manager" ldap://server.example.com  pwpolicy set --pwdmustchange on

  2. Configure the temporary password rules settings:

    • For an existing sub-tree: 

      # dsconf -D "cn=Directory Manager" ldap://server.example.com localpwp addsubtree --pwptprmaxuse 5 --pwptprdelayexpireat 3600 --pwptprdelayvalidfrom 60 ou=People,dc=example,dc=com

    • For an existing user: 

      # dsconf -D "cn=Directory Manager" ldap://server.example.com localpwp adduser --pwptprmaxuse 5 --pwptprdelayexpireat 3600 --pwptprdelayvalidfrom 60 uid=example,ou=People,dc=example,dc=com

    In these examples:

    • The --pwptprmaxuse option sets the maximum number of attempts a user can use the temporary password to 5.
    • The --pwptprdelayexpireat option sets the time before the temporary password expires to 3600 seconds (1 hour).
    • The --pwptprdelayvalidfrom option configures that the time set in --pwptprdelayexpireat starts 60 seconds after an administrator reset the password of a user.

Verification

  • Display the local password policy of the distinguished name (DN): 

    # dsconf -D "cn=Directory Manager" ldap://server.example.com localpwp get <DN> | grep -i TPR
passwordTPRMaxUse: 5
passwordTPRDelayExpireAt: 3600
passwordTPRDelayValidFrom: 60

Chapter 5. Assigning password administrator permissions

The Directory Manager can assign the password administrator role to a user or a group of users. Because password administrators need access control instructions (ACIs) with the appropriate permissions, Red Hat recommends that you configure a group to allow a single ACI set to manage all password administrators.

Using the password administrator role is beneficial in the following scenarios:

  • setting up an atribute that forces the user to change their password at the time of the next login
  • changing a user’s password to a different storage scheme defined in the password policy
Important

A password administrator can perform any user password operations. When using a password administrator account or the Directory Manager (root DN) to set a password, password policies are bypassed and not verified. Do not use these accounts for regular user password management. Red Hat recommends performing ordinary password updates under an existing role in the database with permissions to update only the userPassword attribute.

Note

You can add a new passwordAdminSkipInfoUpdate: on/off setting under the cn=config entry to provide a fine grained control over password updates performed by password administrators. When you enable this setting, passwords updates do not update certain attributes, for example, passwordHistory, passwordExpirationTime, passwordRetryCount, pwdReset, and passwordExpWarned.

5.1. Assigning password administrator permissions in a global policy

In a global policy, you can assign the password administrator role to a user or a group of users. Red Hat recommends that you configure a group to allow a single access control instruction (ACI) set to manage all password administrators.

Prerequisites

  • You have created a group named password_admins that includes all of the users to whom you want to assign the password administrator role.

Procedure

  1. Create the ACI that defines the permissions for a password administrator role: 

    ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: ou=people,dc=example,dc=com changetype: modify add: aci aci: (targetattr="userPassword || nsAccountLock || userCertificate || nsSshPublicKey") (targetfilter="(objectClass=nsAccount)")(version 3.0; acl "Enable user password reset"; allow (write, read)(groupdn="ldap:///cn=password_admins,ou=groups,dc=example,dc=com");)

  2. Assign the password administrator role to the group: 

    # dsconf -D "cn=Directory Manager" ldap://server.example.com pwpolicy set --pwdadmin "cn=password_admins,ou=groups,dc=example,dc=com"

5.2. Assigning password administrator permissions in a local policy

In a local policy, you can assign the password administrator role to a user or a group of users. Red Hat recommends that you configure a group to allow a single access control instruction (ACI) set to manage all password administrators.

Prerequisites

  • You have created a group named password_admins that includes all of the users to whom you want to assign the password administrator role.

Procedure

  1. Create the ACI that defines the permissions for a password administrator role: 

    ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: ou=people,dc=example,dc=com changetype: modify add: aci aci: (targetattr="userPassword || nsAccountLock || userCertificate || nsSshPublicKey") (targetfilter="(objectClass=nsAccount)")(version 3.0; acl "Enable user password reset"; allow (write, read)(groupdn="ldap:///cn=password_admins,ou=groups,dc=example,dc=com");)

  2. Assign the password administrator role to the group: 

    # dsconf -D "cn=Directory Manager" ldap://server.example.com localpwp set ou=people,dc=example,dc=com --pwdadmin "cn=password_admins,ou=groups,dc=example,dc=com"

5.3. Additional resources

Chapter 6. Disabling anonymous binds

If a user attempts to connect to Directory Server without supplying any credentials, this operation is called anonymous bind. Anonymous binds simplify searches and read operations, such as finding a phone number in the directory by not requiring users to authenticate first. However, anonymous binds can also be a security risk, because users without an account are able to access the data.

Warning

By default, anonymous binds are enabled in Directory Server for search and read operations. This allows unauthorized access to user entries as well as configuration entries, such as the root directory server entry (DSE).

6.1. Disabling anonymous binds using the command line

To increase the security, you can disable anonymous binds.

Procedure

  • Set the nsslapd-allow-anonymous-access configuration parameter to off: 

    # dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-allow-anonymous-access=off

Verification

  • Run a search without specifying a user account: 

    # ldapsearch -H ldap://server.example.com -b "dc=example,dc=com" -x
ldap_bind: Inappropriate authentication (48)
	additional info: Anonymous access is not allowed

6.2. Disabling anonymous binds using the web console

To increase the security, you can disable anonymous binds.

Prerequisites

  • You are logged in to the instance in the web console.

Procedure

  1. Navigate to Server → Server Settings → Advanced Settings.
  2. Set the Allow Anonymous Access parameter to off.
  3. Click Save.

Verification

  • Run a search without specifying a user account: 

    # ldapsearch -H ldap://server.example.com -b "dc=example,dc=com" -x
ldap_bind: Inappropriate authentication (48)
        additional info: Anonymous access is not allowed

Chapter 7. Manually inactivating users and roles

In Directory Server, you can temporarily inactivate a single user account or a set of accounts. Once an account is inactivated, a user cannot bind to the directory. The authentication operation fails.

7.1. Inactivation and activation of users and roles using the command line

You can manually inactivate users and roles using the command line or the operational attribute.

Roles behave as both a static and a dynamic group. With a group, entries are added to a group entry as members. With a role, the role attribute is added to an entry and then that attribute is used to identify members in the role entry automatically.

Users and roles are inactivated executing the same procedures. However, when a role is inactivated, the members of the role are inactivated, not the role entry itself.

To inactivate users and roles, execute the following commands in the command line:

  • For inactivation of a user account: 

    # dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" account lock "uid=user_name,ou=People,dc=example,dc=com"

  • For inactivation of a role: 

    # dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" role lock "cn=Marketing,ou=People,dc=example,dc=com"

To activate users and roles, execute the following commands in the command line:

  • For activation of a user account: 

    # dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" account unlock "uid=user_name,ou=People,dc=example,dc=com"

  • For activation of a role: 

    # dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" role unlock "cn=Marketing,ou=People,dc=example,dc=com"

Optionally, instead of using the commands, you can add the operational attribute nsAccountLock to the entry. When an entry contains the nsAccountLock attribute with a value of true, the server rejects the bind.

7.2. Commands for displaying the status of an account or a role

You can display the status of an account or a role in Directory Server using the corresponding commands in the command line.

Commands for displaying the status

  • Display the status of an account: 

    # dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" account entry-status "uid=user_name,ou=People,dc=example,dc=com"
Entry DN: uid=user_name,ou=People,dc=example,dc=com
Entry Creation Date: 20210813085535Z (2021-08-13 08:55:35)
Entry Modification Date: 20210813085535Z (2021-08-13 08:55:35)
Entry State: activated

    Optional: The -V option displays additional details.

    Example 7.1. Detailed output for an active account

    # dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" account entry-status "uid=user_name,ou=People,dc=example,dc=com" -V
Entry DN: uid=user_name,ou=People,dc=example,dc=com
Entry Creation Date: 20210824160645Z (2021-08-24 16:06:45)
Entry Modification Date: 20210824160645Z (2021-08-24 16:06:45)
Entry Last Login Date: 20210824160645Z (2021-08-24 16:06:45)
Entry Time Until Inactive: 2 seconds (2021-08-24 16:07:45)
Entry State: activated

    Example 7.2. Detailed output for an inactive account

    # dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" account entry-status "uid=user_name,ou=People,dc=example,dc=com" -V
Entry DN: uid=user_name,ou=People,dc=example,dc=com
Entry Creation Date: 20210824160645Z (2021-08-24 16:06:45)
Entry Modification Date: 20210824160645Z (2021-08-24 16:06:45)
Entry Last Login Date: 20210824160645Z (2021-08-24 16:06:45)
Entry Time Since Inactive: 3 seconds (2021-08-24 16:07:45)
Entry State: inactivity limit exceeded

  • Display the status of a role: 

    # dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" role entry-status "cn=Marketing,ou=People,dc=example,dc=com"
Entry DN: cn=Marketing,ou=people,dc=example,dc=com
Entry State: activated

  • Display the status of a sub-tree: 

    # dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" account subtree-status "ou=People,dc=example,dc=com" -f "(uid=*)" -V -o "2021-08-25T14:30:30"

    To filter the results of the search in a sub-tree, you can use:

    • The -f option to set the search filter
    • The -s option to set the search scope
    • The -i option to return only inactive accounts
    • The -o option to return only accounts which will be inactive before the specified date YYYY-MM-DDTHH:MM:SS

Chapter 8. Synchronizing account lockout attributes across all servers in a replication environment

Directory Server stores account lockout attributes locally. In an environment with multiple servers, configure replication for these attributes to prevent attackers from attempting to log in to one server until the account lockout count is reached and then continue on other servers.

8.1. How Directory Server handles password and account lockout policies in a replication environment

Directory Server enforces password and account lockout policies as follows:

  • Password policies are enforced on the data supplier
  • Account lockout policies are enforced on all servers in a replication topology

Directory Server replicates the following password policy attributes:

  • passwordMinAge
  • passwordMaxAge
  • passwordExp
  • passwordWarning

However, by default, Directory Server does not replicate the general account lockout attributes:

  • passwordRetryCount
  • retryCountResetTime
  • accountUnlockTime

To prevent attackers from attempting to log in to one server until the account lockout count is reached and then continue on other servers, replicate these account lockout attributes.

Additional resources

8.2. Configuring Directory Server to replicate account lockout attributes

If you use an account lockout policy or password policy that updates the passwordRetryCount, retryCountResetTime, or accountUnlockTime attributes, configure Directory Server to replicate these attributes so that their values are the same across all servers.

Perform this procedure on all suppliers in the replication topology.

Prerequisites

  • You configured an account lockout policy or a password policy that updates one or more of the mentioned attributes.
  • You use Directory Server in a replication environment.

Procedure

  1. Enable replication of password policy attributes: 

    # dsconf -D "cn=Directory Manager" ldap://server.example.com pwpolicy set --pwdisglobal="on"

  2. If you use fractional replication, display the list of attributes that are excluded from replication: 

    # dsconf -D "cn=Directory Manager" ldap://server.example.com repl-agmt get --suffix "dc=example,dc=com" example-agreement | grep "nsDS5ReplicatedAttributeList"

    Using the default settings, no output is shown, and Directory Server replicates the account lockout attributes. However, if the command returns a list of excluded attributes, such as in the following example, verify the attribute list: 

    nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE accountUnlockTime passwordRetryCount retryCountResetTime example1 example2

    In this example, the accountUnlockTime, passwordRetryCount, and retryCountResetTime lockout policy attributes are excluded from replication, along with two other attributes.

  3. If the output of the previous command lists any of the account lockout attributes, update the fractional replication settings to only include attributes other than the lockout policy attributes: 

    # dsconf -D "cn=Directory Manager" ldap://server.example.com repl-agmt set --suffix "dc=example,dc=com" --frac-list "example1 example2" example-agreement

Verification

  1. Attempt to perform a search as a user using an invalid password: 

    # ldapsearch -H ldap://server.example.com -D "uid=example,ou=People,dc=example,dc=com" -w "invalid-password" -b "dc=example,dc=com" -x
ldap_bind: Invalid credentials (49)

  2. Display the passwordRetryCount attribute of the user: 

    # ldapsearch -H ldap://server.example.com -D "cn=Directory Manager" -W -b "uid=example,ou=People,dc=example,dc=com" -x passwordRetryCount
...
dn: uid=example,ou=People,dc=example,dc=com
passwordRetryCount: 1
  3. Run the previous command on a different server in the replication topology. If the value of the passwordRetryCount attribute is the same, Directory Server replicated the attribute.

Additional resources

Chapter 9. Using Referential Integrity to maintain relationships between entries

Referential Integrity is a database mechanism that ensures that Directory Server maintains relationship between related entries. You can use this feature to ensure that an update to one entry in the directory is correctly reflected in other entries that reference the updated entry.

For example, if you remove a user from the directory and the Referential Integrity plug-in is enabled, the server also removes the user from any group in which the user is a member. If the plug-in is not enabled, the user remains a member of the group until an administrator manually removes it.

Referential Integrity is an important feature if you integrate Directory Server with other products that rely on Directory Server for user and group management.

9.1. How the Referential Integrity plug-in works

When you enable the Referential Integrity plug-in, it performs integrity updates on the member, uniqueMember, owner, and seeAlso attributes, by default, immediately after an operation.

For example, if an administrator deletes, updates, renames, or moves a group or user within the directory, Directory Server logs the operation in the Referential Integrity log file. Directory Server then uses the distinguished name (DN) from this log file and searches entries matching the attribute specified in the plug-in’s configuration, and then updates the matching entries. For example, after deleting the cn=demo,dc=example,dc=com entry the plug-in searches for entries with the member attribute set to cn=demo,dc=example,dc=com and removes these member attributes. Afterwards, the plug-in does the same for the uniqueMember, owner, and seeAlso attributes.

By default, Directory Server does searches and updates in the same transaction as the original operation. Because search and update operations can take a lot of time, it is possible to delay them after the completion of the original operation. You can use the --update-delay option of the dsconf plugin referential-integrity set command to separate the original operations from integrity updates.

To avoid poor performance of modify and delete operations, index the attributes you specify in the Referential Integrity plug-in configuration.

Additional resources

9.2. Configuring the Referential Integrity plug-in using the command line

You can use the command line to configure the Referential Integrity plug-in.

Perform this procedure on every supplier in a replication topology.

Procedure

  1. Enable the Referential Integrity plug-in: 

    # dsconf -D "cn=Directory Manager" ldap://server.example.com plugin referential-integrity enable

  2. Set the subtree in which the plug-in searches for delete or rename operations of user entries: 

    # dsconf -D "cn=Directory Manager" ldap://server.example.com plugin referential-integrity set --entry-scope "ou=People,dc=example,dc=com"

  3. Optional: Exclude a subtree under the entry scope: 

    # dsconf -D "cn=Directory Manager" ldap://server.example.com plugin referential-integrity set --exclude-entry-scope "ou=Special Users,ou=People,dc=example,dc=com"

    This command configures the plug-in to ignore delete or rename operations performed in the ou=Special Users,ou=People,dc=example,dc=com subtree.

  4. Configure the subtree in which the plug-in updates group entries: 

    # dsconf -D "cn=Directory Manager" ldap://server.example.com plugin referential-integrity set --container-scope "ou=Groups,dc=example,dc=com"

  5. By default, the plug-in performs integrity updates on the member, uniqueMember, owner, and seeAlso attributes. To specify other attributes, enter: 

    # dsconf -D "cn=Directory Manager" ldap://server.example.com plugin referential-integrity set --membership-attr attribute_1 attribute_2

    Note that this command overrides the list of attributes in the plug-in’s configuration. If you want to add an attribute, pass the current list of attributes and the additional one to the --membership-attr option.

  6. Optional: By default, Directory Server performs referential integrity checks immediately. If you want to set a delay, enter: 

    # dsconf -D "cn=Directory Manager" ldap://server.example.com plugin referential-integrity set --update-delay=5

    This command delays the referential integrity checks by 5 seconds. Note that, if you enabled the Referential Integrity on multiple suppliers, setting a delay can cause replication loops and directory inconsistencies. To avoid such problems, enable the plug-in only on one supplier in the topology.

  7. Restart the instance: 

    # dsctl instance_name restart

Verification

  1. Display the Referential Integrity plug-in configuration: 

    # dsconf -D "cn=Directory Manager" ldap://server.example.com plugin referential-integrity show
...
nsslapd-plugincontainerscope: ou=Groups,dc=example,dc=com
nsslapd-pluginentryscope: ou=People,dc=example,dc=com
...
referint-membership-attr: member
referint-membership-attr: uniquemember
referint-membership-attr: owner
referint-membership-attr: seeAlso
referint-update-delay: 0
...

  2. List the members of a group by displaying the member attributes of the groups: 

    # ldapsearch -D "cn=Directory Manager" -W -H ldap://server.example.com -b "cn=demoGroup,ou=Groups,dc=example,dc=com" member
...
member: uid=demoUser,ou=People,dc=example,dc=com

  3. Delete the uid=demoUser,ou=People,dc=example,dc=com user: 

    # dsidm -D "cn=Directory manager" ldap://server.example.com -b "dc=example,dc=com" user delete "uid=demoUser,ou=People,dc=example,dc=com"

  4. Display the members of the group again: 

    # ldapsearch -D "cn=Directory Manager" -W -H ldap://server.example.com -b "cn=demoGroup,ou=People,dc=example,dc=com" member

    If uid=demoUser,ou=People,dc=example,dc=com is no longer listed as a member of the group, the Referential Integrity plug-in works.

9.3. Configuring the Referential Integrity plug-in using the web console

You can use the Directory Server web console to configure the Referential Integrity plug-in.

Perform this procedure on every supplier in a replication topology.

Prerequisites

  • You are logged in to the instance in the web console.

Procedure

  1. Navigate to Plugins → Referential Integrity.
  2. Enable the plug-in.
  3. Click Actions → Restart Instance.
  4. Navigate again to Plugins → Referential Integrity.
  5. By default, the plug-in performs integrity updates on the member, uniqueMember, owner, and seeAlso attributes. To specify other attributes, update the list in the Membership Attribute field.
  6. Set the Entry Scope field to the DN of the subtree in which the plug-in should search for delete or rename operations of user entries.
  7. Optional: To exclude a subtree under the entry scope, enter the DN of the subtree in the Exclude Entry Scope field.
  8. Set the Container Scope field to the DN of the subtree in which the plug-in should update group entries.
  9. Optional: Update the path to the Referential Integrity log file. Directory Server uses this file to track changes in the directory. Note that the dirsrv user must have write permissions to this location.

  10. Optional: By default, Directory Server performs referential integrity checks immediately. If you want to set a delay, set it in the Update Delay field.

    Note that, if you enabled the Referential Integrity on multiple suppliers, setting a delay can cause replication loops and directory inconsistencies. To avoid such problems, enable the plug-in only on one supplier in the topology.

  11. Click Save Config.

Verification

  1. List the members of a group by displaying the member attributes of the groups: 

    # ldapsearch -D "cn=Directory Manager" -W -H ldap://server.example.com -b "cn=demoGroup,ou=Groups,dc=example,dc=com" member
...
member: uid=demoUser,ou=People,dc=example,dc=com

  2. Delete the uid=demoUser,ou=People,dc=example,dc=com user: 

    # dsidm -D "cn=Directory manager" ldap://server.example.com -b "dc=example,dc=com" user delete "uid=demoUser,ou=People,dc=example,dc=com"

  3. Display the members of the group again: 

    # ldapsearch -D "cn=Directory Manager" -W -H ldap://server.example.com -b "cn=demoGroup,ou=People,dc=example,dc=com" member

    If uid=demoUser,ou=People,dc=example,dc=com is no longer listed as a member of the group, the Referential Integrity plug-in works.

Chapter 10. Using roles in Directory Server

You can group Directory Server entries by using roles. Roles behave as both a static and a dynamic group. Roles are easier to use than groups because they are more flexible in their implementation. For example, an application can get the list of roles to which an entry belongs by querying the entry itself rather than selecting a group and browsing the members list of several groups.

You can manage roles by using the command line or the web console.

10.1. Roles in Directory Server

A role behaves as both a static and a dynamic group, similarly to a hybrid group:

  • With a group, Directory Server adds entries to the group entry as members.
  • With a role, Directory Server adds the role attribute to the entry and then uses this attribute to automatically identify members in the role entry.

Role members are entries that possess the role. You can specify members of the role explicitly or dynamically depending on the role type. Directory Server supports the following types of roles:

  • Managed roles

    Managed roles have an explicit list of members. You can use managed roles to perform the same tasks that you perform with static groups.

  • Filtered roles

    You can filter the role members by using filtered roles, similarly to filtering with dynamic groups. Directory Server assigns entries to a filtered role depending on whether the entry possesses a specific attribute defined in the role.

  • Nested roles

    Nested roles can contain managed and filtered roles.

When you create a role, determine if users can add or remove themselves from the role. For more details, see Section 10.2, “Using roles securely in Directory Server”.

Note

Evaluating roles is more resource-intensive for the Directory Server than evaluating groups because the server does the work for the client application. With roles, the client application can check role membership by searching for the nsRole attribute. The nsRole attribute is a computed attribute that identifies which roles an entry belongs to. Directory Server does not store the nsRole attribute. From the client application point of view, the method for checking membership is uniform and is performed on the server side.

Find considerations for using roles in [Deciding between groups and roles] in the Planning and designing a directory service. documentation.

10.2. Using roles securely in Directory Server

When creating a new role, consider if users can easily add or remove themselves from a role. For example, you can allow users of the Mountain Biking interest group role to add or remove themselves easily. However, you must not allow users who are assigned the Marketing role to add or remove themselves from the role.

One potential security risk is inactivating user accounts by inactivating roles. Inactive roles have special access control instructions (ACIs) defined for their suffix. If an administrator allows users to add and remove themselves from roles freely, these users can remove themselves from an inactive role to unlock their accounts.

For example, a user is assigned a managed role. When Directory Server locks this managed role by using account inactivation, the user can not bind to the server because Directory Server computes the nsAccountLock attribute as true for that user. However, if the user was already bound to Directory Server and now is locked through the managed role, the user can remove the nsRoleDN attribute from his entry and unlock himself if no restricting ACIs are specified.

To prevent users from removing the nsRoleDN attribute, use the following ACIs depending on the type of role:

  • Managed roles. For entries that are members of a managed role, use the following ACI: 

    aci: (targetattr="nsRoleDN")
(targattrfilters= add=nsRoleDN:(!(nsRoleDN=cn=AdministratorRole,dc=example,dc=com)), del=nsRoleDN:(!(nsRoleDN=cn=nsManagedDisabledRole,dc=example,dc=com)))
(version3.0;acl "allow mod of nsRoleDN by self but not to critical values"; allow(write) userdn=ldap:///self;)
  • Filtered roles. Protect attributes that are part of the filter (nsRoleFilter). Do not allow a user to add, delete, or modify the attribute that the filtered role uses. If Directory Server computes the value of the filter attribute, then you must protect all attributes that can modify this filter attribute value.
  • Nested roles. A nested role can contain filtered and managed roles. Thus, you must restrict modify operations in ACIs for each attribute of the roles that the nested role contains.

Additional resources

10.3. Managing roles in Directory Server by using the command line

You can view, create, and delete roles by using the command line.

10.3.1. Creating a managed role in Directory Server

Managed roles are roles that have an explicit enumerated list of members. You can use the ldapmodify utility to create a managed role. The following example creates a managed role for a marketing team.

Prerequisites

  • The ou=people,dc=example,dc=com parent entry exists in Directory Server.
  • The cn=Bob Jones,ou=people,dc=example,dc=com user entry exists in Directory Server.

Procedure

  1. Create the cn=Marketing managed role entry by using the ldapmodify command with the -a option: 

    # ldapmodify -a -D "cn=Directory Manager" -W -H ldap://server.example.com -x << EOF
dn: cn=Marketing,ou=people,dc=example,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: nsRoleDefinition
objectclass: nsSimpleRoleDefinition
objectclass: nsManagedRoleDefinition
cn: Marketing
description: managed role for the marketing team
EOF

    The managed role entry must contain the following object classes:

    • LDAPsubentry
    • nsRoleDefinition
    • nsSimpleRoleDefinition
    • nsManagedRoleDefinition

  2. Assign the cn=Marketing,ou=people,dc=example,dc=com managed role to the cn=Bob Jones,ou=people,dc=example,dc=com user entry by adding the nsRoleDN attribute to this user entry: 

    # ldapmodify -D "cn=Directory Manager" -W -H ldap://server.example.com -x << EOF
dn: cn=Bob Jones,ou=people,dc=example,dc=com
changetype: modify
add: nsRoleDN
nsRoleDN: cn=Marketing,ou=people,dc=example,dc=com
EOF

modifying entry "cn=Bob Jones,ou=people,dc=example,dc=com"

  3. Optional: Configure the equality index for the nsRoleDN attribute in the userRoot database to avoid unindexed searches: 

    #  dsconf -D "cn=Directory Manager" ldap://server.example.com backend index add --index-type eq --attr nsroleDN --reindex userRoot

Verification

  • List user entries that now belong to the cn=Marketing,ou=people,dc=example,dc=com managed role: 

    # ldapsearch -D "cn=Directory Manager" -W -H ldap://server.example.com -x -b "dc=example,dc=com" "(nsRole=cn=Marketing,ou=people,dc=example,dc=com)" dn 

dn: cn=Bob Jones,ou=people,dc=example,dc=com

dn: cn=Tom Devis,ou=people,dc=example,dc=com

Additional resources

10.3.2. Creating a filtered role in Directory Server

Directory Server assigns entries to a filtered role if the entries have a specific attribute defined in the role. The role definition specifies the nsRoleFilter LDAP filter. Entries that match the filter are members of the role.

You can use ldapmodify utility to create a filtered role. The following example creates a filtered role for sales department managers.

Prerequisites

  • The ou=people,dc=example,dc=com parent entry exists in Directory Server.

Procedure

  1. Create the cn=SalesManagerFilter filtered role entry by using the ldapmodify command with the -a option: 

    # ldapmodify -a -D "cn=Directory Manager" -W -H ldap://server.example.com -x << EOF
dn: cn=SalesManagerFilter,ou=people,dc=example,dc=com
changetype: add
objectclass: top
objectclass: LDAPsubentry
objectclass: nsRoleDefinition
objectclass: nsComplexRoleDefinition
objectclass: nsFilteredRoleDefinition
cn: SalesManagerFilter
nsRoleFilter: o=sales managers
Description: filtered role for sales managers
EOF

    The cn=SalesManagerFilter filtered role entry has the o=sales managers filter for the role. All user entries that have the o attribute with the value of sales managers are members of the filtered role.

    Example of the user entry that is now a member of the filtered role: 

    dn: cn=Pat Smith,ou=people,dc=example,dc=com
objectclass: person
cn: Pat
sn: Smith
userPassword: password
o: sales managers

    The filtered role entry must have the following object classes:

    • LDAPsubentry
    • nsRoleDefinition
    • nsComplexRoleDefinition
    • nsFilteredRoleDefinition

  2. Optional: Configure the equality index for the attribute that you use in the nsRoleFilter role filter to avoid unindexed searches. In the given example, the role uses o=sales managers as the filter. Therefore, index the o attribute to improve the search performance: 

    #  dsconf -D "cn=Directory Manager" ldap://server.example.com backend index add --index-type eq --attr o --reindex userRoot

Verification

  • List user entries that now belong to the cn=SalesManagerFilter,ou=people,dc=example,dc=com filtered role: 

    # ldapsearch -D "cn=Directory Manager" -W -H ldap://server.example.com -x -b "dc=example,dc=com" "(nsRole=cn=SalesManagerFilter,ou=people,dc=example,dc=com)" dn 

dn: cn=Jess Mor,ou=people,dc=example,dc=com

dn: cn=Pat Smith,ou=people,dc=example,dc=com

Additional resources

10.3.3. Creating a nested role in Directory Server

Nested roles can contain managed and filtered roles. A nested role entry requires the nsRoleDN attribute to identify the roles to nest.

You can use ldapmodify utility to create a nested role. The following example creates a nested role that contains the managed and the filtered roles you created in Creating a managed role in Directory Server and Creating a filtered role in Directory Server.

Prerequisites

  • The ou=people,dc=example,dc=com parent entry exists in Directory Server.

Procedure

  1. Create the cn=MarketingSales nested role entry that contains the cn=SalesManagerFilter filtered role and the cn=Marketing managed role by using the ldapmodify command with the -a option: 

    # ldapmodify -a -D "cn=Directory Manager" -W -H ldap://server.example.com -x << EOF
dn: cn=MarketingSales,ou=people,dc=example,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: nsRoleDefinition
objectclass: nsComplexRoleDefinition
objectclass: nsNestedRoleDefinition
cn: MarketingSales
nsRoleDN: cn=SalesManagerFilter,ou=people,dc=example,dc=com
nsRoleDN: cn=Marketing,ou=people,dc=example,dc=com
EOF

    Optionally, the role can have the description attribute.

    The nested role entry must have the following object classes:

    • LDAPsubentry
    • nsRoleDefinition
    • nsComplexRoleDefinition
    • nsNestedRoleDefinition

Verification

  • List user entries that now belong to the cn=MarketingSales nested role: 

    # ldapsearch -D "cn=Directory Manager" -W -H ldap://server.example.com -x -b "dc=example,dc=com" "(nsRole=cn=MarketingSales,ou=people,dc=example,dc=com)" dn 

dn: cn=Bob Jones,ou=people,dc=example,dc=com
dn: cn=Pat Smith,ou=people,dc=example,dc=com
dn: cn=Jess Mor,ou=people,dc=example,dc=com
dn: cn=Tom Devis,ou=people,dc=example,dc=com

Additional resources

10.3.4. Viewing roles for an entry

To view roles for an entry, use the ldapsearch command with explicitly specified nsRole virtual attribute.

Prerequisites

  • Roles entry exists.
  • You assigned roles to the uid=user_name user entry.

Procedure

  • Search for the uid=user_name entry with specified nsRole virtual attribute: 

    # ldapsearch -D "cn=Directory Manager" -W -H ldap://server.example.com -b "dc=example,dc=com" -s sub -x "(uid=user_name)" nsRole

dn: uid=user_name,ou=people,dc=example,dc=com
...
nsRole: cn=Role for Managers,dc=example,dc=com
nsRole: cn=Role for Accounting,dc=example,dc=com

    The command retrieves all roles which the uid=user_name user is a member of.

10.3.5. Deleting roles in Directory Server

To delete a role in Directory Server, you can use ldapmodify command.

The following is an example of deleting the cn=Marketing managed role from Directory Server.

Procedure

  • To delete the cn=Marketing managed role entry, enter: 

    # ldapmodify -D "cn=Directory Manager" -W -H ldap://server.example.com -x << EOF
dn: cn=Marketing,ou=People,dc=example,dc=com
changetype: delete
EOF

deleting entry "cn=Marketing,ou=People,dc=example,dc=com"
    Note

    When you delete a role, Directory Server deletes only the role entry and does not delete the nsRoleDN attribute for each role member. To delete the nsRoleDN attribute for each role member, enable the Referential Integrity plug-in and configure this plug-in to manage the nsRoleDN attribute.

    For more information about the Referential Integrity plug-in, see Using Referential Integrity to maintain relationships between entries.

Additional resources

10.4. Managing roles in Directory Server by using the web console

You can view, create, and delete roles by using LDAP browser in the web console.

10.4.1. Creating a role in the LDAP Browser

You can create a role for a Red Hat Directory Server entry by using the LDAP Browser wizard in the web console.

Prerequisites

  • Access to the web console.
  • A parent entry exists in Directory Server.

Procedure

  1. Log in to the web console and click Red Hat Directory Server.
  2. After the web console loads the Red Hat Directory Server interface, open the LDAP Browser.
  3. Select an LDAP entry and open the Options menu.
  4. From the drop-down menu select New and click Create a new role.
  5. Follow the steps in the wizard and click the Next button after you complete each step.
  6. To create the role, review the role settings in the Create Role step and click the Create button. You can click the Back button to modify the role settings or click the Cancel button to cancel the role creation.
  7. To close the wizard window, click the Finish button.

Verification

  • Expand the LDAP entry and verify the new role appears among the entry parameters.

10.4.2. Deleting a role in the LDAP browser

You can delete the role from the Red Hat Directory Server entry by using the LDAP Browser in the web console.

Prerequisites

  • Access to the web console.
  • A parent entry exists in Directory Server.

Procedure

  1. Log in to the web console and click Red Hat Directory Server.
  2. After the web console loads the Red Hat Directory Server interface, click LDAP browser.
  3. Expand the LDAP entry select the role which you want to delete.
  4. Open the Options menu and select Delete.
  5. Verify the data about the role you want to delete and click the Next button until you reach the Deletion step.
  6. Toggle the switch to the Yes, I’m sure position and click the Delete button.
  7. To close the wizard window, click the Finish button.

Verification

  • Expand the LDAP entry and verify the role is no longer a part of the entry parameters.

10.4.3. Modifying a role in the LDAP browser

You can modify the role parameters for a Red Hat Directory Server entry by using the LDAP Browser in the web console.

Prerequisites

  • Access to the web console.
  • A parent entry exists in the Red Hat Directory Server.

Procedure

  1. Log in to the web console and click Red Hat Directory Server.
  2. After the web console loads the Red Hat Directory Server interface, click LDAP Browser.
  3. Expand the LDAP entry and select the role you are modifying.
  4. Click the Options menu and select Edit to modify the parameters of the role or Rename to rename the role.
  5. In the wizard window modify the necessary parameters and click Next after each step until you observe the LDIF Statements step.
  6. Check the updated parameters and click Modify Entry or Change Entry Name.
  7. To close the wizard window, click the Finish button.

Verification

  • Expand the LDAP entry and verify the updated parameters are listed for the role.

Legal Notice

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.