This line diffs:
AllowUnencrypted = false
That setting basically dictates wether you're allowed to use basic auth
using non-encrypted comms.
Again, from another windows node could you ensure that you're able to
connect to the problematic server using basic auth? Try both with and
without the -usessl parameter and compare to a working node. I suspect you
will find some diffs.
In general we advise using 5986 (SSL) with Ansible.
On Thursday, October 8, 2015 at 3:49:11 PM UTC+2, Eyal Zarchi wrote:
>
> yes that works.
> from one machine to another with ps-remotesession i had no problem.
> even with the domain username and password i was able to connect.
> this happens to all the windows machine in the domain.
> beside the powershell script to prepare for ansible i tried to add the
> security permission for the user but it still doesnt work.
>
> the winrm is ready since i am able to connect with a local username that
> is in the administrators group.
>
> i already got a few windows machine to work with the domain username so i
> am probably just missing something
> this is from a machine that works:
>
> PS C:\Users\TEMP.JAJAH> winrm get winrm/config/service
> Service
> RootSDDL =
> O:NSG:BAD:P(A;;GA;;;BA)(A;;GWGR;;;S-1-5-21-1738876665-1027346198-3318579073-26131)(A;;GR;;;IU)S:P(AU;FA;G
> A;;;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
>
>
> this is from a machine that doesnt work:
> 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 = true
> Kerberos = true
> Negotiate = true
> Certificate = false
> CredSSP = false
> CbtHardeningLevel = Relaxed
> DefaultPorts
> HTTP = 5985
> HTTPS = 5986
> IPv4Filter = *
> IPv6Filter = *
> EnableCompatibilityHttpListener = false
> EnableCompatibilityHttpsListener = false
> CertificateThumbprint = eb 9b 2d f2 a5 89 03 f2 e2 ca 0e 8a 35 32 39
> 08c5 a8 42 d7
> AllowRemoteAccess = true
>
>
>
> On Thursday, October 8, 2015 at 4:17:25 PM UTC+3, Trond Hindenes wrote:
>>
>> Could you test regular ps remoting from another domain-joined windows
>> node against the problematic servers to see if that works?
>>
>> On Thursday, October 8, 2015 at 3:04:00 PM UTC+2, Eyal Zarchi wrote:
>>>
>>> Hi again.
>>> well after removing all extra PTR the servers where good to do.
>>> i started deploying the ansible on production servers and here i have
>>> the same issue exactly but this time the dns and resolve are correct.
>>> local user on the machine is working perfectly
>>> domain user will produce the "
>>> FAILED => the username/password specified for this server was incorrect"
>>> error message.
>>>
>>> is there any logs i can check or extra errors i can check?
>>> thanks
>>>
>>> On Monday, September 7, 2015 at 5:51:13 PM UTC+3, Trond Hindenes wrote:
>>>>
>>>> Good. Kerberos relies on service principal names (which again relies on
>>>> name resolution), so you need a working DNS infrastructure for Kerberos to
>>>> work correctly.
>>>>
>>>> On Monday, September 7, 2015 at 10:35:15 AM UTC+2, Eyal Zarchi wrote:
>>>>>
>>>>> Trond - thanks for the tip.
>>>>> it actually helped because using tcpdump we saw that we had more than
>>>>> 1 PTR records for the server.
>>>>> as soon as we fixed that, the winrm worked.
>>>>> again it was weird since it did work in the same network but not over
>>>>> vlan.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Monday, September 7, 2015 at 2:27:53 AM UTC+3, Trond Hindenes wrote:
>>>>>>
>>>>>> EYal, just a thought: Could you try replacing ip addresses in your
>>>>>> hosts file with actual servername fqdns (sts03.domain.com) and see
>>>>>> if that helps?
>>>>>>
>>>>>> On Sunday, September 6, 2015 at 1:20:55 PM UTC+2, Eyal Zarchi wrote:
>>>>>>>
>>>>>>> Hi
>>>>>>> the servers are of course in the host file.
>>>>>>>
>>>>>>> Ok some updates on this but first information:
>>>>>>>
>>>>>>> Domain controller : 172.16.10.6
>>>>>>> Ansible controller - 172.16.19.1
>>>>>>> server that works (STS03) - 172.16.19.41
>>>>>>> servers that DOESNT work (STS01) - 172.16.1.114
>>>>>>>
>>>>>>>
>>>>>>> now if i try with a domain username to access from ansible to STS03
>>>>>>> (that works), it is all good.
>>>>>>> if i try with a domain username to access from ansible to STS01
>>>>>>> (doesnt work) - i get the "server not found in kerberos database" and
>>>>>>> "username is incorrect"
>>>>>>>
>>>>>>> now if i take the server that doesnt work and move it to the same
>>>>>>> network (172.16.19.42) near the server that works - everything is
>>>>>>> working
>>>>>>> on both servers.
>>>>>>>
>>>>>>> as soon as it is in another vlan, the domain username doesnt work
>>>>>>> anylonger (a local username on the machine works anywhere).
>>>>>>>
>>>>>>> so i suspected it is maybe something on the dc (in the firewall i
>>>>>>> have ANY to ANY on all 4 servers: DC, ansible , STS01 & STS 03).
>>>>>>>
>>>>>>> i ran wireshark on the DC and ran against both servers:
>>>>>>>
>>>>>>> when the ansible runs again the server INSIDE the network (STS03) i
>>>>>>> see this:
>>>>>>> 172.16.10.6 172.16.19.41 TCP 66 kerberos > 55200 [SYN, ACK] Seq=0
>>>>>>> Ack=1 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
>>>>>>> 172.16.10.6 172.16.19.41 TCP 54 kerberos > 55200 [RST, ACK]
>>>>>>> Seq=1441 Ack=1419 Win=0 Len=0
>>>>>>>
>>>>>>> so it seems that the DC is working directly against the destination
>>>>>>> server.
>>>>>>>
>>>>>>>
>>>>>>> BUT if i run the same winrm against the server in another VLAN i see
>>>>>>> this:
>>>>>>> 172.16.10.6 172.16.12.71 KRB5 176 KRB Error:
>>>>>>> KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN
>>>>>>> 172.16.10.6 172.16.12.71 TCP 54 kerberos > 60772 [RST, ACK] Seq=111
>>>>>>> Ack=1441 Win=0 Len=0
>>>>>>>
>>>>>>>
>>>>>>> it seems that when the destination server is in another VLAN, the
>>>>>>> kerberos is checked against the controller machine and not the
>>>>>>> destination
>>>>>>> server.
>>>>>>>
>>>>>>>
>>>>>>> could i be on to something?
>>>>>>>
>>>>>>>
>>>>>>> On Tuesday, September 1, 2015 at 11:08:41 AM UTC+3, Eyal Zarchi
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi.
>>>>>>>>
>>>>>>>> we have a few windows server 2008 R2 that we would like to use the
>>>>>>>> winrm module.
>>>>>>>> we have similar machines that some work and some dont. i compared
>>>>>>>> the build of the machine, the build of the powershell and even local
>>>>>>>> security policy. the result is still the same.
>>>>>>>> we use kerberos and winbind on the controller machine and since the
>>>>>>>> winrm module work for windows 2012 and some of the 2008 R2 machines
>>>>>>>> with
>>>>>>>> the domain username, i am guessing the issue is not on the controller.
>>>>>>>>
>>>>>>>> i though it was because it uses the ticket with the ldap user i
>>>>>>>> logged into the controller machine but i am a member of the
>>>>>>>> administrator
>>>>>>>> group on the target machine and it still doesnt work.
>>>>>>>> if i create a local username and put it in the administrator group,
>>>>>>>> the winrm work.
>>>>>>>>
>>>>>>>> here is a machine that works:
>>>>>>>>
>>>>>>>> <rnpl-qa1-bes01> WINRM RESULT <Response code 0, out
>>>>>>>> "C:\Users\deploy_rn\A", err "">
>>>>>>>> <rnpl-qa1-bes01> PUT /tmp/tmpe8SQvn TO
>>>>>>>> C:\Users\deploy_rn\AppData\Local\Temp\ansible-tmp-1441020926.8-178247757458762\\win_ping
>>>>>>>> <rnpl-qa1-bes01> WINRM PUT /tmp/tmpe8SQvn to
>>>>>>>> C:\Users\deploy_rn\AppData\Local\Temp\ansible-tmp-1441020926.8-178247757458762\\win_ping.ps1
>>>>>>>>
>>>>>>>> (offset=0 size=2035)
>>>>>>>> <rnpl-qa1-bes01> WINRM PUT /tmp/tmpe8SQvn to
>>>>>>>> C:\Users\deploy_rn\AppData\Local\Temp\ansible-tmp-1441020926.8-178247757458762\\win_ping.ps1
>>>>>>>>
>>>>>>>> (offset=2035 size=2035)
>>>>>>>> <rnpl-qa1-bes01> WINRM PUT /tmp/tmpe8SQvn to
>>>>>>>> C:\Users\deploy_rn\AppData\Local\Temp\ansible-tmp-1441020926.8-178247757458762\\win_ping.ps1
>>>>>>>>
>>>>>>>> (offset=4070 size=2035)
>>>>>>>> <rnpl-qa1-bes01> WINRM PUT /tmp/tmpe8SQvn to
>>>>>>>> C:\Users\deploy_rn\AppData\Local\Temp\ansible-tmp-1441020926.8-178247757458762\\win_ping.ps1
>>>>>>>>
>>>>>>>> (offset=6105 size=602)
>>>>>>>> <rnpl-qa1-bes01> PUT /tmp/tmpsiY4YG TO
>>>>>>>> C:\Users\deploy_rn\AppData\Local\Temp\ansible-tmp-1441020926.8-178247757458762\\arguments
>>>>>>>> <rnpl-qa1-bes01> WINRM PUT /tmp/tmpsiY4YG to
>>>>>>>> C:\Users\deploy_rn\AppData\Local\Temp\ansible-tmp-1441020926.8-178247757458762\\arguments
>>>>>>>>
>>>>>>>> (offset=0 size=2)
>>>>>>>> <rnpl-qa1-bes01> EXEC PowerShell -NoProfile -NonInteractive
>>>>>>>> -ExecutionPolicy Unrestricted -File
>>>>>>>> C:\Users\deploy_rn\AppData\Local\Temp\ansible-tmp-1441020926.8-178247757458762\\win_ping.ps1
>>>>>>>>
>>>>>>>> C:\Users\deploy_rn\AppData\Local\Temp\ansible-tmp-1441020926.8-178247757458762\\arguments;
>>>>>>>>
>>>>>>>> Remove-Item
>>>>>>>> "C:\Users\deploy_rn\AppData\Local\Temp\ansible-tmp-1441020926.8-178247757458762\"
>>>>>>>>
>>>>>>>> -Force -Recurse;
>>>>>>>> <rnpl-qa1-bes01> WINRM EXEC 'PowerShell' ['-NoProfile',
>>>>>>>> '-NonInteractive', '-EncodedCommand',
>>>>>>>> 'UABvAHcAZQByAFMAaABlAGwAbAAgAC0ATgBvAFAAcgBvAGYAaQBsAGUAIAAtAE4AbwBuAEkAbgB0AGUAcgBhAGMAdABpAHYAZQAgAC0ARQB4AGUAYwB1AHQAaQBvAG4AUABvAGwAaQBjAHkAIABVAG4AcgBlAHMAdAByAGkAYwB0AGUAZAAgAC0ARgBpAGwAZQAgAEMAOgBcAFUAcwBlAHIAcwBcAGQAZQBwAGwAbwB5AF8AcgBuAFwAQQBwAHAARABhAHQAYQBcAEwAbwBjAGEAbABcAFQAZQBtAHAAXABhAG4AcwBpAGIAbABlAC0AdABtAHAALQAxADQANAAxADAAMgAwADkAMgA2AC4AOAAtADEANwA4ADIANAA3ADcANQA3ADQANQA4ADcANgAyAFwAXAB3AGkAbgBfAHAAaQBuAGcALgBwAHMAMQAgAEMAOgBcAFUAcwBlAHIAcwBcAGQAZQBwAGwAbwB5AF8AcgBuAFwAQQBwAHAARABhAHQAYQBcAEwAbwBjAGEAbABcAFQAZQBtAHAAXABhAG4AcwBpAGIAbABlAC0AdABtAHAALQAxADQANAAxADAAMgAwADkAMgA2AC4AOAAtADEANwA4ADIANAA3ADcANQA3ADQANQA4ADcANgAyAFwAXABhAHIAZwB1AG0AZQBuAHQAcwA7ACAAUgBlAG0AbwB2AGUALQBJAHQAZQBtACAAIgBDADoAXABVAHMAZQByAHMAXABkAGUAcABsAG8AeQBfAHIAbgBcAEEAcABwAEQAYQB0AGEAXABMAG8AYwBhAGwAXABUAGUAbQBwAFwAYQBuAHMAaQBiAGwAZQAtAHQAbQBwAC0AMQA0ADQAMQAwADIAMAA5ADIANgAuADgALQAxADcAOAAyADQANwA3ADUANwA0ADUAOAA3ADYAMgBcACIAIAAtAEYAbwByAGMAZQAgAC0AUgBlAGMAdQByAHMAZQA7AA==']
>>>>>>>> <rnpl-qa1-bes01> WINRM RESULT <Response code 0, out "{ "changed":
>>>>>>>> f", err "">
>>>>>>>> rnpl-qa1-bes01 | success >> {
>>>>>>>> "changed": false,
>>>>>>>> "ping": "pong"
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>> here is one that doesnt work:
>>>>>>>>
>>>>>>>> <rnpl-qa1-sts01> ESTABLISH WINRM CONNECTION FOR USER: on PORT 5986
>>>>>>>> TO rnpl-qa1-sts01
>>>>>>>> <rnpl-qa1-sts02> ESTABLISH WINRM CONNECTION FOR USER: on PORT 5986
>>>>>>>> TO rnpl-qa1-sts02
>>>>>>>> <rnpl-qa1-sts01> WINRM CONNECT: transport=kerberos endpoint=
>>>>>>>> https://rnpl-qa1-sts01:5986/wsman
>>>>>>>> <rnpl-qa1-sts02> WINRM CONNECT: transport=kerberos endpoint=
>>>>>>>> https://rnpl-qa1-sts02:5986/wsman
>>>>>>>> rnpl-qa1-sts01 | FAILED => the username/password specified for this
>>>>>>>> server was incorrect
>>>>>>>> rnpl-qa1-sts02 | FAILED => the username/password specified for this
>>>>>>>> server was incorrect
>>>>>>>>
>>>>>>>>
>>>>>>>> as soon as i remove the @DOMAIN from the host file, and use a local
>>>>>>>> username, the winrm works.
>>>>>>>> i am probably missing a silly thing but i cant find it.
>>>>>>>> thanks
>>>>>>>>
>>>>>>>
--
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/96d4bfa2-714f-4859-9bdf-2505b66e0c75%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
