[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cifs-protocol
Subject:    Re: [cifs-protocol] [REG: 111052361876778] RE: userParameters
From:       Andrew Bartlett <abartlet () samba ! org>
Date:       2011-05-29 23:23:35
Message-ID: 1306711415.3062.7.camel () obed
[Download RAW message or body]

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

_______________________________________________
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol


[prev in list] [next in list] [prev in thread] [next in thread]