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 ansible-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/b219ecf4-3a8b-4aa2-aa77-b8628be47f51%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
