Thanks for your answer Jordan..
I checked your list and indeed i'm using kerberos over HTTP. I tried 
setting 'ansible_winrm_message_encryption' to 'always', but the error 
remains the same.
The user that is used for the delegation is exactly the same user that I 
use to connect to the primary machine and this user is a domain admin hence 
implicit local admin of both machines.

I also checked winrm/config/service/auth settings and indeed only 
negotiate/kerberos is enabled but 'CbtHardeningLevel' is set to 'Relaxed' 
so requests-kerberos/requests-ntlm shouldn't have problems with it.

The strange thing is that when I target the machine, which I here try to 
delegate to, directly using another simpler playbook winrm authentication 
completely works as expected. So winrm then doesn't have any authentication 
problems on that same machine with that same user and the same ansible 
settings. Only when that machine is used for delegation, suddenly winrm 
fails to authenticate on that machine, while authentication on the actual 
target machine of the playbook, with the same credentials does work..

Are there other settings/variables in ansible that make delegate_to 
authenticate differently?

Thanks
Robin

Op zondag 1 december 2019 21:49:00 UTC+1 schreef Jordan Borean:
>
> Having a invalid credentials error means WinRM returns a 401 HTTP code 
> with means the request was unauthorized. In WinRM terms this can mean a few 
> different things;
>
>    - The request is not encrypted
>       - Using https is always encrypted
>       - Using http is only encrypted if using NTLM, Kerberos, or CredSSP 
>       (depending on the versions of pywinrm and requests-kerberos installed)
>       - I see you are using Kerberos over HTTP so it should be encrypted 
>       but try setting 'ansible_winrm_message_encryption=always' to 100% check 
> it 
>       doesn't fail on you.
>       - The user is not a local Administrator of the remote host
>       - By default only local Administrators can connect over WinRM
>       - This can be changed with 'winrm configSDDL default' and giving 
>       the user/group Execute rights
>    - For non domain accounts you need to make sure 
>    LocalAccountTokenFilterPolicy is set to 1
>       - If not defined or set to 0, any network connections are 
>       authenticated with a limited token so the user is not seen as 
> Administrator 
>       (see above)
>       - This does not apply to domain accounts so not actually something 
>       that is relevant for you to check
>       - The authentication choice is not supported
>       - By default WinRM only enables Negotiate/Kerberos (NTLM + Kerberos)
>       - Shouldn't affect you because you are using Kerberos
>       - Run 'winrm get winrm/config/service/auth' to see what's enabled
>       - CbtHardeningLevel is Strict and the required Python packages are 
>    not up to date
>       - This has been fixed in the newer requests-kerberos/requests-ntlm 
>       versions but you might be on an older one
>       - If 'winrm get winrm/config/service/auth' 'CbtHardeningLevel' is 
>       Strict then make sure you have a newer version of the requests-kerberos 
>       package installed
>       - Probably something else I'm not thinking off
>       - Kerberos auth can be troublesome to set up, one big thing you may 
>       want to verify is whether the time is in sync on your servers
>       
> Thanks
>
> Jordan
>

-- 
You received this message because you are subscribed to the Google Groups 
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ansible-project+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ansible-project/83ad4205-e985-4776-9cc0-9426b80eba9c%40googlegroups.com.

Reply via email to