CredSSP / Windows Server to Windows Domain Controller

Archives Ansible Project
,
1

Trying to figure out how to handle this situation.

  1. In AWS, I create a Windows Server and set the Local Administrator password while its coming up
  2. Ive defined a Group in my hosts file, and a group vars file
  4. ansible_user: Administrator
  5. ansible_password: passwordhere
  6. ansible_port: 5986
  7. ansible_connection: winrm
  8. ansible_winrm_server_cert_validation: ignore
  9. ansible_winrm_transport: credssp1. I run my playbook

`

2

This should work for you, I’ve done something similar here https://github.com/jborean93/ansible-windows/blob/master/vagrant/roles/domain-setup/tasks/main.yml. The error is indicating WinRM isn’t on and listening on that port and not an authentication failure. Sounds like it “may” be related to https://github.com/ansible/ansible/issues/39235 but it doesn’t seem to be exactly the same. I have a few questions;

  • Does the host actually reboot, the error’s indicate win_reboot didn’t start the task so if it did reboot then the win_domain step did it which isn’t good
  • Can you eventually connect to the host with WinRM (after a few minutes)
  • What’s the status of the winrm service (‘Get-Service -Name winrm’)
  • What’s the output of ‘winrm enumerate winrm/config/listener’
    For the authentication side, domain controllers are a bit unique when it comes to auth. After promotion, any local accounts become domain accounts so the account should still work properly. CredSSP should be no exception but I’ve never tried it in this situation. Looking at your tasks I don’t see a real need for using CredSSP so it may be more prudent to use another auth over SSL instead.

Thanks

Jordan

3

I assumed since I was working with a Domain Controller I had to use CredSSP or Kerberos, and I have no idea how kerberos works. Is CredSSP not my best choice?

  • The Host does not reboot
  • After that failure, RDP doesn’t immediatly respond.
  • After a few minutes RDP respond but it fails with ‘An Attempt was made to logon, but the network logon service was not started’
  • Forced a reboot via AWS console
  • Attempting to RDP again, Creds are accepted, but we hang on ‘Please wait for the Group Policy Client’ for longer than usual.
  • After that login, Ansible is able to connect again and my playbook runs.
4

Realized i didnt answer 2 of your questions. Ill have to re-run this while being already RDP’d into the instance to get you those outputs.

5

Here are the commands you requested. notice, netlogon is not running.

PS C:\Users\Administrator> Get-Service -Name winrm

Status Name DisplayName

Running winrm Windows Remote Management (WS-Manag…

PS C:\Users\Administrator> winrm enumerate winrm/config/listener
Listener
Address = *
Transport = HTTP
Port = 5985
Hostname
Enabled = true
URLPrefix = wsman
CertificateThumbprint
ListeningOn = 10.0.136.5, 127.0.0.1, ::1, 2001:0:4137:9e76:2004:734:f5ff:77fa, fe80::5efe:10.0.136.5%4, fe80::2004:7
34:f5ff:77fa%6, fe80::454f:4d56:893d:4bba%3

Listener
Address = *
Transport = HTTPS
Port = 5986
Hostname = EC2AMAZ-COGMS1M
Enabled = true
URLPrefix = wsman
CertificateThumbprint = 50DC9242DDC63F4D7F854DE704C069857BECFDB0
ListeningOn = 10.0.136.5, 127.0.0.1, ::1, 2001:0:4137:9e76:2004:734:f5ff:77fa, fe80::5efe:10.0.136.5%4, fe80::2004:7
34:f5ff:77fa%6, fe80::454f:4d56:893d:4bba%3

PS C:\Users\Administrator>

PS C:\Users\Administrator> Get-Service -Name netlogon

Status Name DisplayName

Stopped Netlogon netlogon

6

Thanks for the info, yea does sounds like one of the problems mentioned on the ticket, I remember some people saying Netlogon is stopped which will definitely cause some issues. The strangest thing is I have used this module multiple times and have never come across this issue. There’s not much I can do to help right now but I am looking at trying to make this more stable as part of the 2.7 release, I just haven’t gotten to start working on it yet.

For your CredSSP question, it’s probably a bit more of a moot point with Ansible but the reason why MS have a warning around using it is because;

  • It uses unconstrained delegation, e.g. it will authenticate any downstream services even if you don’t want it to. This may be a security risk in case that downstream service is compromised as now they have your kerb token/ntlm hash
  • It sends the actual password (encrypted) and not just a hash which is not optimal

Usually our recommendation is;

  • Use Kerberos if possible, as this only works on domain accounts then it can’t be used in all cases (like promoting a server to an ad controller)
  • If you can’t use the above, use https (with any other auth) to ensure any headers/http info is encrypted
  • NTLM is a fallback to Kerberos but really shouldn’t be used without https
  • CredSSP is a newer protocol (uses NTLM or Kerberos in the spec as well) but because of the points I mentioned above, it may not be ideal for all situations

Thanks

Jordan