"msg": "basic: the specified credentials were rejected by the server" - Please help

Archives Ansible Project
,
1

Hi All,

I am running a playbook (from AWX) against a Windows Server 2016 and it is failing with:-

{
“msg”: “basic: the specified credentials were rejected by the server”,
“unreachable”: true,
“changed”: false
}

I am using winrm as the transport and am now going using basic authentication over http.

My winrm config (winrm get winrm/config) is as follows:-

Config
MaxEnvelopeSizekb = 500
MaxTimeoutms = 60000
MaxBatchItems = 32000
MaxProviderRequests = 4294967295
Client
NetworkDelayms = 5000
URLPrefix = wsman
AllowUnencrypted = true
Auth
Basic = true
Digest = true
Kerberos = true
Negotiate = true
Certificate = true
CredSSP = false
DefaultPorts
HTTP = 5985
HTTPS = 5986
TrustedHosts
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 = true
Auth
Basic = true
Kerberos = true
Negotiate = true
Certificate = false
CredSSP = false
CbtHardeningLevel = Relaxed
DefaultPorts
HTTP = 5985
HTTPS = 5986
IPv4Filter = *
IPv6Filter = *
EnableCompatibilityHttpListener = false
EnableCompatibilityHttpsListener = false
CertificateThumbprint
AllowRemoteAccess = true
Winrs
AllowRemoteShellAccess = true
IdleTimeout = 7200000
MaxConcurrentUsers = 2147483647
MaxShellRunTime = 2147483647
MaxProcessesPerShell = 2147483647
MaxMemoryPerShellMB = 2147483647
MaxShellsPerUser = 2147483647

The following group_vars are set:-

ansible_winrm_transport: basic
ansible_winrm_scheme: http
ansible_ssh_port: 5985
ansible_winrm_server_cert_validation: ignore

oh and the playbook run also generates a security event (id 4625) on the managed node as follows:-

Failure Information:
Failure Reason: Unknown user name or bad password.
Status: 0xC000006D
Sub Status: 0xC0000064

The password is correctly stored in the AWX credential. I’m at a loss as to the problem

Any pointers will be greatly appreciated as i have googled this to death

Kind Regards

Chris.

2

You should never be using basic auth over http as everything is in cleartext. You would have had to 1 enable basic auth support and 2 disable the encryption check on the Windows host which should tell you this isn’t recommended. You can set ntlm as the auth type (transport) as that will at least give you some message encryption even if it isn’t great. We also have scripts you can use to setup a https listener so everything is encrypted by TLS.

Potentially your problem is that you are authenticating with a domain account which does not work with basic authentication. If that is the case you should be using kerberos as it’s a lot more secure and is recommended by Microsoft. You could use ntlm but like the above it is an older protocol and not 100% secure against something who knows what they are doing.

If it is a local account then I don’t know what else to say, if Windows is saying the username or password is incorrect then they are the definitive source on validating it.

Thanks

Jordan

3

Jordan,

Many thanks for the quick response. I am using the Administrator account on the box so I dont think basic/ntlm is the issue.

Not sure where else to go with this

Chris

4

Then you can only go with what Windows is telling you which is the credentials are incorrect. This could mean that AWX is not passing the credentials properly or there is a typo somewhere. I don’t think this is the problem but you could be having issues because the LocalAccountTokenFilterPolicy [1] value is not set to 1. You can use the following PowerShell snippet to set this policy.

`

$token_path = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System"
$token_prop_name = "LocalAccountTokenFilterPolicy"
$token_key = Get-Item -Path $token_path
$token_value = $token_key.GetValue($token_prop_name, $null)
if ($token_value -ne 1) {
    Write-Verbose "Setting LocalAccountTOkenFilterPolicy to 1"
    if ($null -ne $token_value) {
        Remove-ItemProperty -Path $token_path -Name $token_prop_name
    }
    New-ItemProperty -Path $token_path -Name $token_prop_name -Value 1 -PropertyType DWORD > $null
}

`

What this policy controls is whether Windows will create a limited or full access token from network logons. A limited access token has privileges groups like the BUILTIN\Administrators and special privileges ripped out and will cause an Authorisation failure (not Authentication) because WinRM by default requires the Administrators group. Because the security descriptor on the WinRM listener requires the Administrators group for a user to access it, you need to have the full token.

One other thing you can test is to try and connect to your Windows host from another Windows host using the tools that Microsoft provides. I recommend you run the following winrs command to see if you can connect using the credentials you have;

`
winrs -r:http://server:5985/wsman -u:Administrator -p:Password hostname.exe

`

Obviously replace server and the password with whatever is relevant to you.

[1] - https://support.microsoft.com/en-us/help/951016/description-of-user-account-control-and-remote-restrictions-in-windows

Thanks

Jordan

5

That's great! I'll try this tomorrow and let you know how I get on.

6

I ran the winrs command from my laptop and got the following:…

Winrs error:The server certificate on the destination computer (quicker1.fyre.ibm.com:5986) has the following errors:
The SSL certificate is signed by an unknown certificate authority.
The SSL certificate contains a common name (CN) that does not match the hostname.

Could this be the issue?

I have changed a few things now, the winrm config is now as follows:-
Config
MaxEnvelopeSizekb = 500
MaxTimeoutms = 60000
MaxBatchItems = 32000
MaxProviderRequests = 4294967295
Client
NetworkDelayms = 5000
URLPrefix = wsman
AllowUnencrypted = false
Auth
Basic = false
Digest = true
Kerberos = true
Negotiate = true
Certificate = true
CredSSP = false
DefaultPorts
HTTP = 5985
HTTPS = 5986
TrustedHosts
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 = false
CbtHardeningLevel = Relaxed
DefaultPorts
HTTP = 5985
HTTPS = 5986
IPv4Filter = *
IPv6Filter = *
EnableCompatibilityHttpListener = false
EnableCompatibilityHttpsListener = false
CertificateThumbprint
AllowRemoteAccess = true
Winrs
AllowRemoteShellAccess = true
IdleTimeout = 7200000
MaxConcurrentUsers = 2147483647
MaxShellRunTime = 2147483647
MaxProcessesPerShell = 2147483647
MaxMemoryPerShellMB = 2147483647
MaxShellsPerUser = 2147483647

Chris

7

If you are using a self signed certificate and are connecting over https then yes you will get that error. Windows cannot verify the cert and so it fails. Try against the http listener with port 5985 instead.