[cifs-protocol] [REG: 111052361876778] RE: userParameters attribute

[Andrew Bartlett]

On Fri, 2011-05-27 at 22:40 +0000, Hongwei Sun wrote:
> Metze,
> 
>    The UserParameters attribute was documented in 2.345  MS-ADA3.  It is defined as a Unicode string as below:
>   
>     " This attribute specifies parameters of the user. Points to a Unicode string that is set aside for use by 
> applications. This string can be a null string, or it can have any number of characters before the 
> terminating null character. Terminal servers use this attribute to store session configuration data for 
> the user. For more information, see [MS-TSTS]."
>  
>     As per MD-GLOS , throughout the protocol document,  unless otherwise specified ,  an Unicode string follows the UTF-
> 16LE encoding scheme with no Byte Order Mark (BOM).   so it is not documented as UTF8 Unicode string.
> 
>    But  I am wondering if it matters what kind of Unicode encoding (utf8 vs utf16)  is used.    The structure layout of this attribute is documented in 2.3.1 MS-TSTS.  It is just a BLOB interpreted by the Terminal Service , not a  null terminated Unicode string.    We may be not correct to define the attribute as a Unicode string (attributeSyntax: 2.5.5.12 ) in 2.345 MS-ADA3.    I will  file a request to check with the product team. 

I thought it wasn't NULL terminated in the traditional sense, as the
Terminal Services stuff has embedded NULLs, and was after a NULL that
allowed it to be stuffed there in the first place.

The story I recall is that when Terminal services was first developed
outside Microsoft, that the dialback string for RAS was the only
parameter in the SAM that could be safely extended, and this was done
after the initial terminating NULL (of the RAS dialback string).  

We have had some real trouble dealing with this over time, with Samba3
domains hosting terminal services, and that's why we want to get this
right, once and for all for Samba4.  In particular, we are keen to
ensure we know exactly the right transformations required between the
LDAP and RPC representations.  Even if it is a duplicate, it is a
special enough case to warrant a clear, specific explanation or
clarification. 

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org