Closed cidrbl0ck closed 1 year ago
The Credential exchange is the last step of CredSSP and indicates the underlying CredSSP logon with the delegated credentials had failed. Check the security event log on your Windows host to find the login failure message and look at the reason/sub reason for more information.
Yeah I've been there Jordan. No errors, successful credential validation, and logon events. In typical Windows fashion, it's no help. But if you are saying it's nothing with the plugin or something I did wrong with the plugin then I will take it and focus efforts elsewhere.
The only times I've seen this particular error is when either;
The first scenario cannot happen as the credentials used in the negotiate phase is always going to be the same as the delegation phase so it passing the former means the latter should work.
The second scenario typically happens when the account is a domain account and is not allowed to log on during specific hours or from specific workstations. As this is a local account this shouldn't apply here but there could potentially be other policies at play.
For example here is the Security event log entry when I've manually edited the code to send the wrong credentials during the credential delegation phase
It gives me the NTSTATUS of 0xC000006D
which is STATUS_LOGON_FAILURE
and the sub status of 0xC000006A
which is STATUS_WRONG_PASSWORD
. Unless these event logs are explicitly disabled I'm not sure why Windows doesn't show it. If that's not the problem and something else is happening you should see at least 3 Logon
entries
This is the initial negotiate authentication phase
I appreciate it! I'm waiting for a response from the guys who manage the DC's (including GPOs). I suspect there's something under the covers I'm unaware of. Thanks for the help and info!
Environment: RHEL9 AWS AMI Ansible Automation Platform 2.3 Custom Execution Environment: ansible-automation-platform-23/ee-minimal-rhel8:latest built with:
Windows Server 2019 target host:
windowsfirewall: Windows Remote management listening all ip's, allowing all remote sources, direction=in, action=allow WinRM listener: http:5985 Service RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)(A;;GR;;;IU)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD) MaxConcurrentOperations = 4294967295 MaxConcurrentOperationsPerUser = 1500 EnumerationTimeoutms = 240000 MaxConnections = 300 MaxPacketRetrievalTimeSeconds = 120 AllowUnencrypted = false Auth Basic = false Kerberos = true Negotiate = true Certificate = false CredSSP = true CbtHardeningLevel = Relaxed DefaultPorts HTTP = 5985 HTTPS = 5986 IPv4Filter = IPv6Filter = EnableCompatibilityHttpListener = false EnableCompatibilityHttpsListener = false CertificateThumbprint AllowRemoteAccess = true
PSRemoting enabled WinRM service running "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy = 1"
Basically all the contents of the standard https://github.com/ansible/ansible/blob/devel/examples/scripts/ConfigureRemotingForAnsible.ps1 have been set except I'm not using a self-signed (or any) certificate and I'm using the HTTP winrm listener versus HTTPS.
Error:
We are migrating away from an AD domain internally to Okta, therefor I'm trying to use a local user account. I've tried both Basic and CredSSP auth. NTLM is old and is mostly disabled on internal systems.
Group Vars (to be perfectly honest I'm not 100% sure this is the appropriate place in AAP): group - os_windows