All right, Ansible networking.
What you're looking at right now is the contents of my Ansible
control node's krb5.conf file because I'm assuming Active Directory
Domain Services and Kerberos authentication.
I mentioned in the original lesson back in the I think the first content module,
I mentioned you should or you have to install Kerberos on your
control node and configure your krb5.conf file with the name
of your Active Directory domain.
In Kerberos language, it's called a realm.
And you're also specifying one or more domain controllers.
You've got your key distribution center.
Basically the same thing, your domain controllers, of which I have just one.
I also mentioned regarding Kerberos that you may have to,
depending upon how often you're using your Ansible service account,
you may need to refresh the account's Kerberos ticket.
You can do that right from the command line.
I've run klist here to see all of the tickets associated
with the currently logged‑on user, which happens to be Tim@TIMW.INFO.
All right,
so assuming that you've got Kerberos configured on your Ansible control node,
we then remember that in configuring our inventory,
we're going to need to make sure that we specify Kerberos.
Now ansible_user, I don't even technically need this in my list anymore.
So, I'm just going to go ahead and remove it.
The reason for that is I have ansible_user in my Ansible Vault file.
And whenever I need either ansible_user or ansible_password,
I'll just fetch them from there.
There's this permission denied.
You can see this.
If you're running WSL in VS Code,
you're going to run into not being able to sudo to save.
So I installed‑‑‑ I already mentioned this.
But there's an extension called Save as Root in WSL,
and it allows you to do that elevation and to save your changes.
Another tip I have regarding WSL that you may be interested in is on the host,
in my case my Windows server, you can and use the universal naming convention,
\\wsl$.
All right.
And if you're using the Ubuntu, the default distribution,
you can do \\wsl$\Ubuntu with a capital U.
And what do you know?
Lo and behold, we now have read/write access to the full file system.
So this can be really helpful because you might have picked
up on a theme from the previous module.
You might have downloaded manually some roles from
Ansible Galaxy or from another source,
and you want to quickly put them onto your control node.
That control node is in WSL,
and Ubuntu does not have a desktop and you may not want to have a desktop.
This is a convenient alternative I found,
and I figured that you could probably use that tip as well.
So anyway,
in order for your Ubuntu inventory hosts to work with
Windows Remote Management and Kerberos, we need to specify the port.
5985 is HTTP; 5986 is HTTPS.
The Ansible connection is WinRM, by default. Our transport
is Kerberos. Our realm is the domain.
And then lastly,
I'm manually stopping certificate validation because what I've
done in my environment is just did a garden variety setup that
uses self‑signed digital certificates.
I know that there's businesses that use self‑signed certificates even in
production, but I think you and I all know that we want to have an honest to
goodness PKI even though it's a lot more work.
Now to that point, I'd like us to take a look at,
let me see, that file that Ansible makes available to us.
Let me switch out of WSL and show my local file system. In the
course files, I give you that PowerShell script.
It's a few years old.
It's called ConfigureRemotingForAnsible.ps1.
Now do you have to use this setup script on your Windows nodes?
No, it just makes it a lot easier.
It's definitely an easy button to get started.
It opens up your WinRM listener for HTTP or HTTPS. The setup will
assume that you're using self‑signed certificates,
which is true.
You could either read through this file and edit it, or you could just
configured WinRM with TLS in your own certificates yourself.
It's totally up to you as life is.