WinRM DS_user DS_userparameters

Greetings.

I've been doing development in the area of querying WinRM on a server for
Active Directory information (as well as other types of information). I've
enumerated the domain users on a system using both WinRM client and my own C#
code. Both approaches detect an HTTP character error in the response. There
is a 0x01 byte being returned in the middle of a series of spaces (0x20) for
the inner text of the <DS_userparameters> element of one of the users being
enumerated. The WinRM client as well as the .NET XML reader class end up
complaining about the invalid character. The byte can be clearly seen on a
network trace of the HTTP transaction. The 0x01 byte is at 0xD5A0 in the
following network trace.

0000D56F 75 65 22 2f 3e 3c 70 3a 44 53 5f 75 73 65 72 50 ue"/><pS_userP
0000D57F 61 72 61 6d 65 74 65 72 73 3e 6d 3a 20 20 20 20 arameters>m:
0000D58F 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
0000D59F 64 01 20 20 20 20 20 20 20 20 20 20 20 20 20 20 d.
0000D5AF 20 20 20 20 20 20 20 20 20 20 3c 2f 70 3a 44 53 </pS
0000D5BF 5f 75 73 65 72 50 61 72 61 6d 65 74 65 72 73 3e _userParameters>

I thought it would be appropriate to pass this along to the WinRM team. I'm
reasonably sure I'm running the latest WinRM on a Windows Server 2003 (not
R2) with all the latest Windows Updates applied.

kburgoyne wrote: I'll try to look at it in detail, and ask for more information tomorrow.

There's a WinRM 2.0 CTP out now, but only for Vista and 2008.

Marco

--
Microsoft MVP - Windows PowerShell
http://www.microsoft.com/mvp

PowerGadgets MVP
http://www.powergadgets.com/mvp

Blog:
http://marcoshaw.blogspot.com

kburgoyne wrote: Before I report it to them, could you try the WinRM 2.0 CTP:
https://connect.microsoft.com/site/s...spx?SiteID=200

You'll need Vista or 2008 though.

Marco

--
Microsoft MVP - Windows PowerShell
http://www.microsoft.com/mvp

PowerGadgets MVP
http://www.powergadgets.com/mvp

Blog:
http://marcoshaw.blogspot.com

Hi Marco --

Being a developer, I completely understand the desire to only worry about
the problem if it occurs on the latest release. Unfortunately we're just a
little garage-shop start-up operation at this point, and so we don't have the
spare machines configured with 08 or Vista (yet). What we're developing has
a wider client base using 03 and XP systems at this time, but we'll certainly
be pursuing 08 and Vista in the future.

I did a lot of testing and narrowed down the issue for the WinRM team.

The focus is specifically on the DS_userParameters element of the DS_user
class of Active Directory. The Active Directory documentation says that the
UserParameters attribute of the User class contains a null-terminated Unicode
string. That implies the attribute should only contain human-readable data,
which should be fine to use "as is" in HTTP/XML. However, testing indicates
that the UserParameters attribute under Active Directory can contain
non-human readable data.

Please reference the hex dump I provided earlier. The users being enumerated
from our 03 server have that exact same data pattern for their
DS_userParameters element, but with a single byte difference at location
0xD5A0 in the provided dump. Many of the users have a 0x09 byte at that
position, while only a few have a 0x01 byte. The 0x09 byte is acceptable for
HTTP/XML, but the 0x01 is not.

Using that information, I investigated the account settings for the users.
Note that the difference between the 0x01 and 0x09 byte values is only the
state of the 0x08 bit. After investigation and testing, it turns out that
the 0x08 bit is the following setting under MMC:

Active Directory Users and Computers Snap-in
User Properties
Dial-in Tab
Remote Access Permissions (Dial-in or VPN) Panel
Allow access Radio Button

If Allow Access is selected, the byte value is 0x09. If Deny Access is
selected, the byte value is 0x01. The remaining settings for that tab are:

Verify Caller-ID: Unchecked
Calback Options: No Callback
Assigned a Static IP Address: Unchecked
Apply Static Routes: Unchecked

Those additional settings may also be important since they may influence
other bits in that byte value.

I did follow the CTP link you provided with the intention of checking any
release notes to see if the problem had been addressed already. I was not
able to find a reference to any release notes.

Best regards.

kburgoyne wrote: I've emailed the WinRM team with the info provided in your 2 posts.

Marco

kburgoyne wrote: Can you email me directly? Remove the "_NO_SPAM_" from the address on
this post...

Marco