Creating ous within the active directory database is also called prestaging. true or false?

This chapter describes how to integrate Identity Service (keystone) with Active Directory Domain Services. In this use case, Identity Service authenticates certain Active Directory Domain Services (AD DS) users, while retaining authorization settings and critical service accounts in the Identity Service database. As a result, Identity Service has read-only access to AD DS for user account authentication, while retaining management over the privileges assigned to authenticated accounts.

Inhaltsverzeichnis Show

1.1. Key terms
1.2. Assumptions
1.3. Impact Statement
1.3.1. High Availability options
1.4. Outage requirements
1.5. Firewall configuration
1.6. Configure Active Directory Domain Services
1.7. Configure the LDAPS certificate
1.8. Configure Identity Service
1.8.1. Enable command line access to keystone v3
1.8.2. Configure the controller
1.8.3. Configure Compute to use keystone v3
1.8.4. Configure Block Storage to use keystone v3
1.8.5. Allow Active Directory group members to access Projects
1.8.6. Allow Active Directory users to access Projects
1.9. Grant access to the Domain tab
1.10. Creating a new project
1.11. Changes to the dashboard log in process
1.12. Changes to the command line
1.13. Test AD DS integration
1.14. Configure for high availability
What is Microsoft's best practice when it comes to creating additional Active Directory domains?
Which of the following is a Windows Active Directory feature to identify and control the execution of applications on various systems?
Which of the following group scope can contain objects from any domain within the forest?
What is Active Directory ad quizlet?

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

PS C:\> Get-ADDomain | select NetBIOSName
NetBIOSName
-----------
LAB

3 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.

1.1. Key terms

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 resources they are attempting to access.
Domain - This term is not the same as an AD DS domain, and instead refers to the additional namespaces that are configured in Identity Service for partitioning users, groups, and projects. These separate domains can be configured to authenticate users in different LDAP or AD DS environments.

1.2. Assumptions

This example deployment makes the following assumptions:

Active Directory Domain Services is configured and operational.
Red Hat OpenStack Platform is configured and operational.
DNS name resolution is fully functional and all hosts are registered appropriately.
AD DS authentication traffic is encrypted with LDAPS, using port 636.

1.3. Impact Statement

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

1.3.1. High Availability options

This configuration creates a dependency on the availability of a single Active Directory Domain Controller; Project users will be affected if Identity Service is unable to authenticate to the AD Domain Controller. A number of options are available to manage this risk; for example, you might configure Identity Service to query a DNS alias or a load balancing appliance, rather than an individual AD Domain Controller. You can also configure keystone to query a different Domain Controller, should one become unavailable. See for more information.

1.4. Outage requirements

The Identity Service will need to be restarted to add the AD DS 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 AD DS. To reduce downtime, consider pre-staging the AD DS accounts well in advance of this change.

1.5. Firewall configuration

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

SourceDestinationTypePort

OpenStack Controller Node

Active Directory Domain Controller

LDAPS

TCP 636

1.6. Configure Active Directory Domain Services

This section describes the tasks that Active Directory administrators will need to complete:

Table 1.1. Configuration steps

Task

Details

Create a service account.

This can be named according to your naming convention for service accounts, for example:

PS C:\> Get-ADDomain | select NetBIOSName
NetBIOSName
-----------
LAB

4. This can be a regular domain user account. Administrator privileges are not required.

Create a user group.

If a user needs access to OpenStack, they must be a member of this group. This can be named according to your naming convention for user groups, for example:

PS C:\> Get-ADDomain | select NetBIOSName
NetBIOSName
-----------
LAB

5. Members of this group can be granted access to Projects in the dashboard, if they are also members of the Project groups.

Create the Project groups.

Each OpenStack Project will require a corresponding AD group. For example,

PS C:\> Get-ADDomain | select NetBIOSName
NetBIOSName
-----------
LAB

6 and

PS C:\> Get-ADDomain | select NetBIOSName
NetBIOSName
-----------
LAB

7 .

Configure the service account.

The service account

PS C:\> Get-ADDomain | select NetBIOSName
NetBIOSName
-----------
LAB

4 must be a member of the

PS C:\> Get-ADDomain | select NetBIOSName
NetBIOSName
-----------
LAB

5 group.

Export the LDAPS public key.

Export the public key (not the private key) in the following format:

# openssl x509 -inform der -in addc.lab.local.cer -out addc.lab.local.pem

# openssl x509 -inform der -in addc.lab.local.cer -out addc.lab.local.pem

# openssl x509 -inform der -in addc.lab.local.cer -out addc.lab.local.pem

2 file.

Send the key to the OpenStack administrators.

The OpenStack administrators will use this key to encrypt LDAPS communications between OpenStack and Active Directory.

Retrieve the NetBIOS name of your AD DS domain.

The OpenStack administrators will use this name for the Keystone domain, allowing consistent domain naming between the environments.

For example, the procedure below shows the PowerShell commands that would be run on the Active Directory Domain Controller:

1. Create the LDAP lookup account. This account is used by Identity Service to query the AD DS LDAP service:

PS C:\> New-ADUser -SamAccountName svc-ldap -Name "svc-ldap" -GivenName LDAP -Surname Lookups -UserPrincipalName [email protected]  -Enabled $false -PasswordNeverExpires $true -Path 'OU=labUsers,DC=lab,DC=local'

2. Set a password for this account, and then enable it. You will be prompted to specify a password that complies with your AD domain’s complexity requirements:

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

3. Create a group for OpenStack users, called grp-openstack.

PS C:\> NEW-ADGroup -name "grp-openstack" -groupscope Global -path "OU=labUsers,DC=lab,DC=local"

4. Create the Project groups:

PS C:\> NEW-ADGroup -name "grp-openstack-demo" -groupscope Global -path "OU=labUsers,DC=lab,DC=local"
PS C:\> NEW-ADGroup -name "grp-openstack-admin" -groupscope Global -path "OU=labUsers,DC=lab,DC=local"

5. Add the svc-ldap user to the grp-openstack group:

PS C:\> ADD-ADGroupMember "grp-openstack" -members "svc-ldap"

6. From an AD Domain Controller, use a Certificates MMC to export your LDAPS certificate’s public key (not the private key) as a DER-encoded

# openssl x509 -inform der -in addc.lab.local.cer -out addc.lab.local.pem

1 .cer file. Send this file to the OpenStack administrators.

7. Retrieve the NetBIOS name of your AD DS domain.

PS C:\> Get-ADDomain | select NetBIOSName
NetBIOSName
-----------
LAB

Send this value to the OpenStack administrators.

1.7. Configure the LDAPS certificate

Note

When using multiple domains for LDAP authentication, you might receive various errors, such as

# openssl x509 -inform der -in addc.lab.local.cer -out addc.lab.local.pem

4, or

# openssl x509 -inform der -in addc.lab.local.cer -out addc.lab.local.pem

5. This can arise if keystone uses the incorrect certificate for a certain domain. As a workaround, merge all of the LDAPS public keys into a single

# openssl x509 -inform der -in addc.lab.local.cer -out addc.lab.local.pem

6 bundle, and configure all of your keystone domains to use this file.

1. Copy the LDAPS public key to the node running OpenStack Identity (keystone), and convert the

# openssl x509 -inform der -in addc.lab.local.cer -out addc.lab.local.pem

2 to

# openssl x509 -inform der -in addc.lab.local.cer -out addc.lab.local.pem

8. This example uses a certificate file named

# openssl x509 -inform der -in addc.lab.local.cer -out addc.lab.local.pem

# openssl x509 -inform der -in addc.lab.local.cer -out addc.lab.local.pem

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

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

3. Convert the .pem to .crt and copy to the certificate directory:

# openssl x509 -outform der -in addc.lab.local.pem -out addc.lab.local.crt
# cp addc.lab.local.crt /etc/ssl/certs/

1.8. Configure Identity Service

These steps prepare Identity Service for integration with AD DS.

1.8.1. Enable command line access to keystone v3

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

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

$ cp overcloudrc overcloudrc-v3

2. Edit the new

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

1 file:

Change

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

2 from v2.0 to v3. For example:

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

Add the following entries to the bottom of

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

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

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

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

1.8.2. Configure the controller

Perform this procedure from the controller running the keystone service. If running a HA environment with multiple controllers, then these steps must be performed on each controller:

1. Configure SELinux:

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

The output might include messages similar to this. They can be ignored:

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

2. Create the domains directory:

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

3. Configure Identity Service to use multiple back ends:

Note

You might need to install

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

4 using

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

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

Note

PS C:\> Get-ADDomain | select NetBIOSName
NetBIOSName
-----------
LAB

4. Enable multiple domains in dashboard. Add these lines to /etc/openstack-dashboard/local_settings:

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

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

PS C:\> Get-ADDomain | select NetBIOSName
NetBIOSName
-----------
LAB

Restart the httpd service to apply the settings:

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

5. Configure an additional back end:

In this example,

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

8 is the NetBIOS name to use as the Identity Service domain.

a. Create the keystone domain for AD DS integration.

Use the NetBIOS name value retrieved previously as the domain name. This approach allows you to present a consistent domain name to users during the login process. For example, if the NetBIOS name is

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

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

Note

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

# openssl x509 -outform der -in addc.lab.local.pem -out addc.lab.local.crt
# cp addc.lab.local.crt /etc/ssl/certs/

b. Create the configuration file:

To add the AD DS back end, enter the LDAP settings in a new file called /etc/keystone/domains/keystone.LAB.conf (where

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

8 is the NetBIOS name retrieved previously). You will need to edit the sample settings below to suit your AD DS deployment:

PS C:\> NEW-ADGroup -name "grp-openstack" -groupscope Global -path "OU=labUsers,DC=lab,DC=local"

Explanation of each setting:

SettingDescription

# openssl x509 -outform der -in addc.lab.local.pem -out addc.lab.local.crt
# cp addc.lab.local.crt /etc/ssl/certs/

The AD Domain Controller to use for authentication. Uses LDAPS port

# openssl x509 -outform der -in addc.lab.local.pem -out addc.lab.local.crt
# cp addc.lab.local.crt /etc/ssl/certs/

# openssl x509 -outform der -in addc.lab.local.pem -out addc.lab.local.crt
# cp addc.lab.local.crt /etc/ssl/certs/

The Distinguished Name of an AD account to use for LDAP queries. For example, you can locate the Distinguished Name value of the svc-ldap account in AD using

# openssl x509 -outform der -in addc.lab.local.pem -out addc.lab.local.crt
# cp addc.lab.local.crt /etc/ssl/certs/

# openssl x509 -outform der -in addc.lab.local.pem -out addc.lab.local.crt
# cp addc.lab.local.crt /etc/ssl/certs/

The plaintext password of the AD account used above.

# openssl x509 -outform der -in addc.lab.local.pem -out addc.lab.local.crt
# cp addc.lab.local.crt /etc/ssl/certs/

The Distinguished Name of your AD domain. You can locate this value using

# openssl x509 -outform der -in addc.lab.local.pem -out addc.lab.local.crt
# cp addc.lab.local.crt /etc/ssl/certs/

# openssl x509 -outform der -in addc.lab.local.pem -out addc.lab.local.crt
# cp addc.lab.local.crt /etc/ssl/certs/

The Organizational Unit (OU) that contains the OpenStack accounts.

$ cp overcloudrc overcloudrc-v3

Defines the type of LDAP user. For AD, use the

$ cp overcloudrc overcloudrc-v3

1 type.

$ cp overcloudrc overcloudrc-v3

Filters the users presented to Identity Service. As a result, only members of the grp-openstack group can have permissions defined in Identity Service. This value requires the full Distinguished Name of the group:

$ cp overcloudrc overcloudrc-v3

$ cp overcloudrc overcloudrc-v3

Maps the AD value to use for user IDs.

$ cp overcloudrc overcloudrc-v3

Maps the AD value to use for names.

$ cp overcloudrc overcloudrc-v3

Maps the AD value to use for user email addresses.

$ cp overcloudrc overcloudrc-v3

Leave this value blank.

$ cp overcloudrc overcloudrc-v3

The AD setting that validates whether the account is enabled.

$ cp overcloudrc overcloudrc-v3

Defines the value to check to determine whether an account is enabled. Used when booleans are not returned.

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

The AD value that indicates that an account is enabled.

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

Defines user attributes that Identity Service should disregard.

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

Set this value to

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

03, as keystone only requires read-only access.

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

Set this value to

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

03, as keystone only requires read-only access.

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

Set this value to

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

03, as keystone only requires read-only access.

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

Maps the AD value to use for groups.

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

The Organizational Unit (OU) that contains the user groups.

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

Filters the groups presented to Identity Service.

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

Maps the AD value to use for group IDs.

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

Maps the AD value to use for group names.

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

Set this value to

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

03, as keystone only requires read-only access.

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

Set this value to

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

03, as keystone only requires read-only access.

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

Set this value to

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

03, as keystone only requires read-only access.

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

Defines whether TLS is to be used. This needs to be disabled if you are encrypting with LDAPS rather than STARTTLS.

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

Specifies the path to the .crt certificate file.

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

Configures Identity Service to also search within nested child OUs, when locating users that are members of the

PS C:\> Get-ADDomain | select NetBIOSName
NetBIOSName
-----------
LAB

5 group.

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

Set to

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

24, this setting prevents

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

25 from chasing all referrals with anonymous access.

6. Change ownership of the configuration file to the keystone user:

PS C:\> NEW-ADGroup -name "grp-openstack" -groupscope Global -path "OU=labUsers,DC=lab,DC=local"

7. Restart the httpd service to apply the changes:

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

8. Grant the admin user access to the domain:

Note

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

a. Get the

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

26 of the

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

8 domain:

PS C:\> NEW-ADGroup -name "grp-openstack" -groupscope Global -path "OU=labUsers,DC=lab,DC=local"

b. Get the

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

26 value of the admin user:

PS C:\> NEW-ADGroup -name "grp-openstack" -groupscope Global -path "OU=labUsers,DC=lab,DC=local"

c. Get the

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

26 value of the admin role:

PS C:\> NEW-ADGroup -name "grp-openstack" -groupscope Global -path "OU=labUsers,DC=lab,DC=local"

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:

PS C:\> NEW-ADGroup -name "grp-openstack" -groupscope Global -path "OU=labUsers,DC=lab,DC=local"

9. View the list of users in the AD DS domain by adding the NetBIOS name to the command:

Note

It might take some time for the LDAP to become queryable after a reboot or service restart.

PS C:\> NEW-ADGroup -name "grp-openstack" -groupscope Global -path "OU=labUsers,DC=lab,DC=local"

10. View the service accounts in the local Identity Service database:

PS C:\> NEW-ADGroup -name "grp-openstack" -groupscope Global -path "OU=labUsers,DC=lab,DC=local"

1.8.3. Configure Compute to use keystone v3

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

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

30 value:

PS C:\> NEW-ADGroup -name "grp-openstack" -groupscope Global -path "OU=labUsers,DC=lab,DC=local"

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

PS C:\> NEW-ADGroup -name "grp-openstack-demo" -groupscope Global -path "OU=labUsers,DC=lab,DC=local"
PS C:\> NEW-ADGroup -name "grp-openstack-admin" -groupscope Global -path "OU=labUsers,DC=lab,DC=local"

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

PS C:\> NEW-ADGroup -name "grp-openstack-demo" -groupscope Global -path "OU=labUsers,DC=lab,DC=local"
PS C:\> NEW-ADGroup -name "grp-openstack-admin" -groupscope Global -path "OU=labUsers,DC=lab,DC=local"

1.8.4. Configure Block Storage to use keystone v3

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

In /etc/cinder/cinder.conf:

PS C:\> NEW-ADGroup -name "grp-openstack-demo" -groupscope Global -path "OU=labUsers,DC=lab,DC=local"
PS C:\> NEW-ADGroup -name "grp-openstack-admin" -groupscope Global -path "OU=labUsers,DC=lab,DC=local"

```
PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount
```
31 - replace
```
PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount
```
32 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.

Restart the cinder services:

PS C:\> NEW-ADGroup -name "grp-openstack-demo" -groupscope Global -path "OU=labUsers,DC=lab,DC=local"
PS C:\> NEW-ADGroup -name "grp-openstack-admin" -groupscope Global -path "OU=labUsers,DC=lab,DC=local"

1.8.5. Allow Active Directory group members to access Projects

To allow authenticated users access to OpenStack resources, the recommended method is to authorize certain Active Directory groups to grant access to Projects. This saves the OpenStack administrators from having to allocate each user to a role in a Project. Instead, the Active Directory groups are granted roles in Projects. As a result, Active Directory users that are members of these Active Directory groups will be able to access pre-determined Projects.

Note

If you would prefer to manually manage the authorization of individual Active Directory users, see the following section: Allow individual Active Directory users to access Projects

This section presumes that the Active Directory administrator has already completed these steps:

Create a group named

PS C:\> Get-ADDomain | select NetBIOSName
NetBIOSName
-----------
LAB

7 in Active Directory.

Create a group named

PS C:\> Get-ADDomain | select NetBIOSName
NetBIOSName
-----------
LAB

6 in Active Directory.

Add your Active Directory users to one of the above groups, as needed.

Add your Active Directory users to the

PS C:\> Get-ADDomain | select NetBIOSName
NetBIOSName
-----------
LAB

5 group.

These steps assign a role to an AD group. Group members will then have permission to access OpenStack resources.

1. Retrieve a list of AD groups:

PS C:\> NEW-ADGroup -name "grp-openstack-demo" -groupscope Global -path "OU=labUsers,DC=lab,DC=local"
PS C:\> NEW-ADGroup -name "grp-openstack-admin" -groupscope Global -path "OU=labUsers,DC=lab,DC=local"

2. Retrieve a list of roles:

PS C:\> NEW-ADGroup -name "grp-openstack-demo" -groupscope Global -path "OU=labUsers,DC=lab,DC=local"
PS C:\> NEW-ADGroup -name "grp-openstack-admin" -groupscope Global -path "OU=labUsers,DC=lab,DC=local"

3. Grant the Active Directory groups access to Projects by adding them to one or more of these roles. For example, if you want users in the

PS C:\> Get-ADDomain | select NetBIOSName
NetBIOSName
-----------
LAB

6 group to be general users of the demo project, you must add the group to the member role:

PS C:\> NEW-ADGroup -name "grp-openstack-demo" -groupscope Global -path "OU=labUsers,DC=lab,DC=local"
PS C:\> NEW-ADGroup -name "grp-openstack-admin" -groupscope Global -path "OU=labUsers,DC=lab,DC=local"

As a result, members of

PS C:\> Get-ADDomain | select NetBIOSName
NetBIOSName
-----------
LAB

6 are able to log in to the dashboard by entering their AD DS username and password, when also entering

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

8 in the Domain field:

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.

1.8.6. Allow Active Directory users to access Projects

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

1. Retrieve a list of AD users:

PS C:\> NEW-ADGroup -name "grp-openstack-demo" -groupscope Global -path "OU=labUsers,DC=lab,DC=local"
PS C:\> NEW-ADGroup -name "grp-openstack-admin" -groupscope Global -path "OU=labUsers,DC=lab,DC=local"

2. Retrieve a list of roles:

PS C:\> NEW-ADGroup -name "grp-openstack" -groupscope Global -path "OU=labUsers,DC=lab,DC=local"

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:

PS C:\> NEW-ADGroup -name "grp-openstack-demo" -groupscope Global -path "OU=labUsers,DC=lab,DC=local"
PS C:\> NEW-ADGroup -name "grp-openstack-admin" -groupscope Global -path "OU=labUsers,DC=lab,DC=local"

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

PS C:\> ADD-ADGroupMember "grp-openstack" -members "svc-ldap"

As a result, user1 is able to log in to the dashboard by entering their AD DS username and password, when also entering

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

8 in the Domain field:

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.

1.9. Grant access to the Domain tab

To allow the

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

40 user to see the

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

41 tab, you will need to assign it the

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

40 role in the

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

43 domain:

Find the

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

40 user’s UUID:

PS C:\> ADD-ADGroupMember "grp-openstack" -members "svc-ldap"

Add the

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

40 role in the

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

43 domain to the

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

40 user:

PS C:\> ADD-ADGroupMember "grp-openstack" -members "svc-ldap"

As a result, the

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

40 user can now see the

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

41 tab.

1.10. Creating a new project

After you have completed these integration steps, when you create a new project you will need to decide whether to create it in the

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

50 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 to manage service accounts and the admin project. For separation purposes, you might want to keep your AD-backed users in a separate keystone domain.

1.11. Changes to the dashboard log in process

Configuring multiple domains in Identity Service enables a new Domain field in the dashboard login page.
Users are expected to enter the domain that matches their login credentials. This field must be manually filled with one of the domains present in keystone. Use the openstack command to list the available entries.

In this example, AD DS accounts will need to specify the

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

8 domain. The built-in keystone accounts, such as admin, must specify

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

50 as their domain:

PS C:\> ADD-ADGroupMember "grp-openstack" -members "svc-ldap"

1.12. Changes to the command line

For certain commands, you might need to specify the applicable domain. For example, appending

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

53 in this command returns users in the LAB domain (that are members of the grp-openstack group):

PS C:\> NEW-ADGroup -name "grp-openstack" -groupscope Global -path "OU=labUsers,DC=lab,DC=local"

Appending

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

54 returns the built-in keystone accounts:

PS C:\> ADD-ADGroupMember "grp-openstack" -members "svc-ldap"

1.13. Test AD DS integration

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

1. Create a test user in AD, and add the user to the

PS C:\> Get-ADDomain | select NetBIOSName
NetBIOSName
-----------
LAB

5 AD DS group.

2. Add the user to the

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

56 role of the

PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount

57 tenant.

3. Log in to the dashboard using the credentials of the AD 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 AD ←→ Identity integration settings. See .

1.14. Configure for high availability

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

1. Add a second server to the

# openssl x509 -outform der -in addc.lab.local.pem -out addc.lab.local.crt
# cp addc.lab.local.crt /etc/ssl/certs/

2 entry. For example, updating the

# openssl x509 -outform der -in addc.lab.local.pem -out addc.lab.local.crt
# cp addc.lab.local.crt /etc/ssl/certs/

2 setting in the keystone.LAB.conf file will have Identity Service send all query traffic to the first Domain Controller in the list, addc.lab.local:

PS C:\> ADD-ADGroupMember "grp-openstack" -members "svc-ldap"

If a query to addc.lab.local fails due to it being unavailable, Identity Service will attempt to query the next server in the list: addc2.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:

PS C:\> ADD-ADGroupMember "grp-openstack" -members "svc-ldap"

In addition, if you have firewalls configured between the controller and the domain controllers, then you should not configure the domain controllers to silently drop packets from the controller. This will allow python-keystoneclient to properly detect outages and redirect the request to the next domain controller 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.

What is Microsoft's best practice when it comes to creating additional Active Directory domains?

For the following reasons, the best practice is to create new Active Directory domains that have fully qualified DNS names: Single-label DNS names cannot be registered by using an Internet registrar.

Which of the following is a Windows Active Directory feature to identify and control the execution of applications on various systems?

Software Restriction Policies (SRPs) is a Group Policy-based feature in Active Directory (AD) that identifies and controls the execution of various programs on the computers in an AD domain.

Which of the following group scope can contain objects from any domain within the forest?

Universal Group It can contain users and groups (global and universal) from any domain in the forest. Universal groups do not care about trust. Universal groups can be a member of domain local groups or other universal groups but NOT global groups.

What is Active Directory ad quizlet?

Active Directory (AD) is a directory service developed by Microsoft and used to store objects like User, Computer, printer, Network information, It facilitate to manage your network effectively with multiple Domain Controllers in different location with AD database, able to manage/change AD from any Domain Controllers ...