Anything in the event logs? Since it seems to be a connection reset, I'd
hope there might be a message on the windows machine to say why.
On Monday, June 6, 2016 at 1:48:11 PM UTC+1, Mike Fennemore wrote:
>
> Thanks Jon, good to see it's being well maintained. Had already gone down
> the route of the self-signed cert via Powershell unfortunately.
> I ran the ConfigureForAnsible.ps1 just in case I had missed something.
> Seems like the same issue though:
>
> <xx.xx.xx.xx> ESTABLISH WINRM CONNECTION FOR USER: ansible_user@DOMAIN on
> PORT 5986 TO xx.xx.xx.xx
> Server.domain | UNREACHABLE! => {
> "changed": false,
> "msg": "ntlm: ('Connection aborted.', error(104, 'Connection reset by
> peer'))",
> "unreachable": true
> }
>
>
> On Monday, June 6, 2016 at 2:35:39 PM UTC+2, J Hawkesworth wrote:
>>
>> Interesting.
>>
>> This change was recently added so you can force the
>> ConfigureRemotingForAnsible.ps1 to generate a new self-signed cert by
>> running like this:
>>
>> .\ConfigureRemotingForAnsible.ps1 -ForceNewSSLCert true
>>
>> https://github.com/ansible/ansible/pull/15275
>>
>> As its says in the PR 'This is necessary when a CN name changes and the
>> self-signed cert is no longer valid and winRM is not allowing a connection
>> because of winRM SSL validation errors.'
>>
>> Hope this helps,
>>
>> Jon
>>
>> On Monday, June 6, 2016 at 1:20:21 PM UTC+1, Mike Fennemore wrote:
>>>
>>> I'm beginning to think this might be as a result of the problem servers
>>> being templated in VMWare perhaps?
>>>
>>> On Wednesday, June 1, 2016 at 7:41:50 PM UTC+2, Matt Davis wrote:
>>>>
>>>> Sorry, by "local user" I just meant using a non-domain user via
>>>> pywinrm/Ansible. But yeah, for Basic to work, you'd have to (temporarily)
>>>> enable unencrypted auth with something like:
>>>>
>>>> Set-Item WSMan:\localhost\Service\AllowUnencrypted $true
>>>>
>>>> The HTTPS_PROXY not working seems odd- I use it dozens of times a
>>>> day... Sure you've got it exported? The problem is almost certainly on the
>>>> control-machine side, as it'd just hang if the envvar worked and Fiddler
>>>> wasn't configured properly.
>>>>
>>>> On Monday, May 30, 2016 at 12:45:48 AM UTC-7, Mike Fennemore wrote:
>>>>>
>>>>> For testing locally I'm assuming you mean Test-WSMan -Authentication
>>>>> Basic -Credential <problem account> ? I am currently connecting on 5986
>>>>> with ignore certificate validation turned on.
>>>>> So in that case I would add -UseSSL switch on the Test-WSMan.
>>>>> Currently running Test-WSMan -Authentication Basic -Credential <problem
>>>>> account> gives:
>>>>>
>>>>> Test-WSMAN : <f:WSManFault xmlns:f="
>>>>> http://schemas.microsoft.com/wbem/wsman/1/wsmanfault";
>>>>> Code="2150858974" Machine="Server101"><f:Message>The WinRM client cannot
>>>>> process the request. Unencrypted traffic is currently disabled in the
>>>>> client configuration. Change the client configuration and try the request
>>>>> again. </f:Message></f:WSManFault>
>>>>> At line:1 char:1
>>>>>
>>>>> Normally I would say that would mean mean configuring AllowUnencrypted
>>>>> on Winrm Client, however the other working systems do not have this
>>>>> configured.
>>>>>
>>>>> Running Test-WSMAN -Authentication Negotiate -Credential "<user>"
>>>>> -ComputerName localhost returns:
>>>>>
>>>>> wsmid :
>>>>> http://schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentity.xsd
>>>>> ProtocolVersion : http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd
>>>>> ProductVendor : Microsoft Corporation
>>>>> ProductVersion : OS: 6.3.9600 SP: 0.0 Stack: 3.0
>>>>>
>>>>> I will try the Fiddler method shortly and return the results.
>>>>>
>>>>> On Friday, May 27, 2016 at 7:48:53 PM UTC+2, Matt Davis wrote:
>>>>>>
>>>>>> Hey Mike,
>>>>>>
>>>>>> Unfortunately pywinrm currently has *zero* logging/diagnostic
>>>>>> capabilities (something I'd like to correct for troubleshooting stuff
>>>>>> like
>>>>>> this). Meantime...
>>>>>>
>>>>>> A couple of things to try:
>>>>>> - Does it work with Basic auth and a local user on that same box?
>>>>>> - Any chance you could run with Fiddler in the middle? Just run
>>>>>> Fiddler on some Windows box, configure it to capture/decrypt HTTPS and
>>>>>> to
>>>>>> allow external connection, then on your Ansible controller, export
>>>>>> HTTPS_PROXY=http://(ip-of-fiddler-box):8888/ and go watch the fun.
>>>>>>
>>>>>> I'm mostly just curious where the connection reset is occurring, as
>>>>>> there are numerous round-trips involved here (eg, is it NTLM auth
>>>>>> failure,
>>>>>> resource issue, or something else?).
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> -Matt
>>>>>>
>>>>>>
>>>>>> On Friday, May 27, 2016 at 7:26:32 AM UTC-7, Mike Fennemore wrote:
>>>>>>>
>>>>>>> I have a selected few workgroup Windows server 2012 R2 servers that
>>>>>>> give the following error:
>>>>>>>
>>>>>>> <10.128.44.37> ESTABLISH WINRM CONNECTION FOR USER: ansible_user on
>>>>>>> PORT 5986 TO 10.128.44.37
>>>>>>> server_101 | UNREACHABLE! => {
>>>>>>> "changed": false,
>>>>>>> "msg": "ntlm: ('Connection aborted.', error(104, 'Connection
>>>>>>> reset by peer'))",
>>>>>>> "unreachable": true
>>>>>>> }
>>>>>>>
>>>>>>> I am using ntlm with Ansible 2.1.0.0 and pywinrm [kerberos] 2RC4. I
>>>>>>> have tested the port is open, recreated the listeners, run a curl to
>>>>>>> the
>>>>>>> server which delivers a successful 411 response.
>>>>>>> Any ideas on further troubleshooting?
>>>>>>>
>>>>>>>
>>>>>>>
--
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/0d5e6c22-ae30-44cd-9393-89c7e190454a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
