Red Hat Security: Identity Management and Authentication
Configure IdM as a source for account authentication information for automation controller users.
Ansible is an open source automation platform that can manage powerful automation tasks, and can adapt to many different workflows and environments. As your experience with Ansible matures, you might find additional opportunities for leveraging Ansible to simplify and improve IT operations.
However, sharing an existing Ansible infrastructure to scale IT automation across an enterprise can present some challenges. For example, Ansible does not provide any facilities for managing shared access of Ansible Playbooks. Additionally, although playbooks can allow for the delegation of complex tasks, their execution might require highly privileged and guarded administrator credentials.
Automation controller overcomes many of these challenges by providing a framework for running and managing Ansible efficiently on an enterprise scale. Automation controller eases the administration involved with sharing an Ansible infrastructure but still maintains an organization's security by introducing features such as a centralized web interface for playbook management, role-based access control (RBAC), and centralized logging and auditing.
By default, automation controller maintains a local, internal database of user accounts, which it uses for the local authentication of users. However, it supports other methods of authentication such as Microsoft Azure Active Directory, Security Assertion Markup Language (SAML), Radius, and LDAP.
Organizations with both IdM and automation controller infrastructure can configure automation controller authentication using IdM. To authenticate using IdM, you can configure LDAP authentication. This configuration requires the use of a bind account, which has read access to the entire LDAP structure on the IdM server.
The following example shows how to use the ldapmodify command to create a bind account, uid=controller,cn=sysaccounts,cn=etc,dc=lab,dc=example,dc=com, to be used by automation controller for LDAP authentication against IdM.
The new account uses controller123 as the initial password.
[user@host ~]#ldapmodify -x -D 'cn=Directory Manager' -W <<EOFdn: uid=controller,cn=sysaccounts,cn=etc,dc=lab,dc=example,dc=comchangetype: addobjectclass: accountobjectclass: simplesecurityobjectuid: systemuserPassword: controller123passwordExpirationTime: 20280101000000ZnsIdleTimeout: 0EOF
Account creation requires elevated privileges.
In the example, the -x option specifies the use of simple authentication.
The -D 'cn=Directory Manager' option configures ldapmodify to perform its action using the privileged Directory Manager distinguished name.
Finally, the -W option prompts for the password of the Directory Manager distinguished name.
To configure automation controller for LDAP authentication with IdM, you need both a bind account to access the LDAP directory, and knowledge of the structure of the LDAP directory.
You can use the ldapsearch command to determine the structure of the LDAP directory by authenticating as the bind account.
The following command demonstrates the use of the ldapsearch command to execute a query for the ipausers user group.
[user@host ~]$ldapsearch \-D "uid=controller,cn=sysaccounts,cn=etc,dc=lab,dc=example,dc=com" \-W -h idm.lab.example.com \-b "cn=ipausers,cn=groups,cn=accounts,dc=lab,dc=example,dc=com"
The following procedure describes how to configure automation controller to authenticate using the IdM LDAP directory.
Log in to automation controller with an administrator account, and then click . Under , click and then click at the bottom of the page.
Important
Because LDAP is a plain text protocol, use LDAPS or Start TLS to encrypt credentials. These protocols require a working Public Key Infrastructure (PKI).
In the field, enter the LDAP URI for the IdM server.
In the field, enter the DN for the new bind account, which has read access to the entire LDAP structure on the IdM server.
In the field, enter the password for the bind account.
Set to if LDAPS is not required.
In the field, define the base DN, the search scope, and the search query format for user searches during authentication.
Click to commit the change.
The following example demonstrates the user search parameters for querying by the user ID (UID) in the lab.example.com domain using the subtree scope:
CN=users,CN=accounts,DC=lab,DC=example,DC=com SCOPE_SUBTREE (uid=%(user)s)
The first time an IdM user logs into automation controller successfully, automation controller creates a user account in its local user database. Automation controller creates the account with a name matching that of the IdM user account. Other than the account name, automation controller does not bring any other user account information over from IdM. To obtain user information such as first and last names and populate them into the automation controller user database, create an LDAP user attribute map in automation controller's LDAP authentication configuration.
The following steps outline the process for configuring automation controller to map IdM user attributes to automation controller user account data elements:
Log in to automation controller with an administrator account, and then click .
Under select , and then click at the bottom of the page.
In the field, enter the desired mapping in JSON format.
Click to commit the change.
The following example demonstrates the mapping of the first_name, last_name, and email user attributes:
{
"first_name": "givenName",
"last_name": "sn",
"email": "mail"
}You can use automation controller to map groups of users to specific user flags. After the mapping configuration is in place, any IdM user that belongs to the specified group is added to automation controller with the specified flag enabled.
The following steps outline the process for configuring automation controller to map an IdM user group to a user flag:
Log in to automation controller with an administrator account, and then click . Under select , and then click at the bottom of the page. In the field, enter the desired mapping in JSON format. Click to commit the change.
The following example demonstrates the mapping of users in the controlleradmin IdM user group to the is_superuser flag:
{
"is_superuser": "CN=controlleradmin,CN=groups,CN=accounts,DC=lab,DC=example,DC=com"
}When automation controller can perform external authentication using IdM's LDAP directory, by default all IdM users gain access. The automation controller administrator can restrict access based on group membership in IdM.
Group-based access to automation controller can be managed using inclusion, exclusion, or a combination of both methods. The following steps outline the process for configuring automation controller to allow access based on group membership:
Log in to automation controller with an administrator account, and then click .
Under , click , and then click at the bottom of the page.
In the field, choose .
To allow user access by group membership, in the field, enter the DN for the group to allow.
Click to commit the change.
Alternatively, to deny user access by group membership, enter the DN for the group to deny in the field.
The following example allows automation controller access for IdM users in the prodadmin IdM user group in the lab.example.com domain:
CN=prodadmin,CN=groups,CN=accounts,DC=lab,DC=example,DC=com
In automation controller, an organization is a logical unit that contains a set of related resources, such as teams, projects, and inventories. By associating users with an organization, an administrator can then manage their level of access to the resources contained within the organization.
In automation controller, a team is a group of users. Automation controller uses RBAC and teams are an efficient way to assign roles.
When enabling IdM users in automation controller, it is efficient to automatically place users into the organization containing the resources they need. This automation is enabled through the mapping of users to organizations based on their IdM group membership. Besides user-to-organization mapping, automation controller can also automate the mapping of users to teams based on their IdM group membership.
The following steps outline the process for configuring the mapping of IdM users to automation controller organizations and teams:
Log in to automation controller with an administrator account, and then click .
Under , select , and then click at the bottom of the page.
In the field, define the base DN, the search scope, and the search query format for searching user groups in IdM.
The following example demonstrates the group search parameters when querying for the ipausergroup object class in the lab.example.com domain using the subtree scope:
CN=groups,CN=accounts,DC=lab,DC=example,DC=com SCOPE_SUBTREE (objectClass=ipausergroup)
To map IdM users to automation controller organizations, specify the mapping in JSON format in the field.
The following example maps IdM users in the labadmin IdM group in the lab.example.com domain to the Lab organization as administrators:
{
"Lab": {
"admins": "CN=labadmin,CN=groups,CN=accounts,DC=lab,DC=example,DC=com"
}
}To map IdM users to an automation controller organization and team, specify the mapping in JSON format in the field.
The following example maps IdM users in the produsers IdM group in the lab.example.com domain to the Prod organization as users and members of the produsers team.
The "remove": false entry prevents users who are not members of the group from being removed from the team:
{
"produsers": {
"organization": "Prod",
"users": "CN=produsers,CN=groups,CN=accounts,DC=lab,DC=example,DC=net",
"remove": false
}
}Click to commit any changes.
Errors in the LDAP configuration can result in a failure to log in.
Review the /var/log/tower/tower.log file on controller to see details of the login failure.
For example, the following error indicates that controller does not trust the CA for the IdM server:
tls_process_server_certificate:certificate verify failed
The following error indicates that LDAP communication is working, but that a specified DN is incorrect:
NO_SUCH_OBJECT({'msgtype': 111, 'msgid': 6, 'result': 32, 'desc': 'No such object', 'ctrls': []})References
