Chapter 3. Generic LDAP Integration

3.1. Key terms
Copiar o link

Authentication - The process of using a password to verify that the user is who they claim to be.
Authorization - Validating that authenticated users have proper permissions to the systems they’re attempting to access.
Domain - Refers to the additional back ends configured in Identity Service. For example, Identity Service can be configured to authenticate users from external LDAP environments. The resulting collection of users can be thought of as a domain.

3.2. Assumptions
Copiar o link

This example deployment makes the following assumptions:

Your LDAP server is configured and operational.
Red Hat OpenStack Platform is configured and operational.
DNS name resolution is fully functional and all hosts are registered appropriately.

Important

Multidomain Dashboard configuration is not supported in this version of Red Hat OpenStack Platform. As a result, this guide only describes Dashboard configuration for a single domain.

3.3. Impact Statement
Copiar o link

These steps allow LDAP users to authenticate to OpenStack and access resources. OpenStack service accounts (such as keystone and glance) and authorization management (permissions and roles) will remain in the Identity Service database. Permissions and roles are assigned to the LDAP accounts using Identity Service management tools.

3.3.1. High Availability options
Copiar o link

This configuration creates a dependency on the availability of a single LDAP server: Project users will be affected if Identity Service is unable to authenticate to the LDAP Server. There are a number of options available to manage this risk, for example: you might configure keystone to query a DNS alias or a load balancing appliance, rather than an individual LDAP server. You can also configure keystone to query a different LDAP server, should one become unavailable. See Section 3.11, “Configure for high availability” for more information.

3.4. Outage requirements
Copiar o link

The Identity Service will need to be restarted in order to add the LDAP back end.
The Compute services on all nodes will need to be restarted in order to switch over to keystone v3.
Users will be unable to access the dashboard until their accounts have been created in LDAP. To reduce downtime, consider pre-staging the LDAP accounts well in advance of this change.

3.5. Firewall configuration
Copiar o link

If firewalls are filtering traffic between LDAP and OpenStack, you will need to allow access through the following port:

Expand

Source	Destination	Type	Port
OpenStack Controller Node	LDAP server	LDAPS	TCP 636

3.6. Configure the LDAP server
Copiar o link

Perform the following steps on your LDAP server to prepare for Identity Service integration:

1. Create the LDAP lookup account.

This account is used by Identity Service to query the LDAP service. In addition to your standard password policy requirements, it will need the following attributes for this example deployment:

First name: OpenStack
Last name: LDAP
User name: svc-ldap

Note

Review the password expiration settings of this account, once created.

2. Create a LDAP group for OpenStack users, called grp-openstack. Only members of this group can have permissions assigned in OpenStack Identity.

3. Set the svc-ldap account password, and add it to the grp-openstack group.

3.7. Configure the LDAPS certificate
Copiar o link

1. In your LDAP environment, locate the LDAPS certificate. This file can be located using /etc/openldap/ldap.conf:

TLS_CACERT /etc/ipa/ca.crt

TLS_CACERT /etc/ipa/ca.crt

Copy to Clipboard

Toggle word wrap

2. Copy the file to the node running OpenStack Identity (keystone). For example, this command uses scp to copy ca.crt to the controller node named node.lab.local:

scp /etc/ipa/ca.crt root@node.lab.local:/root/

scp /etc/ipa/ca.crt root@node.lab.local:/root/

Copy to Clipboard

Toggle word wrap

3. On the controller node, convert the .crt to .pem:

openssl x509 -in ca.crt -out ca.pem -outform PEM

# openssl x509 -in ca.crt -out ca.pem -outform PEM

Copy to Clipboard

Toggle word wrap

4. Install the .pem on your OpenStack controller. For example, in Red Hat Enterprise Linux:

cp ca.pem /etc/pki/ca-trust/source/anchors/
update-ca-trust

# cp ca.pem /etc/pki/ca-trust/source/anchors/
# update-ca-trust

Copy to Clipboard

Toggle word wrap

5. Copy the .crt to the certificate directory:

cp ca.crt /etc/ssl/certs/

# cp ca.crt /etc/ssl/certs/

Copy to Clipboard

Toggle word wrap

3.8. Configure Identity Service
Copiar o link

These steps prepare Identity Service for integration with LDAP.

3.8.1. Enable command line access to keystone v3
Copiar o link

To manage Identity Service domains from the command line, you need to enable access to keystone v3.

Perform this procedure from the controller running the keystone service.

1. Create a copy of the existing environment variable file. In a director-based deployment, it will be called overcloudrc:

cp overcloudrc overcloudrc-v3

$ cp overcloudrc overcloudrc-v3

Copy to Clipboard

Toggle word wrap

2. Edit the new overcloudrc-v3 file:

Change OS_AUTH_URL from v2.0 to v3. For example:

export OS_AUTH_URL=https://controllerIP:5000/v3/

export OS_AUTH_URL=https://controllerIP:5000/v3/

Copy to Clipboard

Toggle word wrap

Add the following entries to the bottom of overcloudrc-v3:

export OS_IDENTITY_API_VERSION=3
export OS_PROJECT_DOMAIN_NAME=Default
export OS_USER_DOMAIN_NAME=Default

export OS_IDENTITY_API_VERSION=3
export OS_PROJECT_DOMAIN_NAME=Default
export OS_USER_DOMAIN_NAME=Default

Copy to Clipboard

Toggle word wrap

3. Enable these options for your current command line session by sourcing the file:

source overcloudrc-v3

$ source overcloudrc-v3

Copy to Clipboard

Toggle word wrap

3.8.2. Configure the controller
Copiar o link

Perform this procedure from the controller running the keystone service:

1. Configure SELinux:

setsebool -P authlogin_nsswitch_use_ldap=on

# setsebool -P authlogin_nsswitch_use_ldap=on

Copy to Clipboard

Toggle word wrap

2. Create the domains directory:

mkdir /etc/keystone/domains/
chown keystone /etc/keystone/domains/

# mkdir /etc/keystone/domains/
# chown keystone /etc/keystone/domains/

Copy to Clipboard

Toggle word wrap

3. Configure Identity Service to use multiple back ends:

Note

You might need to install crudini using yum install crudini.

crudini --set /etc/keystone/keystone.conf identity domain_specific_drivers_enabled true
crudini --set /etc/keystone/keystone.conf identity domain_config_dir /etc/keystone/domains
crudini --set /etc/keystone/keystone.conf assignment driver sql

# crudini --set /etc/keystone/keystone.conf identity domain_specific_drivers_enabled true
# crudini --set /etc/keystone/keystone.conf identity domain_config_dir /etc/keystone/domains
# crudini --set /etc/keystone/keystone.conf assignment driver sql

Copy to Clipboard

Toggle word wrap

Note

If you are using Red Hat OpenStack Platform director, then you will need to be aware that /etc/keystone/keystone.conf is managed by Puppet. Consequently, any custom configuration you add might be overwritten whenever you run the openstack overcloud deploy process. As a result, you might need to re-add this configuration manually each time. It is expected that a future release of director will include the Puppet parameters that will allow you to re-apply these settings automatically using a post-deployment script.

4. Configure an additional back end:

a. Create the keystone domain for LDAP integration. You will need to decide on a name to use for your new keystone domain, and then create the domain. For example, this command creates a keystone domain named LAB:

openstack domain create LAB

# openstack domain create LAB

Copy to Clipboard

Toggle word wrap

Note

If this command is not available, check that you have enabled keystone v3 for your command line session.

b. Create the configuration file:

To add the LDAP back end, enter the LDAP settings in a new file called /etc/keystone/domains/keystone.LAB.conf (where LAB is the domain name created previously). You will need to edit the sample settings below to suit your LDAP deployment:

[ldap]
url =  ldaps://ldap.lab.local
user = uid=svc-ldap,cn=users,cn=accounts,dc=lab,dc=local
user_filter = (memberOf=cn=grp-openstack,cn=groups,cn=accounts,dc=lab,dc=local)
password = RedactedComplexPassword
user_tree_dn = cn=users,cn=accounts,dc=lab,dc=local
user_objectclass = inetUser
user_id_attribute = uid
user_name_attribute = uid
user_mail_attribute = mail
user_pass_attribute =
user_allow_create = False
user_allow_update = False
user_allow_delete = False
tls_cacertfile = /etc/ssl/certs/ca.crt

[identity]
driver = keystone.identity.backends.ldap.Identity

[ldap]
url =  ldaps://ldap.lab.local
user = uid=svc-ldap,cn=users,cn=accounts,dc=lab,dc=local
user_filter = (memberOf=cn=grp-openstack,cn=groups,cn=accounts,dc=lab,dc=local)
password = RedactedComplexPassword
user_tree_dn = cn=users,cn=accounts,dc=lab,dc=local
user_objectclass = inetUser
user_id_attribute = uid
user_name_attribute = uid
user_mail_attribute = mail
user_pass_attribute =
user_allow_create = False
user_allow_update = False
user_allow_delete = False
tls_cacertfile = /etc/ssl/certs/ca.crt

[identity]
driver = keystone.identity.backends.ldap.Identity

Copy to Clipboard

Toggle word wrap

Explanation of each setting:

Expand

Setting	Description
`url`	The LDAP server to use for authentication. Uses LDAPS port `636`.
`user`	The account in LDAP to use for LDAP queries.
`password`	The plaintext password of the LDAP account used above.
`user_filter`	Filters the users presented to Identity Service. As a result, only members of the grp-openstack group can have permissions defined in Identity Service.
`user_tree_dn`	The path to the OpenStack accounts in LDAP.
`user_objectclass`	Defines the type of LDAP user. For LDAP, use the `inetUser` type.
`user_id_attribute`	Maps the LDAP value to use for user IDs.
`user_name_attribute`	Maps the LDAP value to use for names.
`user_mail_attribute`	Maps the LDAP value to use for user email addresses.
`user_pass_attribute`	Leave this value blank.
`user_allow_create`	Set this value to `False`, as keystone only requires read-only access.
`user_allow_update`	Set this value to `False`, as keystone only requires read-only access.
`user_allow_delete`	Set this value to `False`, as keystone only requires read-only access.

5. Change ownership of the config file to the keystone user:

chown keystone /etc/keystone/domains/keystone.LAB.conf

# chown keystone /etc/keystone/domains/keystone.LAB.conf

Copy to Clipboard

Toggle word wrap

6. Grant the admin user access to the domain:

Note

This does not grant the OpenStack admin account any permissions in LDAP. In this case, the term domain refers to OpenStack’s usage of the keystone domain.

a. Get the ID of the LAB domain:

openstack domain show LAB

# openstack domain show LAB
+---------+----------------------------------+
| Field   | Value                            |
+---------+----------------------------------+
| enabled | True                             |
| id      | 6800b0496429431ab1c4efbb3fe810d4 |
| name    | LAB                              |
+---------+----------------------------------+

Copy to Clipboard

Toggle word wrap

b. Get the ID value of the admin user:

openstack user list --domain default | grep admin

# openstack user list --domain default | grep admin

| 3d75388d351846c6a880e53b2508172a | admin      |

Copy to Clipboard

Toggle word wrap

c. Get the ID value of the admin role:

openstack role list

# openstack role list
+----------------------------------+---------------+
| ID                               | Name          |
+----------------------------------+---------------+
| 544d48aaffde48f1b3c31a52c35f01f9 | SwiftOperator |
| 6d005d783bf0436e882c55c62457d33d | ResellerAdmin |
| 785c70b150ee4c778fe4de088070b4cf | admin         |
| 9fe2ff9ee4384b1894a90878d3e92bab | _member_      |
+----------------------------------+---------------+

Copy to Clipboard

Toggle word wrap

d. Use the returned domain and admin IDs to construct the command that adds the admin user to the admin role of the keystone LAB domain:

openstack role add --domain 6800b0496429431ab1c4efbb3fe810d4 --user 3d75388d351846c6a880e53b2508172a 785c70b150ee4c778fe4de088070b4cf

# openstack role add --domain 6800b0496429431ab1c4efbb3fe810d4 --user 3d75388d351846c6a880e53b2508172a 785c70b150ee4c778fe4de088070b4cf

Copy to Clipboard

Toggle word wrap

7. Configure the dashboard to use the LAB keystone domain at the login page. Add these lines to /etc/openstack-dashboard/local_settings:

Important

Multidomain Dashboard configuration is not supported in this version of Red Hat OpenStack Platform. As a result, this guide only describes Dashboard configuration for a single domain.

OPENSTACK_API_VERSIONS = {
    "identity": 3
}
OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = 'LAB'

OPENSTACK_API_VERSIONS = {
    "identity": 3
}
OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = 'LAB'

Copy to Clipboard

Toggle word wrap

Note

If you are using Red Hat OpenStack Platform director, then you will need to be aware that /etc/openstack-dashboard/local_settings is managed by Puppet. Consequently, any custom configuration you add might be overwritten whenever you run the openstack overcloud deploy process. As a result, you might need to re-add this configuration manually each time. It is expected that a future release of director will include the Puppet parameters that will allow you to re-apply these settings automatically using a post-deployment script.

8. Restart the httpd service to apply the changes:

systemctl restart httpd.service

# systemctl restart httpd.service

Copy to Clipboard

Toggle word wrap

9. View the list of users in the LDAP domain by adding the keystone domain name to the command:

openstack user list --domain LAB

# openstack user list --domain LAB

Copy to Clipboard

Toggle word wrap

10. View the service accounts in the local keystone database:

openstack user list --domain default

# openstack user list --domain default

Copy to Clipboard

Toggle word wrap

3.8.3. Configure Compute to use keystone v3
Copiar o link

Compute uses keystone v2.0 by default, and so needs to be configured to use keystone v3 in order to use multi-domain capabilities.

1. On each Compute node, and the controller, adjust the keystone_authtoken value:

crudini --set /etc/nova/nova.conf keystone_authtoken auth_version v3

# crudini --set /etc/nova/nova.conf keystone_authtoken auth_version v3

Copy to Clipboard

Toggle word wrap

2. Restart these services on the controller to apply the changes:

systemctl restart openstack-nova-api.service openstack-nova-cert.service openstack-nova-conductor.service openstack-nova-consoleauth.service openstack-nova-novncproxy.service openstack-nova-scheduler.service

# systemctl restart openstack-nova-api.service openstack-nova-cert.service openstack-nova-conductor.service openstack-nova-consoleauth.service openstack-nova-novncproxy.service openstack-nova-scheduler.service

Copy to Clipboard

Toggle word wrap

3. Restart this service on each Compute node to apply the changes:

systemctl restart openstack-nova-compute.service

# systemctl restart openstack-nova-compute.service

Copy to Clipboard

Toggle word wrap

3.8.4. Configure Block Storage to use keystone v3
Copiar o link

You must also configure Block Storage (cinder) to authenticate to keystone v3.

In /etc/cinder/cinder.conf:
```
[keystone_authtoken]
auth_uri = https://controllerIP:5000/v3
auth_version = v3
```
```
[keystone_authtoken]
auth_uri = https://controllerIP:5000/v3
auth_version = v3
```
Copy to Clipboard Toggle word wrap
- auth_uri - replace controllerIP with the IP address of the controller. If your deployment has more than one controller, you should use the keystone endpoint VIP instead of the controller IP.

3.8.5. Allow LDAP users to access Projects
Copiar o link

LDAP users that are members of the grp-openstack LDAP group can be granted permission to log in to a project in the dashboard:

1. Retrieve a list of LDAP users:

openstack user list --domain LAB

# openstack user list --domain LAB
 +------------------------------------------------------------------+----------------+
| ID                                                               | Name           |
+------------------------------------------------------------------+----------------+
| 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e | user1          |
| 12c062fLDAP5f8b065434d9ff6fce03eb9259537c93b411224588686e9a38bf1 | user2          |
| afaf48031eb54c3e44e4cb0353f5b612084033ff70f63c22873d181fdae2e73c | user3          |
| e47fc21dcf0d9716d2663766023e2d8dc15a6d9b01453854a898cabb2396826e | user4          |
+------------------------------------------------------------------+----------------+

Copy to Clipboard

Toggle word wrap

2. Retrieve a list of roles:

openstack role list

# openstack role list
+----------------------------------+---------------+
| ID                               | Name          |
+----------------------------------+---------------+
| 544d48aaffde48f1b3c31a52c35f01f9 | SwiftOperator |
| 6d005d783bf0436e882c55c62457d33d | ResellerAdmin |
| 785c70b150ee4c778fe4de088070b4cf | admin         |
| 9fe2ff9ee4384b1894a90878d3e92bab | _member_      |
+----------------------------------+---------------+

Copy to Clipboard

Toggle word wrap

3. Grant users access to Projects by adding them to one or more of these roles. For example, if you want user1 to be a general user of the demo project, you add them to the _member_ role:

openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e _member_

# openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e _member_

Copy to Clipboard

Toggle word wrap

Or, if you want user1 to be an administrative user of the demo project, you add them to the admin role:

openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e admin

# openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e admin

Copy to Clipboard

Toggle word wrap

As a result, user1 is able to log in to the dashboard by entering their LDAP username and password.

Note

If users receive the error "Error: Unable to retrieve container list.", and expect to be able to manage containers, then they must be added to the SwiftOperator role.

3.9. Grant access to the Domain tab
Copiar o link

To allow the admin user to see the Domain tab, you will need to assign it the admin role in the default domain:

Find the admin user’s UUID:

openstack user list | grep admin

$ openstack user list | grep admin
| a6a8adb6356f4a879f079485dad1321b | admin      |

Copy to Clipboard

Toggle word wrap

Add the admin role in the default domain to the admin user:

openstack role add --domain default --user a6a8adb6356f4a879f079485dad1321b admin

$ openstack role add --domain default --user a6a8adb6356f4a879f079485dad1321b admin

Copy to Clipboard

Toggle word wrap

As a result, the admin user can now see the Domain tab.

3.10. Creating a new project
Copiar o link

After you have completed these integration steps, when you create a new project you will need to decide whether to create it in the Default domain, or in the keystone domain you’ve just created. This decision can be reached by considering your workflow, and how you administer user accounts. The Default domain can be be thought of as an internal domain, used for service accounts and the admin project, so it might make sense for your AD-backed users to be placed within a different keystone domain; this does not strictly need to be the same keystone domain as the LDAP users are in, and for separation purposes, there might be multiple keystone domains.

3.10.1. Changes to the command line
Copiar o link

For certain commands, you might need to specify the applicable domain. For example, appending --domain LAB in this command returns users in the LAB domain (that are members of the grp-openstack group):

openstack user list --domain LAB

# openstack user list --domain LAB

Copy to Clipboard

Toggle word wrap

Appending --domain Default returns the built-in keystone accounts:

openstack user list --domain Default

# openstack user list --domain Default

Copy to Clipboard

Toggle word wrap

3.10.2. Test LDAP integration
Copiar o link

This procedure validates LDAP integration by testing user access to dashboard features:

1. Create a test user in LDAP, and add the user to the grp-openstack LDAP group.

2. Add the user to the _member_ role of the demo tenant.

3. Log in to the dashboard using the credentials of the LDAP test user.

4. Click on each of the tabs to confirm that they are presented successfully without error messages.

5. Use the dashboard to build a test instance.

Note

If you experience issues with these steps, perform steps 3-5 with the built-in admin account. If successful, this demonstrates that OpenStack is still working as expected, and that an issue exists somewhere within the LDAP ←→ Identity integration settings. See Section 3.13, “Troubleshooting”.

3.11. Configure for high availability
Copiar o link

With keystone v3 enabled, you can make this configuration highly available by listing multiple LDAP servers in the configuration file for that domain.

1. Add a second server to the url entry. For example, updating the url setting in the keystone.LAB.conf file will have Identity Service send all query traffic to the first LDAP server in the list, ldap.lab.local:

url =  ldaps://ldap.lab.local,ldaps://ldap2.lab.local

url =  ldaps://ldap.lab.local,ldaps://ldap2.lab.local

Copy to Clipboard

Toggle word wrap

If a query to ldap.lab.local fails due to it being unavailable, Identity Service will attempt to query the next server in the list: ldap2.lab.local. Note that this configuration does not perform queries in a round-robin fashion, so cannot be considered a load-balancing solution.

2. Set the network timeout in /etc/openldap/ldap.conf:

NETWORK_TIMEOUT 2

NETWORK_TIMEOUT 2

Copy to Clipboard

Toggle word wrap

In addition, if you have firewalls configured between the controller and the LDAP servers, then you should not configure the LDAP servers to silently drop packets from the controller. This will allow python-keystoneclient to properly detect outages and redirect the request to the next LDAP server in the list.

Note

There might be connection delays while queries are being redirected to the second LDAP server in the list. This is because the connection to the first server must first time out before the second is attempted.

3.12. Create a RC file for a non-admin user
Copiar o link

You might need to create a RC file for a non-admin user. For example:

cat overcloudrc-v3-user1
Clear any old environment that may conflict.
for key in $( set | awk '{FS="="}  /^OS_/ {print $1}' ); do unset $key ; done
export OS_USERNAME=user1
export NOVA_VERSION=1.1
export OS_PROJECT_NAME=demo
export OS_PASSWORD=RedactedComplexPassword
export OS_NO_CACHE=True
export COMPUTE_API_VERSION=1.1
export no_proxy=,10.0.0.5,192.168.2.11
export OS_CLOUDNAME=overcloud
export OS_AUTH_URL=https://10.0.0.5:5000/v3
export OS_AUTH_TYPE=password
export PYTHONWARNINGS="ignore:Certificate has no, ignore:A true
SSLContext object is not available"
export OS_IDENTITY_API_VERSION=3
export OS_PROJECT_DOMAIN_NAME=Default
export OS_USER_DOMAIN_NAME=LAB

$ cat overcloudrc-v3-user1
# Clear any old environment that may conflict.
for key in $( set | awk '{FS="="}  /^OS_/ {print $1}' ); do unset $key ; done
export OS_USERNAME=user1
export NOVA_VERSION=1.1
export OS_PROJECT_NAME=demo
export OS_PASSWORD=RedactedComplexPassword
export OS_NO_CACHE=True
export COMPUTE_API_VERSION=1.1
export no_proxy=,10.0.0.5,192.168.2.11
export OS_CLOUDNAME=overcloud
export OS_AUTH_URL=https://10.0.0.5:5000/v3
export OS_AUTH_TYPE=password
export PYTHONWARNINGS="ignore:Certificate has no, ignore:A true
SSLContext object is not available"
export OS_IDENTITY_API_VERSION=3
export OS_PROJECT_DOMAIN_NAME=Default
export OS_USER_DOMAIN_NAME=LAB

Copy to Clipboard

Toggle word wrap

3.13. Troubleshooting
Copiar o link

3.13.1. Test LDAP connections
Copiar o link

Use ldapsearch to remotely perform test queries against the LDAP server. A successful result here indicates that network connectivity is working, and the LDAP services are up. In this example, a test query is performed against the server ldap.lab.local on port 636:

ldapsearch -D "cn=directory manager" -H ldaps://ldap.lab.local:636 -b "dc=lab,dc=local" -s sub "(objectclass=*)" -w RedactedComplexPassword

# ldapsearch -D "cn=directory manager" -H ldaps://ldap.lab.local:636 -b "dc=lab,dc=local" -s sub "(objectclass=*)" -w RedactedComplexPassword

Copy to Clipboard

Toggle word wrap

Note

ldapsearch is a part of the openldap-clients package. You can install this using # yum install openldap-clients.

3.13.2. Test port access
Copiar o link

Use nc to check that the LDAPS port (636) is remotely accessible. In this example, a probe is performed against the server ldap.lab.local. Press ctrl-c to exit the prompt.

nc -v ldap.lab.local 636

# nc -v ldap.lab.local 636
Ncat: Version 6.40 ( http://nmap.org/ncat )
Ncat: Connected to 192.168.200.10:636.
^C

Copy to Clipboard

Toggle word wrap

Failure to establish a connection could indicate a firewall configuration issue.

Este conteúdo não está disponível no idioma selecionado.

3.1. Key terms
Copiar o link

3.2. Assumptions
Copiar o link

3.3. Impact Statement
Copiar o link

3.3.1. High Availability options
Copiar o link

3.4. Outage requirements
Copiar o link

3.5. Firewall configuration
Copiar o link

3.6. Configure the LDAP server
Copiar o link

3.7. Configure the LDAPS certificate
Copiar o link

3.8. Configure Identity Service
Copiar o link

3.8.1. Enable command line access to keystone v3
Copiar o link

3.8.2. Configure the controller
Copiar o link

3.8.3. Configure Compute to use keystone v3
Copiar o link

3.8.4. Configure Block Storage to use keystone v3
Copiar o link

3.8.5. Allow LDAP users to access Projects
Copiar o link

3.9. Grant access to the Domain tab
Copiar o link

3.10. Creating a new project
Copiar o link

3.10.1. Changes to the command line
Copiar o link

3.10.2. Test LDAP integration
Copiar o link

3.11. Configure for high availability
Copiar o link

3.12. Create a RC file for a non-admin user
Copiar o link

3.13. Troubleshooting
Copiar o link

3.13.1. Test LDAP connections
Copiar o link

3.13.2. Test port access
Copiar o link

Aprender

Experimente, compre e venda

Comunidades

Sobre a documentação da Red Hat

Tornando o open source mais inclusivo

Sobre a Red Hat

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

Este conteúdo não está disponível no idioma selecionado.

Chapter 3. Generic LDAP Integration

3.1. Key termsCopiar o linkLink copiado para a área de transferência!

3.2. AssumptionsCopiar o linkLink copiado para a área de transferência!

3.3. Impact StatementCopiar o linkLink copiado para a área de transferência!

3.3.1. High Availability optionsCopiar o linkLink copiado para a área de transferência!

3.4. Outage requirementsCopiar o linkLink copiado para a área de transferência!

3.5. Firewall configurationCopiar o linkLink copiado para a área de transferência!

3.6. Configure the LDAP serverCopiar o linkLink copiado para a área de transferência!

3.7. Configure the LDAPS certificateCopiar o linkLink copiado para a área de transferência!

3.8. Configure Identity ServiceCopiar o linkLink copiado para a área de transferência!

3.8.1. Enable command line access to keystone v3Copiar o linkLink copiado para a área de transferência!

3.8.2. Configure the controllerCopiar o linkLink copiado para a área de transferência!

3.8.3. Configure Compute to use keystone v3Copiar o linkLink copiado para a área de transferência!

3.8.4. Configure Block Storage to use keystone v3Copiar o linkLink copiado para a área de transferência!

3.8.5. Allow LDAP users to access ProjectsCopiar o linkLink copiado para a área de transferência!

3.9. Grant access to the Domain tabCopiar o linkLink copiado para a área de transferência!

3.10. Creating a new projectCopiar o linkLink copiado para a área de transferência!

3.10.1. Changes to the command lineCopiar o linkLink copiado para a área de transferência!

3.10.2. Test LDAP integrationCopiar o linkLink copiado para a área de transferência!

3.11. Configure for high availabilityCopiar o linkLink copiado para a área de transferência!

3.12. Create a RC file for a non-admin userCopiar o linkLink copiado para a área de transferência!

3.13. TroubleshootingCopiar o linkLink copiado para a área de transferência!

3.13.1. Test LDAP connectionsCopiar o linkLink copiado para a área de transferência!

3.13.2. Test port accessCopiar o linkLink copiado para a área de transferência!

Aprender

Experimente, compre e venda

Comunidades

Sobre a documentação da Red Hat

Tornando o open source mais inclusivo

Sobre a Red Hat

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

3.1. Key terms
Copiar o link

3.2. Assumptions
Copiar o link

3.3. Impact Statement
Copiar o link

3.3.1. High Availability options
Copiar o link

3.4. Outage requirements
Copiar o link

3.5. Firewall configuration
Copiar o link

3.6. Configure the LDAP server
Copiar o link

3.7. Configure the LDAPS certificate
Copiar o link

3.8. Configure Identity Service
Copiar o link

3.8.1. Enable command line access to keystone v3
Copiar o link

3.8.2. Configure the controller
Copiar o link

3.8.3. Configure Compute to use keystone v3
Copiar o link

3.8.4. Configure Block Storage to use keystone v3
Copiar o link

3.8.5. Allow LDAP users to access Projects
Copiar o link

3.9. Grant access to the Domain tab
Copiar o link

3.10. Creating a new project
Copiar o link

3.10.1. Changes to the command line
Copiar o link

3.10.2. Test LDAP integration
Copiar o link

3.11. Configure for high availability
Copiar o link

3.12. Create a RC file for a non-admin user
Copiar o link

3.13. Troubleshooting
Copiar o link

3.13.1. Test LDAP connections
Copiar o link

3.13.2. Test port access
Copiar o link