Blog

Using Red Hat Ansible Automation Platform on Windows

Here in this blog, we will learn how to use the Red Hat Ansible Automation platform on Windows.

Trying to access a file from a network location—for instance, installing a project from a network path or copying application settings from a central file share—is a very frequent use case for Windows. Usually, when you try to perform the same action while logged in interactively, it works just fine. However, if you try to perform the same action in the Red Hat Ansible Automation Platform, it might not work.

Using ansible.windows.win_copy to copy a file from a UNC path to a local directory is one specific example in Ansible:

The aforementioned example would not work with:

Credential delegation, sometimes referred to as the double-hop problem, is the cause of this issue. This article will attempt to explain why it doesn’t work and provide solutions.

Windows-based authentication

In order to comprehend this issue, we must first comprehend Windows authentication mechanisms. An outline of the win_copy example from above would be as follows:

Ansible Automation Platform usually uses an authentication protocol such as Kerberos, NTLM, or CredSSP, among others, when establishing an authentication with a remote Windows host. Typically, these protocols depend on proving to the Windows server that we are aware of a secret that is only known by the user, like an SSH private key pair or a Kerberos ticket that is created using the user’s password. While some protocols don’t give the server enough information to create new tokens for recurrent authentication attempts, others do. An Access is denied error message will appear if the logon session is unable to re-authenticate with the File Server after failing to obtain this information.
The token that Ansible provided is scoped specifically for Ansible to authenticate with Windows Server, so the Windows server cannot use it again. This means that in order to solve the issue, we must supply the Windows server with sufficient data so that it can re-authenticate the user with the file server. We have several options for resolving this issue with the Ansible Automation Platform:

• Employing “become on the task”
• Utilizing a protocol for connection authentication that allows delegation
• Supplying clear credentials if the script or module allows it

Turn into

Using the Ansible Automation Platform’s implementation is the most straightforward way to solve this issue because it doesn’t involve altering the connection that the Ansible Automation Platform uses. The ansible. builtin. run as a plugin for Windows that can be used to execute the module task as a different user or with specific credentials used for outbound authentication. Here, we can use run to set delegation credentials using our win_copy example:

Examining the aforementioned example in detail reveals that the following task directives have been added.

This permits one to focus on this particular task.

This sets the Run as plugin as the active plugin and makes it the one used for this task. The run-as plugin is designed only to be used on Windows hosts. The ansible_become_method variable on the host/group vars can also be used to set the become plugin, which simplifies the task definition.

These unique flags instruct run to use the provided credentials for all outbound authentication attempts, such as gaining access to a file server. Without these flags, the module process would operate as the user has instructed throughout. The become flags restrict the use of credentials to only what is necessary for outbound authentication and solving the double hop problem.

Using particular variables on that task, provide the username and password for the Become plugin explicitly. These are the login credentials that will be used in this example to authenticate with the target file server, fs. You are free to enter any value that makes sense for our environment for the username and password. In this instance, the double hop problem is being solved by simply using the same connection variables again.

Since this is an unrestricted form of delegation, it is crucial that the Windows host that the Ansible Automation Platform is connecting to is reliable in handling the credentials. The compromised Windows host might theoretically use the supplied credentials again and assume that user’s identity for other purposes. We will need to employ a type of limited delegation using a connection-based solution in order to get around this issue.

Delegation based on connections

The double hop problem can be resolved by utilizing features Ansible uses in the connection plugin that Ansible uses. There isn’t a single option that works in every situation because these features are unique to the connection plugin. The Windows built-in connection plugins can be used with the following authentication protocols for credential delegation:

The explicit username and password are sent to the Windows server via the CredSSP and SSH plaintext password authentication protocols, which work similarly to Become. Due to the fact that the server can use those credentials to authenticate with any target, this is known as unconstrained delegation in the language of delegation.

Unconstrained delegation can also be accomplished through the Kerberos protocol, though it can also be utilized with constrained delegation. Although it limits how the server can reuse the user’s identity, constrained delegation is ideal. However, in order for it to function, additional configuration in the Active Directory environment is needed. A future blog post will address the topic of how to use Kerberos delegation, which is a complicated subject in and of itself.

Context-specific qualifications

Providing credentials as part of a module-specific option is the last option that the Ansible Automation Platform has to solve the double-hop issue. For instance, the domain_username and domain_password options in the Microsoft.ad.user module can be used to authenticate to the Active Directory server using particular credentials.

In the example above, the username and password that the Microsoft.ad.user module will use for authentication are specified by the ad_username and ad_password variables, respectively. Whether or not a module exposes this option will determine whether or not a credential can be provided in this way. When using ansible. builtin. script, ansible.windows.win_powershell, or ansible.windows.win_shell to run custom PowerShell code, the cmdlet must expose the functionality using a parameter like -Credential.

To ensure that the credentials are not inadvertently saved in any logging system, it is crucial that the tasks in the aforementioned examples are executed with no_log: true:

With all of this knowledge, we ought to be able to recognize potential double-hop problems and their solutions. This can be readily fixed by using become, connection authentication settings, or already-available module options to write tasks that function in the same way as when run interactively.