Create Playbooks for Windows Nodes.
One difference, and it's just architectural,
between Microsoft Windows and Linux, macOS is credential elevation.
Mac users have long known about sudo and administrative elevation
when you need to do a privileged operation.
In Windows, we've had the run as command that still exists.
In fact, as you probably are seeing right on the side, it's already here.
Basically,
what you've got in your playbooks is this is showing creating a
variable called ansible_become method runas,
which is standard in Windows, and then ansible_become_user.
Those are reserved keys.
So those are actually important.
So is become.
So basically those variables answer the question,
do you need to request elevation?
Yes.
I'm going to become administrator via runas.exe.
You see what I mean?
So basically, as I've shown you in some previous demos,
this is the main thing we want to think about in a Windows environment.
You do have quite a bit.
I would guess if you're doing configuration management,
like I've always done it,
you're doing work that's going to require local administrator privileges.
So, that's why understanding the become method is important.
And this slide is a bad example with administrator.
You're not going to want to use a built‑in account identity like that.
I just want to save my credibility there before I go on.
But I own the error because I made this slide.
So thus in Windows and in Active Directory domain,
what are some techniques for avoiding having our Ansible service
account a member of the domain admins group?
That's one option.
If you put your Ansible service account in domain admins,
then if a playbook invokes run as and escalates to that identity, well,
okay.
It's known and accounted for.
You could use Ansible to create its own service account in the
local administrators group on each manage node. That would
contain the blast radius somewhat.
Maybe you'd want to use a managed, a group managed service, account or LAPS.
There's lots of other add‑ons that I can think of off the top of my head.
I'm giving generic suggestions here.
Well, not generic, but I'll just say general suggestions.
Another is to use the win_command module that has run_as
that you presumably could use an identity,
a different identity, and you'd specify the password interactively.
I'm just making up the rest as I'm going along. Or you could leverage a
PAM, privileged access management solution, like Ansible.
Now I sound like a Red Hat salesperson.
I have no affiliation with Red Hat at all.
Let me also say that to save my integrity.
I say that because I'm mentioning products like Ansible
Automation Platform a lot, and it is a paid product.
This is not for sales.
It's because I believe in it.
It's good solid technology.
I think you should know about this,
at least by name, at the level we're at here at fundamentals.
Anyway,
let's move on to using conditional statements effectively in our playbooks.