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

[Chris Jackson]

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.

[Jordan Borean]

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

[Chris Jackson]

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

[Jordan Borean]

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

[Chris Jackson]

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

[Chris Jackson]

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

[Jordan Borean]

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.