Windows Vista Forums
Vista Forums Home Join Vista Forums Donate Vista Tutorials Tags

Welcome to Vista Forums we are your forum to discuss Windows Vista x64 and x86 systems. Whether you need help or just want to post an idea you have on Vista, this is the forum for you.
Register at Vista forums...the world biggest Windows Vista resource Join Vista Forums Now

Go Back   Vista Forums > Microsoft Technical Newsgroups > PowerShell

Winrm behaviour on negotiate auth..

Update your Vista Drivers Update Your Drivers Now!!
Closed Thread
 
Thread Tools Display Modes
Old 06-30-2008   #1 (permalink)
Venkat_srin
Guest


 

Winrm behaviour on negotiate auth..

Hi,
I am trying to get the negotiate auth working with WinRM.
The code is as follows,
I have created a XMLHttpRequest and am trying to get a WMI class through
WinRM through a POST request.
I have enabled only negotiate auth on WinRM side.
I’ve coded my javascript to send a POST request with a soap-xml.
When I try to get this code working from IE7, I find that the browser sends
the POST request with authorization set NTLM as the first request to the
WinRM server.

I am trying to understand how this is possible?
As far as I know the flow for negotiate should be as follows,

The client requests a protected resource from the server:
GET /index.html HTTP/1.1

The server responds with a 401 status, indicating that the client must
authenticate.
"NTLM" is presented as a supported authentication mechanism via the
"WWW-Authenticate" header.
Typically, the server closes the connection at this time:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: NTLM
Connection: close


The client resubmits the request with an "Authorization" header containing a
Type 1 message parameter.
The Type 1 message is Base-64 encoded for transmission.
From this point forward, the connection is kept open; closing the connection
requires reauthentication of subsequent requests.
This implies that the server and client must support persistent connections,
via either the HTTP 1.0-style
"Keep-Alive" header or HTTP 1.1 (in which persistent connections are
employed by default).
The relevant request headers appear as follows (the line break in the
"Authorization" header below is for display purposes only, and is not present
in the actual message):

GET /index.html HTTP/1.1
Authorization: NTLM TlRMTVNTUAABAAAABzIAAAYABgArAAAACwALACAAAABXT1
JLU1RBVElPTkRPTUFJTg==

The server replies with a 401 status containing a Type 2 message in the
"WWW-Authenticate" header (again, Base-64 encoded).
This is shown below (the line breaks in the "WWW-Authenticate" header are
for editorial clarity only, and are not present in the actual header).

HTTP/1.1 401 Unauthorized
WWW-Authenticate: NTLM TlRMTVNTUAACAAAADAAMADAAAAABAoEAASNFZ4mrze8
AAAAAAAAAAGIAYgA8AAAARABPAE0AQQBJAE4AAgAMAEQATwBNAEEASQBOAAEADABTA
EUAUgBWAEUAUgAEABQAZABvAG0AYQBpAG4ALgBjAG8AbQADACIAcwBlAHIAdgBlAHI
ALgBkAG8AbQBhAGkAbgAuAGMAbwBtAAAAAAA=

The client responds to the Type 2 message by resubmitting the request with
an "Authorization" header containing a Base-64 encoded Type 3 message
(again, the line breaks in the "Authorization" header below are for display
purposes only):

GET /index.html HTTP/1.1
Authorization: NTLM TlRMTVNTUAADAAAAGAAYAGoAAAAYABgAggAAAAwADABAAA
AACAAIAEwAAAAWABYAVAAAAAAAAACaAAAAAQIAAEQATwBNAEEASQBOAHUAcwBlAHIA
VwBPAFIASwBTAFQAQQBUAEkATwBOAMM3zVy9RPyXgqZnr21CfG3mfCDC0+d8ViWpjB
wx6BhHRmspst9GgPOZWPuMITqcxg==

Finally, the server validates the responses in the client's Type 3 message
and allows access to the resource.
HTTP/1.1 200 OK


But what I find is that,
The first request which reaches the WinRM server is,
GET /index.html HTTP/1.1
Authorization: NTLM TlRMTVNTUAABAAAABzIAAAYABgArAAAACwALACAAAABXT1
JLU1RBVElPTkRPTUFJTg==


Meaning IE is somehow able to figure out that NTLM is the authorization to
be used?
How is this done?
Any reason for WinRM to respond in this fashion (or) have I got something
wrong here?


Venkat


My System SpecsSystem Spec
Old 06-30-2008   #2 (permalink)
Venkat_srin
Guest


 

Re: Winrm behaviour on negotiate auth..

Thanks a lot for your inputs.
Please find answers to questions which you had posed below,

1.> If you can find a link that supports what you believe the "handshake"
Quote:

> should look like, I can try to reproduce.
<http://msdn.microsoft.com/en-us/library/ms995329.aspx>
The link talks about how the handshake should look like.

2.What OS? What version of WinRM? Have you tried the WinRM 2.0 CTP2 also?
OS - Windows 2003 server r2 sp1 rtm.
Version of winrm - 1.1
No, i have not tried the same on CTP2.
I will try now.
As i see the download of CTP2 i find that this works only on server'08 and
vista
I would like to see this also work for server'03 and XP!

3.> Sounds like you're using the WinRM COM interface. Have you tried a
Quote:

> browser other than IE7?
Yes, i have tried the same from mozilla and there the winrm server does not
provide the proper negotiation schemes.
That is the problem i am facing.
The winrm server is supposed to respond with the proper negotiation schemes
which it can support like NTLM,kerberos etc.
But it does not do it!
I wanted to know if this is a known issue?

Venkat
My System SpecsSystem Spec
Old 06-30-2008   #3 (permalink)
Marco Shaw [MVP]
Guest


 

Re: Winrm behaviour on negotiate auth..

> 2.What OS? What version of WinRM? Have you tried the WinRM 2.0 CTP2 also?
Quote:

> OS - Windows 2003 server r2 sp1 rtm.
> Version of winrm - 1.1
> No, i have not tried the same on CTP2.
> I will try now.
> As i see the download of CTP2 i find that this works only on server'08 and
> vista
> I would like to see this also work for server'03 and XP!
What's the setup as far as whether the client and server or in a domain
or workgroup? Are you testing this only locally by any chance by
connecting to localhost or 127.0.0.1?
Quote:

> 3.> Sounds like you're using the WinRM COM interface. Have you tried a
Quote:

>> browser other than IE7?
> Yes, i have tried the same from mozilla and there the winrm server does not
> provide the proper negotiation schemes.
> That is the problem i am facing.
> The winrm server is supposed to respond with the proper negotiation schemes
> which it can support like NTLM,kerberos etc.
> But it does not do it!
The WinRM server depends on HTTP.sys. I don't see anything just yet
about whether the server-side could be an issue. After all, later
versions (maybe not IIS7) depend somewhat on HTTP.sys, so I'd assume if
IIS5 can do it, so can HTTP.sys.
Quote:

> I wanted to know if this is a known issue?
I don't know.

Marco
My System SpecsSystem Spec
Old 06-30-2008   #4 (permalink)
Marco Shaw [MVP]
Guest


 

Re: Winrm behaviour on negotiate auth..

Quote:

> The WinRM server depends on HTTP.sys. I don't see anything just yet
> about whether the server-side could be an issue. After all, later
> versions (maybe not IIS7) depend somewhat on HTTP.sys, so I'd assume if
> IIS5 can do it, so can HTTP.sys.
Oh, and... You mention it is the client who doesn't appear to
negotiating properly.

Now, are you sure that's the first message coming from the client? Just
want to make sure you don't already have a session setup beforehand
which has determined the auth protocol already.

From what I understand, if you have keep-alives set on the server-side,
then you will continue with the same auth scheme once negotiated.

Marco
My System SpecsSystem Spec
Old 06-30-2008   #5 (permalink)
Venkat_srin
Guest


 

Re: Winrm behaviour on negotiate auth..

So how do i disable the server side keep-alive?
Is it possible that i do this through winrm?
I couldn't find such a thing in msdn though!

I think the best way to answer your question is to explain what the output
looks like in case of
the browser based script,

C->Server POST request sent

S->Client HTTP 401 WWW-Negotiate.

No schemes being sent.

The problem i am facing is that since the scheme is not being sent mozilla
is not able to negotiate this request!

Mozilla expects the response from the server to list down all the schemes
which are supported (like NTLM/Kerberos).

Also to answer your previous question(s),

I am trying to connect from a remote client box which is part of a domain to
a server which happens to be part of a workgroup.

I will try again to restart the server and see to that the server does not
work on an existing connection!


Venkat


"Marco Shaw [MVP]" wrote:
Quote:

>
Quote:

> > The WinRM server depends on HTTP.sys. I don't see anything just yet
> > about whether the server-side could be an issue. After all, later
> > versions (maybe not IIS7) depend somewhat on HTTP.sys, so I'd assume if
> > IIS5 can do it, so can HTTP.sys.
>
> Oh, and... You mention it is the client who doesn't appear to
> negotiating properly.
>
> Now, are you sure that's the first message coming from the client? Just
> want to make sure you don't already have a session setup beforehand
> which has determined the auth protocol already.
>
> From what I understand, if you have keep-alives set on the server-side,
> then you will continue with the same auth scheme once negotiated.
>
> Marco
>
My System SpecsSystem Spec
Old 07-01-2008   #6 (permalink)
Venkat_srin
Guest


 

Re: Winrm behaviour on negotiate auth..


Attached find the wireshark dump.

I see only the response from winrm which says,

WWW-Authenticate: Negotiate\r\n where in i am expecting WWW-Authenticate: NTLM

No. Time Source Destination Protocol Info
185 19.559840 10.94.145.201 10.94.22.74 HTTP
HTTP/1.1 401

Ethernet II, Src: Dell_31:41:c8 (00:11:43:31:41:c8), Dst: Cisco_84:5a:41
(00:1b:53:84:5a:41)
Internet Protocol, Src: 10.94.145.201 (10.94.145.201), Dst: 10.94.22.74
(10.94.22.74)
Transmission Control Protocol, Src Port: http (80), Dst Port: lbc-sync
(2779), Seq: 1, Ack: 1461, Len: 191
Hypertext Transfer Protocol
HTTP/1.1 401 \r\n
Request Version: HTTP/1.1
Response Code: 401
Server: Microsoft-HTTPAPI/1.0\r\n
WWW-Authenticate: Negotiate\r\n
WWW-Authenticate: Basic realm="WSMAN"\r\n
Date: Tue, 01 Jul 2008 18:23:54 GMT\r\n
Connection: close\r\n
Content-Length: 0
\r\n




No. Time Source Destination Protocol Info
187 19.560165 10.94.22.74 10.94.145.201 HTTP/XML
POST /wsman HTTP/1.1

Frame 187 (412 bytes on wire, 412 bytes captured)
Ethernet II, Src: Cisco_84:5a:41 (00:1b:53:84:5a:41), Dst: Dell_31:41:c8
(00:11:43:31:41:c8)
Internet Protocol, Src: 10.94.22.74 (10.94.22.74), Dst: 10.94.145.201
(10.94.145.201)
Transmission Control Protocol, Src Port: lbc-sync (2779), Dst Port: http
(80), Seq: 1461, Ack: 1, Len: 358
[Reassembled TCP Segments (1818 bytes): #184(1460), #187(358)]
Hypertext Transfer Protocol
POST /wsman HTTP/1.1\r\n
Request Method: POST
Request URI: /wsman
Request Version: HTTP/1.1
Host: 10.94.145.201:80\r\n
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2)
Gecko/2007121120 Firefox/3.0b2\r\n
Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n
Accept-Language: en-us,en;q=0.5\r\n
Accept-Encoding: gzip,deflate\r\n
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\n
Keep-Alive: 300\r\n
Connection: keep-alive\r\n
Authorization: Basic\r\n
SOAPAction: Enumerate\r\n
Content-Type: application/soap+xml; charset=utf-8\r\n
Content-Length: 1281
Pragma: no-cache\r\n
Cache-Control: no-cache\r\n
\r\n
eXtensible Markup Language
<?xml
<s:Envelope
xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://schemas.xmlsoap.org/ws/2004/08/addressing"
xmlns:n="http://schemas.xmlsoap.org/ws/2004/09/enumeration"
xmlns:w="http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd">
<s:Header>
<a:To>
http://10.94.145.201:80/wsman
</a:To>
<w:ResourceURI
s:mustUnderstand="true">

http://schemas.microsoft.com/wbem/ws...v2/cim_process
</w:ResourceURI>

<!--************************************\n\t<w:SelectorSet>\n\t\n\t\t<Selector
Name="">2</Selector>\n\t</w:SelectorSet>\n\t****************************************-->
<a:ReplyTo>
<a:Address
s:mustUnderstand="true">

http://schemas.xmlsoap.org/ws/2004/0...nonymous\n\t\t
</a:Address>
</a:ReplyTo>
<a:Action
s:mustUnderstand="true">
http://schemas.xmlsoap.org/ws/2004/0...tion/Enumerate
</a:Action>
<w:MaxEnvelopeSize
s:mustUnderstand="true">
153600
</w:MaxEnvelopeSize>
<a:MessageID>
uuid:OPH90OL1-PM15-PK62-MBX1-81350L03QD12
</a:MessageID>
<w:Locale
xml:lang="en-US"
s:mustUnderstand="false"/>
<w:OperationTimeout>
PT60.00S
</w:OperationTimeout>
</s:Header>
<s:Body>
<n:Enumerate>
<w:OptimizeEnumeration/>
<w:MaxElements>
20
</w:MaxElements>
</n:Enumerate>
</s:Body>
</s:Envelope>


No. Time Source Destination Protocol Info
6884 369.246843 10.94.145.201 10.94.22.74 HTTP
HTTP/1.1 401

Frame 6884 (245 bytes on wire, 245 bytes captured)
Ethernet II, Src: Dell_31:41:c8 (00:11:43:31:41:c8), Dst: Cisco_84:5a:41
(00:1b:53:84:5a:41)
Internet Protocol, Src: 10.94.145.201 (10.94.145.201), Dst: 10.94.22.74
(10.94.22.74)
Transmission Control Protocol, Src Port: http (80), Dst Port: nmsigport
(2839), Seq: 1, Ack: 483, Len: 191
Hypertext Transfer Protocol
HTTP/1.1 401 \r\n
Request Version: HTTP/1.1
Response Code: 401
Server: Microsoft-HTTPAPI/1.0\r\n
WWW-Authenticate: Negotiate\r\n
WWW-Authenticate: Basic realm="WSMAN"\r\n
Date: Tue, 01 Jul 2008 18:29:44 GMT\r\n
Connection: close\r\n
Content-Length: 0
\r\n



Look into the following link,
http://msdn.microsoft.com/en-us/library/cc208304.aspx

It says that the webserver should respond with a WWW-Authenticate: Negotiate.
But winrm does not!
Any reason for the same.

Venkat


"Venkat_srin" wrote:
Quote:

> So how do i disable the server side keep-alive?
> Is it possible that i do this through winrm?
> I couldn't find such a thing in msdn though!
>
> I think the best way to answer your question is to explain what the output
> looks like in case of
> the browser based script,
>
> C->Server POST request sent
>
> S->Client HTTP 401 WWW-Negotiate.
>
> No schemes being sent.
>
> The problem i am facing is that since the scheme is not being sent mozilla
> is not able to negotiate this request!
>
> Mozilla expects the response from the server to list down all the schemes
> which are supported (like NTLM/Kerberos).
>
> Also to answer your previous question(s),
>
> I am trying to connect from a remote client box which is part of a domain to
> a server which happens to be part of a workgroup.
>
> I will try again to restart the server and see to that the server does not
> work on an existing connection!
>
>
> Venkat
>
>
> "Marco Shaw [MVP]" wrote:
>
Quote:

> >
Quote:

> > > The WinRM server depends on HTTP.sys. I don't see anything just yet
> > > about whether the server-side could be an issue. After all, later
> > > versions (maybe not IIS7) depend somewhat on HTTP.sys, so I'd assume if
> > > IIS5 can do it, so can HTTP.sys.
> >
> > Oh, and... You mention it is the client who doesn't appear to
> > negotiating properly.
> >
> > Now, are you sure that's the first message coming from the client? Just
> > want to make sure you don't already have a session setup beforehand
> > which has determined the auth protocol already.
> >
> > From what I understand, if you have keep-alives set on the server-side,
> > then you will continue with the same auth scheme once negotiated.
> >
> > Marco
> >
My System SpecsSystem Spec
Closed Thread

Thread Tools
Display Modes



Similar Threads
Thread Thread Starter Forum Replies Last Post
cmd.exe suddenly requires admin auth to run Killarny Vista General 0 03-08-2008 08:42 PM
OE - error ERR auth not enabled? Finz Vista mail 1 10-25-2007 09:20 PM
SMTP Auth and Windows Mail Ric Messier Vista mail 1 08-27-2007 06:10 PM
VPN auth BEFORE login (domain users) LeMassyKoi Vista networking & sharing 1 07-27-2007 11:28 AM
anyone have a key left? willing to negotiate =?Utf-8?B?Q2FybG9zIEFsZmFybw==?= Vista installation & setup 3 07-18-2006 03:28 PM


Vistax64.com is an independent web site and has not been authorized,
sponsored, or otherwise approved by Microsoft Corporation.
"Windows Vista", the Start Orb, and related materials are trademarks of Microsoft Corp.
© Designer Media 2005-2008

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51