RE: [cifs-protocol] String and binary forms of attributes
Andrew, Thanks for the question regarding string and binary forms of AD attributes. We will review your question and let you know as soon as our investigation completes. Thanks -- Hongwei Sun - Support Escalation Engineer DSC Protocol Team, Microsoft [EMAIL PROTECTED] Tel: 469-7757027 x 57027 --- -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Bartlett Sent: Monday, June 09, 2008 2:59 AM To: Interoperability Documentation Help Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [cifs-protocol] String and binary forms of attributes I am requesting correction assistance on the string and binary forms of these attributes: In MS-ADA3 - 2.43 and 2.44 we see a description of the objectGUID and objectSID attributes. Helpful cross-references to MS-DTYP are included. However, no reference in either document is made to the ability of AD LDAP servers to accept string (rather than binary) forms of these attributes in searches. Is there a schema attribute that defines which attribute types allow these kinds of polymorphic searches, or is it a hard-coded list? What other attributes have such flexible matching rules? Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] FW: Specific sockaddr layout in MS-ADTS 7.3.1.7
Andrew, For your questions, the following are responses. 1. when IPv6 is in use? Our current server versions only support returning IPv4. We can add the information into the documentation. 2. Are there any other protocols (hey IPX ;-) that are possibly represented by this wire element? No other protocols , IP only. Thanks -- Hongwei Sun - Support Escalation Engineer DSC Protocol Team, Microsoft [EMAIL PROTECTED] Tel: 469-7757027 x 57027 --- -Original Message- From: Andrew Bartlett [mailto:[EMAIL PROTECTED] Sent: Thursday, June 05, 2008 5:42 PM To: Hongwei Sun Cc: cifs-protocol@cifs.org; [EMAIL PROTECTED] Subject: Re: Specific sockaddr layout in MS-ADTS 7.3.1.7 On Thu, 2008-06-05 at 09:03 -0700, Hongwei Sun wrote: Hi, Andrew, In response to your question regarding DcSocketAddr structure in NETLOGON_SAM_LOGON_RESPONSE_EX , we confirmed that this structure has the following layout . Bytes Elements ByteOrder Notes 0-1sin_family LittleEndian Value should always be AF_INET 2-3sin_port LittleEndian Value should always be 0 4-7sin_addr BigEndian IPV4 address 8-15 sin_zero Just padding 0s We will update the documentation [MS-ADTS] accordingly in the future release. Thanks again for helping us improve protocol documentation. And when IPv6 is in use? Are there any other protocols (hey IPX ;-) that are possibly represented by this wire element? Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] RE: Specific sockaddr layout in MS-ADTS 7.3.1.7
Hi, Andrew, We have completed our investigation on Window clients implementation regarding NETLOGON_NT_VERSION_5EX_WITH_IP bit. We confirmed that in all clients of Windows NT 4 or higher, NETLOGON_NT_VERSION_5EX_WITH_IP bit of NtVersion flag is always set for NetBIOS based mailslot ping, but is never set for LDAP ping. We verified in our testing that clients did set this bit when a NetBIOS domain name is used. Please let us know if you have further questions. Thanks ! Hongwei -Original Message- From: Andrew Bartlett [mailto:[EMAIL PROTECTED] Sent: Thursday, June 26, 2008 5:21 PM To: Hongwei Sun Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: Specific sockaddr layout in MS-ADTS 7.3.1.7 On Thu, 2008-06-26 at 14:03 -0700, Hongwei Sun wrote: Hi, Andrew, Thanks for your question regarding NETLOGON_NT_VERSION_5EX_WITH_IP flag. In terms of the server, it is not deprecated. That is, current servers still support requests that include this flag and respond appropriately. For a server to be interoperable with Windows clients, it needs to accept the flag in either way whenever it is sent. The documentation explains what server should do if the bit is set in the NtVersion flag and what server should do if it is not set and that it should be prepared to accept a communication that contains this flag at any time. Any actions taken by a Windows client based on this flag do not affect the interoperability of a server implementation. All those words, yet no new information! Can you please answer the question: What windows client will set this flag, and under what circumstances? If no Microsoft clients set this flag, then can the documentation be updated to reflect this. This is an important question for implementers. We could spend all year implementing things that Microsoft servers do, but if we concentrate our efforts on the things that exist the the real world, then we are all much more productive. Perhaps you could escalate this question to someone who is able to find this out? Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] RE: CAR - missing SMB2 SetFileInfo levels
STATUS_NOT_SUPPORTED 45+ STATUS_INVALID_INFO_CLASS 2. For setting file system information ( InfoType = SMB2_0_INFO_FILESYSTEM) The responses for all possible levels are listed as below. Level Name IF Supported Error Codes 1 FileFsVolumeInformation STATUS_INVALID_INFO_CLASS 2FileFsLabelInformation STATUS_NOT_SUPPORTED 3FileFsSizeInformation STATUS_INVALID_INFO_CLASS 4 FileFsDeviceInformation STATUS_INVALID_INFO_CLASS 5FileFsAttributeInformation STATUS_INVALID_INFO_CLASS 6 FileFsControlInformation SUPPORTED 7FileFsFullSizeInformation STATUS_INVALID_INFO_CLASS 8FileFsObjectIdInformation SUPPORTED 9FileFsDriverPathInformation STATUS_INVALID_INFO_CLASS 10 FileFsVolumeFlagsInformation SUPPORTED The information above will be added into the future release of [MS-SMB2] and [MS-FSCC]. The update of the documents are still in progress. Please let us know if this provides all the information you need or you need further clarification in the documents. Thanks -- Hongwei Sun - Support Escalation Engineer DSC Protocol Team, Microsoft [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] Tel: 469-7757027 x 57027 --- -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, May 30, 2008 8:52 PM To: Interoperability Documentation Help Cc: [EMAIL PROTECTED] Subject: CAR - missing SMB2 SetFileInfo levels Hi, MS-SMB2 section 2.2.39 says that these are the only 12 levels for setfileinfo: FileBasicInformation4 FileRenameInformation 10 FileLinkInformation11 FileDispositionInformation 13 FilePositionInformation14 FileFullEaInformation 15 FileModeInformation16 FileAllocationInformation 19 FileEndOfFileInformation 20 FilePipeInformation23 FileValidDataLengthInformatio 39 FileShortNameInformation 40 Section 3.3.5.20.1 says that any unsupported level must respond with STATUS_INVALID_INFO_CLASS A scanner in our testsuite (the SMB2-SCANSETINFO test) shows that Vista responds to an additional 11 levels with some other error code, indicating that the level is available. The additional levels are 25, 27, 29, 30, 31, 32, 36, 41, 42, 43, 44 Can you please document these additional levels? The scan also shows that Vista responds to 4 setfsinfo levels: 2, 6, 8, 10 but the doc only lists 6 and 8. Can you please document the extra 2 levels? Cheers, Tridge ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
RE: [cifs-protocol] Clarify AEAD behaviour for GSSAPI with AES
Hi, Andrew, Thanks for your comments and the diagram attached. The security product group will review the content of the diagram to see whether we can incorporate it into the document. Before we can use the diagram, we would like to confirm that Mr. Astrand is covered by the PFIF WSPP agreement that gives Microsoft a broad license to use and distribute any comments or suggestions to improve the WSPP documentation. This license is dependent on whether Mr. Astrand is a member of PFIF/Samba. We also need to know if the he is expecting attribution for the work. We appreciate your efforts to help us improve protocol documentation. Thanks -- Hongwei Sun - Support Escalation Engineer DSC Protocol Team, Microsoft [EMAIL PROTECTED] Tel: 469-7757027 x 57027 --- -Original Message- From: Andrew Bartlett [mailto:[EMAIL PROTECTED] Sent: Monday, August 04, 2008 7:13 PM To: Hongwei Sun Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [cifs-protocol] Clarify AEAD behaviour for GSSAPI with AES On Thu, 2008-07-31 at 14:36 -0700, Hongwei Sun wrote: Andrew, The encryption function in Kerberos is described in details in 5.3 [RFC3961] (http://www.ietf.org/rfc/rfc3961.txt), which is referenced by [MS-KILE]. I can summarize as follows ·conf is actually a random confounder prefix of length c ,such as 16. ·pad is for shortest padding to bring confounder and plaintext to a length that is the multiple of message block size m, which is octet(8) for AES encryption, as specified in section 6 [RFC 3962] (http://www.ietf.org/rfc/rfc3962.txt) · Ke is an encryption key and Ki is a checksum key. ·Plain text is the input confidential data before encryption. ·The GSSWrapEX() is exactly the same as the GSSWrap except that it supports ordered list of input buffers. Input buffers for which conf_req_flag == TRUE are encrypted and returned. Buffers which sign == TRUE are included in the signature. ·We use the Kerberos standard’s encryption and signatures. It is very important to concatenate the correct buffers to make it work. Indeed - and that is why I am asking for this to be much more clearly specified. I find digrams much more useful - see the attached work by Love Hörnquist Åstrand [EMAIL PROTECTED]. Can you please expand MS-KILE with this information? Thanks, -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
RE: [cifs-protocol] Session keys are not always 16 bytes long
Hi, Andrew, In our last conference call, we talked about your question regarding which of the numerous keys Kerberos produce is considered the 'SMB session key'. I had discussions with the product team to find what or how should be documented. You mentioned that you would like to see the document to specify which GSSAPI call returns the session key. They would like to have a little more background information, which you already talked about a little bit during our conversation. I just want to confirm so I can pass it accurately to product team. What do you mean by GSSAPI with CFX ? Do you mean the mechanism conforming to RFC 4121 ? What implementation are you using for GSSAPI with CFX in Vista ? Is it Heimdal's implementation ? What is your expectation about how this detail should be included in the document ? Do you expect it to associate with specific GSSAPI calls? I hope that with the information we can have a resolution soon. Thanks for your patience. Thanks -- Hongwei Sun - Support Escalation Engineer DSC Protocol Team, Microsoft [EMAIL PROTECTED] Tel: 469-7757027 x 57027 --- -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Bartlett Sent: Wednesday, July 23, 2008 12:58 AM To: Interoperability Documentation Help Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [cifs-protocol] Session keys are not always 16 bytes long I'm looking for correction assistance regarding SMB session keys. Our tests show that the session keys, referred consistently in MS-SMB and MS-SAMR as 16 byte quantities are not a simple as they are made out to be. For example, a Windows Vista SP1 client using GSSAPI with CFX will negotiate an AES session key with Samba4. This is 32 bytes long, and all 32 bytes are required to satisfy the SMB signing between Vista SP1 and Samba4. (despite MS-SMB 4.3 talking about a 16 bytes key). Similarly, our tests have shown that for DES kerberos, an 8 byte key is used. However, further in on the domain join, Samr password set operations are made. There similarly we have observed 8 bytes kerberos keys in the past, but testing shows that for the 32 byte key from the Vista join, the key must be truncated to 16 bytes. (See MS-SAMR 3.1.2.2). Please correct the documentation to clearly specify when the variable-length key is used (perhaps make it clear that it is usually, but not always 16 bytes), and when a truncated key is used. Furthermore, please clarify the linkage between MS-SAMR, MS-SMB and MS-KILE regarding session keys. I can't find a clear reference as to which of the numerous keys kerberos produces is considered the 'SMB session key'. Is it not possible to include section numbers in the document cross-references? Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
RE: [cifs-protocol] Session keys are not always 16 bytes long
Stefan, I just found that the session key used to decrypt the password attributes in the DsGetNCChanges() is not truncated. Do you have network trace for this case ? And I need to use gsskrb5_get_subkey() instead of gsskrb5_get_initiator_subkey(), when aes keys are used. Does this happen only when you use AES keys Thanks -- Hongwei Sun - Support Escalation Engineer DSC Protocol Team, Microsoft [EMAIL PROTECTED] Tel: 469-7757027 x 57027 --- -Original Message- From: Stefan (metze) Metzmacher [mailto:[EMAIL PROTECTED] Sent: Friday, August 08, 2008 5:19 AM To: Andrew Bartlett Cc: Hongwei Sun; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [cifs-protocol] Session keys are not always 16 bytes long I just found that the session key used to decrypt the password attributes in the DsGetNCChanges() is not truncated. And I need to use gsskrb5_get_subkey() instead of gsskrb5_get_initiator_subkey(), when aes keys are used. metze In our last conference call, we talked about your question regarding which of the numerous keys Kerberos produce is considered the 'SMB session key'. I had discussions with the product team to find what or how should be documented. You mentioned that you would like to see the document to specify which GSSAPI call returns the session key. They would like to have a little more background information, which you already talked about a little bit during our conversation. I just want to confirm so I can pass it accurately to product team. What do you mean by GSSAPI with CFX ? Do you mean the mechanism conforming to RFC 4121 ? Yes. (I should stop using that term, as it never made it into the RFC) What implementation are you using for GSSAPI with CFX in Vista ? Is it Heimdal’s implementation ? Yes. What is your expectation about how this detail should be included in the document ? Do you expect it to associate with specific GSSAPI calls? An indication of the (hopefully shared) MIT/Heimdal API would be very useful (as these are almost certainly the basis of any new implementations). However, this should be alongside a description of where in the kerberos protocol is is found: 'the session key generated on ... and encrypted in message ... as element ... from (client/server) to the (client/server) is also used as the SMB Session key' (for example) I hope that with the information we can have a resolution soon. Thanks for your patience. No worries, Andrew Bartlett -- -- ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
RE: [cifs-protocol] Generic passthrough gpInput1 mis-named.
Andrew,
I will be working on this request. I will let you know once I complete my
investigation.
Thanks
--
Hongwei Sun - Support Escalation Engineer
DSC Protocol Team, Microsoft
[EMAIL PROTECTED]
Tel: 469-7757027 x 57027
---
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Bartlett
Sent: Sunday, August 10, 2008 11:20 PM
To: Interoperability Documentation Help
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [cifs-protocol] Generic passthrough gpInput1 mis-named.
MS-APDS makes numerious references (eg in 3.2.5.1) to
GenericPassthrough.gpInput1 and GenericPassthrough.gpInput2. These appear to
have been renamed more usefully in the IDL as LogonData and PackageName.
see:
typedef struct _NETLOGON_GENERIC_INFO
{
NETLOGON_LOGON_IDENTITY_INFO Identity;
UNICODE_STRING PackageName;
unsigned long DataLength;
[size_is(DataLength)] unsigned char * LogonData; } NETLOGON_GENERIC_INFO,
*PNETLOGON_GENERIC_INFO;
Please remove references to the gpInput* names, they are just confusing.
Thanks,
Andrew Bartlett
--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.
___
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol
RE: [cifs-protocol] Session keys are not always 16 bytes long
Stefan, For your SMB signing problem shown in the network traces attached, what is your configuration ? Are you using Vista client connecting to Samba server and KDC ?You also mentioned windows servers. How are they used in your configuration ? I just want to make sure we check the correct section of the code and create a testing environment that will be more helpful for finding the problem. Thanks! Hongwei -Original Message- From: Stefan (metze) Metzmacher [mailto:[EMAIL PROTECTED] Sent: Thursday, August 14, 2008 10:36 AM To: Hongwei Sun Cc: Andrew Bartlett; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [cifs-protocol] Session keys are not always 16 bytes long Hongwei Sun schrieb: Stefan, I just found that the session key used to decrypt the password attributes in the DsGetNCChanges() is not truncated. Do you have network trace for this case ? See the attached capture and keytab. And I need to use gsskrb5_get_subkey() instead of gsskrb5_get_initiator_subkey(), when aes keys are used. Does this happen only when you use AES keys Yes, as for AES the acceptor subkey is different from the initiator one. Windows servers seem to just use the same subkey as acceptor subkey and the inititor subkey for rc4 and des keys. For me the remaining unsolved problem is smb signing with AES keys. If I disable mutual auth is works using the initiator subkey, but if mutual auth is used I'm getting a NT_STATUS_ACCESS_DENIED on the tree connect after the session setup. Both initiator and acceptor subkey doesn't work. And truncating the session key to 16 bytes also doesn't help. I attached 2 capture of it. SMB2 signing works fine with the 32byte acceptor subkey. Could it be a bug in windows? Or does smb signing works for you with AES keys and mutual auth? metze ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
RE: [cifs-protocol] Generic passthrough gpInput1 mis-named.
Andrew,
You are correct. It should be named as GenericPassthrough.LogonData and
GenericPassthrough.PackageName in order to be consistent with the definition of
the structure in 2.2.1.4.2 [MS-NRPC]. It has been confirmed that the document
will be updated in the next release.
Thanks
--
Hongwei Sun - Support Escalation Engineer
DSC Protocol Team, Microsoft
[EMAIL PROTECTED]mailto:[EMAIL PROTECTED]
Tel: 469-7757027 x 57027
---
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Bartlett
Sent: Sunday, August 10, 2008 11:20 PM
To: Interoperability Documentation Help
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [cifs-protocol] Generic passthrough gpInput1 mis-named.
MS-APDS makes numerious references (eg in 3.2.5.1) to
GenericPassthrough.gpInput1 and GenericPassthrough.gpInput2. These appear to
have been renamed more usefully in the IDL as LogonData and PackageName.
see:
typedef struct _NETLOGON_GENERIC_INFO
{
NETLOGON_LOGON_IDENTITY_INFO Identity;
UNICODE_STRING PackageName;
unsigned long DataLength;
[size_is(DataLength)] unsigned char * LogonData; } NETLOGON_GENERIC_INFO,
*PNETLOGON_GENERIC_INFO;
Please remove references to the gpInput* names, they are just confusing.
Thanks,
Andrew Bartlett
--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.
___
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol
RE: [Pfif] [cifs-protocol] Clarify AEAD behaviour for GSSAPI with AES
Andrew, In this case, you provided a diagram for us to add to the document and metze added some comments. Thanks for your contribution to our documentation and continued feedback. The product team reviewed the diagram and comments provided. We believe that the diagrams imply interaction between elements and without detailed notes they are subject to multiple interpretation and hence confusion.We believe that as a matter of providing deterministic documentation, we would prefer to provide specific examples. We'll be happy to get your feedback on creating examples and send them for your review once they are ready. Thanks ! Hongwei -Original Message- From: Andrew Bartlett [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 19, 2008 8:17 PM To: Hongwei Sun Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Stefan (metze) Metzmacher Subject: Re: [Pfif] [cifs-protocol] Clarify AEAD behaviour for GSSAPI with AES On Fri, 2008-08-08 at 09:17 +0200, Stefan (metze) Metzmacher wrote: Hongwei, The encryption function in Kerberos is described in details in 5.3 [RFC3961] (http://www.ietf.org/rfc/rfc3961.txt), which is referenced by [MS-KILE]. I can summarize as follows * conf is actually a random confounder prefix of length c ,such as 16. * pad is for shortest padding to bring confounder and plaintext to a length that is the multiple of message block size m, which is octet(8) for AES encryption, as specified in section 6 [RFC 3962] (http://www.ietf.org/rfc/rfc3962.txt) * Ke is an encryption key and Ki is a checksum key. * Plain text is the input confidential data before encryption. * The GSSWrapEX() is exactly the same as the GSSWrap except that it supports ordered list of input buffers. Input buffers for which conf_req_flag == TRUE are encrypted and returned. Buffers which sign == TRUE are included in the signature. It would be extremly useful if the MS-RPCE document would explain what the exact input buffers to GssWrapEX() are and what flags are used in each of the cases (with and without header signing). Then it would be useful to know to what exactly SSPI EncryptMessage call this is mapped. And finally how each of the of the encryption types (des-*, arcfour-hmac-md5, and aes-*) are supposed to process the EncryptMessage input. It would be nice if you could use a realistic example, with explicit values. A bit like the A.5 Test suite section of RFC1321 - The MD5 Message-Digest Algorithm. While we have Microsoft's bugs and features in this area worked around, this is the level of documentation this area needs. Has there been any more progress on this? (We didn't seem to get to this on the call today). Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
RE: [cifs-protocol] What are the POLICY_DOMAIN_KERBEROS_TICKET_INFO flags?
Andrew, I will be working on this request and I'll let you know when I have the information for you. Thanks ! Hongwei -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Bartlett Sent: Monday, August 25, 2008 8:31 PM To: Interoperability Documentation Help Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [cifs-protocol] What are the POLICY_DOMAIN_KERBEROS_TICKET_INFO flags? In MS-LSAD 2.2.53 POLICY_DOMAIN_KERBEROS_TICKET_INFO, it states: AuthenticationOptions: Optional flags that affect validations performed during authentication. What are the optional flags, what do they do, and where are they defined? (this is the packet against Windows 2008) trying QueryDomainInformationPolicy level 3 lsa_QueryDomainInformationPolicy: struct lsa_QueryDomainInformationPolicy in: struct lsa_QueryDomainInformationPolicy handle : * handle: struct policy_handle handle_type : 0x (0) uuid : 5b01caf4-d140-4325-b851-18cafb0c251c level: 0x0003 (3) lsa_QueryDomainInformationPolicy: struct lsa_QueryDomainInformationPolicy out: struct lsa_QueryDomainInformationPolicy info : * info : union lsa_DomainInformationPolicy(case 3) kerberos_info: struct lsa_DomainInfoKerberos enforce_restrictions : 0x0080 (128) service_tkt_lifetime : 0x0053d1ac1000 (3600) user_tkt_lifetime: 0x0053d1ac1000 (3600) user_tkt_renewaltime : 0x058028e44000 (60480) clock_skew : 0xb2d05e00 (30) unknown6 : 0x (0) result : NT_STATUS_OK Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
RE: [cifs-protocol] What are the POLICY_DOMAIN_KERBEROS_TICKET_INFO flags?
Andrew: Thanks for your suggestion. We will add the information about AuthenticationOptions to [MS-KILE] and then create a cross reference in [MS-LSAD]. We will also keep the names consistent among documents ([MS-KILE] and [MS-LSAD]) because they are basically for the same purpose. We appreciate your help to improve the protocol documents. Thanks -- Hongwei Sun - Sr. Support Escalation Engineer DSC Protocol Team, Microsoft [EMAIL PROTECTED] Tel: 469-7757027 x 57027 --- -Original Message- From: Andrew Bartlett [mailto:[EMAIL PROTECTED] Sent: Friday, August 29, 2008 5:15 PM To: Hongwei Sun Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [cifs-protocol] What are the POLICY_DOMAIN_KERBEROS_TICKET_INFO flags? On Fri, 2008-08-29 at 14:27 -0700, Hongwei Sun wrote: Andrew, We completed the investigation for your questions. The following is the information that will be added to MS-LSAD 2.2.53 in the future release. AuthenticationOptions contains optional flags that affect validations preformed during authentication. The only flag currently defined is POLICY_KERBEROS_VALIDATE_CLIENT(0x0080).When the POLICY_KERBEROS_VALIDATE_CLIENT flag is set, during a TGS request, the KDC will check the client account for account restriction if the client account is in the local domain *and* the client was authenticated more than 20 minutes ago. Please let us know if you need further clarification. That looks good, thanks! With that clue, think you need to add a cross-reference to AUTH_REQ_VALIDATE_CLIENT in MS-KILE. If they are the same flag, it would be great if the names could be lined up. Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
RE: [cifs-protocol] Session keys are not always 16 bytes long
Metze/Andrew, The subkey in the EncAPRepPart of the AP-REP should be used as the session key when the mutual authentication is enabled(as described in RFC 4121). When DES and RC4 are used in Kerberos, the implementation is based on RFC1964 (instead of RFC4121). According to RFC1964, you can pick the subkey in AP_REQ as the session key as it is the same as the subkey in AP_REP, but this is not true when AES is used because both subkeys are different (again AES means RFC4121 being used, not RFC1964). This explains what you observed. We will add the information to [MS-KILE] to describe how the session key is selected. The session key returned from Kerberos package can be used for SMB signing as described in the section 4.3 of [MS-SMB]. You have to truncate the keys to 128 bits in your code because SMB does the truncation on the windows side. I ran the similar testing as you did. I had one Vista machine connected to Windows 2008 DC/KDC and configured AES256-CTS-HMAC-SHA1-96 as Kerberos encryption type with mutual authentication enabled. I cannot duplicate your SMB signing problem(see the network capture attached). It is working between Windows servers and clients. Thanks -- Hongwei Sun - Sr. Support Escalation Engineer DSC Protocol Team, Microsoft [EMAIL PROTECTED] Tel: 469-7757027 x 57027 --- -Original Message- From: Stefan (metze) Metzmacher [mailto:[EMAIL PROTECTED] Sent: Thursday, August 14, 2008 10:36 AM To: Hongwei Sun Cc: Andrew Bartlett; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [cifs-protocol] Session keys are not always 16 bytes long Hongwei Sun schrieb: Stefan, I just found that the session key used to decrypt the password attributes in the DsGetNCChanges() is not truncated. Do you have network trace for this case ? See the attached capture and keytab. And I need to use gsskrb5_get_subkey() instead of gsskrb5_get_initiator_subkey(), when aes keys are used. Does this happen only when you use AES keys Yes, as for AES the acceptor subkey is different from the initiator one. Windows servers seem to just use the same subkey as acceptor subkey and the inititor subkey for rc4 and des keys. For me the remaining unsolved problem is smb signing with AES keys. If I disable mutual auth is works using the initiator subkey, but if mutual auth is used I'm getting a NT_STATUS_ACCESS_DENIED on the tree connect after the session setup. Both initiator and acceptor subkey doesn't work. And truncating the session key to 16 bytes also doesn't help. I attached 2 capture of it. SMB2 signing works fine with the 32byte acceptor subkey. Could it be a bug in windows? Or does smb signing works for you with AES keys and mutual auth? metze AESSinging.cap Description: AESSinging.cap ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] RE: Other types of Kerberos messages on SamLogon Generic
Andrew, I went through the logic of the generic pass through function in Kerberos package for both Windows server 2003 and 2008. I found that it only processes KerbVerifyPacMessage (0x03). For any other message types, STATUS_ACCESS_DENIED should be returned. Could you give me more information about your testing ? Which version of Windows server did you use ? Did you just use a KERB_VERIFY_PAC_REQUEST structure as LogonInformation passed to NetrLogonSamLogon() and set MessageType from 0x00 to 0xFF ? If you can send us a network trace to show that NT_STATUS_OK is returned for any message type other than 0x03, it would be really helpful. Thanks -- Hongwei Sun - Sr. Support Escalation Engineer DSC Protocol Team, Microsoft [EMAIL PROTECTED] Tel: 469-7757027 x 57027 --- From: Andrew Bartlett [EMAIL PROTECTED] Sent: Tuesday, September 02, 2008 11:06 PM To: Interoperability Documentation Help Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Other types of Kerberos messages on SamLogon Generic MS-APDS 2.2.2.1 describes only one Generic message type (0x3) for the Package Kerberos. However, Microsoft servers still return NT_STATUS_OK on a message type in the range 0x0..0xff (for example). What other message types are valid on this Package, and what are their formats? Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] RE: Other types of Kerberos messages on SamLogon Generic
Andrew, We ran Smbtortue RPC-PAC testing on windows 2008 DC and got the following output. [EMAIL PROTECTED] source]# bin/smbtorture -k yes //VM-W2K8.nick.com/public RPC-PAC Using seed 1220896649 Running PAC Password for [NICKDOM\root]: Domain join failed - Connection to SAMR pipe of DC VM-W2K8.nick.com failed: Connection to DC VM-W2K8.nick.com failed: NT_STATUS_UNSUCCESSFUL Setup failed: torture/rpc/rpc.c:144: Failed to join as BDC PAC took 11.264 sec Is this what you observed ? Is there any documentation describing what this test is doing ? Thanks ! Hongwei -Original Message- From: Andrew Bartlett [mailto:[EMAIL PROTECTED] Sent: Sunday, September 07, 2008 7:07 PM To: Hongwei Sun Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: Other types of Kerberos messages on SamLogon Generic On Sun, 2008-09-07 at 17:01 -0700, Hongwei Sun wrote: Andrew, I went through the logic of the generic pass through function in Kerberos package for both Windows server 2003 and 2008. I found that it only processes KerbVerifyPacMessage (0x03). For any other message types, STATUS_ACCESS_DENIED should be returned. Could you give me more information about your testing ? Which version of Windows server did you use ? Did you just use a KERB_VERIFY_PAC_REQUEST structure as LogonInformation passed to NetrLogonSamLogon() and set MessageType from 0x00 to 0xFF ? If you can send us a network trace to show that NT_STATUS_OK is returned for any message type other than 0x03, it would be really helpful. Feel free to run smbtorture's RPC-PAC against your server (ensure you turn on kerberos with the '-k yes' switch to get kerberos failures early). I was testing against a Windows 2003 DC. A trace would not be much use, as this is encrypted (which was my first mistake :-) Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] RE: [Pfif] Other types of Kerberos messages on SamLogon Generic
Andrew,
We still have problem with the test. The following is we did during our test.
Please give us some advice.
Here's the output:
[EMAIL PROTECTED] source]# bin/smbtorture -k yes --realm=test.net
//W2K3SRV.test.net/public RPC-PAC -UTESTDOM/[EMAIL PROTECTED]
Using seed 1221036728
Running PAC
Domain join failed - Connection to SAMR pipe of DC W2K3SRV.test.net failed:
Connection to DC W2K3SRV.test.net failed: NT_STATUS_INVALID_PARAMETER
Setup failed: torture/rpc/rpc.c:144: Failed to join as BDC
PAC took 0.194445 secs
This is my krb5.conf file:
[EMAIL PROTECTED] source]# cat /etc/krb5.conf
[libdefaults]
default_realm = TEST.NET
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
forwardable = yes
[realms]
TEST.NET = {
kdc = W2K3SRV.test.net:88
admin_server = W2K3SRV.test.net:749
default_domain = test.net
}
[domain_realm]
.test.net = TEST.NET
test.net = TEST.NET
Note: A netstat -an does not show any processes listening on port 749 on the
W2K3SRV machine.
Also, as a reference, here are the steps I followed on the Linux side:
1. Pulled down the current Samba source tree using rsync
2. ./configure
3. make
4. make install
5. setup/provision --realm=test.net --domain=TESTDOM [EMAIL PROTECTED]
--server-role=dc
6. Copied /usr/local/samba/private/krb5.conf to /etc/
7. Edited /etc/krb5.conf to look as shown above.
Changed following entries:
dns_lookup_realm
dns_lookup_kdc
kdc
admin_server
8. Run smbtorture
Linux is configured to use W2K3SRV as its DNS server.
Thanks !
Hongwei
-Original Message-
From: Andrew Bartlett [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 09, 2008 8:37 PM
To: Hongwei Sun
Cc: Stefan (metze) Metzmacher; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: [Pfif] Other types of Kerberos messages on SamLogon Generic
On Tue, 2008-09-09 at 07:46 -0700, Hongwei Sun wrote:
Metze,
After we set time correctly, we got the following output. The error
doesn't look like related to verify PAC message. Maybe we didn't go
further enough. Any suggestion?
Thanks!
Hongwei
--- After setting time
[EMAIL PROTECTED] source]# bin/smbtorture //VM-W2K8.test.net/public RPC-PAC
-UTESTDOM/[EMAIL PROTECTED]
Add -k yes --realm=test.net
TEST verify FAILED! - torture/rpc/remote_pac.c:101: status was
NT_STATUS_INVALID_PARAMETER, expected NT_STATUS_OK:
It failed to connect using kerberos (which was strictly required for this test)
because it did not find the KDC (or some other pre-requisite).
Also ensure your krb5.conf points the kerberos libs to your KDC with:
[libdefaults]
default_realm = S4.NAOMI.ABARTLET.NET
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
forwardable = yes
Andrew Bartlett
--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.
___
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] format of password attributes in AD
Metze/Andrew, We completed the investigation for two issues listed in the e-mail below. For the first issue, we finally determined where the extra bytes come from. There are two issues contributing to the extra bytes. (1) The cause of these bytes is an off by one calculation error when allocating the buffer for the credentials structure. The KERB_STORED_CREDENTIAL and KERB_STORED_CREDENTIAL_NEW structures contain space for KERB_KEY_DATA and KERB_KEY_DATA_NEW structures respectively which are not accounted for correctly in the Windows implementation. The calculation for the count of these structures should have been based on CredentialCount - 1. This adjustment is not performed in the code and therefore exactly sizeof(KERB_KEY_DATA) and sizeof(KERB_KEY_DATA) extra bytes of 0 are present after the last real key data. The benign presence of these bytes with value of 0 are not referenced by any offset and the salt value following them is referenced correctly, therefore it should not affect interoperability. (2) The storage of a dummy key that is included in the supplemental credentials when the current domain functional level is DS_BEHAVIOR_WIN2003 or less. For this issue we will make the following change to 2.2.10.8 [MS-SAMR]. 2.2.10.8 Kerberos Encryption Algorithm Identifiers The following table identifies the various algorithms that can be used in the KERB_KEY_DATA and KERB_KEY_DATA_NEW structures.24 Windows Behavior 24 Section 2.2.10.8: When the current domain functional level is DS_BEHAVIOR_WIN2003 or less, a Windows Server 2008 DC includes a key entry of type -140 in each of KERB_STORED_CREDENTIAL and KERB_STORED_CREDENTIAL_NEW, which is not needed and can be ignored; it is a dummy type in the supplemental credentials that is not present when the domain functional level is raised to DS_BEHAVIOR_WIN2008 or greater. The key data is the NT hash of the password. For the second issue with regard to the extra byte at the end we need additional information on how to reproduce the problem , as Richard indicated in his mail below. Thanks -- Hongwei Sun - Sr. Support Escalation Engineer DSC Protocol Team, Microsoft [EMAIL PROTECTED] Tel: 469-7757027 x 57027 --- -Original Message- Stefan/Andrew, I wanted to give you an update on this issue. I was able to parse the NDR dump you gave us and have identified the two issues you point out. Here is info on our findings to date. Both Primary:Kerberos-Newer-Keys - KERB_STORED_CREDENTIAL_NEW and Primary:Kerberos - KERB_STORED_CREDENTIAL show extra bytes between the last credential structure and the salt value. However, the offset for DefaultSaltOffset is correct so you should be able to correctly parse the structure. We are working to determine exactly where the bytes are coming from. I hope to have that information shortly. I also see the extra byte (value 0x66) at the end of the NDR dump however, we are unable to reproduce that behavior currently. Can you provide a detailed set of steps that can be used to reproduce this behavior? Also, is it possible there is an issue in your parsing at a lower level? I am not saying there is I just want to try and attack the issue from multiple angles. I am also working on the reserved fields and hope to send an update shortly as well. Please let us know if you have any additional questions. Richard Guthrie Open Protocols Support Team Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM Tel: +1 (469) 775-7794 E-mail: [EMAIL PROTECTED] We're hiring http://members.microsoft.com/careers/search/details.aspx?JobID=A976CE32-B0B9-41E3-AF57-05A82B88383Estart=1interval=10SortCol=DatePosted -Original Message- From: Stefan (metze) Metzmacher [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 19, 2008 1:12 AM To: Andrew Bartlett Cc: Richard Guthrie; Nick Meier Subject: Re: 600300 RE: [cifs-protocol] format of password attributes in AD Andrew Bartlett schrieb: On Mon, 2008-08-18 at 14:43 -0700, Richard Guthrie wrote: Stefan, I reviewed your IDL and need to see if I can get some additional information from you in order to correctly interpret what you sent. I see your supplementalCredentialsBlob structure in your IDL. The way I read your mail you are seeing an extra byte at the end of the structure for which you do not have an understanding. That value is marked as [value(0)] uint8 unknown3 In your IDL. Can you send me a dump of the structure in memory (not sure how your environment is setup but a memory dump would be great)? This looks very similar to the USER_PROPERTIES structure btw, any chance it is part of the PropertySignature or PropertyCount? With regard to package_PrimaryKerberosCtr3, I see the 20 bytes you have marked in the structure. I wanted
RE: [cifs-protocol] RE: 600634 - RE: salt used for various principal types
Andrew, We completed the document change regarding the key salt calculation for realm trust. The change will appear in the future release of 3.3.1 [MS-KILE] as follows. 3.3 KDC Details 3.3.1 Abstract Data Model KILE concatenates the following information to use as the key salt for realm trusts: Inbound trusts: all upper case name of the remote realm | krbtgt | all upper case name of the local realm Outbound trusts: all upper case name of the local realm | krbtgt | all upper case name of the remote realm Please let us know if you need further clarification on this subject. Thanks -- Hongwei Sun - Sr. Support Escalation Engineer DSC Protocol Team, Microsoft [EMAIL PROTECTED] Tel: 469-7757027 x 57027 --- -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Bartlett Sent: Tuesday, August 26, 2008 5:07 PM To: Richard Guthrie Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [cifs-protocol] RE: 600634 - RE: salt used for various principal types On Tue, 2008-08-26 at 08:37 -0700, Richard Guthrie wrote: Andrew Microsoft does use different methods of calculating the salt value used in encryption depending on the type account that is submitted to the salt calculation implementation. For example, in the case of interdomain trust accounts, krbtgt is appended. In the case of machine accounts, host is appended to the start of the salt value. Implementers are free to implement a salt algorithm of their choice, without affecting interoperability. This would be true, but this applies only to objects of the type normally found under cn=users. The salt to use for a password stored in trustAuthIncoming/trustAuthOutgoing must be specified in the docs. It is not possible to negotiate an alternate salt for the AES or DES keys of interdomain trusts in Kerberos. In any case, the salts as you describe should be included in a discussion of the Microsoft KDC. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
RE: [cifs-protocol] Session keys are not always 16 bytes long
Metze, When you tested SMB signing with 32 byte AES session key, did you test Vista with Samba server , Samba client with Windows server or both ? Hongwei -Original Message- From: Stefan (metze) Metzmacher [mailto:[EMAIL PROTECTED] Sent: Friday, September 05, 2008 3:25 PM To: Hongwei Sun Cc: Andrew Bartlett; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [cifs-protocol] Session keys are not always 16 bytes long Hongwei Sun schrieb: Metze/Andrew, The subkey in the EncAPRepPart of the AP-REP should be used as the session key when the mutual authentication is enabled(as described in RFC 4121). When DES and RC4 are used in Kerberos, the implementation is based on RFC1964 (instead of RFC4121). According to RFC1964, you can pick the subkey in AP_REQ as the session key as it is the same as the subkey in AP_REP, but this is not true when AES is used because both subkeys are different (again AES means RFC4121 being used, not RFC1964). This explains what you observed. We will add the information to [MS-KILE] to describe how the session key is selected. The session key returned from Kerberos package can be used for SMB signing as described in the section 4.3 of [MS-SMB]. You have to truncate the keys to 128 bits in your code because SMB does the truncation on the windows side. I ran the similar testing as you did. I had one Vista machine connected to Windows 2008 DC/KDC and configured AES256-CTS-HMAC-SHA1-96 as Kerberos encryption type with mutual authentication enabled. I cannot duplicate your SMB signing problem(see the network capture attached). It is working between Windows servers and clients. I got it working, the session key isn't truncated for the SMB signing. The problem was that we reseted the sequence number when updating the session key from the initiator subkey to the acceptor subkey between the session setup request and response. Also windows signs the response with the acceptor subkey, so that the client needs to check the signature after processing the response. metze ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] RE: Other types of Kerberos messages on SamLogon Generic
Andrew, After running Samba RPC-PAC test, analyzing network trace and reviewing its source code, we think that we found the problem in the Sambatorture implementation. In the loop of setting message type from 0x00 to 0xFF, the test program sends the exactly same PAC_Validate buffer for each call. This can be observed from the network trace. Then we confirmed that in ndr_push_PAC_Validate(), which marshals the PAC_Validate structure, message type is always set to NETLOGON_GENERIC_KRB5_PAC_VALIDATE (0x3). That explains why Microsoft servers always return NT_STATUS_OK for all the calls in your test. We also found that the other tests(wrong length, corrupted data, bad signature etc) performed by Smbtorture failed as expected. Please let us know if what we found is correct. Thanks -- Hongwei Sun - Sr. Support Escalation Engineer DSC Protocol Team, Microsoft [EMAIL PROTECTED] Tel: 469-7757027 x 57027 --- -Original Message- From: Andrew Bartlett [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 02, 2008 11:06 PM To: Interoperability Documentation Help Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Other types of Kerberos messages on SamLogon Generic MS-APDS 2.2.2.1 describes only one Generic message type (0x3) for the Package Kerberos. However, Microsoft servers still return NT_STATUS_OK on a message type in the range 0x0..0xff (for example). What other message types are valid on this Package, and what are their formats? Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
RE: [cifs-protocol] Session keys are not always 16 bytes long
Metze, The product team confirmed that Windows servers always truncate session keys to 16 bytes for signing. As per previous e-mail, your SMB signing has to use entire 32 bytes of AES session key for signing. Do your newly found bugs affect this statement ? Thanks ! Hongwei -Original Message- From: Stefan (metze) Metzmacher [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 17, 2008 10:57 AM To: Hongwei Sun Cc: Andrew Bartlett; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [cifs-protocol] Session keys are not always 16 bytes long Hongwei Sun schrieb: Metze, When you tested SMB signing with 32 byte AES session key, did you test Vista with Samba server , Samba client with Windows server or both ? Samba as client and Windows 2008 as server. I found a few bugs in Samba's smb signing implementation. Windows only signs the last session setup response and samba also signs the last session setup request. I have some hacks which fix samba, but I haven't done a clean implementation yet. The key thing is that the client needs to process the last session setup response first and then verify its signature after when the correct session key is avaliable. metze -Original Message- From: Stefan (metze) Metzmacher [mailto:[EMAIL PROTECTED] Sent: Friday, September 05, 2008 3:25 PM To: Hongwei Sun Cc: Andrew Bartlett; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [cifs-protocol] Session keys are not always 16 bytes long Hongwei Sun schrieb: Metze/Andrew, The subkey in the EncAPRepPart of the AP-REP should be used as the session key when the mutual authentication is enabled(as described in RFC 4121). When DES and RC4 are used in Kerberos, the implementation is based on RFC1964 (instead of RFC4121). According to RFC1964, you can pick the subkey in AP_REQ as the session key as it is the same as the subkey in AP_REP, but this is not true when AES is used because both subkeys are different (again AES means RFC4121 being used, not RFC1964). This explains what you observed. We will add the information to [MS-KILE] to describe how the session key is selected. The session key returned from Kerberos package can be used for SMB signing as described in the section 4.3 of [MS-SMB]. You have to truncate the keys to 128 bits in your code because SMB does the truncation on the windows side. I ran the similar testing as you did. I had one Vista machine connected to Windows 2008 DC/KDC and configured AES256-CTS-HMAC-SHA1-96 as Kerberos encryption type with mutual authentication enabled. I cannot duplicate your SMB signing problem(see the network capture attached). It is working between Windows servers and clients. I got it working, the session key isn't truncated for the SMB signing. The problem was that we reseted the sequence number when updating the session key from the initiator subkey to the acceptor subkey between the session setup request and response. Also windows signs the response with the acceptor subkey, so that the client needs to check the signature after processing the response. metze ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
RE: [cifs-protocol] RE: [Pfif] Microsoft Client tool expectatations
Andrew, Does this mean that you cannot duplicate the issue any more ? Can you give us some clarification at your earliest convenience ? The only information I have been using for my investigation is winxp-aduc-fail.cap attached in your original e-mail ? Is it still relevant ? Thanks -- Hongwei Sun - Sr. Support Escalation Engineer DSC Protocol Team, Microsoft [EMAIL PROTECTED] Tel: 469-7757027 x 57027 --- -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Bartlett Sent: Tuesday, September 09, 2008 3:39 AM To: Edgar Olougouna Cc: Interoperability Documentation Help; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [cifs-protocol] RE: [Pfif] Microsoft Client tool expectatations On Tue, 2008-09-09 at 16:29 +1000, Andrew Bartlett wrote: On Mon, 2008-09-08 at 09:24 -0700, Edgar Olougouna wrote: Good morning Andrew, Thank you for your request concerning the Windows Client tool expectations. I have created a case for this (see info below); one of my colleagues will be in touch with you. SRX080908600475 - ProtoDoc 9: [MS-ADTS]: Microsoft Client tool expectations This should probably be split into two cases. Similarly, against our current GIT tree, the Win2k3 admin pack on WinXP won't launch 'Active Directory Users and Computers' against Samba4. The error seems to be in response to our return value for the cn=aggregate schema. While we still have the problem of 'how do I get past cryptic client messages', the particular case here was easily solved by a comparative trace with windows. It turns out that this did not solve the issue - I now can't reproduce the issue with or without this fix. Further clarification is required. The issue is that we would include an entry: objectClasses: ( 2.5.6.0 NAME 'top' SUP top ABSTRACT.. The MMC Active Directory Users and Computers snap in presumably objected to the 'loop' this would present. The fixed entry is: objectClasses: ( 2.5.6.0 NAME 'top' ABSTRACT... Now, the new resolution I would like is for this someone to find where this should be documented in MS-ATDS and to call out the semantics here very carefully (that top must not be SUP 'top', despite being so indicated in the full schema). Also, an indication of the semantics of modifyTimeStamp on this entry would be worthwhile. I generate these attributes on the fly, so this value will not normally change (even with schema updates) - but ADUC very specifically reads this value. Does it implement a cache of some kind, and therefore how must this change after schema updates? Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
RE: [cifs-protocol] RE: [Pfif] Microsoft Client tool expectatations
Andrew, Andrew, Does this mean that you cannot duplicate the issue any more ? Correct. However, my original reporter still reproduces the issue. Could you explain a little bit more about this ? If you put everything back to original condition, you can still see the problem with XP ADCU. After some changes made to schema, the problem doesn't occur any more. Is my understanding right ? Should I still concentrate on the original condition under which we have a capture ? Is it possible for you to send us a network trace for the current successful condition so we can compare ? Thanks -- Hongwei Sun - Sr. Support Escalation Engineer DSC Protocol Team, Microsoft [EMAIL PROTECTED] Tel: 469-7757027 x 57027 --- -Original Message- From: Andrew Bartlett [mailto:[EMAIL PROTECTED] Sent: Monday, September 22, 2008 5:22 PM To: Hongwei Sun Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [cifs-protocol] RE: [Pfif] Microsoft Client tool expectatations On Mon, 2008-09-22 at 14:31 -0700, Hongwei Sun wrote: Andrew, Does this mean that you cannot duplicate the issue any more ? Correct. However, my original reporter still reproduces the issue. Can you give us some clarification at your earliest convenience ? The only information I have been using for my investigation is winxp-aduc-fail.cap attached in your original e-mail ? Is it still relevant ? That shows the original failure - but as this could be any part of the whole schema that is incorrect, it is hard to tell what is wrong. Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] RE: Microsoft Client tool expectatations
Andrew, I just want to check with you about the current status of the domain trust issue between Windows 2008 server and Samba4. I know that you have made significant progresses during Interop Lab Event. Please let me know whether I can close this case if you don't have any issue left. Thanks -- Hongwei Sun - Sr. Support Escalation Engineer DSC Protocol Team, Microsoft [EMAIL PROTECTED] Tel: 469-7757027 x 57027 --- -Original Message- From: Andrew Bartlett [mailto:[EMAIL PROTECTED] Sent: Monday, September 08, 2008 7:22 AM To: Interoperability Documentation Help Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Microsoft Client tool expectatations How do I determine what LDAP values a Microsoft client tool is expecting? For example, with the attached patch against current GIT, I cannot make windows 2008 join Samba4 as a 2-way, forest level trusted domain. It seems something is wrong with what we return to cn=partitions,cn=configuration, Similarly, against our current GIT tree, the Win2k3 admin pack on WinXP won't launch 'Active Directory Users and Computers' against Samba4. The error seems to be in response to our return value for the cn=aggregate schema. In both cases, I just have cryptic error messages. How can I determine what these tools are expecting? Attached please find network traces for both the 2008 server attempting to join the trust and a WinXP machine trying to open 'Active Directory Users and Computers'. (keytab to follow in private mail) The join fails with: 'unable to read the functional level of the forest' Cannot convert to/from the native DS datatype. The ADUC launch fails with: 'unspecified error'. (This used to work, before I 'fixed' some schema stuff). Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
RE: [cifs-protocol] Session keys are not always 16 bytes long
Andrew, Thanks for the information provided. We successfully reproduced and debugged the behavior of SMB signing between Samba Smbclient and Windows server using AES256 session key(32 bytes). The outcome of live debugging proved that SMB signing is using entire 32 bytes session key, just as you reported initially. The product team also confirmed this behavior. We will update MS-SMB document accordingly. Please let us know if you have any further question regarding this topic. Thanks! -Original Message- From: Andrew Bartlett [mailto:abart...@samba.org] Sent: Sunday, November 30, 2008 8:53 PM To: Hongwei Sun Cc: Stefan (metze) Metzmacher Subject: RE: [cifs-protocol] Session keys are not always 16 bytes long On Tue, 2008-11-25 at 15:52 -0800, Hongwei Sun wrote: Andrew, As per our discussion during conference call, I would like to run testing on Samba with Windows server for session key length used for SMB signing. Can I run smbtorture to see the behavior ? If so, what test option should I select ? How can I configure it to use Kerberos with AES256 ? Use Krb5.conf ? If you could point me to the source code file and lines, it will be helpful for me too. I suggest running just smbclient, to a windows server that enforces signing, with 'smbclient //myserver/share -d11 -k yes -Uuser%pass' as the command line. This should trigger the behaviour, and print the key if you are on a modern linux distro. You must have compiled Samba using 'make clean ./configure --enable-developer make all'. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
RE: [cifs-protocol] Session keys are not always 16 bytes long
Andrew, We finished updating the MS-SMB document as you suggested. (1) The following text is updated to describe how session keys are generally used for signing in Windows clients and servers in section 3.1.4.1 and 3.1.5.1. The MD5 algorithm, as specified in [RFC1321], MUST be used to generate a hash of the SMB message (from the start of the SMB header) through the entire session key with the actual session key length. (2) The following Windows Behavior note is updated to describe the special behavior of Windows clients, especially when the session key length is less than 16. 177 Section 3.1.4.1: Windows SMB clients use the entire session key for signing if the session key length is equal to or greater than 16, and pad the session key with zero up to 16 bytes if the session key length is less than 16. Please let us know if you have any further questions. We really appreciate your suggestion. Thanks! Hongwei -Original Message- From: Andrew Bartlett [mailto:abart...@samba.org] Sent: Tuesday, February 10, 2009 3:45 PM To: Hongwei Sun Cc: Stefan (metze) Metzmacher; cifs-proto...@samba.org; p...@tridgell.net Subject: RE: [cifs-protocol] Session keys are not always 16 bytes long On Tue, 2009-02-10 at 07:13 -0800, Hongwei Sun wrote: Andrew, I am sending you the new windows behavior notes that have been added to MS-SMB with respect to the length of session key used for SMB signing. 173 Section 3.1.5.1: Windows SMB clients use entire session key for signing if the session key length is equal to or more than 16, and pad session key with zero up to 16 bytes if session key length is less than 16; Windows SMB servers always use the actual length of the session key for signing. Please let me know if you have any more questions. Why is this a windows behaviour note? It isn't like this is some optional or additional behaviour, or a non-optimal outcome. Please ensure this is specified in the main protocol. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] RE: MS-ERREF addition requested
Zachary, Thanks for your question. We will start working on it and let you know as soon as our investigation is complete. Thanks! Hongwei Sun - Sr. Support Escalation Engineer DSC Protocol Team, Microsoft hongw...@microsoft.com Tel: 469-7757027 x 57027 - -Original Message- From: zachary.loaf...@isilon.com [mailto:zachary.loaf...@isilon.com] Sent: Tuesday, March 31, 2009 5:35 PM To: Interoperability Documentation Help Cc: cifs-proto...@samba.org; p...@tridgell.net Subject: MS-ERREF addition requested (Resending with CC to dochelp) Win7 build 7000 is sending NT status code 0xC1A1 in response to certain Byte-Range Lock operations, for example the offset = UINT64_MAX, length = UINT64_MAX case. I totally agree with this change, but MS-ERREF does not document 0xC1A1, nor do any public-facing documents that I can find. Can we get this documented? (An example of this can be found in the smbtorture RAW-LOCK test.) -- Zach Loafman | Staff Engineer | Isilon Systems ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] RE: CAR - problem with MS-ADTS docs on possibleInferiors
Hi, Tridge, We reproduced the behavior by running your Python script with latest Samba tree against Windows server. After further review, we confirmed that your description of behaviors is correct. This is a documentation issue that we are going to fix in MS-ADTS. For the definitions of AUXCLASS(),POSSSUPERIORS(), and CLASSATTS(), your assumption is also correct. The functions are mapped onto every element in the list, and the resulting (concatenated) list is returned. We will update the information into MS-ADTS too. I will send you the document update when it is available. Please let us know if you have any more questions. Thanks! Hongwei Sun - Sr. Support Escalation Engineer DSC Protocol Team, Microsoft hongw...@microsoft.com Tel: 469-7757027 x 57027 - -Original Message- From: tri...@samba.org [mailto:tri...@samba.org] Sent: Thursday, March 26, 2009 5:35 PM To: Interoperability Documentation Help Cc: cifs-proto...@samba.org; p...@tridgell.net Subject: CAR - problem with MS-ADTS docs on possibleInferiors Hi, Andrew and I have been trying to implement possibleInferiors in the ldap server in Samba4. To start with, we've written a python script to test our understanding of how possibleInferiors is calculated. We wrote the script based on the documentation in [MS-ADTS].pdf (January 2009 version) sections 3.1.1.4.2 and 3.1.1.4.5.21. The script connects to an AD ldap server and asks the server for the list of object classes, then for every class it asks for the possibleInferiors attribute. It then calculates the possibleInferiors using the methods given in the documentation, and compares the results. We found that a windows server gave slightly different results than what we get by following the documentation. After some experimentation we found a different algorithm that does match windows behaviour. Could you please check the description of possibleInferiors in the [MS-ADTS].pdf and see if it is correct? The script we've written is available here: http://samba.org/ftp/unpacked/samba_4_0_test/source4/dsdb/samdb/ldb_modules/tests/possibleinferiors.py If you look near line 142 of the script you can see this: if opts.wspp: # the WSPP docs suggest we should do this: list2.extend(POSSSUPERIORS(classinfo, AUXCLASSES(classinfo, [oc]))) else: # but testing against w2k3 and w2k8 shows that we need to do this instead list2.extend(SUBCLASSES(classinfo, list2)) What this is saying is that the documentation suggests calculating the POSSSUPERIORS() list to include the AUXCLASSES() list. When we included the AUXCLASSES() list we found that we calculated an extra class in our possibleInferiors that w2k8 does not return for 4 classes. The class is 'remoteMailRecipient' and is calculated as being a possibleInferior for 'rpcContainer', 'container', 'groupPolicyContainer' and 'msExchConfigurationContainer'. When we don't use the AUXCLASSES() contribution to POSSSUPERIORS() then 'remoteMailRecipient' is not included in possibleInferiors. Additionally, we found that we needed to include the SUBCLASSES() list in the POSSSUPERIORS() calculation. The SUBCLASSES() list isn't described in the documentation, but comes from an inversion of the class tree using subClassOf. If we don't include SUBCLASSES() in POSSSUPERIORS() then we get back a mismatch for possibleInferiors for 22 classes. For example, for the class 'linkTrackObjectMoveTable' a w2k8 server returns 4 entries in the possibleInferiors list: 'fileLinkTrackingEntry', 'linkTrackOMTEntry', 'linkTrackObjectMoveTable', 'linkTrackVolumeTable' whereas our code (with the SUBCLASSES() call removed) produced just one entry, 'linkTrackOMTEntry' We also found the documentation rather hard to follow. I think part of that just comes from the notation. For example, the documentation gives a definition of AUXCLASSES(O). That notation would seem to imply that AUXCLASSES() takes the name of a class and returns a list of classes, but in the recursive definition of AUXCLASSES() it refers to AUXCLASSES(SUPCLASSES(O)), which now implies that AUXCLASSES() takes a list of classes. We guessed that the documentation implied that when the AUXCLASSES() function is called with a list as an argument it takes the results of AUXCLASSES() for every object in the list, then concatenates the resulting lists (possibly removing duplicates). Can you confirm that this is what is meant? It is also rather surprising that we found that AUXCLASSES() doesn't contribute to possibleInferiors. Could you confirm whether this is a bug in the documentation or the implementation in windows, or is it just a bug in our little python script? To run the script, build the Samba4 tree, then run it like this: ./dsdb/samdb/ldb_modules/tests
[cifs-protocol] RE: [Pfif] MS-ERREF addition requested
Steve,
We are not aware of the request you mentioned in your mail in any of the
established communication channels.Could you please forward us your request
so we can work on investigating the issue and also figure out why your question
never reached us ?Please make sure that you always copy
doch...@winse.microsoft.com alias when you send any requests for Open Protocol
Documentation to us.
Thanks for bringing this to our attention and we appreciate your effort to
help us improve documentation.
Hongwei Sun - Sr. Support Escalation Engineer
DSC Protocol Team, Microsoft
hongw...@microsoft.com
Tel: 469-7757027 x 57027
-
-Original Message-
From: Steve French [mailto:smfre...@gmail.com]
Sent: Wednesday, April 01, 2009 12:15 PM
To: Bill Wesse
Cc: zachary.loaf...@isilon.com; Interoperability Documentation Help;
p...@tridgell.net; cifs-proto...@samba.org
Subject: Re: [Pfif] MS-ERREF addition requested
This post reminded me that I never saw a response to my earlier post
that MS-ERREF has an error on page 442 (it is at least a typo). See
below:
0x0xC721 STATUS_CALLBACK_RETURNED_THREAD_AFFINITY
On Wed, Apr 1, 2009 at 11:42 AM, Bill Wesse bil...@microsoft.com wrote:
Mr. Loafman, thanks for your question. I have created case SRX090331600478,
and filed a documentation change request (details below), as applicable to:
[MS-ERREF]: Windows Error Codes
2.1 HRESULT
2.3.1 NTSTATUS values
The specific error code you asked about (0xC1A1) is new, and is
documented in the 'Microsoft Windows SDK for Windows 7 and .NET Framework 3.5
SP1: BETA, which is available as a DVD iso at:
http://www.microsoft.com/downloads/details.aspx?FamilyID=A91DC12A-FC94-4027-B67E-46BAB7C5226Cdisplaylang=en
Here is the actual declaration:
//
// MessageId: STATUS_INVALID_LOCK_RANGE
//
// MessageText:
//
// A requested file lock operation cannot be processed due to an invalid byte
range.
//
#define STATUS_INVALID_LOCK_RANGE ((NTSTATUS)0xC1A1L)
==
Documentation change request details.
==
2.1 HRESULT
New facility codes in Win7 ntstatus.h:
Facility (11 bits):
8 FACILITY_NTCERT
60 FACILITY_DIS
62 FACILITY_WIN32K_NTUSER
63 FACILITY_WIN32K_NTGDI
#define FACILITY_WIN32K_NTUSER 0x3E
#define FACILITY_WIN32K_NTGDI 0x3F
#define FACILITY_MAXIMUM_VALUE 0x3F // Was 0x3A
#define FACILITY_DIS 0x3C
#define FACILITY_NTCERT 0x8
==
2.3.1 NTSTATUS values
New error codes in Win7 ntstatus.h:
// The oplock that was associated with this handle is now associated with a
different handle.
#define STATUS_OPLOCK_SWITCHED_TO_NEW_HANDLE ((NTSTATUS)0x0215L)
// The handle with which this oplock was associated has been closed. The
oplock is now broken.
#define STATUS_OPLOCK_HANDLE_CLOSED ((NTSTATUS)0x0216L)
// An oplock of the requested level cannot be granted. An oplock of a lower
level may be available.
#define STATUS_CANNOT_GRANT_REQUESTED_OPLOCK ((NTSTATUS)0x802EL)
// An attribute was successfully built.
#define STATUS_DIS_ATTRIBUTE_BUILT ((NTSTATUS)0x003C0001L)
// An oplock of the requested level cannot be granted. An oplock of a lower
level may be available.
#define STATUS_CANNOT_GRANT_REQUESTED_OPLOCK ((NTSTATUS)0x802EL)
// {No ACE Condition}
// The specified access control entry (ACE) does not contain a condition.
#define STATUS_NO_ACE_CONDITION ((NTSTATUS)0x802FL)
// BitLocker encryption keys were ignored because the volume was in a
transient state.
#define STATUS_FVE_TRANSIENT_STATE ((NTSTATUS)0x80210002L)
// Short name settings may not be changed on this volume due to the global
registry setting.
#define STATUS_INCOMPATIBLE_WITH_GLOBAL_SHORT_NAME_REGISTRY_SETTING
((NTSTATUS)0xC19EL)
// Short names are not enabled on this volume.
#define STATUS_SHORT_NAMES_NOT_ENABLED_ON_VOLUME ((NTSTATUS)0xC19FL)
// The security stream for the given volume is in an inconsistent state.
// Please run CHKDSK on the volume.
#define STATUS_SECURITY_STREAM_IS_INCONSISTENT ((NTSTATUS)0xC1A0L)
// A requested file lock operation cannot be processed due to an invalid byte
range.
#define STATUS_INVALID_LOCK_RANGE ((NTSTATUS)0xC1A1L)
// {Invalid ACE Condition}
// The specified access control entry (ACE) contains an invalid condition.
#define STATUS_INVALID_ACE_CONDITION ((NTSTATUS)0xC1A2L)
// The subsystem needed to support the image type is not present.
#define STATUS_IMAGE_SUBSYSTEM_NOT_PRESENT ((NTSTATUS
RE: [cifs-protocol] RE: CAR - problem with MS-ADTS docs on possibleInferiors
Andrew, We will rename POSSSUPNOSUBCLASSES to make it easier to read by adding underscore as you suggested. It will appear in a future release of MS-ADTS document. Thanks for your suggestion!! Thanks! Hongwei -Original Message- From: Andrew Bartlett [mailto:abart...@samba.org] Sent: Wednesday, April 15, 2009 1:34 AM To: Hongwei Sun Cc: tri...@samba.org; p...@tridgell.net; cifs-proto...@samba.org Subject: Re: [cifs-protocol] RE: CAR - problem with MS-ADTS docs on possibleInferiors On Mon, 2009-04-13 at 16:03 -0700, Hongwei Sun wrote: Tridge, Thanks for pointing out the problem in the description of POSSSUPERIORS(). We revised the definition of the function in section 3.1.1.4.2 of future release of MS-ADTS. Please let us know if there is any problem. Can you please rename POSSSUPNOSUBCLASSES? It's a real mouthful and really, really painful to read. A few underscores would make the world of difference. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] RE: CAR - ldap display specifiers
Tridge, Thanks for your request. We will work on it and let you know as soon as we complete the investigation. Thanks! Hongwei Sun - Sr. Support Escalation Engineer DSC Protocol Team, Microsoft hongw...@microsoft.com Tel: 469-7757027 x 57027 - -Original Message- From: tri...@samba.org [mailto:tri...@samba.org] Sent: Thursday, July 02, 2009 2:15 AM To: Interoperability Documentation Help Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: CAR - ldap display specifiers Hi, We've been having trouble getting AD server administrative tools (such as the users and computers tool) working correctly when using a Samba DC. The problem is that we don't have all the entries from the CN=DisplaySpecifiers,CN=Configuration part of the ldap tree. To work correctly for english we at minimum need all of the CN=409 entries, but we also want to work correctly with the 23 other languages that AD supports. The WSPP docs don't seem to contain these DisplaySpecifier entries. The 2.2.1 table in [MS-ADTS].pdf has the mappings from the LCID to the language, but we need the full ldif for the entries themselves. I think you either need to publish these as a lump of ldif (it would be over 30k lines of ldif I think) or you need to publish an approved tool for WSPP licensees to use to extract the DisplaySpecifier information from a running Windows DC, and make it clear that the output is then available to licensees under the WSPP license terms. We'd be happy to write that tool for you if you like. Please don't just stick it all in a PDF format in a WSPP update - extracting large lumps of ldif back out of PDFs is pretty nasty :-) Cheers, Tridge ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Clarify reserved bytes that are in fact used in LogonSamLogonEx response
Andrew, Thanks for the information. It fixed the problem. Now I don't receive any error other than the expected ones. Hongwei -Original Message- From: Andrew Bartlett [mailto:abart...@samba.org] Sent: Monday, August 03, 2009 2:39 AM To: Hongwei Sun Cc: Nick Meier; Sebastian Canevari; p...@tridgell.net; cifs-proto...@samba.org Subject: RE: [cifs-protocol] Clarify reserved bytes that are in fact used in LogonSamLogonEx response On Fri, 2009-07-31 at 00:30 +, Hongwei Sun wrote: Andrew, We are able to set up environment with a W2k8 server joined to Samba domain. I ran the three commands you mentioned in your e-mail. bin/smbclient //win2008-2/test -Uadministrator%samba2 -d1 -kno bin/smbclient //win2008-2/test -Uadministrator%samba2 -d1 -kyes bin/smbclient //win2008-2/test -Uadministrator%samba2 -d1 -kyes --option=gensec:spnego=no --option=gensec:gssapi_spnego=yes I get the same error as you in the first command that is basically using NTLM. But I have problem with the next two commands that use Kerberos. Please see the errors returned on screen shots. Any chance you can include these as text next time? (it just makes it easier to quote etc). As I see it, you need to put: [libdefaults] default_realm = SAMBA4.NET dns_lookup_realm = true dns_lookup_kdc = true into your /etc/krb5.conf (assuming you can get to samba4.net with DNS, otherwise add a manual KDC declaration). Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Clarify reserved bytes that are in fact used in LogonSamLogonEx response
Matthieu, The bit in your UserFlags (0x520), that is enabled but undefined in MS-PAC, is bit 0x400. It is LOGON_PROFILE_PATH_RETURNED, which by the way is actually defined in Samba source (librpc/gen_ndr/netlogon.h) too. This bit is turned on when bit I in ParameterControl in NETLOGON_LOGON_IDENTITY_INFO(2.2.1.4.15 MS-NPRC) is enabled. I filed a request to have this confirmed and the document updated. We are also working on checking other bits on UserFlags too. I will keep you posted. Thanks! Hongwei -Original Message- From: Matthieu Patou [mailto:mat+informatique.sa...@matws.net] Sent: Saturday, August 01, 2009 4:40 AM To: Hongwei Sun Cc: Andrew Bartlett; Nick Meier; p...@tridgell.net; cifs-proto...@samba.org; Sebastian Canevari; Interoperability Documentation Help Subject: Re: [cifs-protocol] Clarify reserved bytes that are in fact used in LogonSamLogonEx response Hello all, I found the problem. Right now samba4 return 0 as logon and logoff time either in the LogonSamLogonEx (SAM_INFO4 structure) or in kerberos (PAC_LOGON_INFO of PAC). It seems that the srv component that handle smb dialogs in windows 2008 server do not appreciate this answer. Tweaking the source of samba4 to make return 0x7fff (infinite time) for logoff makes it more happy. It would have be simpler to find the problem if windows 2008 returned a more explicit error in place of STATUS_REQUEST_NOT_ACCEPTED. For some reason it seems that this problem do not occur in interactive logons (it's not the same components that are called also). In any case fine inspection through wireshark of a SAM_INFO4 structure returned by a Windows 2003 R2 server to a Windows 2008 server request gives us some User Flags not documented. Users Flags returned:: 20 05 00 00 (last 4 bytes of line 0x70) It gives us 0x520 or 0101 0010 In MS-PAC.pdf only the 12 lower bits are documented which didn't give an explanation for the third bit of the second byte. Can you gives us the explanation of this bit (and others one if applicable). Here is the full content of the sam_info4: 06 00 00 00 00 00 02 00 10 95 6f 37 a6 05 ca 01 ..o7 0010 ff ff ff ff ff ff ff 7f ff ff ff ff ff ff ff 7f 0020 04 53 0a 67 38 61 c9 01 04 13 74 91 01 62 c9 01 .S.g8at..b.. 0030 ff ff ff ff ff ff ff 7f 1a 00 1c 00 04 00 02 00 0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0060 00 00 00 00 00 00 00 00 3b 00 00 00 f4 01 00 00 ;... 0070 01 02 00 00 05 00 00 00 08 00 02 00 20 05 00 00 ... 0080 fa 40 c6 06 2c 65 f8 cc 0e 8e 5c 8a 9e 9a 57 b7 @..,e\...W. 0090 14 00 16 00 0c 00 02 00 0c 00 0e 00 10 00 02 00 00a0 14 00 02 00 c7 b2 00 73 b4 fb 7d b2 10 02 00 00 ...s..}. 00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00d0 00 00 00 00 14 00 16 00 18 00 02 00 30 00 30 00 0.0. 00e0 1c 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0130 00 00 00 00 0e 00 00 00 00 00 00 00 0d 00 00 00 0140 41 00 64 00 6d 00 69 00 6e 00 69 00 73 00 74 00 A.d.m.i.n.i.s.t. 0150 72 00 61 00 74 00 6f 00 72 00 00 00 05 00 00 00 r.a.t.o.r... 0160 07 02 00 00 07 00 00 00 08 02 00 00 07 00 00 00 0170 00 02 00 00 07 00 00 00 06 02 00 00 07 00 00 00 0180 01 02 00 00 07 00 00 00 0b 00 00 00 00 00 00 00 0190 0a 00 00 00 57 00 32 00 4b 00 33 00 41 00 44 00 W.2.K.3.A.D. 01a0 56 00 5a 00 30 00 31 00 07 00 00 00 00 00 00 00 V.Z.0.1. 01b0 06 00 00 00 4d 00 53 00 57 00 32 00 4b 00 33 00 M.S.W.2.K.3. 01c0 04 00 00 00 01 04 00 00 00 00 00 05 15 00 00 00 01d0 86 ec 41 48 9a 49 bf 58 d1 8f f7 2b 0b 00 00 00 ..AH.I.X...+ 01e0 00 00 00 00 0a 00 00 00 6d 00 73 00 77 00 32 00 m.s.w.2. 01f0 6b 00 33 00 2e 00 74 00 73 00 74 00 18 00 00 00 k.3...t.s.t. 0200 00 00 00 00 18 00 00 00 41 00 64 00 6d 00 69 00 A.d.m.i. 0210 6e 00 69 00 73 00 74 00 72 00 61 00 74 00 6f 00 n.i.s.t.r.a.t.o. 0220 72 00 40 00 6d 00 73 00 77 00 32 00 6b 00 33 00 r...@.m.s.w.2.k.3. 0230 2e 00 74 00 73 00 74 00 01 00 00 00 00 00 00 00 ..t.s.t. 0240 00 00 00 00 Please also note that if the MS-PAC.pdf could be updated to clearly define the first two long in array ExpansionRoom as being LanmanSessionKey (if confirmed). Regards. Matthieu Patou. On 07
Re: [cifs-protocol] Excel timestamp client side-caching request
Hi, Jeremy, Thanks for the information! I will start working on this. I will let you know if I have any question. Hongwei -Original Message- From: Jeremy Allison [mailto:j...@samba.org] Sent: Wednesday, August 05, 2009 4:47 PM To: Interoperability Documentation Help Cc: j...@samba.org; p...@tridgell.net; cifs-proto...@samba.org Subject: Excel timestamp client side-caching request Hi Hongwei, As requested here is a write up of the Excel timestamps issue I've discovered with client side caching turned on. To reproduce. Use Windows Vista with Microsoft Office 2003 : Set up a share called offline, containing a single Excel file test.xls. Mount this share as drive z:, then open with explorer z: Right click on the test.xls file and enable Make this file available offline. Then double click text.xls to open the file, and *immediately* (as soon as the Excel window opens) click on the X (top right hand corner) to close Excel. Then right click on test.xls and select Sync. Against a Windows 2003 server this always works, against a Samba server it intermittently (50% to 90% of the time) fails. The symptom is that the Sync icon in the lower bar shows a ! icon, and looking at the synchronization failure shows that the last write timestamp on the file on the remote server has been updated to the current time at open, instead of being the same as the original last write time which is being stored in the cache on the local Vista client. What is going on under the covers - On selecting Make this file available offline the file (and metadata is copied locally onto the Vista client). When the file is double clicked and opened by Excel, the sequence of events is that the file is opened with NTCreateX, then the last write time is set to the current time using SET_FILE_INFO, then part of the file is written to (I'm assuming to enable synchronization info to be conveyed to another process trying to open this .xls file at the same time). When the .xls file is closed, the client *should* then use SET_FILE_INFO to restore the last write time to the original last write time that was originally read before the file was opened. Against a Samba server the client does this *sometimes*, but not reliably and I'm trying to figure out why. I'm enclosing two packet capture traces. The first is called office2003-openclose-samba-bad.pcap and is the above scenario being done from a Vista client (IP address: 172.18.102.177) to a Samba server (IP address: 172.18.102.85). The meta data of the .XLS file on the Samba server is : File: `test.xls' Size: 811520 Blocks: 1608 IO Block: 4096 regular file Device: 806h/2054d Inode: 11567162Links: 1 Access: (0666/-rw-rw-rw-) Uid: (41427/ jra) Gid: ( 5000/ eng) Access: 2009-07-22 12:00:00.0 -0700 Modify: 2009-07-31 00:00:00.0 -0700 Change: 2009-08-04 10:21:49.0 -0700 This is a modified version of Samba that stores the create time in the access field of the POSIX timestamp, on a filesystem mounted with noatime so that field is free to use by Samba as the create time. Packets 0 - 900 show the right click - Set Offline action from explorer. Packets 958 - 2079 show the open/close being done by Excel on the file - note this is an example of a correct operation by the client (in that it resets the last write timestamp correctly back to the server). Packets 2080 - 2200 show the right click - Sync action from explorer (that succeeds). The rest of the packets 2201 - 2976 show the open/close right click - Sync operation being done again immediately against the .XLS file, and this time the operation fails (the last write timestamp is not correctly reset). The interesting packets are : 1043: SET_FILE_INFO setting the last write time to the current time. 1882: SET_FILE_INFO resetting the last write time to the original time (2009-07-31 00:00:00.0 -0700) - this is the step that is missing from the second operation that causes the sync to succeed. 2262: SET_FILE_INFO setting the last write time to the current time. Note that in this second case there is no follow up SET_FILE_INFO to reset the time to the correct original value. What I'm trying to find out is what it is within the data Samba is returning to the client that causes the client to fail to restore the original timestamp in the case where CSC sync caching is turned on. As a comparison, I'm including a packet trace from the same client against a Win2K3 server, called : office2003-open-close-windows-good.cap. This is exactly the same sequence of operations against a Win2k3 server, with IP address : 172.18.103.237 (the client IP address is still 172.18.102.177). The file in this case is called Book1.xls. The interesting packets in this trace are: 1216: SET_FILE_INFO setting the last write time to the current time. 1513: SET_FILE_INFO resetting the last write time to the original time.
Re: [cifs-protocol] erroneous references to little-endian
Andrew, Richard has left our team and I have taken the ownership of this request. In the last a few weeks, We have been actively working on updating documentation for this broad issue to improve our documentation. We will finish the update soon. I will let you know as soon as the detail is finalized. We have scheduled a meeting between the Samba team and our documentation team to have more discussion on this issue in the Samba IOLab next month. Thanks for your patience. Hongwei -Original Message- From: cifs-protocol-boun...@cifs.org [mailto:cifs-protocol-boun...@cifs.org] On Behalf Of Andrew Bartlett Sent: Monday, August 10, 2009 2:41 AM To: Richard Guthrie Cc: 'p...@tridgell.net'; 'cifs-proto...@samba.org' Subject: Re: [cifs-protocol] erroneous references to little-endian On Sat, 2009-07-11 at 09:42 +1000, Andrew Bartlett wrote: On Fri, 2009-07-10 at 09:23 -0700, Richard Guthrie wrote: Andrew, We will continue to work to resolution on the broader issue of how to handle bit fields in the documentation. Your feedback is much appreciated there. For this specific issue, in general, for custom-marshaled fields you should see a bit field that follows the RFC convention where the high bit of the first byte to hit the wire is in column 0, and the low bit of the last byte to hit the wire is in column 31 (so that the bits are shown from left-to-right in the order they naturally appear over the network). Your two statements are inconsistent, and not consistent with what the documentation does. Do you mean to say that I can expect the above in future, or that you claim the documentation does the above? If the bits were numbers, for little-endian numbers, such that bit 0, representing integer 1 appeared a the left (the little end), and that the numbers in the heading increased 0..31 left-to-right, above the value such that for it's natural natural number representation (as indicated by the stated endianness) that value == n^2, then I would be happy. We are going back through the documentation to ensure that custom marshaled fields have the appropriate specification for endianness. Alternately, can you please point me at the RFC that indicates both bit numbering such that (value != n^2) where n is the described bit number, and where bits are ordered in a different order to bytes. Microsoft's documentation is the only place, ever, that I have seen this insanity. I'm still unsatisfied with the situation here. Will there ever be any progress? Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Excel timestamp client side-caching request
Jeremy, Just a quick update. I have duplicated the exactly same behavior as you reported, which makes live debugging possible. We are actively working on it. I will keep you posted. Thanks! --- Hongwei Sun - Sr. Support Escalation Engineer DSC Protocol Team, Microsoft hongw...@microsoft.com Tel: 469-7757027 x 57027 - -Original Message- From: Jeremy Allison [mailto:j...@samba.org] Sent: Wednesday, August 05, 2009 4:47 PM To: Interoperability Documentation Help Cc: j...@samba.org; p...@tridgell.net; cifs-proto...@samba.org Subject: Excel timestamp client side-caching request Hi Hongwei, As requested here is a write up of the Excel timestamps issue I've discovered with client side caching turned on. To reproduce. Use Windows Vista with Microsoft Office 2003 : Set up a share called offline, containing a single Excel file test.xls. Mount this share as drive z:, then open with explorer z: Right click on the test.xls file and enable Make this file available offline. Then double click text.xls to open the file, and *immediately* (as soon as the Excel window opens) click on the X (top right hand corner) to close Excel. Then right click on test.xls and select Sync. Against a Windows 2003 server this always works, against a Samba server it intermittently (50% to 90% of the time) fails. The symptom is that the Sync icon in the lower bar shows a ! icon, and looking at the synchronization failure shows that the last write timestamp on the file on the remote server has been updated to the current time at open, instead of being the same as the original last write time which is being stored in the cache on the local Vista client. What is going on under the covers - On selecting Make this file available offline the file (and metadata is copied locally onto the Vista client). When the file is double clicked and opened by Excel, the sequence of events is that the file is opened with NTCreateX, then the last write time is set to the current time using SET_FILE_INFO, then part of the file is written to (I'm assuming to enable synchronization info to be conveyed to another process trying to open this .xls file at the same time). When the .xls file is closed, the client *should* then use SET_FILE_INFO to restore the last write time to the original last write time that was originally read before the file was opened. Against a Samba server the client does this *sometimes*, but not reliably and I'm trying to figure out why. I'm enclosing two packet capture traces. The first is called office2003-openclose-samba-bad.pcap and is the above scenario being done from a Vista client (IP address: 172.18.102.177) to a Samba server (IP address: 172.18.102.85). The meta data of the .XLS file on the Samba server is : File: `test.xls' Size: 811520 Blocks: 1608 IO Block: 4096 regular file Device: 806h/2054d Inode: 11567162Links: 1 Access: (0666/-rw-rw-rw-) Uid: (41427/ jra) Gid: ( 5000/ eng) Access: 2009-07-22 12:00:00.0 -0700 Modify: 2009-07-31 00:00:00.0 -0700 Change: 2009-08-04 10:21:49.0 -0700 This is a modified version of Samba that stores the create time in the access field of the POSIX timestamp, on a filesystem mounted with noatime so that field is free to use by Samba as the create time. Packets 0 - 900 show the right click - Set Offline action from explorer. Packets 958 - 2079 show the open/close being done by Excel on the file - note this is an example of a correct operation by the client (in that it resets the last write timestamp correctly back to the server). Packets 2080 - 2200 show the right click - Sync action from explorer (that succeeds). The rest of the packets 2201 - 2976 show the open/close right click - Sync operation being done again immediately against the .XLS file, and this time the operation fails (the last write timestamp is not correctly reset). The interesting packets are : 1043: SET_FILE_INFO setting the last write time to the current time. 1882: SET_FILE_INFO resetting the last write time to the original time (2009-07-31 00:00:00.0 -0700) - this is the step that is missing from the second operation that causes the sync to succeed. 2262: SET_FILE_INFO setting the last write time to the current time. Note that in this second case there is no follow up SET_FILE_INFO to reset the time to the correct original value. What I'm trying to find out is what it is within the data Samba is returning to the client that causes the client to fail to restore the original timestamp in the case where CSC sync caching is turned on. As a comparison, I'm including a packet trace from the same client against a Win2K3 server, called : office2003-open-close-windows-good.cap. This is exactly the same sequence of operations
Re: [cifs-protocol] Excel timestamp client side-caching request
Jeremy, We are still working on identifying the issue. It seems that when Excel tries to send SET_INFO when closing the file, CSC thinks ,for some reason, that the object is in disconnected offline state and any update to the file is just applied to the CSC local cache. That is why the SMB Transact2 request is not really sent over the wire. It looks like that it is timing related as I have much smaller chance to capture the condition if it is running under debugger. I will be on vacation next week until Friday. Nick and Edgar will continue working on the issue. If you have any information or requests, please let us know. We will also let you know as soon as we get the root cause on the issue. Thanks! Hongwei -Original Message- From: Jeremy Allison [mailto:j...@samba.org] Sent: Monday, August 10, 2009 11:28 PM To: Hongwei Sun Cc: Jeremy Allison; p...@tridgell.net; cifs-proto...@samba.org Subject: Re: Excel timestamp client side-caching request On Tue, Aug 11, 2009 at 02:57:44AM +, Hongwei Sun wrote: Jeremy, Just a quick update. I have duplicated the exactly same behavior as you reported, which makes live debugging possible. We are actively working on it. I will keep you posted. Great ! I'm in the process of adding real create timestamps with full Windows semantics to the Samba code, so let me know if that's the issue and I should have some new code later this week :-). Thanks a *lot* for the help ! Jeremy. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] MS-NRPC: AES Schannel problems
Metze, Thanks for your question. I will be working on this request. I will let you know as soon as I complete the investigation. Thanks! Hongwei Sun - Sr. Support Escalation Engineer DSC Protocol Team, Microsoft hongw...@microsoft.com Tel: 469-7757027 x 57027 - -Original Message- From: Stefan (metze) Metzmacher [mailto:me...@samba.org] Sent: Tuesday, August 25, 2009 11:13 AM To: Interoperability Documentation Help Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: MS-NRPC: AES Schannel problems Hi, I'm currently trying to implement the AES based Netlogon Secure Channel in Samba. But the documentation is not really clear about the used algorithms. I have started with the implementation here: http://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master4-schannel And here's the actual commit that tries to add aes support: http://gitweb.samba.org/?p=metze/samba/wip.git;a=commitdiff;h=50dca9ce0f051c863f00cc949db2c19bf247887b In Section 3.1.4.3 Session-Key Computation the hmac-sha256 base computation of the session-key seems to use the plain SharedSecret and not the NT-HASH of it (MD4(UNICODE(ShareSecret))), is that correct? I thought the plain text is never stored in AD by default... Where should the netlogon server get the plain text from? I just tried the NT-HASH see my netlogon_creds_init_hmac_sha256() function. In Section 3.1.4.4 Netlogon Credential Computation there's a AesEncrypt function used. Can you please document the exact algorithm that's used there. You say AES128 is used in CFB mode without initialization vector. http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation says that all modes except ECB require an IV. It would also be nice if you could add some more example values in secion 4.2 Cryptographic Values for Session Key Validation. metze ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] MS-NRPC: AES Schannel problems
Metze, The SharedSecret used for AES session key computation, as described in 3.1.4.3 MS-NRPC , should be the NTOWF (MD4(UNICODE(Passwd))) of the plaintext password. The section 3.1.1 of MS-NRPC explains what a SharedSecret is used for session key calculation in Windows implementations. The SharedSecret is stored in UnicodePwd AD attribute. Please see section 3.1.1 and Windows Behavior notes 66,67 of MS-NRPC for details. I will continue working on all questions related to AES encryption. Thanks! Hongwei Sun - Sr. Support Escalation Engineer DSC Protocol Team, Microsoft hongw...@microsoft.commailto:hongw...@microsoft.com Tel: 469-7757027 x 57027 - -Original Message- From: Stefan (metze) Metzmacher [mailto:me...@samba.org] Sent: Tuesday, August 25, 2009 11:13 AM To: Interoperability Documentation Help Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: MS-NRPC: AES Schannel problems Hi, I'm currently trying to implement the AES based Netlogon Secure Channel in Samba. But the documentation is not really clear about the used algorithms. I have started with the implementation here: http://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master4-schannel And here's the actual commit that tries to add aes support: http://gitweb.samba.org/?p=metze/samba/wip.git;a=commitdiff;h=50dca9ce0f051c863f00cc949db2c19bf247887b In Section 3.1.4.3 Session-Key Computation the hmac-sha256 base computation of the session-key seems to use the plain SharedSecret and not the NT-HASH of it (MD4(UNICODE(ShareSecret))), is that correct? I thought the plain text is never stored in AD by default... Where should the netlogon server get the plain text from? I just tried the NT-HASH see my netlogon_creds_init_hmac_sha256() function. In Section 3.1.4.4 Netlogon Credential Computation there's a AesEncrypt function used. Can you please document the exact algorithm that's used there. You say AES128 is used in CFB mode without initialization vector. http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation says that all modes except ECB require an IV. It would also be nice if you could add some more example values in secion 4.2 Cryptographic Values for Session Key Validation. metze ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Status: Please clarify LSA and OsVersion behaviour in MS-NRPC (SRX090713600128)
Andrew,
I just want to make sure that you have received all the information for this
request. As Bill already indicated, how the OS version specified in
NETLOGON_WORKSTATION_INFO is translated into the operatingSystemVersion
attribute is documented in 2.2.1.3.16 of MS-NRPC
http://msdn.microsoft.com/en-us/library/dd240432.aspx as follows:
OsVersionInfo: If not NULL, the attribute operatingSystemVersion on the
client's computer account in Active Directory (using the ABNF Syntax as
specified in [RFC2234]) is set to:
If OsVersionInfo.dwBuildNumber is 0:
operatingSystemVersion = MajorVersion . MinorVersion
MajorVersion = OsVersionInfo.dwMajorVersion
MinorVersion = OsVersionInfo.dwMinorVersionOtherwise:
operatingSystemVersion = MajorVersion . MinorVersion
.
BuildNumber
MajorVersion = OsVersionInfo.dwMajorVersion
MinorVersion = OsVersionInfo.dwMinorVersion
BuildNumber = OsVersionInfo.dwBuildNumber
We will add the reference to this information to OsVersion in 2.2.1.3.6
NETLOGON_WORKSTATION_INFO in the future version of the document.
Please let us know if you have any further questions.
Thanks!
Hongwei
-Original Message-
From: cifs-protocol-boun...@cifs.org [mailto:cifs-protocol-boun...@cifs.org] On
Behalf Of Bill Wesse
Sent: Wednesday, August 26, 2009 9:09 AM
To: Andrew Bartlett
Cc: p...@tridgell.net; cifs-proto...@samba.org; Matthias Dieter Wallnöfer
Subject: Re: [cifs-protocol] Status: Please clarify LSA and OsVersion behaviour
in MS-NRPC (SRX090713600128)
Andrew - thanks for focusing me - I assume you are referring to the quoted text
below:
OsVersion: ... The DC that receives this data structure updates the
operatingSystemVersion attribute of the client's machine account object in
Active Directory with this value, unchanged and uninterpreted, as specified in
[MS-ADTS].
I find that OSVERSIONINFOEX is equivalent to NL_OSVERSIONINFO_V1, which is
documented as shown below - and contains the information you are seeking.
I have already advised the bug/TDI owner concerning this.
==
[MS-NRPC]: Netlogon Remote Protocol Specification
2.2.1.3.14 NL_IN_CHAIN_SET_CLIENT_ATTRIBUTES_V1
http://msdn.microsoft.com/en-us/library/dd240432.aspx
OsVersionInfo: If not NULL, the attribute operatingSystemVersion on the
client's computer account in Active Directory (using the ABNF Syntax as
specified in [RFC2234]) is set to:
If OsVersionInfo.dwBuildNumber is 0:
operatingSystemVersion = MajorVersion . MinorVersion
MajorVersion = OsVersionInfo.dwMajorVersion
MinorVersion = OsVersionInfo.dwMinorVersion
Otherwise:
operatingSystemVersion = MajorVersion . MinorVersion .
BuildNumber
MajorVersion = OsVersionInfo.dwMajorVersion
MinorVersion = OsVersionInfo.dwMinorVersion
BuildNumber = OsVersionInfo.dwBuildNumber
OsName: NULL or a null-terminated Unicode string that is used to update the
attribute operatingSystem on the client's computer account object in Active
Directory. 37
37 Section 2.2.1.3.16: Added in Windows Server 2008.
==
[MS-NRPC]: Netlogon Remote Protocol Specification
2.2.1.3.15 NL_OSVERSIONINFO_V1
http://msdn.microsoft.com/en-us/library/dd240431.aspx
typedef struct _NL_OSVERSIONINFO_V1 {
DWORD dwOSVersionInfoSize;
DWORD dwMajorVersion;
DWORD dwMinorVersion;
DWORD dwBuildNumber;
DWORD dwPlatformId;
wchar_t szCSDVersion[128];
unsigned short wServicePackMajor;
unsigned short wServicePackMinor;
unsigned short wSuiteMask;
unsigned char wProductType;
unsigned char wReserved;
} NL_OSVERSIONINFO_V1;
==
Example:
==
[MS-DRSR]: Directory Replication Service (DRS) Remote Protocol Specification
4.1.5.3.1 Initial State
http://msdn.microsoft.com/en-us/library/cc228355.aspx
1 operatingSystem: Windows Server 2003;
1 operatingSystemVersion: 5.2 (3790);
1 operatingSystemServicePack: Service Pack 1;
Regards,
Bill Wesse
MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
TEL: +1(980) 776-8200
CELL: +1(704) 661-5438
FAX: +1(704) 665-9606
-Original Message-
From: Andrew Bartlett [mailto:abart...@samba.org]
Sent: Tuesday, August 25, 2009 9:18 PM
To: Bill Wesse
Cc: p...@tridgell.net; cifs-proto...@samba.org; Matthias Dieter Wallnöfer
Subject: RE: Status: Please clarify LSA and OsVersion behaviour in MS-NRPC
(SRX090713600128)
On Tue, 2009-08-25 at 07:17 -0700, Bill Wesse wrote:
Thanks again for your input; my response interpolated below...
Good morning
Re: [cifs-protocol] MS-NRPC: AES Schannel problems
Metze, We confirmed that AesCrypt follows the normative reference of [FIPS197] (http://www.csrc.nist.gov/publications/fips/fips197/fips-197.pdf). As far as the statement about AES128 encryption CFB mode, we also confirmed that we do use 0 as Initialize Vector(IV), so in this case all you have to do is set the IV to the 128-bit quantity consisting of all zeros. The reference we are using for CFB mode is [SP800-38A] ( http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf ) which states that CFB mode requires a valid and unpredictable IV (Section 6.3). Zero is a valid IV, certainly not unpredictable. However, the unpredictability is required only to guard against specific types of attacks, which become possible when a single key is used to encrypt a large number of related plaintexts. Predictable IVs could be used in applications where this is not a concern. We will update the document with the correct references to the related statements in the MS-NRPC document. Thanks! Hongwei -Original Message- From: Stefan (metze) Metzmacher [mailto:me...@samba.org] Sent: Wednesday, August 26, 2009 12:15 AM To: Hongwei Sun Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: Re: MS-NRPC: AES Schannel problems Hongwei, The SharedSecret used for AES session key computation, as described in 3.1.4.3 MS-NRPC , should be the NTOWF (MD4(UNICODE(Passwd))) of the plaintext password. The section 3.1.1 of MS-NRPC explains what a SharedSecret is used for session key calculation in Windows implementations. The SharedSecret is stored in UnicodePwd AD attribute. Please see section 3.1.1 and Windows Behavior notes 66,67 of MS-NRPC for details. Yes, I saw that and that's why I've also done it like this, but I was wondering why Section 3.4.1 has M4SS := MD4(UNICODE(SharedSecret)) explicit for the hmac_md5 session key and the des session key. I think it would make sense to also add it to the hmac_sha256 section in order to remove the confusion I had. I will continue working on all questions related to AES encryption. Thanks, as it seems I compute the session key correct, this is the place (netlogon_creds_step_crypt()) where I have a bug, because I'm getting access denied when I try DCERPC_SCHANNEL_AES against a w2k8r2rc server. metze -Original Message- From: Stefan (metze) Metzmacher [mailto:me...@samba.org] Sent: Tuesday, August 25, 2009 11:13 AM To: Interoperability Documentation Help Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: MS-NRPC: AES Schannel problems Hi, I'm currently trying to implement the AES based Netlogon Secure Channel in Samba. But the documentation is not really clear about the used algorithms. I have started with the implementation here: http://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads /master4-schannel And here's the actual commit that tries to add aes support: http://gitweb.samba.org/?p=metze/samba/wip.git;a=commitdiff;h=50dca9ce 0f051c863f00cc949db2c19bf247887b In Section 3.1.4.3 Session-Key Computation the hmac-sha256 base computation of the session-key seems to use the plain SharedSecret and not the NT-HASH of it (MD4(UNICODE(ShareSecret))), is that correct? I thought the plain text is never stored in AD by default... Where should the netlogon server get the plain text from? I just tried the NT-HASH see my netlogon_creds_init_hmac_sha256() function. In Section 3.1.4.4 Netlogon Credential Computation there's a AesEncrypt function used. Can you please document the exact algorithm that's used there. You say AES128 is used in CFB mode without initialization vector. http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation says that all modes except ECB require an IV. It would also be nice if you could add some more example values in secion 4.2 Cryptographic Values for Session Key Validation. metze ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Bitfields in the WSPP docs
Andrew, Thanks for the valuable feedback that is very important for us to continuously improve the protocol documentation. We will definitely consider your suggestion and we can also have further discussion during IO Lab next week. Thanks! Hongwei Sun - Sr. Support Escalation Engineer DSC Protocol Team, Microsoft hongw...@microsoft.com Tel: 469-7757027 x 57027 - -Original Message- From: cifs-protocol-boun...@cifs.org [mailto:cifs-protocol-boun...@cifs.org] On Behalf Of Andrew Bartlett Sent: Sunday, September 13, 2009 11:59 PM To: Interoperability Documentation Help Cc: cifs-proto...@samba.org; docfeedb...@thetc.org Subject: [cifs-protocol] Bitfields in the WSPP docs Over a year ago, I wrote to this list about the incredible frustration I suffer on a regular basis attempting to read and use the Microsoft documentation. The problem was regarding the layout and incomprehensible system used to describe the bitfields that occur in so many of the protocol documents I use, and a year on, I was wondering if I had to reinforce my concerns. But there is hope - I've just seen a copy of the MS-CIFS document that Chris Hertel has helped author (contracting to Microsoft), and I'm truly amazed by the progress that has been made. If this document survives intact to final form, it will show that programmer-compatible documentation can be produced within this framework. To pick a random example, I see 2.2.4.43 'SMB_COM_WRITEX_ANDX'. It shows the format of the packet in a clear, text based format, replacing the block diagrams, and the error codes are clearly given both textual names and hexidecimal values. (While it is incredibly disappointing to no longer need to do 2^(n-31) in my head, I do find it a little easier ;-) It also puts to rest the incredibly insane 'bytes in little endian, bits in big endian' that I have to say was so truly 'special'. What I'm trying to say is that I really, really appreciate the improvement. These make the documents the single best example of network interface documentation formatting that I have seen from this protocol program, I strongly hope that whatever challenges have prevented the use of such clear language in other documents might finally have been overcome, so that other critical documents, the RPC documents in particular, can also benefit from this treatment. Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [Pfif] MS-NRPC: AES Schannel problems
Metze, I think that Nick already informed you that AES 128 with 8 bit CFB mode has to be used. I filed a request to add the information into 3.1.4.4 of MS-NRPC. I also noticed that in mxnrpc.c you attached , you used AES_cfb128_encrypt() (128 bit CFB mode) for computing server credential. Please let us know if you have resolved the issue and if we can provide further help. Meanwhile, I provide some sample values that I captured from debugger for you to verify your logic. OWF Password : 13 c0 b0 4b 66 25 0d 08-b8 a3 90 4d cc 8b 34 e3 Client Challenge: 25 63 e3 5f 69 e1 5a 24 Server Challenge: 9C 66 5F 90 D9 83 DF 43 Session Key calculated: c9 c7 f7 2f c6 b9 13 e3-67 ae a9 1d 0a e3 a7 70 Client Credential: 58 6a df 53 ef 72 78 d9 Server Credential E1 41 62 09 B2 3E 57 51 Thanks! Hongwei -Original Message- From: Stefan (metze) Metzmacher [mailto:me...@samba.org] Sent: Monday, September 14, 2009 7:31 PM To: Hongwei Sun Cc: p...@tridgell.net; cifs-proto...@samba.org; Nick Meier Subject: Re: [Pfif] MS-NRPC: AES Schannel problems now with attachment... We confirmed that AesCrypt follows the normative reference of [FIPS197] (http://www.csrc.nist.gov/publications/fips/fips197/fips-197.pdf). As far as the statement about AES128 encryption CFB mode, we also confirmed that we do use 0 as Initialize Vector(IV), so in this case all you have to do is set the IV to the 128-bit quantity consisting of all zeros. The reference we are using for CFB mode is [SP800-38A] ( http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf ) which states that CFB mode requires a valid and unpredictable IV (Section 6.3). Zero is a valid IV, certainly not unpredictable. However, the unpredictability is required only to guard against specific types of attacks, which become possible when a single key is used to encrypt a large number of related plaintexts. Predictable IVs could be used in applications where this is not a concern. thanks I'll try that. AES128 is also used in section 3.3.4.2.1 Generating an Initial Netlogon Signature Token under 8., is that the same AesCrypt function (also using CFB mode) with a just IV being contructed by using the sequence number twice? I've tried to get that working, but it doesn't work:-( I've setup a trust between two w2k8r2 domains and captured the ServerReqChallenge and ServerAuthenticate3. And they're using Netlogon Schannel with AES. (They also use NDR64, wireshark doesn't handle this yet...) There're 5 ServerAuthenticate3 exchanges in the capture and I put the data into a simple standalone crypto challenge program. So all we need is to find the algorithm to recalculate the examples, changing the mxnrpc.c file. metze We will update the document with the correct references to the related statements in the MS-NRPC document. It would be really nice if you could also add some more example values in secion 4.2 Cryptographic Values for Session Key Validation. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [Pfif] MS-NRPC: AES Schannel problems
Metze, Yes, your initial observation is right. Checksum is only 8 bytes and the cofounder follows with 8 bytes of checksum. I filed a request to update the document. I will look at the code and compare it with the documentation and Windows implementation. I will let you know. Thanks! Hongwei -Original Message- From: Stefan (metze) Metzmacher [mailto:me...@samba.org] Sent: Thursday, September 17, 2009 11:17 AM To: Hongwei Sun; p...@tridgell.net; cifs-proto...@samba.org; Nick Meier; Guenther Deschner Subject: Re: [Pfif] MS-NRPC: AES Schannel problems Hi Hongwei, Nick just told me that Windows seems to have a bug there and I tried to reproduce this bug in our code, but I still can't get windows to accept signed or sealed traffic from us. See the attached capture: Frames 178 and 179 are with signing Frames 330 and 331 are with sealing You can take a look at my code here (see the top 5 commits) http://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master4-schannel metze -Original Message- From: Stefan (metze) Metzmacher [mailto:me...@samba.org] Sent: Wednesday, September 16, 2009 1:46 PM To: Hongwei Sun Cc: p...@tridgell.net; cifs-proto...@samba.org; Nick Meier; Guenther Deschner Subject: Re: [Pfif] MS-NRPC: AES Schannel problems Hi Hongwei, I think that Nick already informed you that AES 128 with 8 bit CFB mode has to be used. I filed a request to add the information into 3.1.4.4 of MS-NRPC. I also noticed that in mxnrpc.c you attached , you used AES_cfb128_encrypt() (128 bit CFB mode) for computing server credential. Please let us know if you have resolved the issue and if we can provide further help. Yes, he does and we got that part working. Thanks! using AES_cfb8_encrypt() instead of AES_cfb128_encrypt(). However we have the next challenge, the Netlogon SSPI provider. I used tried both AES_cfb8_encrypt() and AES_cfb128_encrypt() but both don't work. Looking at the frame 308 and the following in w2k8r2rc-l4-w2k8r2-trust-aes-schannel-01.pcap. I think there's a bug in w2k8r2 in the docs. The NL_AUTH_SHA2_SIGNATURE is filled in with very strange values. It seem that the checksum is still 8 byte and the confounder directly follows. The last 24 bytes are just uninitalized memory. They are: Frame 308: 32 00 2e 00 33 00 31 00 2e 00 39 00 2e 00 32 00 31 00 34 00 00 00 00 00 Frame 310: 35 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 Frame 311: (I think it's random because the pdu is so long and point memory in other aeas) 51 03 21 9b 41 84 cc 90 e7 e8 70 1c 52 60 55 5a 64 0c 6a 17 be 07 de 80 Looks like a unicode string instead of parts of a checksum and a confounder. metze Meanwhile, I provide some sample values that I captured from debugger for you to verify your logic. OWF Password : 13 c0 b0 4b 66 25 0d 08-b8 a3 90 4d cc 8b 34 e3 Client Challenge: 25 63 e3 5f 69 e1 5a 24 Server Challenge: 9C 66 5F 90 D9 83 DF 43 Session Key calculated: c9 c7 f7 2f c6 b9 13 e3-67 ae a9 1d 0a e3 a7 70 Client Credential: 58 6a df 53 ef 72 78 d9 Server Credential E1 41 62 09 B2 3E 57 51 It would be great if you could add this values to the docs. metze ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [Pfif] MS-NRPC: AES Schannel problems
Metze, We just found that there is a problem with the logic in step 9 of 3.3.4.2.1 (Generating an Initial Netlogon Signature Token) and step 5 of 3.3.4.2.2 (Receiving an Initial Netlogon Signature Token). When we encrypt or decrypt SequenceNumber, the IV is actually the concatenation of checksum, instead of SequenceNumber itself.I will file a request to update the document. You can change your function netsec_do_seq_num() to use checksum to construct IV. Thanks! Hongwei -Original Message- From: Stefan (metze) Metzmacher [mailto:me...@samba.org] Sent: Thursday, September 17, 2009 11:17 AM To: Hongwei Sun; p...@tridgell.net; cifs-proto...@samba.org; Nick Meier; Guenther Deschner Subject: Re: [Pfif] MS-NRPC: AES Schannel problems Hi Hongwei, Nick just told me that Windows seems to have a bug there and I tried to reproduce this bug in our code, but I still can't get windows to accept signed or sealed traffic from us. See the attached capture: Frames 178 and 179 are with signing Frames 330 and 331 are with sealing You can take a look at my code here (see the top 5 commits) http://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master4-schannel metze -Original Message- From: Stefan (metze) Metzmacher [mailto:me...@samba.org] Sent: Wednesday, September 16, 2009 1:46 PM To: Hongwei Sun Cc: p...@tridgell.net; cifs-proto...@samba.org; Nick Meier; Guenther Deschner Subject: Re: [Pfif] MS-NRPC: AES Schannel problems Hi Hongwei, I think that Nick already informed you that AES 128 with 8 bit CFB mode has to be used. I filed a request to add the information into 3.1.4.4 of MS-NRPC. I also noticed that in mxnrpc.c you attached , you used AES_cfb128_encrypt() (128 bit CFB mode) for computing server credential. Please let us know if you have resolved the issue and if we can provide further help. Yes, he does and we got that part working. Thanks! using AES_cfb8_encrypt() instead of AES_cfb128_encrypt(). However we have the next challenge, the Netlogon SSPI provider. I used tried both AES_cfb8_encrypt() and AES_cfb128_encrypt() but both don't work. Looking at the frame 308 and the following in w2k8r2rc-l4-w2k8r2-trust-aes-schannel-01.pcap. I think there's a bug in w2k8r2 in the docs. The NL_AUTH_SHA2_SIGNATURE is filled in with very strange values. It seem that the checksum is still 8 byte and the confounder directly follows. The last 24 bytes are just uninitalized memory. They are: Frame 308: 32 00 2e 00 33 00 31 00 2e 00 39 00 2e 00 32 00 31 00 34 00 00 00 00 00 Frame 310: 35 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 Frame 311: (I think it's random because the pdu is so long and point memory in other aeas) 51 03 21 9b 41 84 cc 90 e7 e8 70 1c 52 60 55 5a 64 0c 6a 17 be 07 de 80 Looks like a unicode string instead of parts of a checksum and a confounder. metze Meanwhile, I provide some sample values that I captured from debugger for you to verify your logic. OWF Password : 13 c0 b0 4b 66 25 0d 08-b8 a3 90 4d cc 8b 34 e3 Client Challenge: 25 63 e3 5f 69 e1 5a 24 Server Challenge: 9C 66 5F 90 D9 83 DF 43 Session Key calculated: c9 c7 f7 2f c6 b9 13 e3-67 ae a9 1d 0a e3 a7 70 Client Credential: 58 6a df 53 ef 72 78 d9 Server Credential E1 41 62 09 B2 3E 57 51 It would be great if you could add this values to the docs. metze ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] repsFromTo blob format (WSPP CAR)
Tridge, Thanks for your question. I will take the ownership of this request and I will let you know once I complete the investigation. Thanks! Hongwei Sun - Sr. Support Escalation Engineer DSC Protocol Team, Microsoft hongw...@microsoft.com Tel: 469-7757027 x 57027 - -Original Message- From: tri...@samba.org [mailto:tri...@samba.org] Sent: Sunday, September 20, 2009 12:15 PM To: Interoperability Documentation Help Cc: cifs-proto...@samba.org; p...@tridgell.net; me...@samba.org Subject: repsFromTo blob format (WSPP CAR) We've been unable to find a description in the WSPP docs of the format for the repsFromToBlob blob that is used to encode the repsFrom and repsTo attributes in DRS/LDAP. For now we have produced our own IDL for the blobs, which you can see here: http://samba.org/ftp/unpacked/samba_4_0_test/librpc/idl/drsblobs.idl in the typedef for the structure repsFromToBlob, but it would be good if we could confirm this with IDL (or other binary structure encoding) in the WSPP docs. The MS-DRSR doc shows some examples for version1 of the structure, but nothing for version 2 (version 2 is used by W2K8). Cheers, Tridge ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Group Policy questions
Matthieu, For Problem #1, only the SE_DACL_PROTECTED(0x1000) has to be set for ControlFlag in Security Descriptor in order to pass the step 2 in consistency testing. This is translated to P flag in SDDL. With this said, it is normal to have D:PAI since this will indicate that the SE_DACL_PROTECTED bit is set. It seems that your Security Descriptor is right in this regard. We have to get more information to see why the consistency checking fails. Could you enable GPMC logging as described in my previous mail? Please enable VERBOSE for Gpmgmttracelevel. Just for your reference, you can also use ldp.exe to display the security descriptor of a policy object in SSDL string format and parsed display format. Thanks! Hongwei -Original Message- From: Matthieu Patou [mailto:mat+informatique.sa...@matws.net] Sent: Saturday, October 17, 2009 11:33 AM To: Hongwei Sun Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: Re: Group Policy questions Hello Hongwei,Matthieu, Thank you for the answers. I have a few more questions: After testing, I think that I have some information to help you resolve all the problems. Problem #1: As described in the following link (http://support.microsoft.com/default.aspx?scid=kb;en-us;828760 ) , GPMO will check the consistency between ACLs in GPO in Active Directory and ACLs of policy folders in SYSVOL when a GPO object is clicked in GPMC. The logic is something like the following: 1. Get the security descriptor (SD) for GOP in AD and folders in SYSVOL 2. Check both security descriptors to make sure they are DACL protected (PD bit in Control flag is set). If not, ACL consistency check will fail. 3. For every permission in AD DACL, there should be the same permission in SYSVOL DACL. If all permissions have be checked through in AD ACL and there is still extra permission in SYSVOL ACL, ACLs are not consistent. Looking at the your attached SSDL of the new policy, it doesn't have PD bit set. (D:PAI means DI bit is set, which is not DACL protected). This will fail the second step of consistency checking. I did an extraction of a W2K3 policy and got the following SDDL: O:S-1-5-21-3208502064-746857408-2662927446-512G:S-1-5-21-3208502064-746857408-2662927446-512 D:PAI (A;CI;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-3208502064-746857408-2662927446-512) (A;CI;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-3208502064-746857408-2662927446-519) (A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-3208502064-746857408-2662927446-512) (A;CIIO;RPWPCCDCLCLORCWOWDSDDTSW;;;CO) (A;CI;RPWPCCDCLCLORCWOWDSDDTSW;;;SY) (A;CI;RPLCLORC;;;AU) (OA;CI;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU) (A;CI;RPLCLORC;;;ED) S:AI (OU;CIIOIDSA;WP;f30e3bbe-9ff0-11d1-b603-f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD) (OU;CIIOIDSA;WP;f30e3bbf-9ff0-11d1-b603-f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD) (OU;CIIDSA;WPWD;;f30e3bc2-9ff0-11d1-b603-f80367c1;WD) And you say that we should not have AI flag (because it's related to SE_DACL_AUTO_INHERITED aka DI bit) just the P flag (because it's related to DE_DACL_PROTECTED aka PD bit) right ? But the above SDDL seems to show the opposite, I can't exclude the fact that we have bugs when reading ACL and/or when converting them into SDDL but before to trying to check this I would like to be sure of which flag we should see. I even tweaked XCACLS.vbs (attached to this email) from http://support.microsoft.com/default.aspx?scid=kb;en-us;828760 to make it show the value of the control and it appear that the ACL for the c:\windows\sysvol has both PD and DI bit sets ie. Directory: C:\WINDOWS\SYSVOL ControlFlags: 37892 Do gpmc pass some controls while making its LDAP request because I had a look at the delegated permission through GPMC and through dsa.msc they are really different (a lot of inherited from parents objects). Problem #2: In GPMO, if the attribute sDRightsEffective of selected GPO object has DACL_SECURITY_INFORMATION bit (0x04) set, users will be prompted for ACL correction if ACLs inconsistency between AD GPO and SYSVOL is detected when a GPO node is selected. You should check the attribute for the GOP object in AD. Problem #3: This is basically the same logic as in (2). The Add and Remove buttons in Delegation dialog are enabled only when the attribute sDRightsEffective of selected GPO object has DACL_SECURITY_INFORMATION (0x04) bit set. You should check the attribute for the GOP object in AD. Yeah for this it seems that the obvious problem is the lack of sDRightsEffective in SAMBA 4. Debugging Information: By the way, you can follow the instruction in this link (http://technet.microsoft.com/en-us/library/cc737379(WS.10).aspx ) to enable GPMC logging, if you want to troubleshoot the issues related to operations in GPMC. For example, the logging will show you in which step the consistency
Re: [cifs-protocol] repsFromTo blob format (WSPP CAR)
Tridge,
The documentation update has been completed and it should be included in the
future release published on MSDN. I just like to check to see if you have any
more questions regarding this issue. If not, I will consider this case closed.
Thanks!
Hongwei
-Original Message-
From: Hongwei Sun
Sent: Tuesday, October 13, 2009 4:46 PM
To: tri...@samba.org; Interoperability Documentation Help
Cc: cifs-proto...@samba.org; p...@tridgell.net; me...@samba.org
Subject: RE: repsFromTo blob format (WSPP CAR)
Tridge,
We finished the investigation regarding the different versions of structures
referenced by cbOtherDraOffset in RESP_FROM and RESP_TO (5.107, and 5.108
MS-DRSR).
We made the following changes to the MS-DRSR.
In 5.107 for RESP_FROM and 5.108 for RESP_TO , the changes are:
dwVersion (4 bytes): The version of this structure. It must be 1 or 2.
19
19 Section 5.106: Windows Server 2000 and Windows Server 2003
DCs have value 1 in field dwVersion. Windows Server 2008 and Windows 2008 R2
DCs have value 2 in field dwVersion.
cbOtherDraOffset (4 bytes): The offset from the start of the structure
to a location in the data field, specifying the start of a structure that
contains a NetworkAddress for the source DC. If dwVersion is 1, it is an
MTX_ADDR structure. If dwVersion is 2, it is a DSA_RPC_INST structure.
cbOtherDra (4 bytes): The size of the structure pointed to by
cbOtherDraOffset.
data (variable): The storage for the rest of the structure. The
structure pointed to by cbOtherDraOffset and cbPasDataOffset are packed into
this field and can be referenced using the offsets.
In 5.33, DSA_RPC_INST is defined as:
DSA_RPC_INST is a concrete type for an instance of NTDSA.
typedef struct _DSA_RPC_INST
{
DWORD cb;
DWORD cbpszServerOffset;
DWORD cbpszAnnotationOffset;
DWORD cbpszInstanceOffset;
DWORD cbpguidInstanceOffset;
} DSA_RPC_INST, *PDSA_RPC_INST;
cb: The total number of bytes in the DSA_RPC_INST structure.
cbpszServerOffset: The offset from the start of the DSA_RPC_INST
structure to a location that specifies the start of the server name of this
instance.
cbpszAnnotationOffset: The offset from the start of the DSA_RPC_INST
structure to a location that specifies the start of the annotation of this
instance.
cbpszInstanceOffset: The offset from the start of the DSA_RPC_INST
structure to a location that specifies the start of the NetworkAddress of this
instance.
cbpguidInstanceOffset: The offset from the start of the DSA_RPC_INST
structure to a location that specifies the start of the GUID for the instance.
The information above will be updated into the future release of the
MS-DRSR document. Please let us know if you have more questions.
Thanks!
Hongwei
-Original Message-
From: tri...@samba.org [mailto:tri...@samba.org]
Sent: Sunday, September 20, 2009 12:15 PM
To: Interoperability Documentation Help
Cc: cifs-proto...@samba.org; p...@tridgell.net; me...@samba.org
Subject: repsFromTo blob format (WSPP CAR)
We've been unable to find a description in the WSPP docs of the format
for the repsFromToBlob blob that is used to encode the repsFrom and
repsTo attributes in DRS/LDAP.
For now we have produced our own IDL for the blobs, which you can see
here:
http://samba.org/ftp/unpacked/samba_4_0_test/librpc/idl/drsblobs.idl
in the typedef for the structure repsFromToBlob, but it would be good
if we could confirm this with IDL (or other binary structure encoding)
in the WSPP docs.
The MS-DRSR doc shows some examples for version1 of the structure, but
nothing for version 2 (version 2 is used by W2K8).
Cheers, Tridge
___
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] DRS option bits
Tridge, After a further review, we identified two more bits that could be observed on wire. DRS_INIT_SYNC_NOW 0x0080 DRS_PREEMPTED 0x0100 A description of these two bits and the DRSUAPI_DRS_NEVER_SYNCED bit you mentioned is shown as below. NSY (DRS_NEVER_SYNCED): There is no successfully completed replication from this source server. ISN (DRS_INIT_SYNC_NOW): Perform initial replication now. PE (DRS_PREEMPTED): Replication attempt is preempted by a higher priority replication request. The information above has been added to 5.39 of MS-DRSR and 5.29 of MS-DRDM. The position of DRSUAPI_DRS_SPECIAL_SECRET_PROCESSING bit in bit table has also been corrected. The changes will appear in the future release of the documents. The documentation team also confirmed that it is possible that the section numbers will change when any new content is added to MS-DRSR and MS-DRDM in the future. Section titles would probably work much better than section numbers. If you have any more questions regarding this issue, please let us know. Thanks! Hongwei -Original Message- From: Hongwei Sun Sent: Tuesday, October 13, 2009 4:49 PM To: 'tri...@samba.org'; Interoperability Documentation Help Cc: cifs-proto...@samba.org; p...@tridgell.net Subject: RE: DRS option bits Tridge, I checked the definitions of these bit fields ,comparing with the MS-DRSR document. The following is what I found. 1. 0x0020 is DRSUAPI_DRS_NEVER_SYNCED , which means that sync is never completed successfully. This bit is observed on wire, but not defined in the bit table in 5.39 DRS_OPTIONS. I will file a request to add this bit to the document. 2. DRSUAPI_DRS_SPECIAL_SECRET_PROCESSING should be 0x0040, instead of 0x0080 as indicated in your definition as well as the bit table. Bit SS should be in bit field #22. I will also file a request to get this corrected in the document. 3. There is one field defined in the bit table in the document but it is not shown in your definition. Please check it. DRSUAPI_DRS_SYNC_URGENT= 0x0008 (Bit SU field #19) I will also forward your question regarding the numbering of the sections to the documentation team. I will let you know their response. Thanks! Hongwei -Original Message- From: tri...@samba.org [mailto:tri...@samba.org] Sent: Tuesday, October 13, 2009 6:23 AM To: Interoperability Documentation Help Cc: cifs-proto...@samba.org; p...@tridgell.net Subject: CAR: DRS option bits Hi, I'm still working on our DRSR DsGetNCChanges implementation. One puzzle I've hit is related to MS-DRSR 5.39 DRS Options. I'm receiving replication requests from a w2k8-R2 machine with the replication flags (ulFlags) set to 0x00200074. The bit 0x0020 is one of the 'X' bits in section 5.39, so I guess it is either an undocumented bit or the bitfield is incorrectly labelled in the docs. Given the complexity of decoding WSPP bitfields, here is my decode of it for you to check: DRSUAPI_DRS_ASYNC_OP = 0x0001, DRSUAPI_DRS_GETCHG_CHECK = 0x0002, DRSUAPI_DRS_ADD_REF = 0x0004, DRSUAPI_DRS_SYNC_ALL = 0x0008, DRSUAPI_DRS_DEL_REF = 0x0008, DRSUAPI_DRS_WRIT_REP = 0x0010, DRSUAPI_DRS_INIT_SYNC = 0x0020, DRSUAPI_DRS_PER_SYNC = 0x0040, DRSUAPI_DRS_MAIL_REP = 0x0080, DRSUAPI_DRS_ASYNC_REP = 0x0100, DRSUAPI_DRS_IGNORE_ERROR = 0x0100, DRSUAPI_DRS_TWOWAY_SYNC = 0x0200, DRSUAPI_DRS_CRITICAL_ONLY = 0x0400, DRSUAPI_DRS_GET_ANC = 0x0800, DRSUAPI_DRS_GET_NC_SIZE = 0x1000, DRSUAPI_DRS_LOCAL_ONLY= 0x1000, DRSUAPI_DRS_SYNC_BYNAME = 0x4000, DRSUAPI_DRS_REF_OK= 0x4000, DRSUAPI_DRS_FULL_SYNC_NOW = 0x8000, DRSUAPI_DRS_NO_SOURCE = 0x8000, DRSUAPI_DRS_FULL_SYNC_PACKET = 0x0002, DRSUAPI_DRS_REF_GCSPN = 0x0010, DRSUAPI_DRS_SPECIAL_SECRET_PROCESSING = 0x0080, DRSUAPI_DRS_SYNC_FORCED = 0x0200, DRSUAPI_DRS_DISABLE_AUTO_SYNC = 0x0400, DRSUAPI_DRS_DISABLE_PERIODIC_SYNC = 0x0800, DRSUAPI_DRS_USE_COMPRESSION = 0x1000, DRSUAPI_DRS_NEVER_NOTIFY
Re: [cifs-protocol] DRS option bits
Kamen, Currently MS-DRSR is only available in the WSPP document set. The MS-DRDM (Directory Replication and Data Management (DRDM) Remote Protocol Specification, which will be a part of MCPP document set, contains the similar information as MS-DRSR. This document will be available in the future release on MSDN. Thanks! Hongwei -Original Message- From: Kamen Mazdrashki [mailto:kamen.mazdras...@postpath.com] Sent: Friday, October 23, 2009 3:51 AM To: Hongwei Sun; tri...@samba.org Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: RE: [cifs-protocol] DRS option bits Hi Hongwei, What is this MS-DRDM document for? Is it something to be released in near future or we can downloaded it right now? Thanks, Kamen Mazdrashki kamen.mazdras...@postpath.com http://repo.or.cz/w/Samba/kamenim.git - CISCO SYSTEMS BULGARIA EOOD http://www.cisco.com/global/BG/ -Original Message- From: cifs-protocol-boun...@cifs.org [mailto:cifs-protocol- boun...@cifs.org] On Behalf Of Hongwei Sun Sent: Friday, October 23, 2009 1:09 AM To: tri...@samba.org Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: Re: [cifs-protocol] DRS option bits Tridge, After a further review, we identified two more bits that could be observed on wire. DRS_INIT_SYNC_NOW 0x0080 DRS_PREEMPTED 0x0100 A description of these two bits and the DRSUAPI_DRS_NEVER_SYNCED bit you mentioned is shown as below. NSY (DRS_NEVER_SYNCED): There is no successfully completed replication from this source server. ISN (DRS_INIT_SYNC_NOW): Perform initial replication now. PE (DRS_PREEMPTED): Replication attempt is preempted by a higher priority replication request. The information above has been added to 5.39 of MS-DRSR and 5.29 of MS-DRDM. The position of DRSUAPI_DRS_SPECIAL_SECRET_PROCESSING bit in bit table has also been corrected. The changes will appear in the future release of the documents. The documentation team also confirmed that it is possible that the section numbers will change when any new content is added to MS-DRSR and MS-DRDM in the future. Section titles would probably work much better than section numbers. If you have any more questions regarding this issue, please let us know. Thanks! Hongwei -Original Message- From: Hongwei Sun Sent: Tuesday, October 13, 2009 4:49 PM To: 'tri...@samba.org'; Interoperability Documentation Help Cc: cifs-proto...@samba.org; p...@tridgell.net Subject: RE: DRS option bits Tridge, I checked the definitions of these bit fields ,comparing with the MS-DRSR document. The following is what I found. 1. 0x0020 is DRSUAPI_DRS_NEVER_SYNCED , which means that sync is never completed successfully. This bit is observed on wire, but not defined in the bit table in 5.39 DRS_OPTIONS. I will file a request to add this bit to the document. 2. DRSUAPI_DRS_SPECIAL_SECRET_PROCESSING should be 0x0040, instead of 0x0080 as indicated in your definition as well as the bit table. Bit SS should be in bit field #22. I will also file a request to get this corrected in the document. 3. There is one field defined in the bit table in the document but it is not shown in your definition. Please check it. DRSUAPI_DRS_SYNC_URGENT= 0x0008 (Bit SU field #19) I will also forward your question regarding the numbering of the sections to the documentation team. I will let you know their response. Thanks! Hongwei -Original Message- From: tri...@samba.org [mailto:tri...@samba.org] Sent: Tuesday, October 13, 2009 6:23 AM To: Interoperability Documentation Help Cc: cifs-proto...@samba.org; p...@tridgell.net Subject: CAR: DRS option bits Hi, I'm still working on our DRSR DsGetNCChanges implementation. One puzzle I've hit is related to MS-DRSR 5.39 DRS Options. I'm receiving replication requests from a w2k8-R2 machine with the replication flags (ulFlags) set to 0x00200074. The bit 0x0020 is one of the 'X' bits in section 5.39, so I guess it is either an undocumented bit or the bitfield is incorrectly labelled in the docs. Given the complexity of decoding WSPP bitfields, here is my decode of it for you to check: DRSUAPI_DRS_ASYNC_OP = 0x0001, DRSUAPI_DRS_GETCHG_CHECK = 0x0002, DRSUAPI_DRS_ADD_REF = 0x0004, DRSUAPI_DRS_SYNC_ALL = 0x0008, DRSUAPI_DRS_DEL_REF = 0x0008, DRSUAPI_DRS_WRIT_REP = 0x0010, DRSUAPI_DRS_INIT_SYNC = 0x0020, DRSUAPI_DRS_PER_SYNC = 0x0040, DRSUAPI_DRS_MAIL_REP = 0x0080
Re: [cifs-protocol] DRS option bits
Tridge, The Flag DRS_PREEMPTED is used by the replication client DC to manage its own replicationQueue(5.154 in MS-DRSR), and it is not used between two DCs for replication. The flag indicates that a particular replication operation was interrupted and re-enqueued. The ReplicationQueue stores a sequence of replication operations to be processed by the DC. An implementation can choose its own way to process the queue, including determining when to preempt an operation. Please let us know if you need more information regarding this issue. Thanks! Hongwei -Original Message- From: tri...@samba.org [mailto:tri...@samba.org] Sent: Friday, October 23, 2009 2:05 AM To: Hongwei Sun Cc: cifs-proto...@samba.org; p...@tridgell.net Subject: RE: DRS option bits Hi Hongwei, PE (DRS_PREEMPTED): Replication attempt is preempted by a higher priority replication request. I'm getting errors about pre-emption in the logs sometimes, so I'd like to understand this better. I don't see any mention of 'preemption' in the DRSR doc. Could you explain it please? I suspect it is related to a DC doing two DRS replications in parallel (as it seems to happen when I see a 2nd replication happen while a first cycle is not complete). Can you tell me if parallel replications with the same DsBind handle are actually allowed? If they are, then it seems a bit ambiguous, as I can't see how I would tell whether a particular request is a continuation of an existing replication or a new one (assuming they are on the same NC). At the moment I've added code in our DRS server to refuse a 2nd replication with the same DsBind handle if a previous cycle is not complete. Is that what the Microsoft replication client expects? Cheers, Tridge ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] FW: Group Policy questions
Matthieu, I keep receiving the message from our e-mail server about the undeliverable e-mail to one of the address(cifs-protocol@cifs.org), which is in your original e-mail. In order to make sure you receive the email, I just forward it again. If you already received it, please let me know if it resolved your issue. Thanks! Hongwei -Original Message- From: Hongwei Sun Sent: Monday, October 26, 2009 6:14 PM To: Matthieu Patou; cifs-protocol@cifs.org; p...@tridgell.net Subject: RE: [cifs-protocol] Group Policy questions Matthieu, Matthieu, The attached GPMC log shows the problem of inconsistency between ACLs of the policy object and that of SYSVOL folders. The log shows that [6bc.678] 10/25/2009 00:55:47:359 [VERBOSE] CGPMGPO::IsAclConsistent():Checking Aces for SID S-1-5-21-2212615479-2695158682-2101375467-512 [6bc.678] 10/25/2009 00:55:47:359 [VERBOSE] GetSysvolPermissionsFromDSPermissions: DS access mask is 0xf00ff .. [6bc.678] 10/25/2009 00:55:47:359 [VERBOSE] CGPMGPO::IsAclConsistent(): ACLs not consistent for SID S-1-5-21-2212615479-2695158682-2101375467-512. Mask: Expected 0x1f01ff, Found 0xf00ff The access mask for the ace of Active Directory policy object is 0xf00ff. When the GPMO converts the access mask to a corresponding file system access mask, it expects 0x1f01ff. For SYSVOL, you set the access mask to 0xf00ff. They don't match and that is why inconsistency is declared. In the SYSVOL access mask you set, you missed 0x10(SYNCHRONIZE) and 0x100(FILE_WRITE_ATTRIBUTES). Since AD objects and SYSVOL file/folder objects are different objects, their specific rights in access mask are not one-to-one matched. The following are the definitions of bits for both objects. The specific rights in access mask for Active Directory object are defined in 5.1.3.2 of MS-ADTS as follows. #define RIGHT_DS_CREATE_CHILD 0x0001 #define RIGHT_DS_DELETE_CHILD 0x0002 #define RIGHT_DS_LIST_CONTENTS 0x0004 #define ACTRL_DS_SELF 0x0008 #define RIGHT_DS_READ_PROPERTY 0x0010 #define RIGHT_DS_WRITE_PROPERTY 0x0020 #define RIGHT_DS_DELETE_TREE0x0040 #define RIGHT_DS_LIST_OBJECT0x0080 #define RIGHT_DS_CONTROL_ACCESS 0x0100 The specific rights in access mask for a file or directory object are defined as (http://msdn.microsoft.com/en-us/library/aa364399(VS.85).aspx ) #define FILE_READ_DATA( 0x0001 ) #define FILE_LIST_DIRECTORY ( 0x0001 ) #define FILE_WRITE_DATA ( 0x0002 ) #define FILE_ADD_FILE ( 0x0002 ) #define FILE_APPEND_DATA ( 0x0004 ) #define FILE_ADD_SUBDIRECTORY ( 0x0004 ) #define FILE_CREATE_PIPE_INSTANCE ( 0x0004 ) #define FILE_READ_EA ( 0x0008 ) #define FILE_WRITE_EA ( 0x0010 ) #define FILE_EXECUTE ( 0x0020 ) #define FILE_TRAVERSE ( 0x0020 ) #define FILE_DELETE_CHILD ( 0x0040 ) #define FILE_READ_ATTRIBUTES ( 0x0080 ) #define FILE_WRITE_ATTRIBUTES ( 0x0100 ) The generic access rights that are common to all objects are #define DELETE(0x0001L) #define READ_CONTROL (0x0002L) #define WRITE_DAC (0x0004L) #define WRITE_OWNER (0x0008L) #define SYNCHRONIZE (0x0010L) #define STANDARD_RIGHTS_ALL (0x001FL) The following logic is used by GPMC to convert a access mask for DS object to a access mask for SYSVOL. DSAccessMask as Input; SYSVOLAccessMask as Output; SYSVOLAccessMask = STANDARD_RIGHTS_ALL ; if ((DSAccessMask RIGHT_DS_READ_PROPERTY) AND (DSAccessMask RIGHT_DS_LIST_CONTENTS)) SYSVOLAccessMask |= (SYNCHRONIZE | FILE_LIST_DIRECTORY | FILE_READ_ATTRIBUTES | FILE_READ_EA | FILE_READ_DATA | FILE_EXECUTE); if (DSAccessMask RIGHT_DS_WRITE_PROPERTY) SYSVOLAccessMask |= (SYNCHRONIZE | FILE_WRITE_DATA | FILE_APPEND_DATA | FILE_WRITE_EA | FILE_WRITE_ATTRIBUTES | FILE_ADD_FILE | FILE_ADD_SUBDIRECTORY); if (DSAccessMask RIGHT_DS_CREATE_CHILD) SYSVOLAccessMask |= (FILE_ADD_SUBDIRECTORY | FILE_ADD_FILE); if (DSAccessMask RIGHT_DS_DELETE_CHILD) SYSVOLAccessMask |= FILE_DELETE_CHILD; Please let me know if this solves your problem. I will file a request to update the document accordingly. Thanks! Hongwei -Original Message- From: Matthieu Patou [mailto:mat+informatique.sa...@matws.net] Sent: Sunday, October 25, 2009 5:48 AM To: cifs-protocol
Re: [cifs-protocol] limits on rDN size in AD ?
Tridge, The RDN of Deleted Objects container is a little different from the normal RDN. The following information in MS-ADTS 3.1.1.5.5 describes the composition of RDN for objects in Deleted Object container: The RDN of the object is changed to a delete-mangled RDN-an RDN that is guaranteed to be unique within the Deleted Objects container. If O is the object that is deleted, the delete-mangled RDN is the concatenation of O!name, the character with value 0x0A, the string DEL:, and the dashed string representation ([RFC4122] section 3) of O!objectGUID. It looks like to me that for the Delete Objects container, the size constraint should be dependent on the combination of the each sub component. Since I am out of office, I will ask one of my team member to investigate and confirm the behavior. Thanks ! -Original Message- From: tri...@samba.org [mailto:tri...@samba.org] Sent: Monday, November 09, 2009 6:58 PM To: Hongwei Sun Cc: cifs-proto...@samba.org; h...@highlandsun.com Subject: RE: limits on rDN size in AD ? Hi Hongwei, We're back to the old question of rDN size limits again! I just got a DRS replication reply from w2k8-r2 with a CN that has a length larger than 64. So I suspect that things are a bit more complex than what we'd discussed before. The object was: CN=89532b80-09fe-445e-afef-965c0d7f7d15\0ADEL:462902b4-1824-4f02-8956-9f934f64fa01,CN=Deleted Objects,CN=Configuration,DC=vsofs8,DC=com which gives a length of 80. Are we perhaps supposed to interpret the \0 as a termination character for the purposes of this length constraint? (note that this is a \ followed by a 0, not a nul byte). Or perhaps deleted objects are special in their constraints in some way? Cheers, Tridge ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] SMBv1 LockAndX return status on lock conflict
Steven, I am now working on this issue. I am wondering what program you ran to create the network trace attached in your e-mail. Is it Samba smbtorture ? If we can duplicate the behavior, it may be easier for us to debug it. Thanks! Hongwei From: Steven Danneman [mailto:steven.danne...@isilon.com] Sent: Wednesday, November 25, 2009 5:54 PM To: Interoperability Documentation Help; cifs-proto...@samba.org; p...@tridgell.net Subject: SMBv1 LockAndX return status on lock conflict Hello, When requesting a byte-range lock over SMBv1 on a range of a file which is already locked and thus will contend, the error code returned is inconsistent. The first attempt to acquire a held lock will return STATUS_LOCK_NOT_GRANTED. Subsequent requests will return STATUS_FILE_LOCK_CONFLICT. This seems as though it may be an error in the implementation of the SMBv1 protocol as the explanation of the two errors in MS-ERREF implies that STATUS_LOCK_NOT_GRANTED should always be returned in this circumstance: STATUS_LOCK_NOT_GRANTED A requested file lock cannot be granted due to other existing locks. STATUS_FILE_LOCK_CONFLICT A requested read/write cannot be granted due to a conflicting file lock. And in this same scenario the SMBv2 protocol always returns STATUS_LOCK_NOT_GRANTED. I aware this is a well known issue, as the Samba torture test demonstrating this behavior have existed for a number of years, but I haven't found any Microsoft documentation describing the semantics of this behavior. I've looked in MS-CIFS, MS-SMB, MS-SMB2, and MS-FSA. Furthermore, which error code is returned becomes even more complicated when additional lock requests are interspersed. For example the attached pcap against a W2K8R2 server shows: 1) Two file handles opened to the same file 0x400b, 0x400c 2) Packet 27,28: Handle 0x400b successfully acquiring an exclusive lock on range 100 - 110 3) Packet 29-32: Handles 0x400b and 0x400c requesting the same held range and receiving STATUS_LOCK_NOT_GRANTED 4) Packet 33-44: Again requesting the same held range and receiving STATUS_FILE_LOCK_CONFLICT 5) Packet 45-54: Requesting a lock on an overlapping range, 105-115, and receiving the same pattern of errors 6) Packet 55-64: Requesting a lock on the previous range, 100-110, and now having the response be reset back to STATUS_LOCK_NOT_GRANTED I'd like to have some documentation of the algorithm for determining which error to return based on the state of existing locks, or history of previously requested locks. Thanks, Steven Danneman | Software Development Engineer Isilon SystemsP +1-206-315-7500 F +1-206-315-7501 www.isilon.comhttp://www.isilon.com [cid:image001.gif@01C81005.1792D9C0] How breakthroughs begin. (tm) inline: image001.gif___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] SMBv1 LockAndX return status on lock conflict
Hi, Steven, For the error returned when a byte range lock conflicts with an existing lock in SMB, the logic is as follows:If a lock request is above a configured offset, or if a lock request matches a previously failed lock offset, it will change it from fail immediately with timeout of 0 to timeout of 250 ms on operation issue. The result is that the lock will be pending for 250ms waiting for lock availability, and if it does not retrieve it, it returns a different error (STATUS_FILE_LOCK_CONFLICT). Pseudo code of above logic should be something as below: If (FailImmediately) // Timeout = 0 If Offset == Open.LastFailedLockOffset OR Offset = LockViolationDelayOffset Set Timeout = LockViolationDelay // within 250 milliseconds End If End If If Timeout = 0 and Lock Not Acquired Set LockViolationDelayOffset = (Offset of lock attempt) return STATUS_LOCK_NOT_GRANTED Else If Timeout 0 and Lock Not Acquired after Timeout return STATUS_FILE_LOCK_CONFLICT Else return STATUS_SUCCESS End If. With the logic above, you can easily explain what shows in your network trace.We will add the logic to the SMB protocol document. Please let us know if you have further questions regarding this behavior. Thanks! Hongwei Sun - Sr. Support Escalation Engineer DSC Protocol Team, Microsoft hongw...@microsoft.commailto:hongw...@microsoft.com Tel: 469-7757027 x 57027 - From: Steven Danneman [mailto:steven.danne...@isilon.com] Sent: Wednesday, November 25, 2009 5:54 PM To: Interoperability Documentation Help; cifs-proto...@samba.org; p...@tridgell.net Subject: SMBv1 LockAndX return status on lock conflict Hello, When requesting a byte-range lock over SMBv1 on a range of a file which is already locked and thus will contend, the error code returned is inconsistent. The first attempt to acquire a held lock will return STATUS_LOCK_NOT_GRANTED. Subsequent requests will return STATUS_FILE_LOCK_CONFLICT. This seems as though it may be an error in the implementation of the SMBv1 protocol as the explanation of the two errors in MS-ERREF implies that STATUS_LOCK_NOT_GRANTED should always be returned in this circumstance: STATUS_LOCK_NOT_GRANTED A requested file lock cannot be granted due to other existing locks. STATUS_FILE_LOCK_CONFLICT A requested read/write cannot be granted due to a conflicting file lock. And in this same scenario the SMBv2 protocol always returns STATUS_LOCK_NOT_GRANTED. I aware this is a well known issue, as the Samba torture test demonstrating this behavior have existed for a number of years, but I haven't found any Microsoft documentation describing the semantics of this behavior. I've looked in MS-CIFS, MS-SMB, MS-SMB2, and MS-FSA. Furthermore, which error code is returned becomes even more complicated when additional lock requests are interspersed. For example the attached pcap against a W2K8R2 server shows: 1) Two file handles opened to the same file 0x400b, 0x400c 2) Packet 27,28: Handle 0x400b successfully acquiring an exclusive lock on range 100 - 110 3) Packet 29-32: Handles 0x400b and 0x400c requesting the same held range and receiving STATUS_LOCK_NOT_GRANTED 4) Packet 33-44: Again requesting the same held range and receiving STATUS_FILE_LOCK_CONFLICT 5) Packet 45-54: Requesting a lock on an overlapping range, 105-115, and receiving the same pattern of errors 6) Packet 55-64: Requesting a lock on the previous range, 100-110, and now having the response be reset back to STATUS_LOCK_NOT_GRANTED I'd like to have some documentation of the algorithm for determining which error to return based on the state of existing locks, or history of previously requested locks. Thanks, Steven Danneman | Software Development Engineer Isilon SystemsP +1-206-315-7500 F +1-206-315-7501 www.isilon.comhttp://www.isilon.com [cid:image001.gif@01C81005.1792D9C0] How breakthroughs begin. (tm) inline: image001.gif___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] SMBv1 LockAndX return status on lock conflict
Steven, LockViolationDelayOffset is the file offset beyond which locks are always issued as delayed locks. Default value is 0xEF00. Please let us know if you have any more questions. Thanks! Hongwei From: Steven Danneman [mailto:steven.danne...@isilon.com] Sent: Monday, December 07, 2009 9:03 PM To: Hongwei Sun; cifs-proto...@samba.org; p...@tridgell.net Subject: RE: SMBv1 LockAndX return status on lock conflict Hey Hongwei, That's very interesting and indeed explains the behavior I've seen. I can understand the motivation for delaying a small timeout for locks that the server knows are already held. However, the Offset = LockViolationDelayOffset is strange to me. I don't understand the usefulness of that condition. Perhaps this is an Office specific feature, since Office applications take small byte range locks past the end of file range as a primitive IPC mechanism. Can you tell me what the value of LockViolationDelayOffset is? The smbtorture testing seems to indicate it is Offset 0xEF00. Thanks for your help. I certainly wouldn't have figured these semantics out on my own. -Steven From: Hongwei Sun [mailto:hongw...@microsoft.com] Sent: Monday, December 07, 2009 4:03 PM To: Steven Danneman; cifs-proto...@samba.org; p...@tridgell.net Subject: RE: SMBv1 LockAndX return status on lock conflict Hi, Steven, For the error returned when a byte range lock conflicts with an existing lock in SMB, the logic is as follows:If a lock request is above a configured offset, or if a lock request matches a previously failed lock offset, it will change it from fail immediately with timeout of 0 to timeout of 250 ms on operation issue. The result is that the lock will be pending for 250ms waiting for lock availability, and if it does not retrieve it, it returns a different error (STATUS_FILE_LOCK_CONFLICT). Pseudo code of above logic should be something as below: If (FailImmediately) // Timeout = 0 If Offset == Open.LastFailedLockOffset OR Offset = LockViolationDelayOffset Set Timeout = LockViolationDelay // within 250 milliseconds End If End If If Timeout = 0 and Lock Not Acquired Set LockViolationDelayOffset = (Offset of lock attempt) return STATUS_LOCK_NOT_GRANTED Else If Timeout 0 and Lock Not Acquired after Timeout return STATUS_FILE_LOCK_CONFLICT Else return STATUS_SUCCESS End If. With the logic above, you can easily explain what shows in your network trace.We will add the logic to the SMB protocol document. Please let us know if you have further questions regarding this behavior. Thanks! Hongwei Sun - Sr. Support Escalation Engineer DSC Protocol Team, Microsoft hongw...@microsoft.commailto:hongw...@microsoft.com Tel: 469-7757027 x 57027 - From: Steven Danneman [mailto:steven.danne...@isilon.com] Sent: Wednesday, November 25, 2009 5:54 PM To: Interoperability Documentation Help; cifs-proto...@samba.org; p...@tridgell.net Subject: SMBv1 LockAndX return status on lock conflict Hello, When requesting a byte-range lock over SMBv1 on a range of a file which is already locked and thus will contend, the error code returned is inconsistent. The first attempt to acquire a held lock will return STATUS_LOCK_NOT_GRANTED. Subsequent requests will return STATUS_FILE_LOCK_CONFLICT. This seems as though it may be an error in the implementation of the SMBv1 protocol as the explanation of the two errors in MS-ERREF implies that STATUS_LOCK_NOT_GRANTED should always be returned in this circumstance: STATUS_LOCK_NOT_GRANTED A requested file lock cannot be granted due to other existing locks. STATUS_FILE_LOCK_CONFLICT A requested read/write cannot be granted due to a conflicting file lock. And in this same scenario the SMBv2 protocol always returns STATUS_LOCK_NOT_GRANTED. I aware this is a well known issue, as the Samba torture test demonstrating this behavior have existed for a number of years, but I haven't found any Microsoft documentation describing the semantics of this behavior. I've looked in MS-CIFS, MS-SMB, MS-SMB2, and MS-FSA. Furthermore, which error code is returned becomes even more complicated when additional lock requests are interspersed. For example the attached pcap against a W2K8R2 server shows: 1) Two file handles opened to the same file 0x400b, 0x400c 2) Packet 27,28: Handle 0x400b successfully acquiring an exclusive lock on range 100 - 110 3) Packet 29-32: Handles 0x400b and 0x400c requesting the same held range and receiving STATUS_LOCK_NOT_GRANTED 4) Packet 33-44: Again requesting the same held range and receiving STATUS_FILE_LOCK_CONFLICT 5) Packet 45-54: Requesting a lock
Re: [cifs-protocol] What elements of the DIT are required for AD to operate?
Andrew, I have been actively working with the product team on your request. This one requires more effort than schema and display specifiers. Considering the holiday schedule of the product team and support team, including myself, the progresses will be delayed. I will be on vacation from tomorrow returning January 4.Edgar will be my backup to monitor and work on this case. If you have any additional information, please let us know. Happy Holidays!! Hongwei -Original Message- From: Andrew Bartlett [mailto:abart...@samba.org] Sent: Monday, December 07, 2009 11:16 PM To: Interoperability Documentation Help Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: What elements of the DIT are required for AD to operate? G'day, In the last few months, we have had great success with joining a Window 2008 R2 server into a Samba4 hosted domain. It was a great achievement, and the speed of development we achieved over this difficult area is a testament to the support we received at the plugfest. However, that success was only possible when we have first joined Samba4 to an already operational Active Directory domain, and obtained the full database over DRS replication. Samba aims for and requires a high standard of interoperability - a standard of 'either Samba or Windows must be able provision/initialise the domain, without clients or other domain controllers seeing the difference'. However, during the development last week we also found out (by painful experience and in discussion with your developers) that Windows performs very few checks on the incoming replicated data, and is not tolerant of deviations from the expected form. So, to achieve this interoperability, we need to know precisely what things a windows domain controller needs across the directory replication channel, for it to become and operate correctly as a domain controller. Put another way: what are the required DIT elements for a server to provision to be the initiator of an Active Directory forest? We do already have many of these elements implemented - things like the Display Specifiers and Schema we were very glad to obtain earlier - but it seem there is much more required. Much of this is in the documentation set - particularly MS-ADTS, but scattered in a way that makes for a great reference, but a poor source for implementation (because it is so easy to miss one). My hope is that like the schema and display specifiers, that this information (effectively the minimum initial DIT) can also be made available to us in a similar, machine-readable fashion, for each supported functional level. Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] FW: Group Policy questions
Matthieu, Your summary is a good recap of what we have done on this topic. I have one clarification for the point below. * All ACE for allowed object are wipped out when translating AD ACL to File ACL When translating a ACL for DS object to a ACL for SYSVOL file object, the ACEs with types of ACCESS_ALLOWED_OBJECT_ACE_TYPE, ACCESS_DENIED_OBJECT_ACE_TYPE and SYSTEM_AUDIT_OBJECT_ACE_TYPE are not really deleted from the ACL. Instead, for such a ACE, access mask in AceHeader is assigned to zero. Sebastian will follow up with you on your question regarding documenting the logic for ACE OI and CI flags. Thanks! Hongwei -Original Message- From: Matthieu Patou [mailto:mat+informatique.sa...@matws.net] Sent: Friday, December 18, 2009 4:01 PM To: Sebastian Canevari Cc: Hongwei Sun; Interoperability Documentation Help; cifs-proto...@samba.org Subject: Re: FW: [cifs-protocol] Group Policy questions Hello Sebastian and Hongwei, Sorry for being silent on this. So if I try to sum up we agreed that: * in order to allow modification of ACL on files sdeffectiverights must have the flag DACL_SECURITY_INFORMATION set, and the ACL must have the SE_DACL_PROTECTED set in the control flags. * in order to avoid a warning message ACL of Policy object must be synchronized with ACL in the files following this logic for the translation: The specific rights in access mask for Active Directory object are defined in 5.1.3.2 of MS-ADTS as follows. #define RIGHT_DS_CREATE_CHILD 0x0001 #define RIGHT_DS_DELETE_CHILD 0x0002 #define RIGHT_DS_LIST_CONTENTS 0x0004 #define ACTRL_DS_SELF 0x0008 #define RIGHT_DS_READ_PROPERTY 0x0010 #define RIGHT_DS_WRITE_PROPERTY 0x0020 #define RIGHT_DS_DELETE_TREE0x0040 #define RIGHT_DS_LIST_OBJECT0x0080 #define RIGHT_DS_CONTROL_ACCESS 0x0100 The specific rights in access mask for a file or directory object are defined as (http://msdn.microsoft.com/en-us/library/aa364399(VS.85).aspx ) #define FILE_READ_DATA( 0x0001 ) #define FILE_LIST_DIRECTORY ( 0x0001 ) #define FILE_WRITE_DATA ( 0x0002 ) #define FILE_ADD_FILE ( 0x0002 ) #define FILE_APPEND_DATA ( 0x0004 ) #define FILE_ADD_SUBDIRECTORY ( 0x0004 ) #define FILE_CREATE_PIPE_INSTANCE ( 0x0004 ) #define FILE_READ_EA ( 0x0008 ) #define FILE_WRITE_EA ( 0x0010 ) #define FILE_EXECUTE ( 0x0020 ) #define FILE_TRAVERSE ( 0x0020 ) #define FILE_DELETE_CHILD ( 0x0040 ) #define FILE_READ_ATTRIBUTES ( 0x0080 ) #define FILE_WRITE_ATTRIBUTES ( 0x0100 ) The generic access rights that are common to all objects are #define DELETE(0x0001L) #define READ_CONTROL (0x0002L) #define WRITE_DAC (0x0004L) #define WRITE_OWNER (0x0008L) #define SYNCHRONIZE (0x0010L) #define STANDARD_RIGHTS_ALL (0x001FL) The following logic is used by GPMC to convert a access mask for DS object to a access mask for SYSVOL. DSAccessMask as Input; SYSVOLAccessMask as Output; SYSVOLAccessMask = DSAccessMask; SYSVOLAccessMask= STANDARD_RIGHTS_ALL ; if ((DSAccessMask RIGHT_DS_READ_PROPERTY) AND (DSAccessMask RIGHT_DS_LIST_CONTENTS)) SYSVOLAccessMask |= (SYNCHRONIZE | FILE_LIST_DIRECTORY | FILE_READ_ATTRIBUTES | FILE_READ_EA | FILE_READ_DATA | FILE_EXECUTE); if (DSAccessMask RIGHT_DS_WRITE_PROPERTY) SYSVOLAccessMask |= (SYNCHRONIZE | FILE_WRITE_DATA | FILE_APPEND_DATA | FILE_WRITE_EA | FILE_WRITE_ATTRIBUTES | FILE_ADD_FILE | FILE_ADD_SUBDIRECTORY); if (DSAccessMask RIGHT_DS_CREATE_CHILD) SYSVOLAccessMask |= (FILE_ADD_SUBDIRECTORY | FILE_ADD_FILE); if (DSAccessMask RIGHT_DS_DELETE_CHILD) SYSVOLAccessMask |= FILE_DELETE_CHILD; * All ACE for allowed object are wipped out when translating AD ACL to File ACL * For the following ACE OI and CI flags are always set in the resulting file ACE: ACCESS_ALLOWED_ACE_TYPE ACCESS_DENIED_ACE_TYPE SYSTEM_AUDIT_ACE_TYPE Am I right ? For the part that are hardcoded like this will it change any time soon ? Also do you plan to document
Re: [cifs-protocol] FW: FW: Inconsistencies in ad-schema docs and text files SRX090109601490
Andrew, Most of the issues mentioned in your mail have been fixed in the latest released MS-ADSC or MS-ADA3. The following is a summary. 1. cn: Computer - Schema pulled from Windows 2008R2 shows two additional attributes for systemMayContain msTSSecondaryDesktopBL, msTSPrimaryDesktopBL. 2.21 of MS-ADSC has been updated to include msTSSecondaryDesktopBL and msTSPrimaryDesktopBL in systemMayContain. 2. cn: Domain-DNS - defaultSecurityDescriptor in does not match the schema pulled from Windows 2008R2 2.42 of MS-ADSC (Class domainDNS) has been updated to include the correct defaultSecurityDescriptor as follows. defaultSecurityDescriptor: D: (OA;;CR;1131f6aa-9c07-11d1-f79f-00c04fc2dcd2;;RO)(A;;RP;;;WD) (OA;;CR;1131f6aa-9c07-11d1-f79f-00c04fc2dcd2;;ED) (OA;;CR;1131f6ab-9c07-11d1-f79f-00c04fc2dcd2;;ED) (OA;;CR;1131f6ac-9c07-11d1-f79f-00c04fc2dcd2;;ED) (OA;;CR;1131f6aa-9c07-11d1-f79f-00c04fc2dcd2;;BA) (OA;;CR;1131f6ab-9c07-11d1-f79f-00c04fc2dcd2;;BA) (OA;;CR;1131f6ac-9c07-11d1-f79f-00c04fc2dcd2;;BA)(A;;RPLCLORC;;;AU) (A;;RPWPCRLCLOCCRCWDWOSW;;;DA)(A;CI;RPWPCRLCLOCCRCWDWOSDSW;;;BA) (A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;SY) (A;CI;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;EA)(A;CI;LC;;;RU) (OA;CIIO;RP;037088f8-0ae1-11d2-b422-00a0c968f939; bf967aba-0de6-11d0-a285-00aa003049e2;RU) (OA;CIIO;RP;59ba2f42-79a2-11d0-9020-00c04fc2d3cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU) (OA;CIIO;RP;bc0ac240-79a9-11d0-9020-00c04fc2d4cf; bf967aba-0de6-11d0-a285-00aa003049e2;RU) (OA;CIIO;RP;4c164200-20c0-11d0-a768-00aa006e0529; bf967aba-0de6-11d0-a285-00aa003049e2;RU) (OA;CIIO;RP;5f202010-79a5-11d0-9020-00c04fc2d4cf; bf967aba-0de6-11d0-a285-00aa003049e2;RU) (OA;;RP;c7407360-20bf-11d0-a768-00aa006e0529;;RU) (OA;CIIO;RPLCLORC;;bf967a9c-0de6-11d0-a285-00aa003049e2;RU) (A;;RPRC;;;RU) (OA;CIIO;RPLCLORC;;bf967aba-0de6-11d0-a285-00aa003049e2;RU) (A;;LCRPLORC;;;ED)(OA;CIIO;RP;037088f8-0ae1-11d2-b422-00a0c968f939; 4828CC14-1437-45bc-9B07-AD6F015E5F28;RU) (OA;CIIO;RP;59ba2f42-79a2-11d0-9020-00c04fc2d3cf; 4828CC14-1437-45bc-9B07-AD6F015E5F28;RU) (OA;CIIO;RP;bc0ac240-79a9-11d0-9020-00c04fc2d4cf; 4828CC14-1437-45bc-9B07-AD6F015E5F28;RU) (OA;CIIO;RP;4c164200-20c0-11d0-a768-00aa006e0529; 4828CC14-1437-45bc-9B07-AD6F015E5F28;RU) (OA;CIIO;RP;5f202010-79a5-11d0-9020-00c04fc2d4cf; 4828CC14-1437-45bc-9B07-AD6F015E5F28;RU) (OA;CIIO;RPLCLORC;;4828CC14-1437-45bc-9B07-AD6F015E5F28;RU) (OA;;RP;b8119fd0-04f6-4762-ab7a-4986c76b3f9a;;RU) (OA;;RP;b8119fd0-04f6-4762-ab7a-4986c76b3f9a;;AU) (OA;CIIO;RP;b7c69e6d-2cc7-11d2-854e-00a0c983f608; bf967aba-0de6-11d0-a285-00aa003049e2;ED) (OA;CIIO;RP;b7c69e6d-2cc7-11d2-854e-00a0c983f608; bf967a9c-0de6-11d0-a285-00aa003049e2;ED) (OA;CIIO;RP;b7c69e6d-2cc7-11d2-854e-00a0c983f608; bf967a86-0de6-11d0-a285-00aa003049e2;ED) (OA;;CR;1131f6ad-9c07-11d1-f79f-00c04fc2dcd2;;DD) (OA;;CR;89e95b76-444d-4c62-991a-0facbeda640c;;ED) (OA;;CR;1131f6ad-9c07-11d1-f79f-00c04fc2dcd2;;BA) (OA;;CR;89e95b76-444d-4c62-991a-0facbeda640c;;BA) (OA;;CR;e2a36dc9-ae17-47c3-b58b-be34c55ba633;;S-1-5-32-557) (OA;;CR;280f369c-67c7-438e-ae98-1d46f3c6f541;;AU) (OA;;CR;ccc2dc7d-a6ad-4a7a-8846-c04e3cc53501;;AU) (OA;;CR;05c74c5e-4deb-43b4-bd9f-86664c2a7fd5;;AU) (OA;;CR;1131f6ae-9c07-11d1-f79f-00c04fc2dcd2;;ED) (OA;;CR;1131f6ae-9c07-11d1-f79f-00c04fc2dcd2;;BA) (OA;CIIO;CRRPWP;91e647de-d96f-4b70-9557-d63ff4f3ccd8;;PS) S:(AU;SA;WDWOWP;;;WD)(AU;SA;CR;;;BA)(AU;SA;CR;;;DU) (OU;CISA;WP;f30e3bbe-9ff0-11d1-b603-f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD) (OU;CISA;WP;f30e3bbf-9ff0-11d1-b603-f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD) 3. cn: inetOrgPerson - defaultSecurityDescriptor does not match the schema pulled from Windows 2008R2 This was not reproducible and Richard indicated in the case that he probably made a mistake doing analysis , so there is no action needed for this item. 4. cn: Object-Class - searchFlags do not match the schema pulled from Windows 2008R2 2.39 of MS-ADA3 has been updated to include the correct SearchFlags. searchFlags: fATTINDEX | fPRESERVEONDELETE 5. cn: Sam-Domain - defaultSecurityDescriptor does not match the schema pulled from Windows 2008R2 2.208 of MS-ADSC (Class samDomain) has been updated with the correct defaultSecurityDescriptor as follows. defaultSecurityDescriptor: D: (OA;;CR;1131f6aa-9c07-11d1-f79f-00c04fc2dcd2;;RO)(A;;RP;;;WD) (OA;;CR;1131f6aa-9c07-11d1-f79f-00c04fc2dcd2;;ED) (OA;;CR;1131f6ab-9c07-11d1-f79f-00c04fc2dcd2;;ED)
[cifs-protocol] [REG:110011157366122] Initial Response
Hello Matthieu, Thanks for your question. We will investigate it and let you know if we need any additional clarification. Best Regards, Hongwei Sun Email: hongw...@microsoft.com Phone: +1 (469) 7757027 Time zone: (UTC-06:00) Central Time (US and Canada) -Original Message- From: Matthieu Patou [mailto:mat+informatique.sa...@matws.net] Sent: Monday, January 11, 2010 6:54 AM To: Interoperability Documentation Help; cifs-proto...@samba.org; p...@tridgell.net Subject: DPAPI interaction with Active Directory Hello, In this page http://msdn.microsoft.com/en-us/library/ms995355.aspx it is stated: When a computer is a member of a domain, DPAPI has a backup mechanism to allow unprotection of the data. When a MasterKey is generated, DPAPI talks to a Domain Controller. Domain Controllers have a domain-wide public/private key pair, associated solely with DPAPI. The local DPAPI client gets the Domain Controller public key from a Domain Controller via a mutually authenticated and privacy protected RPC call. The client encrypts the MasterKey with the Domain Controller public key. It then stores this backup MasterKey along with the MasterKey protected by the user's password. While unprotecting data, if DPAPI cannot use the MasterKey protected by the user's password, it sends the backup MasterKey to a Domain Controller via a mutually authenticated and privacy protected RPC call. The Domain Controller then decrypts the MasterKey with its private key and sends it back to the client via the same protected RPC call. This protected RPC call is used to ensure that no one listening on the network can get the MasterKey. My question is: is there any kind of more technical documentation about this explaining the dialogs between a workstation and a DC when masterkey is generated and when the backup is sent to the server ? Regards. Matthieu Patou. Microsoft is committed to protecting your privacy. Please read the Microsoft Privacy Statementhttp://privacy.microsoft.com/en-us/default.mspx for more information. The above is an email for a support case from Microsoft Corp. REPLY ALL TO THIS MESSAGE or INCLUDE casem...@microsoft.commailto:casem...@microsoft.com IN YOUR REPLY if you want your response added to the case automatically. For technical assistance, please include the Support Engineer on the TO: line. Thank you. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] FW: FW: Inconsistencies in ad-schema docs and text files SRX090109601490
Tridge Andrew, I am owning this request now. I will investigate it and let you know. Bt the way, I already responded to the initial questions from Andrew in a separate mail. Thanks! Hongwei -Original Message- From: cifs-protocol-boun...@cifs.org [mailto:cifs-protocol-boun...@cifs.org] On Behalf Of tri...@samba.org Sent: Friday, January 08, 2010 2:05 PM To: John Dunning Cc: CIFS Protocol; Andrew Bartlett Subject: Re: [cifs-protocol] FW: FW: Inconsistencies in ad-schema docs and text files SRX090109601490 Hi John, You can see the patch against the W2K8-R2 schema here: http://build.samba.org/?function=diff;tree=samba_4_0_test;date=1262935494;revision=ad11deb9bd825d699e2b6799b40d98c28c95910e These were the changes that we made to allow the schema from WSPP to operate correctly with a W2K8-R2 windows client joining a Samba domain using DCPROMO. As Andrew mentioned, the curious thing is that there were some obvious typos in the schema (eg. isRecycled - isRecyled). Perhaps you could test the schema file for a future release by comparing it to schema on a windows box? Thanks! Cheers, Tridge ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] FW: FW: Inconsistencies in ad-schema docs and text files SRX090109601490
Andrew, At this moment, I am now going through the diff reports pointed by Tridge. For adminDescription and adminDisplayName, it looks like that they are already included in the schema file (MS-AD_Schema_2K8_R2_Attributes.txt). Have I missed something ? cn: Admin-Description ldapDisplayName: adminDescription attributeId: 1.2.840.113556.1.2.226 attributeSyntax: 2.5.5.12 omSyntax: 64 isSingleValued: TRUE schemaIdGuid: bf967919-0de6-11d0-a285-00aa003049e2 systemOnly: FALSE searchFlags: 0 rangeLower: 0 rangeUpper: 1024 attributeSecurityGuid: 59ba2f42-79a2-11d0-9020-00c04fc2d3cf mapiID: 32842 systemFlags: FLAG_SCHEMA_BASE_OBJECT cn: Admin-Display-Name ldapDisplayName: adminDisplayName attributeId: 1.2.840.113556.1.2.194 attributeSyntax: 2.5.5.12 omSyntax: 64 isSingleValued: TRUE schemaIdGuid: bf96791a-0de6-11d0-a285-00aa003049e2 systemOnly: FALSE searchFlags: 0 rangeLower: 1 rangeUpper: 256 mapiID: 32843 systemFlags: FLAG_SCHEMA_BASE_OBJECT schemaFlagsEx: FLAG_ATTR_IS_CRITICAL Thanks! Hongwei -Original Message- From: Andrew Bartlett [mailto:abart...@samba.org] Sent: Monday, January 11, 2010 2:42 PM To: Hongwei Sun Cc: p...@tridgell.net; cifs-proto...@samba.org; Andrew Tridgell Subject: RE: [cifs-protocol] FW: FW: Inconsistencies in ad-schema docs and text files SRX090109601490 On Mon, 2010-01-11 at 15:23 +, Hongwei Sun wrote: Andrew, Most of the issues mentioned in your mail have been fixed in the latest released MS-ADSC or MS-ADA3. The following is a summary. The schema of Windows 2008 R2 we sent you in 04/24/2009 doesn't incorporate the above changes. I will work on it. We do have tools/scripts to create and validate the schema. Is there a location where you continually post the text file version of the schema, or do we have to ask each time? Also, have you addressed the issues tridge mentioned in his reply, and the adminDescription/adminDisplayName issue? Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] FW: FW: Inconsistencies in ad-schema docs and text files SRX090109601490
Trige, According to schema class document (MS-ADSC), The adminDescription and AdminDisplayName are listed as systemMayContain instead of SystemMustContain in cn:Top. The sub-level class attributeSchema and classSchema also don't require these two attributes as SystemMustContain. Based on the schema, it looks like that they are not mandatory attributes for either class or attribute object. Actually since they are not listed for any attribute or class in the MS-ADAx/MS-ADSC documents so they are not included in the schema files we generated from the documents. I am so glad to see that you are making a lot of progresses. It is a pleasure to work with you. I downloaded and played the video, but I can only hear your voice, not video. Maybe it has something to do with Windows Media Player. Thanks! Hongwei -Original Message- From: tri...@samba.org [mailto:tri...@samba.org] Sent: Monday, January 11, 2010 3:13 PM To: Hongwei Sun Cc: Andrew Bartlett; cifs-proto...@samba.org Subject: RE: [cifs-protocol] FW: FW: Inconsistencies in ad-schema docs and text files SRX090109601490 Hi Hongwei, For adminDescription and adminDisplayName, it looks like that they are already included in the schema file (MS-AD_Schema_2K8_R2_Attributes.txt). Have I missed something ? Each attribute and class in the schema should have an adminDescription and adminDisplayName attribute. I suspect they aren't critical for most things, it would probably only matter if some user app looked for the values specifically, but if you can include them that would be great. I would hope apps would normally look at the ldapDisplayName instead. For now we're setting them equal to the cn in the little python script that munges the raw schema into something we can load. btw, with these schema fixes, the dcpromo test we worked on in Redmond is now quite reliable. I've put out a little movie to demonstrate it: http://blog.tridgell.net/?p=12 Thanks very much for all of the help you gave us to make this possible! Cheers, Tridge ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] [REG:210011157366122001] [MS-ADTS] PFIF DPAPI interaction with Active Directory
Matthieu, This process is described in one of the open protocol document ([MS-BKRP]: BackupKey Remote Protocol Specification http://msdn.microsoft.com/en-us/library/cc224123(PROT.13).aspx ). The following KB article might be useful for understanding DPAPI too (http://support.microsoft.com/kb/309408). Please let me know if you need any more information. Thanks! Hongwei -Original Message- From: Matthieu Patou [mailto:mat+informatique.sa...@matws.net] Sent: Monday, January 11, 2010 6:54 AM To: Interoperability Documentation Help; cifs-proto...@samba.org; p...@tridgell.net Subject: DPAPI interaction with Active Directory Hello, In this page http://msdn.microsoft.com/en-us/library/ms995355.aspx it is stated: When a computer is a member of a domain, DPAPI has a backup mechanism to allow unprotection of the data. When a MasterKey is generated, DPAPI talks to a Domain Controller. Domain Controllers have a domain-wide public/private key pair, associated solely with DPAPI. The local DPAPI client gets the Domain Controller public key from a Domain Controller via a mutually authenticated and privacy protected RPC call. The client encrypts the MasterKey with the Domain Controller public key. It then stores this backup MasterKey along with the MasterKey protected by the user's password. While unprotecting data, if DPAPI cannot use the MasterKey protected by the user's password, it sends the backup MasterKey to a Domain Controller via a mutually authenticated and privacy protected RPC call. The Domain Controller then decrypts the MasterKey with its private key and sends it back to the client via the same protected RPC call. This protected RPC call is used to ensure that no one listening on the network can get the MasterKey. My question is: is there any kind of more technical documentation about this explaining the dialogs between a workstation and a DC when masterkey is generated and when the backup is sent to the server ? Regards. Matthieu Patou. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] [REG:110011477385004] Intial Response: RE: userParameters attribute
Hi, Tridge, Thanks for your question. One of our team member will work on your request and get back to you when the investigation is done. Thanks! Hongwei Hongwei Sun - Sr. Support Escalation Engineer DSC Protocol Team, Microsoft hongw...@microsoft.com Tel: 469-7757027 x 57027 - -Original Message- From: tri...@samba.org [mailto:tri...@samba.org] Sent: Thursday, January 14, 2010 2:55 PM To: Interoperability Documentation Help Cc: cifs-proto...@samba.org; p...@tridgell.net; Michael Ströder Subject: CAR: userParameters attribute Dear Dochelp, The userParameters attribute on a user in AD seems to be a bit of a puzzle. Could you add some docs on it at some stage? Not a really high priority, but we would eventually like to be able to offer admin tools that manage things like session activity timeouts, and it seems that we need to know how to parse and create userParameters to do that. An example userParameters attribute from w2k8r2 (in base64 form) is this: userParameters:: Q3R4Q2ZnUHJlc2VudCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgI CAgUAsaCAFDdHhDZmdQcmVzZW5045S15pSx5oiw44GiIAIBQ3R4V0ZQcm9maWxlUGF0aOOAsBgCAU N0eFdGSG9tZURpcuOAsCICAUN0eFdGSG9tZURpckRyaXZl44CwEggBQ3R4U2hhZG9344Sw44Cw44C w44CwLggBQ3R4TWF4RGlzY29ubmVjdGlvblRpbWXjgaXjjLnjkLDjgLAoCAFDdHhNYXhDb25uZWN0 aW9uVGltZeOAtOOct+aIseOAsBwIAUN0eE1heElkbGVUaW1l44Gj45yy46Sw44CwIAIBQ3R4V29ya 0RpcmVjdG9yeeOAsBgIAUN0eENmZ0ZsYWdzMeOAsOOBpuOYsuOAuCICAUN0eEluaXRpYWxQcm9ncm Ft44Cw the above came from using the windows user admin tool to change the session activity timeout for a test user. Michael Ströder has also pointed out this page: http://daduke.org/linux/userparameters.html which documents a previous effort by the Linux thin client community to work out the format of userParameters. I'm guessing the strange encoding is used to try to keep the attribute as valid UTF8. If you can confirm that the attribute is always valid UTF8 that would be great (as otherwise we might corrupt it during replication with windows). As I mentioned, this is not a high priority, but it would be nice to know the format at some stage. Cheers, Tridge ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] repadmin.exe crashing - TTT trace
Tridge, The problem is the missing of isGlobalCatalogReady attribute in RootDSE in Samba DC. The repadmin will do a string compare of the return value of this attribute against FALSE to check if GC is ready. Since there is no such a attribute defined, the Ldap_get_valueW will return a NULL buffer and thus cause the crash on string comparing function. Please add this attribute to RootDSE. You can check the following KB (http://technet.microsoft.com/en-us/library/cc753809.aspx) for this attribute. Also it is documented in 3.1.1.3.2.10 of MS-ADTS. Hope it helps. Hongwei -Original Message- From: tri...@samba.org [mailto:tri...@samba.org] Sent: Friday, January 15, 2010 8:55 PM To: Hongwei Sun Cc: Andrew Bartlett; erick.nogueira.nascime...@gmail.com; cifs-proto...@samba.org Subject: repadmin.exe crashing - TTT trace Hi Hongwei, Erick Nogueira has recently been adding support for DRSGetReplInfo to Samba, with the aim of making repadmin.exe work against a Samba DC. Unfortunately repadmin.exe on w2k8r2b is crashing when talking to Samba. I've extended Ericks work a bit to try to track down the problem, but I still can't work out why it crashes. I wonder if you might be able to look at a TTT trace of repadmin.exe? I've uploaded it here: http://samba.org/tridge/ttt/repadminttt.zip The trace was taken on repadmin /showrepl blu where blu is the name of a Samba4 DC. The repadmin command was run on a w2k8-r2 box (build 7600) which was a DC in the domain. It was run as the domain administrator. Perhaps TTT can tell us why it crashes? Cheers, Tridge ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] [REG:110011477385004] RE: userParameters attribute
Tridge, How did you generate the UserParameters you mentioned in the e-mail ? I got a little bit different result. The steps I used are (1) Open Avtive Directory Users and Computers - User - select a user such as Administrator (2) In Properties windows , select Sessions tab and then change Active session limit (3) Then the UserParametes attribute was added to the user object, the value is something like userParameters: PCtxCfgPresentCtxCfgFlags1CtxShadow*CtxMinEncryptionLevel? UserParameters attribute is used for storing user specific data for individual programs, such as RAS and Terminal Service. I just want to make sure we are looking at the same tool. Thanks! Hongwei -Original Message- From: tri...@samba.org [mailto:tri...@samba.org] Sent: Thursday, January 14, 2010 2:55 PM To: Interoperability Documentation Help Cc: cifs-proto...@samba.org; p...@tridgell.net; Michael Ströder Subject: CAR: userParameters attribute Dear Dochelp, The userParameters attribute on a user in AD seems to be a bit of a puzzle. Could you add some docs on it at some stage? Not a really high priority, but we would eventually like to be able to offer admin tools that manage things like session activity timeouts, and it seems that we need to know how to parse and create userParameters to do that. An example userParameters attribute from w2k8r2 (in base64 form) is this: userParameters:: Q3R4Q2ZnUHJlc2VudCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgI CAgUAsaCAFDdHhDZmdQcmVzZW5045S15pSx5oiw44GiIAIBQ3R4V0ZQcm9maWxlUGF0aOOAsBgCAU N0eFdGSG9tZURpcuOAsCICAUN0eFdGSG9tZURpckRyaXZl44CwEggBQ3R4U2hhZG9344Sw44Cw44C w44CwLggBQ3R4TWF4RGlzY29ubmVjdGlvblRpbWXjgaXjjLnjkLDjgLAoCAFDdHhNYXhDb25uZWN0 aW9uVGltZeOAtOOct+aIseOAsBwIAUN0eE1heElkbGVUaW1l44Gj45yy46Sw44CwIAIBQ3R4V29ya 0RpcmVjdG9yeeOAsBgIAUN0eENmZ0ZsYWdzMeOAsOOBpuOYsuOAuCICAUN0eEluaXRpYWxQcm9ncm Ft44Cw the above came from using the windows user admin tool to change the session activity timeout for a test user. Michael Ströder has also pointed out this page: http://daduke.org/linux/userparameters.html which documents a previous effort by the Linux thin client community to work out the format of userParameters. I'm guessing the strange encoding is used to try to keep the attribute as valid UTF8. If you can confirm that the attribute is always valid UTF8 that would be great (as otherwise we might corrupt it during replication with windows). As I mentioned, this is not a high priority, but it would be nice to know the format at some stage. Cheers, Tridge ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] How do we know what attributes are OIDs, classes and attributes
Andrew, We finished the investigation on your request. We will update the MS-ADTS as follows. Section 3.1.1.2.2.2 LDAP Representations Changed footnote on attributes of String(OID) to: ††† Values of attributes of syntax String(OID) are accepted in either the numericoid (numeric OID) or descr (the LDAP display name of the attribute or class identified by that OID) format, as defined in [RFC2252] section 4.1. The server determines the format of returning OID values using the first matching rule in the following set of processing rules: 1. If a Binary Option is present on the AttributeDescription (as described in [RFC2251] section 4.1.5.1) of the request, the server MUST return the OID converted to binary format as described in [RFC2252] section 4.3.1. The result is a binary encoded value using Basic Encoding Rules defined in [ITUX690]. 2. If a value of either attributeID of an AttributeSchema object or governsID of a ClassSchema object is requested, the server MUST return the OID in numericoid (Numeric OID) format. 3. If the attribute requested is not attributeID or governsID, but the value of the attribute identifies an attribute or class, the server MUST return the value in Descr format. 4. If none of the above applies, the server MUST return the OID in numericoid (Numeric OID) format. Section 3.1.1.3.1.1.5 Auxiliary Classes In fourth paragraph, it is changed to This dynamic auxiliary class mechanism complies with the [X501] model of auxiliary classes. For your second question regarding attribute of syntax OID(2.5.5.2) transported over DRS, OIDs are transported as ATTRTYPE values([MS-DRSR] Section 5.14 ATTRTYP) over DRS. Please refer to [MS-DRSR] Section 5.16.4 ATTRTYP-to-OID Conversion on conversion between the two formats. Please let us know if you have any further questions regarding this topic. Thanks! Hongwei -Original Message- From: cifs-protocol-boun...@cifs.org [mailto:cifs-protocol-boun...@cifs.org] On Behalf Of Andrew Bartlett Sent: Thursday, January 07, 2010 12:31 AM To: Interoperability Documentation Help Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: [cifs-protocol] How do we know what attributes are OIDs, classes and attributes G'day In LDAP, it is convention to display attribute names and classes as strings, except of course for governsID and attributeID. In DRS, these attribute and class names are transformed (using the prefix map) into 32 bit integers. What we need to know is, how should we tell if an attribute should be displayed in LDAP as an OID (dotted decimal), or as an attribute or class name. My worry is that this can't be handled as just 'schema only' and 'hardcoded list', because it is clearly possible to add OID syntax (2.5.5.2) attributes to objects in the general directory. For example: dn: CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=my,DC=domain transportAddressAttribute: dNSHostName How should I know that transportAddressAttribute must be displayed as a text string, and not an OID? How should I know that I display governsID as an OID? Are all attributes of syntax OID (2.5.5.2) transported over DRS as integers, or is there a hardcoded list? Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:110011477385004] RE: userParameters attribute
Tridge, Could you please take a look at my question below so I can proceed with this request ? If you are busy, we can always come back to visit it whenever it is good time for you. Thanks ! Hongwei -Original Message- From: Hongwei Sun Sent: Tuesday, January 19, 2010 9:31 PM To: 'tri...@samba.org' Cc: cifs-proto...@samba.org; p...@tridgell.net; Michael Ströder; MSSolve Case Email Subject: [REG:110011477385004] RE: userParameters attribute Tridge, How did you generate the UserParameters you mentioned in the e-mail ? I got a little bit different result. The steps I used are (1) Open Avtive Directory Users and Computers - User - select a user such as Administrator (2) In Properties windows , select Sessions tab and then change Active session limit (3) Then the UserParametes attribute was added to the user object, the value is something like userParameters: PCtxCfgPresentCtxCfgFlags1CtxShadow*CtxMinEncryptionLevel? UserParameters attribute is used for storing user specific data for individual programs, such as RAS and Terminal Service. I just want to make sure we are looking at the same tool. Thanks! Hongwei -Original Message- From: tri...@samba.org [mailto:tri...@samba.org] Sent: Thursday, January 14, 2010 2:55 PM To: Interoperability Documentation Help Cc: cifs-proto...@samba.org; p...@tridgell.net; Michael Ströder Subject: CAR: userParameters attribute Dear Dochelp, The userParameters attribute on a user in AD seems to be a bit of a puzzle. Could you add some docs on it at some stage? Not a really high priority, but we would eventually like to be able to offer admin tools that manage things like session activity timeouts, and it seems that we need to know how to parse and create userParameters to do that. An example userParameters attribute from w2k8r2 (in base64 form) is this: userParameters:: Q3R4Q2ZnUHJlc2VudCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgI CAgUAsaCAFDdHhDZmdQcmVzZW5045S15pSx5oiw44GiIAIBQ3R4V0ZQcm9maWxlUGF0aOOAsBgCAU N0eFdGSG9tZURpcuOAsCICAUN0eFdGSG9tZURpckRyaXZl44CwEggBQ3R4U2hhZG9344Sw44Cw44C w44CwLggBQ3R4TWF4RGlzY29ubmVjdGlvblRpbWXjgaXjjLnjkLDjgLAoCAFDdHhNYXhDb25uZWN0 aW9uVGltZeOAtOOct+aIseOAsBwIAUN0eE1heElkbGVUaW1l44Gj45yy46Sw44CwIAIBQ3R4V29ya 0RpcmVjdG9yeeOAsBgIAUN0eENmZ0ZsYWdzMeOAsOOBpuOYsuOAuCICAUN0eEluaXRpYWxQcm9ncm Ft44Cw the above came from using the windows user admin tool to change the session activity timeout for a test user. Michael Ströder has also pointed out this page: http://daduke.org/linux/userparameters.html which documents a previous effort by the Linux thin client community to work out the format of userParameters. I'm guessing the strange encoding is used to try to keep the attribute as valid UTF8. If you can confirm that the attribute is always valid UTF8 that would be great (as otherwise we might corrupt it during replication with windows). As I mentioned, this is not a high priority, but it would be nice to know the format at some stage. Cheers, Tridge ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] FW: FW: Inconsistencies in ad-schema docs and text files SRX090109601490
Andrew, I just want to check with you to see if you have any questions regarding the request and our response below. If not, I will resolve this case for now. Thanks! Hongwei -Original Message- From: Hongwei Sun Sent: Monday, January 18, 2010 6:27 PM To: 'Andrew Bartlett' Cc: p...@tridgell.net; cifs-proto...@samba.org; Andrew Tridgell Subject: RE: [cifs-protocol] FW: FW: Inconsistencies in ad-schema docs and text files SRX090109601490 Andrew Tridge, I finished reviewing the changes you made to the schema file in order to join Windows 2008R2 to Samba domain. For the attributes affected, from my initial review of MS-ADA*/MS-ADSC and code, they will probably result in many change requests to schema documentation. We will make sure that any correction you made will be properly reflected in the documentation after confirmation from the product team. We really appreciate the information you passed back to us, which is really valuable for us to improve schema documentation. Looking back at the history of the request , the previous delivery of a single schema text file combined from the AD* documents is not intended as a permanent process of releasing and maintaining schemas in separate documents, rather a temporary solution to provide a good starting point to unblock your development. But we did request the product team to evaluate the possibility for them to create and maintain the separate schema files. We will let you know when there is any update on this. By the way, there is an entry in our team blog site for how to relate schema to AD documentations (http://blogs.msdn.com/openspecification/archive/2009/06/26/using-the-windows-server-protocols-documentation-set-to-better-understand-the-active-directory-schema.aspx). Thanks! Hongwei -Original Message- From: Andrew Bartlett [mailto:abart...@samba.org] Sent: Monday, January 11, 2010 2:42 PM To: Hongwei Sun Cc: p...@tridgell.net; cifs-proto...@samba.org; Andrew Tridgell Subject: RE: [cifs-protocol] FW: FW: Inconsistencies in ad-schema docs and text files SRX090109601490 On Mon, 2010-01-11 at 15:23 +, Hongwei Sun wrote: Andrew, Most of the issues mentioned in your mail have been fixed in the latest released MS-ADSC or MS-ADA3. The following is a summary. The schema of Windows 2008 R2 we sent you in 04/24/2009 doesn't incorporate the above changes. I will work on it. We do have tools/scripts to create and validate the schema. Is there a location where you continually post the text file version of the schema, or do we have to ask each time? Also, have you addressed the issues tridge mentioned in his reply, and the adminDescription/adminDisplayName issue? Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] FW: FW: Inconsistencies in ad-schema docs and text files SRX090109601490
Thanks for the clarification! It helps a lot. Do you mean identical to the Windows 2008 R2 schema implemented on a windows DC ? Does Exact Value comparison mean to compare the elements between the schema file we sent you and a real Windows 2008 R2 schema ? Hongwei -Original Message- From: Andrew Bartlett [mailto:abart...@samba.org] Sent: Friday, February 12, 2010 5:58 PM To: Hongwei Sun Cc: tri...@samba.org; CIFS Protocol Subject: RE: [cifs-protocol] FW: FW: Inconsistencies in ad-schema docs and text files SRX090109601490 On Fri, 2010-02-12 at 22:55 +, Hongwei Sun wrote: Tridge/Andrew, We are in the process to update our MS-ADA* documents to reflect all the changes you made to the schema. I just want to confirm how you got these changes and if all these changes are essential. Your comments in diff below mentioned only the typos. The schema from WSPP had a number of typos that prevented it from working. These changes allow it to work with Samba, and allow w2k8r2 to run DCPROMO against Samba successfully How about the other changes, especially all these attributes adding SystemFlags: 0 ? If you don't have these changes, does it affect the functionality of W2k8 R2 to join Samba domain ? Have you got the other changes by comparing with an existing W2k8R2 schema ?The following is the list of attributes that affect schema documents. We didn't do this as a 'does this make things break', but as 'what is required to make the schema come out identical again'. We don't trust that we can write tests that can prove that a different schema is equivalent for all client software, so instead we go for exact value comparison. Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] [REG:110020183056252] - Inconsistencies in ACLs
;RPWPCCDCLCLORCWOWDSDDTSW;;;DA)(A;CI;RPWPCCDCLCLORCWOWDSDDTSW;;;EA)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;DA)(A;CIIO;RPWPCCDCLCLORCWOWDSDDTSW;;;CO)(A;CI;RPWPCCDCLCLORCWOWDSDDTSW;;;SY)(A;CI;RPLCLORC;;;AU)(OA;CI;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)(A;CI;RPLCLORC;;;ED)S:AI(OU;CIIDSA;WPWD;;f30e3bc2-9ff0-11d1-b603-f80367c1;WD)(OU;CIIOIDSA;WP;f30e3bbe-9ff0-11d1-b603-f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)(OU;CIIOIDSA;WP;f30e3bbf-9ff0-11d1-b603-f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD) So even if we remove the SACL and apply the transformation rules proposed before there is a huge difference between the file DS ACL and the associated file ACL (owner/group is different, BA is used in file ACL when DA is used in DS ACL). So it is seems that the logic is not ok (although it makes gpmc happy). Can you explain this ? Can you take from your side dump of a fresh w2k3r2 dc (or w2k8/w2k8r2) and look for the ACL on files/dir associated with GPO and with the GPO objects as well ? Regards. Matthieu. Thanks in advance! Regards, Bill Wesse MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 Email:bil...@microsoft.com Tel: +1(980) 776-8200 Cell: +1(704) 661-5438 Fax: +1(704) 665-9606 From: Matthieu Patou [mailto:mat+informatique.sa...@matws.net] Sent: Tuesday, December 22, 2009 3:56 PM To: Hongwei Sun Cc: Sebastian Canevari; cifs-proto...@samba.org; p...@tridgell.net Subject: Re: FW: [cifs-protocol] Group Policy questions On 23/12/2009 00:47, Hongwei Sun wrote: Matthieu, Your summary is a good recap of what we have done on this topic. I have one clarification for the point below. * All ACE for allowed object are wipped out when translating AD ACL to File ACL When translating a ACL for DS object to a ACL for SYSVOL file object, the ACEs with types of ACCESS_ALLOWED_OBJECT_ACE_TYPE, ACCESS_DENIED_OBJECT_ACE_TYPE and SYSTEM_AUDIT_OBJECT_ACE_TYPE are not really deleted from the ACL. Instead, for such a ACE, access mask in AceHeader is assigned to zero. Yeah I meant that when translating an AD ACL to a file ACL we do not care about it, for all those ACCESS_ALLOWED_OBJECT_ACE_TYPE in the AD no corresponding ACE in created. Sebastian will follow up with you on your question regarding documenting the logic for ACE OI and CI flags. Thanks! Hongwei ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:110020183056252] - Inconsistencies in ACLs
Resending.. just an editorial change... Matthieu, The default GPOs created during domain creation time (DcPromo) are Default Domain Group Policy(31B2F340-016D-11D2-945F-00C04FB984F9) and Default Domain Controller Group Policy (6AC1786C-016F-11D2-945F-00C04fB984F9). The initial security descriptors of default GPO SYSVOL folder and default DPO DS objects are assigned pre-defined values ,which are stored in windows implementation specific installation configuration files (schema.ini and defltdc.inf) , during DCPromo process. They are not derived from each other. For default GPO object in DS, the owner is always Domain Admins(DA), Group is always the Domain Admins(DA). For default GPO folder under SYSVOL, the owner should be Builtin Administrator and owner is System. Please let us know if you have more questions. Thanks! Hongwei -Original Message- From: Hongwei Sun Sent: Friday, February 26, 2010 6:34 PM To: 'Matthieu Patou' Cc: Sebastian Canevari; p...@tridgell.net; cifs-proto...@samba.org; MSSolve Case Email Subject: RE: [REG:110020183056252] - Inconsistencies in ACLs Matthieu, Ok from the reading of the DS flags it's not obvious that all this flags will merge to give FA. I suppose we should have a rule saying when you have RPWPCCDCLCLORCWOWDSDDTSW then the associate ACE is FA full stop. Is there other special translations rules ? RPWPCCDCLCLORCWOWDSDDTSW (0x000f00ff) is not mapped to FA directly. RPWPCCDCLCLORCWOWDSDDTSW is the access mask in DS DACL. It is translated to access mask 0x001F01FF in SYSVOL DACL using the algorithm. In SDDL, 0x001F01FF is displayed as FA , which means FILE_ALL_ACCESS. (http://msdn.microsoft.com/en-us/library/aa374928(VS.85).aspx) Ok so following our talks I am about to conclude that yes the algorithm that you gave is OK but it only applies to DACL, SACL didn't count, user and group also (I suppose that for new GPO the user/group is took from the user that created the new GPO). Just you need to investigate the glitches between DS ACE and FS ACE on default GPO (btw what should be the owner/group of default GPO ?). Did i made a right sum-up ? This is a right summary. Hongwei -Original Message- From: Matthieu Patou [mailto:mat+informatique.sa...@matws.net] Sent: Friday, February 26, 2010 4:04 PM To: Hongwei Sun Cc: Sebastian Canevari; p...@tridgell.net; cifs-proto...@samba.org Subject: Re: [REG:110020183056252] - Inconsistencies in ACLs On 26/02/2010 02:52, Hongwei Sun wrote: Matthieu, After considering what the access rights FA is associated with, I think that RPWPCCDCLCLORCWOWDSDDTSW is indeed mapped to FA if the logic is used. Please look at the output below (also attached as DS-Created.txt and SYSVOL-Created.txt) In DS DACL, CC DC LC SW RP WP DT LO SD RC WD WO represents access mask of 0x000f00ff Ace Mask: 0x000f00ff DELETE READ_CONTROL WRITE_DAC WRITE_OWNER ACTRL_DS_CREATE_CHILD ACTRL_DS_DELETE_CHILD ACTRL_DS_LIST ACTRL_DS_SELF ACTRL_DS_READ_PROP ACTRL_DS_WRITE_PROP ACTRL_DS_DELETE_TREE ACTRL_DS_LIST_OBJECT In SYSVOL DACL, FA is corresponding to : Type of access: Special acccess : -Read -Write -Execute -Delete -Change Permissions -Take Ownership Detailed Access Flags : 0x001F01FF FILE_READ_DATA-0x1 FILE_WRITE_DATA-0x2 FILE_APPEND_DATA-0x4 FILE_READ_EA-0x8FILE_WRITE_EA-0x10 FILE_EXECUTE-0x20FILE_DELETE_CHILD-0x40 FILE_READ_ATTRIBUTES-0x80 FILE_WRITE_ATTRIBUTES-0x100 DELETE-0x1 READ_CONTROL-0x2 WRITE_DAC-0x4 WRITE_OWNER-0x8 SYNCHRONIZE-0x10 From the debugging, access mask 0x000f00ff in DS DACL does map to 0x001F01FF in SYSVOL DACL. Ok from the reading of the DS flags it's not obvious that all this flags will merge to give FA. I suppose we should have a rule saying when you have RPWPCCDCLCLORCWOWDSDDTSW then the associate ACE is FA full stop. Is there other special translations rules ? After much of the investigation, I found that there is a little difference between default Group Policies(Domain Default and Domain Controller Default) and the ones created using GPMC. The SYSVOL DACL and DS DACL of the group policy created through GPMC have exactly matching access masks(as per logic) and even trustees. The order of ACEs inside DACL are exactly matching too. Please see the attached dump files(DS-created.txt and SYSVOL-created.txt). But for the default policies, the trustees and order of ACEs are different. The access mask mapping appears fine except
Re: [cifs-protocol] [REG:110020183056252] - Inconsistencies in ACLs
Matthieu, I just want to check with you to see if you have any further questions on this issue. If not , I will consider this case closed. Again, if you have related questions in the future, we can always revisit this case. Thanks! Hongwei -Original Message- From: Hongwei Sun Sent: Thursday, March 04, 2010 6:08 PM To: Matthieu Patou Cc: Sebastian Canevari; p...@tridgell.net; cifs-proto...@samba.org; MSSolve Case Email Subject: RE: [REG:110020183056252] - Inconsistencies in ACLs Resending.. just an editorial change... Matthieu, The default GPOs created during domain creation time (DcPromo) are Default Domain Group Policy(31B2F340-016D-11D2-945F-00C04FB984F9) and Default Domain Controller Group Policy (6AC1786C-016F-11D2-945F-00C04fB984F9). The initial security descriptors of default GPO SYSVOL folder and default DPO DS objects are assigned pre-defined values ,which are stored in windows implementation specific installation configuration files (schema.ini and defltdc.inf) , during DCPromo process. They are not derived from each other. For default GPO object in DS, the owner is always Domain Admins(DA), Group is always the Domain Admins(DA). For default GPO folder under SYSVOL, the owner should be Builtin Administrator and owner is System. Please let us know if you have more questions. Thanks! Hongwei -Original Message- From: Hongwei Sun Sent: Friday, February 26, 2010 6:34 PM To: 'Matthieu Patou' Cc: Sebastian Canevari; p...@tridgell.net; cifs-proto...@samba.org; MSSolve Case Email Subject: RE: [REG:110020183056252] - Inconsistencies in ACLs Matthieu, Ok from the reading of the DS flags it's not obvious that all this flags will merge to give FA. I suppose we should have a rule saying when you have RPWPCCDCLCLORCWOWDSDDTSW then the associate ACE is FA full stop. Is there other special translations rules ? RPWPCCDCLCLORCWOWDSDDTSW (0x000f00ff) is not mapped to FA directly. RPWPCCDCLCLORCWOWDSDDTSW is the access mask in DS DACL. It is translated to access mask 0x001F01FF in SYSVOL DACL using the algorithm. In SDDL, 0x001F01FF is displayed as FA , which means FILE_ALL_ACCESS. (http://msdn.microsoft.com/en-us/library/aa374928(VS.85).aspx) Ok so following our talks I am about to conclude that yes the algorithm that you gave is OK but it only applies to DACL, SACL didn't count, user and group also (I suppose that for new GPO the user/group is took from the user that created the new GPO). Just you need to investigate the glitches between DS ACE and FS ACE on default GPO (btw what should be the owner/group of default GPO ?). Did i made a right sum-up ? This is a right summary. Hongwei -Original Message- From: Matthieu Patou [mailto:mat+informatique.sa...@matws.net] Sent: Friday, February 26, 2010 4:04 PM To: Hongwei Sun Cc: Sebastian Canevari; p...@tridgell.net; cifs-proto...@samba.org Subject: Re: [REG:110020183056252] - Inconsistencies in ACLs On 26/02/2010 02:52, Hongwei Sun wrote: Matthieu, After considering what the access rights FA is associated with, I think that RPWPCCDCLCLORCWOWDSDDTSW is indeed mapped to FA if the logic is used. Please look at the output below (also attached as DS-Created.txt and SYSVOL-Created.txt) In DS DACL, CC DC LC SW RP WP DT LO SD RC WD WO represents access mask of 0x000f00ff Ace Mask: 0x000f00ff DELETE READ_CONTROL WRITE_DAC WRITE_OWNER ACTRL_DS_CREATE_CHILD ACTRL_DS_DELETE_CHILD ACTRL_DS_LIST ACTRL_DS_SELF ACTRL_DS_READ_PROP ACTRL_DS_WRITE_PROP ACTRL_DS_DELETE_TREE ACTRL_DS_LIST_OBJECT In SYSVOL DACL, FA is corresponding to : Type of access: Special acccess : -Read -Write -Execute -Delete -Change Permissions -Take Ownership Detailed Access Flags : 0x001F01FF FILE_READ_DATA-0x1 FILE_WRITE_DATA-0x2 FILE_APPEND_DATA-0x4 FILE_READ_EA-0x8FILE_WRITE_EA-0x10 FILE_EXECUTE-0x20FILE_DELETE_CHILD-0x40 FILE_READ_ATTRIBUTES-0x80 FILE_WRITE_ATTRIBUTES-0x100 DELETE-0x1 READ_CONTROL-0x2 WRITE_DAC-0x4 WRITE_OWNER-0x8 SYNCHRONIZE-0x10 From the debugging, access mask 0x000f00ff in DS DACL does map to 0x001F01FF in SYSVOL DACL. Ok from the reading of the DS flags it's not obvious that all this flags will merge to give FA. I suppose we should have a rule saying when you have RPWPCCDCLCLORCWOWDSDDTSW then the associate ACE is FA full stop. Is there other special translations rules ? After much of the investigation, I found that there is a little difference between
[cifs-protocol] [REG:110041353965669] RE: MS-RPRN: Question on PRINTER_INFO_STRESS.cAddNetPrinters
Andreas, Thanks for your question. One of our team member will work on your question and let you know when the investigation is done. Thanks! Hongwei Sun - Sr. Support Escalation Engineer DSC Protocol Team, Microsoft hongw...@microsoft.com Tel: 469-7757027 x 57027 - -Original Message- From: Andreas Schneider [mailto:m...@cynapses.org] Sent: Tuesday, April 13, 2010 5:25 AM To: Interoperability Documentation Help Cc: cifs-proto...@samba.org; p...@tridgell.net Subject: MS-RPRN: Question on PRINTER_INFO_STRESS.cAddNetPrinters Hello Dochelp Team, my name is Andreas Schneider, I'm a PFIF subcontractor and Samba Team member. In the MS-RPRN documentation the PRINTER_INFO_STRESS structure has a member called cAddNetPrinters. The documentation tells that this is the number of network printers added, per server. Is it correct that this variable is initialized with the number of existing printers when the spooler starts? added_printers = printer_count; Is it monotonically increased by the current number of printers *after* each add or delete printer RPC call? added_netprinter += printer_count; Thanks for your help. Cheers, -- andreas ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:110011477385004] RE: userParameters attribute
Tridge, I just want to check with you to see if you have any question regarding the newly added documentation for this attribute. If not, I will close this CAR. Thanks! Hongwei -Original Message- From: Hongwei Sun Sent: Tuesday, April 06, 2010 2:49 PM To: 'tri...@samba.org' Cc: cifs-proto...@samba.org; p...@tridgell.net; Michael Ströder; MSSolve Case Email Subject: [REG:110011477385004] RE: userParameters attribute Tridge, We finished updating the protocol document for the userParameters attribute. Since this attribute is used by the Terminal Services Terminal Server Runtime Interface, it is documented in [MS-TSTS]: Terminal Services Terminal Server Runtime Interface Protocol Specification (http://msdn.microsoft.com/en-us/library/cc248570(v=PROT.10).aspx) , which is a part of MCPP document set. The information below has been added to the document and will appear in the future release on MSDN. The following are the updated sections in MS-TSTS. I attached a separate PDF file for your reference. 1. The table in Section 2.3, Directory Service Schema Elements, was modified to denote that the attributes listed previously are not used by Microsoft Terminal Services and a new attribute, userParameters, was added to the table. 2. The section 2.3.1, UserParameters, was added. 3. The section 2.3.2, Encoding and decoding PropValue field, was added. 4. The section 4.5, example for Encoding/Decoding, was added Please let us know if you need any more information for this topic. Thanks! Hongwei -Original Message- From: tri...@samba.org [mailto:tri...@samba.org] Sent: Thursday, January 14, 2010 2:55 PM To: Interoperability Documentation Help Cc: cifs-proto...@samba.org; p...@tridgell.net; Michael Ströder Subject: CAR: userParameters attribute Dear Dochelp, The userParameters attribute on a user in AD seems to be a bit of a puzzle. Could you add some docs on it at some stage? Not a really high priority, but we would eventually like to be able to offer admin tools that manage things like session activity timeouts, and it seems that we need to know how to parse and create userParameters to do that. An example userParameters attribute from w2k8r2 (in base64 form) is this: userParameters:: Q3R4Q2ZnUHJlc2VudCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgI CAgUAsaCAFDdHhDZmdQcmVzZW5045S15pSx5oiw44GiIAIBQ3R4V0ZQcm9maWxlUGF0aOOAsBgCAU N0eFdGSG9tZURpcuOAsCICAUN0eFdGSG9tZURpckRyaXZl44CwEggBQ3R4U2hhZG9344Sw44Cw44C w44CwLggBQ3R4TWF4RGlzY29ubmVjdGlvblRpbWXjgaXjjLnjkLDjgLAoCAFDdHhNYXhDb25uZWN0 aW9uVGltZeOAtOOct+aIseOAsBwIAUN0eE1heElkbGVUaW1l44Gj45yy46Sw44CwIAIBQ3R4V29ya 0RpcmVjdG9yeeOAsBgIAUN0eENmZ0ZsYWdzMeOAsOOBpuOYsuOAuCICAUN0eEluaXRpYWxQcm9ncm Ft44Cw the above came from using the windows user admin tool to change the session activity timeout for a test user. Michael Ströder has also pointed out this page: http://daduke.org/linux/userparameters.html which documents a previous effort by the Linux thin client community to work out the format of userParameters. I'm guessing the strange encoding is used to try to keep the attribute as valid UTF8. If you can confirm that the attribute is always valid UTF8 that would be great (as otherwise we might corrupt it during replication with windows). As I mentioned, this is not a high priority, but it would be nice to know the format at some stage. Cheers, Tridge ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] [REG:110041557300829] RE: Questions regarding 7.1.3.1 ACE Ordering Rules
Nadya, Active Directory is supposed to apply the requirements to any security descriptors maintained by a DC, as described in section 7.1.3. ACE ordering is one of the requirement. If forest functional level is DS_BEHAVIOR_WIN2003 and fDontStandardizeSDs is false, the ACEs in the ACLs will be sorted by DC using the ACE ordering rule in 7.1.3.1 MS-ADTS.This enforcement should happen either when a new object is created or when LDAP modify on security descriptor is done. If the ACE reordering cannot be done for some reasons, there will be no LDAP error returned and. The order of explicit ACEs supplied by the client is preserved. You are running test against Windows 2008 and by default fDontStandardizeSDs should be zero. So the ACE reordering should happen. Could you send me (1)the LDAP command you used to create the group (2)the SD you provided (3)the dump of SD finally set on group object ? I will investigate to find the reason why reordering is not happening. I am working on the clarification for the section of 7.1.3.1 based on two of your questions. I will let you know. Thanks! Hongwei -Original Message- From: cifs-protocol-boun...@cifs.org [mailto:cifs-protocol-boun...@cifs.org] On Behalf Of Nadezhda Ivanova Sent: Thursday, April 15, 2010 8:22 AM To: Interoperability Documentation Help Cc: cifs-proto...@samba.org Subject: [cifs-protocol] Questions regarding 7.1.3.1 ACE Ordering Rules Hello, I was running some test against a Windows 2008 server, forest functional level and domain functional level are both 2008. I created a group via LDAP and provided a security descriptor with ACE's deliberately scrambled - e.g Deny before Allow, Object Specific before Regular. I did not get an LDAP error, the group was successfully created, but the SD looked the way I provided it, that is, not according to the rules described in this section. Can you explain why this happens? What behavior should I expect, is Windows supposed to sort them, return an error, or sort them later, or when a recalculate hierarchy request is sent? In addition: What is ACE canonical form? In the sentence: The nest rule is only applied if the previous rule(s) give inconclusive results - what would constitute an inconclusive result? Best Regards, Nadya ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:110041557300829] RE: Questions regarding 7.1.3.1 ACE Ordering Rules
Nadya, Just to confirm what we have just talked about during our conversation. If the client provides ACL sorted by rule 1 and 2, which basically make it in canonical form, Windows will sort them further by rule 3 and 4. Please let me know if there is any more question. Thanks! Hongwei -Original Message- From: Nadezhda Ivanova [mailto:nadezhda.ivan...@postpath.com] Sent: Monday, May 03, 2010 2:30 AM To: Hongwei Sun Cc: MSSolve Case Email; cifs-proto...@samba.org Subject: Re: [REG:110041557300829] RE: [cifs-protocol] Questions regarding 7.1.3.1 ACE Ordering Rules Hi Hongwei, This makes things a bit clearer, but I have one more question: If the client provides ACL sorted by rules 1 and 2, will Windows automatically sort them by rule 3 and 4, or is the client responsible for this too? Regards, Nadya - Original Message - From: Hongwei Sun hongw...@microsoft.com To: Nadezhda Ivanova nadezhda.ivan...@postpath.com Cc: MSSolve Case Email casem...@microsoft.com, cifs-proto...@samba.org cifs-proto...@samba.org Sent: Sunday, May 2, 2010 6:46:08 AM (GMT+02:00) Helsinki, Kyiv, Riga, Sofia, Tallinn, Vilnius Subject: RE: [REG:110041557300829] RE: [cifs-protocol] Questions regarding 7.1.3.1 ACE Ordering Rules Hi, Nadya, We completed the investigation on your questions. The following are our responses to the questions: Q1: What is ACE canonical form? ANS:An ACL is said to be in canonical form if: (1) All explicit ACEs are placed before inherited ACEs. (2) Within the explicit ACEs, deny ACEs come before grant ACEs. (3) Inherited ACEs are placed in the order in which they were inherited. We will add the definition of ACL canonical form to [MS-DTYP] and also add the reference to this information in 7.1.3.1 MS-ADTS. Q2: In the sentence: The nest rule is only applied if the previous rule(s) give inconclusive results - what would constitute an inconclusive result? ANS: We will remove the statement “The next rule is only applied if the previous rule(s) give inconclusive results” from 7.1.3.1 [MS-ADTS]. Q3: . I created a group via LDAP and provided a security descriptor with ACE's deliberately scrambled - e.g Deny before Allow, Object Specific before Regular. I did not get an LDAP error, the group was successfully created, but the SD looked the way I provided it, that is, not according to the rules described in this section. Can you explain why this happens? What behavior should I expect, is Windows supposed to sort them, return an error ANS: If the ACEs in the input ACL are not in the canonical form as defined in Q1 , Windows Active Directory will not sort the ACEs and no error will be returned to the client. Please let us know if you have more questions. Thanks! Hongwei -Original Message- From: Nadezhda Ivanova [mailto:nadezhda.ivan...@postpath.com] Sent: Monday, April 19, 2010 9:00 AM To: Hongwei Sun Cc: MSSolve Case Email; cifs-proto...@samba.org Subject: Re: [REG:110041557300829] RE: [cifs-protocol] Questions regarding 7.1.3.1 ACE Ordering Rules Hi Hongwei, Currently I am using the Samba make test framework. I'll find a way to make a script that can be used without Samba and let you know. Until then, if it helps, this is the ACL I am providing upon group creation, in SDDL: sddl = D:(OA;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;PS)(OA;;CR;ab721a54-1 e 2f-11d0-9819-00aa0040529b;;PS)(OA;;CR;ab721a56-1e2f-11d0-9819-00aa0040 5 29b;;PS)(OA;;RPWP;77b5b886-944a-11d1-aebd-f80367c1;;PS)(OA;;RPWP;e 4 5795b2-9455-11d1-aebd-f80367c1;;PS)(OA;;RPWP;e45795b3-9455-11d1-ae b d-f80367c1;;PS)(OA;;RP;037088f8-0ae1-11d2-b422-00a0c968f939;;RS)(O A ;;RP;4c164200-20c0-11d0-a768-00aa006e0529;;RS)(OA;;RP;bc0ac240-79a9-11 d 0-9020-00c04fc2d4cf;;RS)(A;;RC;;;AU)(OA;;RP;59ba2f42-79a2-11d0-9020-00 c 04fc2d3cf;;AU)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)(A;;RPWPCRCCDCLCLORC W OWDSDDTSW;;;SY)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;AO)(A;;RPLCLORC;;;PS)( O A;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;PS)(OA;;RP;77b5b886-944a-1 1 d1-aebd-f80367c1;;AU)(OA;;RP;e45795b3-9455-11d1-aebd-f80367c1; ; AU)(OA;;RP;e48d0154-bcf8-11d1-8702-00c04fb96050;;AU)(OA;;CR;ab721a53-1 e 2f-11d0-9819-00aa0040529b;;WD)(OA;;RP;5f202010-79a5-11d0-9020-00c04fc2 d 4cf;;RS)(OA;;RPWP;bf967a7f-0de6-11d0-a285-00aa003049e2;;CA)(OA;;RP;46a 9 b11d-60ae-405a-b7e8-ff8a58d456d2;;S-1-5-32-560)(OA;;RPWP;6db69a1c-9422 - 11d1-aebd-f80367c1;;S-1-5-32-561)(OA;;RPWP;5805bc62-bdc9-4428-a5e2 - 856a0f4c185e;;S-1-5-32-561) + ((D;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;%s)(D;;RPLCLORC;;;%s) % (sid, sid)) The group is in an OU where inheritance is broken, that is, it will not inherit anything from the parent. The sid variable is the sid of a regular user, I suppose any user would do. Thanks, Nadya - Original Message
[cifs-protocol] [REG:110051857479854] RE: Replicating deleted object procedure clarifications
Kamen, For your question regarding the algorithm used in UpdateObject() , as documented in 4.1.10.6.9 of MS-DRSR, I think that the RemoveObj() was performed after PerformModifyOperation just to ensure the attributes on the deleted object conform to the invariants of a tombstone or deleted-object(see 3.1..1.5.5 of MS-ADTS). This is mentioned in the comments of the algorithm before RemoveObj is called.Furthermore, as per 5.154 of MS-DRSR, RemoveObj procedure performs a delete operation on an object so the targeted object will be transformed to a deleted-object or a tombstone ,depending on the state of the Recycle Bin option feature. This includes modifying the attributes and moving into the Deleted Container of its NC. But it will not remove the objects from the directory directly.If the object after PerformModifyOperation already conforms to the invariant of deleted-object or tombstone, the RemoveObj may do nothing to the object. Please let me know if I understand you question properly and if you have further questions. Thanks! Hongwei From: cifs-protocol-boun...@cifs.org [mailto:cifs-protocol-boun...@cifs.org] On Behalf Of Kamen Mazdrashki Sent: Tuesday, May 18, 2010 7:33 AM To: Interoperability Documentation Help; cifs-proto...@samba.org; p...@tridgell.net Subject: [cifs-protocol] Replicating deleted object procedure clarifications Dear Dochelp, I am currently trying to refactor Delete object implementation in Samba and I need some help with algorithm used for deleting objects and how the deletion is replicated to other DCs. Reference: ProcessGetNCChangesReply [MS-DRSR] - http://msdn.microsoft.com/en-us/library/dd207758(v=PROT.13).aspx UpdateObject [MS-DRSR] - http://msdn.microsoft.com/en-us/library/dd207780(v=PROT.13).aspx Delete Operation [MS-ADTS] - http://msdn.microsoft.com/en-us/library/cc223480(v=PROT.13).aspx Consider following sutiation: 0. We have two DCs configuration. We have an OU object with following props: dn: OU=TEST_DELETE_0417,DC=samba,DC=devel objectGUID: b7f1b90d-d247-45b7-87fb-f6bc916bd729 1. We delete this OU on DC1. The state of this object on each dc should be as follows: DC1: dn: OU=TEST_DELETE_0417\0ADEL:b7f1b90d-d247-45b7-87fb-f6bc916bd729,CN=Deleted Objects,DC=samba,DC=devel objectGUID: b7f1b90d-d247-45b7-87fb-f6bc916bd729 isDeleted: TRUE isRecycled: TRUE DC2: dn: OU=TEST_DELETE_0417,DC=samba,DC=devel objectGUID: b7f1b90d-d247-45b7-87fb-f6bc916bd729 2. Replication is triggered from DC1 to DC2. Now, according to UpdateObject() procedure, we will identify that Object's DN has changed from dn: OU=TEST_DELETE_0417,DC=samba,DC=devel to dn: OU=TEST_DELETE_0417\0ADEL:b7f1b90d-d247-45b7-87fb-f6bc916bd729,CN=Deleted Objects,DC=samba,DC=devel. Hence we will modify object's DN (calling PerformModifyDNOperation() operation). Which will make this object a Deleted-object right? While progressing further in UpdateObject() procedure, we will check and see, that 'isDeleted' attribute value is TRUE, so we shall call RemoveObj() procedure. At this point I am a little bit puzzled as there are two possible outcomes from this procedure: 1. Object's RDN should be transformed to a delete-mangled RDN. So we should end with an RDN like: TEST_DELETE_0417\0ADEL:b7f1b90d-d247-45b7-87fb-f6bc916bd72\0ADEL:b7f1b90d-d247-45b7-87fb-f6bc916bd72 right? 2. Or, as the object is already under Deleted Object container (moved there by previous call to PerformModifyOperation()), RemoveObj() procedure should delete it further - i.e. if the object is a Tombstone, it will be completely removed. Sorry that my description gets so messy. Basically what UpdateObject() states is that first we should execute PerformModifyOperation() and then RemoveObj(). Which is a little bit confusing, as PerformModifyOperation() will turn the object into a Deleted-object. Calling RemoveObj() later will actually act on already modified object, so I wonder - how does RemoveObj() knows that we just converted the object and this object should not be completely removed? Another possibility is for PeformModifyOperation() to determine that target DN will move the object under Deleted Objects container, and in this case to modify only Attribute values on the object, but not to call PerformModifyDNOperation() operation? -- CU, Kamen Mazdrashki kamen.mazdras...@postpath.commailto:kamen.mazdras...@postpath.com http://gitweb.samba.org/?p=kamenim/samba.git;a=summary - CISCO SYSTEMS BULGARIA EOOD http://www.cisco.com/global/BG/ ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:110052070326491] MS_RRP: Question on Symbolic Links
Andreas, Could you send me the network capture for the test below ? Also, if I can run your test for a repro, it will be easier for me the debug the behavior. Is your test a new test in smbtorture ? Thanks! Hongwei -Original Message- From: Andreas Schneider [mailto:m...@cynapses.org] Sent: Tuesday, May 25, 2010 9:45 AM To: Hongwei Sun Cc: p...@tridgell.net; cifs-proto...@samba.org; MSSolve Case Email Subject: Re: [REG:110052070326491] [cifs-protocol] MS_RRP: Question on Symbolic Links On Monday 24 May 2010 23:58:34 Hongwei Sun wrote: Andreas, When you open the key with REG_OPTION_LINK flag set, the server will return the handle to the source key. With a valid handle, client should be able to update the target of the symbolic link by changing the value of SymbolicLinkValue and also delete the key that is referenced by the handle. As explicitly pointed out in 3.1.1.11, the SymbolicLinkValue for target link should contain Fully Qualified Name(3.1.1.1.1), which is something like HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices. It is not in the kernel mode string such as \registry\machine\system\MountedDevice. I've done some testing with FQN as link value against Windows 2008 here. If I set the 'SymbolicLinkValue' to HKEY_LOCAL_MACHINE\Software\Samba\torture_test\symlink_destination and then do a normal OpenKey (follow the symlink) it fails with WERR_BADFILE. If I set the 'SymbolicLinkValue' to '\Registry\MACHINE\Software\Samba\torture_test\symlink_destination' I can follow the symlink. I think the documentation is wrong here. At least for Windows 2008. I haven't tested it against other Windows versions yet. Best regards, -- andreas ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:110011477385004] RE: userParameters attribute
Andrew, We have confirmed that currently UserParameter attribute is only used by the Terminal Service and there is no any other Microsoft product that also uses this attribute. The Terminal Service doesn't use the first 96 bytes of the UserParameter attribute. In order to avoid any confusion, we will rename MSProductData to UnusedData in the 2.3.1 of the future release of MS-TSTS. Please let us know if you have any more question, if not, I will consider this case closed. Thanks! Hongwei -Original Message- From: Andrew Bartlett [mailto:abart...@samba.org] Sent: Friday, May 14, 2010 6:12 PM To: Hongwei Sun Cc: tri...@samba.org; p...@tridgell.net; cifs-proto...@samba.org; MSSolve Case Email; Michael Ströder Subject: Re: [cifs-protocol] [REG:110011477385004] RE: userParameters attribute On Tue, 2010-04-13 at 18:18 +, Hongwei Sun wrote: Tridge, I just want to check with you to see if you have any question regarding the newly added documentation for this attribute. If not, I will close this CAR. The reference is good, but it seems there is a problem because of the way this parameter is split between products. In particular, while this may be true for MS-TSTS: [MS-TSTS] 2.3.1 UserParamerters: MSProductData (96 bytes): A 96 byte Unicode character array containing 48 Unicode characters. This field is not used by Microsoft Terminal Services. We need to know the full decode of the structure, regardless of which product or document owns it. In short, what is the meaning and expected contents of MSProductData? Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [Pfif] [REG:110052070326491] MS_RRP: Question on Symbolic Links
Michael/Andreas, I just want to give you an update. I have reproduced locally the problem with deleting the symbolic link key after the SymbolicLinkValue value has been deleted. I also changed the function kernel_mode_registry_path() in smbtorture to return FQN to duplicate the behavior of following symbolic link target key in FQN. I have everything I need to do further debugging and provide the clarification. I will let you know when I am done. Thanks! Hongwei -Original Message- From: Michael Adam [mailto:ob...@samba.org] Sent: Friday, May 28, 2010 9:17 AM To: Hongwei Sun; Andreas Schneider Cc: p...@tridgell.net; cifs-proto...@samba.org; MSSolve Case Email Subject: Re: [Pfif] [REG:110052070326491] [cifs-protocol] MS_RRP: Question on Symbolic Links Hi Hongwei, Andreas Schneider wrote: On Monday 24 May 2010 23:58:34 Hongwei Sun wrote: Andreas, Hello Hongwei, When you open the key with REG_OPTION_LINK flag set, the server will return the handle to the source key. With a valid handle, client should be able to update the target of the symbolic link by changing the value of SymbolicLinkValue and also delete the key that is referenced by the handle. As explicitly pointed out in 3.1.1.11, the SymbolicLinkValue for target link should contain Fully Qualified Name(3.1.1.1.1), which is something like HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices. It is not in the kernel mode string such as \registry\machine\system\MountedDevice. How do you delete the value SymbolocLinkVallue ? using BaseRegDeleteValue as per 3.1.5.9 MS-RRP? What do you mean by it didn't work ?Do you mean that the value is not deleted or any error is returned ? I'm able to delete the value but not the key. Yes, this is the main question here: How to delete source key of the symlink. There seems to be no way to do that using the remote registry protocol, since I can find no (documented) call to delete an opened key (i.e. operating on a key handle). The internal libraries document the ZwDeleteKey / NtDeleteKey routines that operate on an opened KeyHandle for this purpose: http://msdn.microsoft.com/en-us/library/ff566437%28VS.85%29.aspx But I can't find acorresponding call in the RRP doc. And, as you stated, when you access the symlink source key without opening it with the REG_OPTION_LINK flag, then you will operate on the target of the symlink. Or else if the special value SymbolicLinkValue is not present, access simply seems to fail. The only other means of deleting a symlink source key I could imagine would be to change the type of the sourcekey first, removing the LINK type flag (3.1.1.2, http://msdn.microsoft.com/en-us/library/cc244886%28PROT.10%29.aspx ) which was set when creating the key. But this does not seem to be achievable, at least not with calling CreateKey with different options on the existing key (which was the only way I could imagine), since the description 3.1.5.7 BaseRegCreateKey (Opnum 6) reads: If the key already exists, the dwOptions parameter in the client request MUST be ignored. Could you please confirm this behaviour or else (preferred! :-) tell us how to delete the source key of a symlink using the remote registry? Cheers - Michael I'm running this test against Windows 2008. Here is some pseudo code. /* create link */ CreateKey(SOFTWARE\torture_test\target) CloseKey(SOFTWARE\torture_test\target) CreateKey(SOFTWARE\torture_test\link, REG_OPTION_CREATE_LINK | REG_OPTION_VOLATILE) SetValue(SymbolicLinkValue, SOFTWARE\torture_test\target) CloseKey(SOFTWARE\torture_test\link) /* delete link */ OpenKey(SOFTWARE\torture_test\link, REG_OPTION_OPEN_LINK | REG_OPTION_VOLATILE) DeleteValue(SymbolicLinkValue) CloseKey(SOFTWARE\torture_test\link) DeleteKey(SOFTWARE\torture_test\link) -- fails with WERR_ACCESS_DENIED Regards, -- andreas ___ Pfif mailing list p...@mail.tridgell.net http://lists.tridgell.net/cgi-bin/mailman/listinfo/pfif ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:110011477385004] RE: userParameters attribute
Andrew, This 96 bytes unused data is not currently used by Terminal Service. The following is the update to the documentation: UnusedData (96 bytes): A 96 byte array of unused data. This array is filled with the ASCII character for space (0x20). Thanks! Hongwei -Original Message- From: Andrew Bartlett [mailto:abart...@samba.org] Sent: Wednesday, May 26, 2010 6:19 PM To: Hongwei Sun Cc: tri...@samba.org; p...@tridgell.net; cifs-proto...@samba.org; MSSolve Case Email; Michael Ströder Subject: RE: [cifs-protocol] [REG:110011477385004] RE: userParameters attribute On Wed, 2010-05-26 at 23:07 +, Hongwei Sun wrote: Andrew, We have confirmed that currently UserParameter attribute is only used by the Terminal Service and there is no any other Microsoft product that also uses this attribute. The Terminal Service doesn't use the first 96 bytes of the UserParameter attribute. In order to avoid any confusion, we will rename MSProductData to UnusedData in the 2.3.1 of the future release of MS-TSTS. Please let us know if you have any more question, if not, I will consider this case closed. That's weird. For ages, this was referred to in samba as the 'munged dialback field', because (from memory) the first part was meant to contain the phone number to call back for old-style modem-callback security. I take it that this does not exist any more? For reference, we finally got rid of the field in this commit: http://www.mail-archive.com/samba-...@lists.samba.org/msg49021.html UNISTR2 uni_munged_dial ; /* munged path name and dial-back tel no */ Where the field after 'comment' on SAM_USER_INFO_23 became 'parameters' from the IDL. This 'parameters' maps to userParameter in LDAP. Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [Pfif] [REG:110052070326491] MS_RRP: Question on Symbolic Links
Michael/Andreas, We completed the investigation and confirmed that functionality of deleting symbolic link's source key is not available in Windows registry remote service(MS-RRP). Unfortunately, there is no way for a remote client to delete a symbolic link source key on the server. Does Samba actually uses this feature ? I would like to know the impact of this undesirable behavior on Samba's implementation. We will update this behavior in MS-RRP. We also confirmed that the kernel mode format should be used for SymbolicLinkValue value. We will update the corresponding section of MS-RRP to reflect the change. Thanks for bringing this into our attention and help us improve the documentation. Please let me know if you have any more questions on this subject and I will follow it up. Thanks! Hongwei -Original Message- From: Michael Adam [mailto:ob...@samba.org] Sent: Wednesday, June 02, 2010 4:17 AM To: Hongwei Sun Cc: Michael Adam; Andreas Schneider; p...@tridgell.net; cifs-proto...@samba.org; MSSolve Case Email Subject: Re: [Pfif] [REG:110052070326491] [cifs-protocol] MS_RRP: Question on Symbolic Links Hi Hongwei, Hongwei Sun wrote: Michael/Andreas, I just want to give you an update. I have reproduced locally the problem with deleting the symbolic link key after the SymbolicLinkValue value has been deleted. I also changed the function kernel_mode_registry_path() in smbtorture to return FQN to duplicate the behavior of following symbolic link target key in FQN. I have everything I need to do further debugging and provide the clarification. I will let you know when I am done. Thanks for the update! Please bear in mind that the original question was if one can delete the symbolic link's source key via the remote registry protocol (and how to do so if the answer is yes). We did not find the procedure for deletion documented. The procedure to first remove the value SymbolicLinkValue was just an attempt to get it done. There may be other ways, but we could not think of one. It seemed the obvious attempt too, because any access on the source key with present value will always work on the target, and there is no way to delete the opened key handle via the RRP. Thanks - Michael Thanks! Hongwei -Original Message- From: Michael Adam [mailto:ob...@samba.org] Sent: Friday, May 28, 2010 9:17 AM To: Hongwei Sun; Andreas Schneider Cc: p...@tridgell.net; cifs-proto...@samba.org; MSSolve Case Email Subject: Re: [Pfif] [REG:110052070326491] [cifs-protocol] MS_RRP: Question on Symbolic Links Hi Hongwei, Andreas Schneider wrote: On Monday 24 May 2010 23:58:34 Hongwei Sun wrote: Andreas, Hello Hongwei, When you open the key with REG_OPTION_LINK flag set, the server will return the handle to the source key. With a valid handle, client should be able to update the target of the symbolic link by changing the value of SymbolicLinkValue and also delete the key that is referenced by the handle. As explicitly pointed out in 3.1.1.11, the SymbolicLinkValue for target link should contain Fully Qualified Name(3.1.1.1.1), which is something like HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices. It is not in the kernel mode string such as \registry\machine\system\MountedDevice. How do you delete the value SymbolocLinkVallue ? using BaseRegDeleteValue as per 3.1.5.9 MS-RRP? What do you mean by it didn't work ?Do you mean that the value is not deleted or any error is returned ? I'm able to delete the value but not the key. Yes, this is the main question here: How to delete source key of the symlink. There seems to be no way to do that using the remote registry protocol, since I can find no (documented) call to delete an opened key (i.e. operating on a key handle). The internal libraries document the ZwDeleteKey / NtDeleteKey routines that operate on an opened KeyHandle for this purpose: http://msdn.microsoft.com/en-us/library/ff566437%28VS.85%29.aspx But I can't find acorresponding call in the RRP doc. And, as you stated, when you access the symlink source key without opening it with the REG_OPTION_LINK flag, then you will operate on the target of the symlink. Or else if the special value SymbolicLinkValue is not present, access simply seems to fail. The only other means of deleting a symlink source key I could imagine would be to change the type of the sourcekey first, removing the LINK type flag (3.1.1.2, http://msdn.microsoft.com/en-us/library/cc244886%28PROT.10%29.aspx ) which was set when creating the key. But this does not seem to be achievable, at least not with calling CreateKey with different options on the existing key (which was the only way I could imagine), since the description 3.1.5.7 BaseRegCreateKey (Opnum 6) reads: If the key already exists, the dwOptions parameter in the client request MUST
Re: [cifs-protocol] [REG:110051856627810] Ordering of domain in case of DFS domain referral
Hi, Matthieu, We have completed the investigation for your questions below. * in which order the domain should be returned ? if any (ie. first lower domain like samba.corp then au.samba.corp then brisbane.au.samba.corp) ANS: The domain referral must include names for the local domain and may include all other domains in a random order. * I understand that nebios/dns name must go in couple, (ie. not return first all the dns name then all the netios name, but each pair accordingly), but what must appear first NETBIOS domain or DNS domain name ? ANS: NETBIOS domain and DNS domain names also appear in a random order in domain referral response. Please let us know if you have more questions, otherwise I will consider this issue closed. Thanks! Hongwei -Original Message- From: cifs-protocol-boun...@cifs.org [mailto:cifs-protocol-boun...@cifs.org] On Behalf Of Matthieu Patou Sent: Tuesday, May 18, 2010 4:31 AM To: Interoperability Documentation Help; cifs-proto...@samba.org; p...@tridgell.net Subject: [cifs-protocol] Ordering of domain in case of DFS domain referral Hello dochelp team, I've got a small question regarding the ordering of domain when answering a Domain referral request as described here: 3.3.5.2 Receiving a Domain Referral Request My questions are: * in which order the domain should be returned ? if any (ie. first lower domain like samba.corp then au.samba.corp then brisbane.au.samba.corp) * I understand that nebios/dns name must go in couple, (ie. not return first all the dns name then all the netios name, but each pair accordingly), but what must appear first NETBIOS domain or DNS domain name ? Also depending on the answer you'll make on the first point this statement might need also amendment: MUST give preference to the NetBIOS and fully qualified names of the DC's own domain first, and then give preference to other domains. This ensures that a client in the same domain as the server will always be able to access SYSVOL and NETLOGON paths correctly.35 As I understand it didn't state that the own domain of the DC must be first, just that if the DC has a choice to make between its own domain referral information and another domain then it should choose its own first. Am I right ? Regards. Matthieu Patou. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] [REG:110080418016869] version field and a GUID field no documented
Proposed Request: Matthieu, I am working on the following issue you reported. 110080418016869 [MS-BKRP] 3.1.4.1.3 -- version field and a GUID field no documented Also I've got questions of what is explained in the document. First in paragraph 3.1.4.1.3, it is stated The server MUST ignore the cbDataIn and pDataIn parameters. It MUST return the RSA public key from the ClientWrap key pair, in the format specified in section 2.2.1. If no such key can be found or created, the server MUST return an error. The client is supposed to send a 2.2.2 Client-Side-Wrapped Secret struct in the pDataIn variable, this struct contains also a version field and a guid field. Nothing is said about this fields, how should they be populated, can you explain this ? I think that there may be something mixed up here. The paragraph 3.1.4.1.3 is for sending BACKUPKEY_RETRIEVE_BACKUP_KEY_GUID to request the public key part of the server's ClientWrap key pair. Just as mentioned in your message, there should no input to pDataIn variable as well as cbDataIn, so I am not sure that the second paragraph is related to your question , unless you are talking about sending BACKUPKEY_RESTORE_GUID which requires clients to send Client-Side-Wrapped Secret structure. If this is the case, version field should be populated as either 2 or 3 based on the EncryptedSecret and AccessCheck fields (2.2.2 MS-BKRP). The guidKey should be populated using the unique GUID of the public key returned from BACKUPKEY_RETRIEVE_BACKUP_KEY_GUID request. Please confirm. Thanks! Hongwei ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:110080418016869] version field and a GUID field no documented
--- Fixed the minimal editor mistake. Matthieu, I am working on the following issue you reported. 110080418016869 [MS-BKRP] 3.1.4.1.3 -- version field and a GUID field no documented Also I've got questions of what is explained in the document. First in paragraph 3.1.4.1.3, it is stated The server MUST ignore the cbDataIn and pDataIn parameters. It MUST return the RSA public key from the ClientWrap key pair, in the format specified in section 2.2.1. If no such key can be found or created, the server MUST return an error. The client is supposed to send a 2.2.2 Client-Side-Wrapped Secret struct in the pDataIn variable, this struct contains also a version field and a guid field. Nothing is said about this fields, how should they be populated, can you explain this ? I think that there may be something mixed up here. The paragraph 3.1.4.1.3 is for sending BACKUPKEY_RETRIEVE_BACKUP_KEY_GUID to request the public key part of the server's ClientWrap key pair. Just as mentioned in your message, there should no input to pDataIn variable as well as cbDataIn, so I am not sure that the second paragraph is related to your question , unless you are talking about sending BACKUPKEY_RESTORE_GUID which requires clients to send Client-Side-Wrapped Secret structure. If this is the case, version field should be populated as either 2 or 3 based on the EncryptedSecret and AccessCheck fields (2.2.2 MS-BKRP). The guidKey should be populated using the unique GUID of the public key returned from BACKUPKEY_RETRIEVE_BACKUP_KEY_GUID request. Please confirm. Thanks! Hongwei ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:110062452298172] Re: Text-file Schema for all of 2000-2008R2
Andrew, Since Bill is out of office, I have taken over the ownership of this case. I have been actively working on this case. I will update you as soon as I have any new status. Thanks for your patience. Hongwei -Original Message- From: cifs-protocol-boun...@cifs.org [mailto:cifs-protocol-boun...@cifs.org] On Behalf Of Andrew Bartlett Sent: Tuesday, August 17, 2010 7:46 PM To: Interoperability Documentation Help Cc: MSSolve Case Email; cifs-proto...@samba.org; Bill Wesse Subject: Re: [cifs-protocol] [REG:110062452298172] Re: Text-file Schema for all of 2000-2008R2 On Thu, 2010-07-08 at 11:43 +, Bill Wesse wrote: Resending the DumpSchema.cmd(.txt) file; I broke the earlier one during an edit (deleted a label ':Perform'). Sorry. Dochelp. I was working on this with Bill, but I need to bump this a long a little, and to clarify things a bit more: It is great having commands to dump the schema - we can write such commands easily, and use those to confirm that the schema we supply to our users is correct. Indeed, such commands have shown that we have not been supplied correct schema in the past. However, what I need isn't tools to extract schema from AD servers, but the actual schema, provided by Microsoft to us under the agreed licence. This makes it unambiguous that we can redistribute the result. Therefore, we do require the schema from the WSPP documentation, we require it in a format that is suitable for use in creation of an interoperable implementation, we need is under the licence, and we require that it is 100% correct. If we cannot get those assurances, we have two problems: We waste an inordinate amount of time fixing bugs that should never have occurred (surely the docs were generated with tools such as you supplied in your mail), and we loose confidence that any update to the schema or a new revision is correct. Have you had any luck securing those assurances from the product group? It seems to have taken quite some time, for something that should be nothing more than providing an automated extract. Thankyou, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:110081752971983] RE: How to RODCs get their membership of the ENTERPRISE_RODCs group
Tridge/Andrew, I have been testing and debugging the Windows behavior related to tokenGroups rootDSE attribute in RODC. It seems that I cannot duplicate what you have observed. I have a RODC joined to a domain that has two more RWDCs. I got the following output for the rootDSE in RODC object and RootDSE when I did a base search to the RODC from another DC in the same domain. They don't include RID 498. Dn: (RootDSE) tokenGroups (16): S-1-5-21-3071076805-1052773752-2226054901-500; S-1-5-21-3071076805-1052773752-2226054901-513; S-1-1-0; S-1-5-32-544; S-1-5-32-545; S-1-5-32-574; S-1-5-32-554; S-1-5-2; S-1-5-11; S-1-5-15; S-1-5-21-3071076805-1052773752-2226054901-512; S-1-5-21-3071076805-1052773752-2226054901-520; S-1-5-21-3071076805-1052773752-2226054901-519; S-1-5-21-3071076805-1052773752-2226054901-518; S-1-5-21-3071076805-1052773752-2226054901-1103; S-1-5-21-3071076805-1052773752-2226054901-572; --- ***Searching... ldap_search_s(ld, CN=RODC01,OU=Domain Controllers,DC=contoso,DC=com, 0, (objectclass=*), attrList, 0, msg) Getting 1 entries: Dn: CN=RODC01,OU=Domain Controllers,DC=contoso,DC=com tokenGroups (2): S-1-5-21-3071076805-1052773752-2226054901-572; S-1-5-21-3071076805-1052773752-2226054901-521; I am wondering what the difference is between your environment and my repro. Andrew mentioned that However, it does show up in the tokenGroups in the rootDSE, if we connect *as* the RODC. Does that mean Samba DC is connected as a RODC ? Thanks! Hongwei -Original Message- From: tri...@samba.org [mailto:tri...@samba.org] Sent: Tuesday, August 17, 2010 7:30 PM To: Hongwei Sun Cc: Andrew Bartlett; cifs-proto...@samba.org; MSSolve Case Email Subject: [REG:110081752971983] RE: How to RODCs get their membership of the ENTERPRISE_RODCs group Hi Hongwei, You mentioned that all the documentation talks about RODCs being a member of the enterprise read only domain controller group, which has a RID of 498. What part of the document do you refer to ? See for example [MS-DRSR] 4.1.10.5.12 which has this: * 1. Caller is an RODC. An RODC will always be a member of * Enterprise Read-Only Domain Controllers (RID 498) Should I take the question as why tokenGroups of rootDSE has 498 but the tokenGroups of RODC account doesn't have it ? that is one way to look at it. We can see via tokenGroups that RODCs are a member of both the group with RID 498 and the group with RID 521. Normally a user becomes a member of a group in one of three ways. 1) via it being the primaryGroupID of the user 2) via a member attribute on a group (or equivalently via a memberOf back link) 3) via some special handling that adds things like anonymous or world or other special groups We suspect that RODCs being a member of 498 is due to something in the special handling category, but we'd like to know what the nature of that special handling is. For example, is it something as simple as when constructing the token for a user, always add RID 498 if they have RID 521 in their token from the same domain. Where things may get tricky is in the inter-domain (eg. forest) handling. We'd like to make sure we get this right, or at least understand how we're getting it wrong :-) Cheers, Tridge ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:110081752971983] RE: How to RODCs get their membership of the ENTERPRISE_RODCs group
Tridge/Andrew, Have you got a chance to take a look at this ? If you can send a confirmation and some information , then I can continue to work on it. I understand that you are probably busy with preparing for IO Lab. If you prefer to work on this together during IO Lab, I am fine with that too. Thanks! Hongwei -Original Message- From: Hongwei Sun Sent: Monday, August 23, 2010 6:37 PM To: 'tri...@samba.org' Cc: Andrew Bartlett; cifs-proto...@samba.org; MSSolve Case Email Subject: RE: [REG:110081752971983] RE: How to RODCs get their membership of the ENTERPRISE_RODCs group Tridge/Andrew, I have been testing and debugging the Windows behavior related to tokenGroups rootDSE attribute in RODC. It seems that I cannot duplicate what you have observed. I have a RODC joined to a domain that has two more RWDCs. I got the following output for the rootDSE in RODC object and RootDSE when I did a base search to the RODC from another DC in the same domain. They don't include RID 498. Dn: (RootDSE) tokenGroups (16): S-1-5-21-3071076805-1052773752-2226054901-500; S-1-5-21-3071076805-1052773752-2226054901-513; S-1-1-0; S-1-5-32-544; S-1-5-32-545; S-1-5-32-574; S-1-5-32-554; S-1-5-2; S-1-5-11; S-1-5-15; S-1-5-21-3071076805-1052773752-2226054901-512; S-1-5-21-3071076805-1052773752-2226054901-520; S-1-5-21-3071076805-1052773752-2226054901-519; S-1-5-21-3071076805-1052773752-2226054901-518; S-1-5-21-3071076805-1052773752-2226054901-1103; S-1-5-21-3071076805-1052773752-2226054901-572; --- ***Searching... ldap_search_s(ld, CN=RODC01,OU=Domain Controllers,DC=contoso,DC=com, 0, (objectclass=*), attrList, 0, msg) Getting 1 entries: Dn: CN=RODC01,OU=Domain Controllers,DC=contoso,DC=com tokenGroups (2): S-1-5-21-3071076805-1052773752-2226054901-572; S-1-5-21-3071076805-1052773752-2226054901-521; I am wondering what the difference is between your environment and my repro. Andrew mentioned that However, it does show up in the tokenGroups in the rootDSE, if we connect *as* the RODC. Does that mean Samba DC is connected as a RODC ? Thanks! Hongwei -Original Message- From: tri...@samba.org [mailto:tri...@samba.org] Sent: Tuesday, August 17, 2010 7:30 PM To: Hongwei Sun Cc: Andrew Bartlett; cifs-proto...@samba.org; MSSolve Case Email Subject: [REG:110081752971983] RE: How to RODCs get their membership of the ENTERPRISE_RODCs group Hi Hongwei, You mentioned that all the documentation talks about RODCs being a member of the enterprise read only domain controller group, which has a RID of 498. What part of the document do you refer to ? See for example [MS-DRSR] 4.1.10.5.12 which has this: * 1. Caller is an RODC. An RODC will always be a member of * Enterprise Read-Only Domain Controllers (RID 498) Should I take the question as why tokenGroups of rootDSE has 498 but the tokenGroups of RODC account doesn't have it ? that is one way to look at it. We can see via tokenGroups that RODCs are a member of both the group with RID 498 and the group with RID 521. Normally a user becomes a member of a group in one of three ways. 1) via it being the primaryGroupID of the user 2) via a member attribute on a group (or equivalently via a memberOf back link) 3) via some special handling that adds things like anonymous or world or other special groups We suspect that RODCs being a member of 498 is due to something in the special handling category, but we'd like to know what the nature of that special handling is. For example, is it something as simple as when constructing the token for a user, always add RID 498 if they have RID 521 in their token from the same domain. Where things may get tricky is in the inter-domain (eg. forest) handling. We'd like to make sure we get this right, or at least understand how we're getting it wrong :-) Cheers, Tridge ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:110081752971983] RE: How to RODCs get their membership of the ENTERPRISE_RODCs group
Andrew, I duplicated the behavior using the information you provided. Thanks! We confirmed that the observed behavior is expected due to the following logic: If the user account is a RODC machine account, in which UserAccountControl flag on the account object has USER_WORKSTATION_TRUST_ACCOUNT | USER_PARTIAL_SECRETS_ACCOUNT set, the RID DOMAIN_GROUP_RID_ENTERPRISE_READONLY_DOMAIN_CONTROLLERS(498) will be automatically added to SID list for group membership. We are working on finding the appropriate way to document the behavior in the future release of the protocol documents. Thanks! Hongwei -Original Message- From: Andrew Bartlett [mailto:abart...@samba.org] Sent: Tuesday, August 31, 2010 3:51 PM To: Hongwei Sun Cc: tri...@samba.org; cifs-proto...@samba.org; MSSolve Case Email Subject: RE: [REG:110081752971983] RE: How to RODCs get their membership of the ENTERPRISE_RODCs group On Mon, 2010-08-23 at 23:37 +, Hongwei Sun wrote: Tridge/Andrew, I have been testing and debugging the Windows behavior related to tokenGroups rootDSE attribute in RODC. It seems that I cannot duplicate what you have observed. I have a RODC joined to a domain that has two more RWDCs. I got the following output for the rootDSE in RODC object and RootDSE when I did a base search to the RODC from another DC in the same domain. They don't include RID 498. Dn: (RootDSE) tokenGroups (16): S-1-5-21-3071076805-1052773752-2226054901-500; S-1-5-21-3071076805-1052773752-2226054901-513; S-1-1-0; S-1-5-32-544; S-1-5-32-545; S-1-5-32-574; S-1-5-32-554; S-1-5-2; S-1-5-11; S-1-5-15; S-1-5-21-3071076805-1052773752-2226054901-512; S-1-5-21-3071076805-1052773752-2226054901-520; S-1-5-21-3071076805-1052773752-2226054901-519; S-1-5-21-3071076805-1052773752-2226054901-518; S-1-5-21-3071076805-1052773752-2226054901-1103; S-1-5-21-3071076805-1052773752-2226054901-572; You have connected as the wrong user. We joined a Windows RODC to the domain, then changed it's password, and ran ldbsearch *as* the RODC, using the password we set on it's account. You have run the search as administrator, and natrually returned the tokenGroups for administrator. --- ***Searching... ldap_search_s(ld, CN=RODC01,OU=Domain Controllers,DC=contoso,DC=com, 0, (objectclass=*), attrList, 0, msg) Getting 1 entries: Dn: CN=RODC01,OU=Domain Controllers,DC=contoso,DC=com tokenGroups (2): S-1-5-21-3071076805-1052773752-2226054901-572; S-1-5-21-3071076805-1052773752-2226054901-521; When you connect as the RODC, you should see these SIDs, and the extra ENTERPRISE_RODCs group in the rootDSE tokenGroups. I'm sorry I didn't respond earlier - I simply didn't see your mail! Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] [REG:110091558099846] RE: Incompleteness in MS-SAMR section 3.1.1.8.1 objectClass
Matthias, Thanks for raising this issue with us. First, We will add the missing definitions for UF_PARTIAL_SECRETS_ACCOUNT (0x400) to 2.2.1.13 MS-SAMR, USER_PARTIAL_SECRETS_ACCOUNT (0x0010) to 2.2.1.12 MS-SAMR and DOMAIN_GROUP_RID_READONLY_DCS(0x0209) to 2.2.1.14 MS-SAMR. In 3.1.1.8.1 MS-SAMR, we will add the following entry to the table in item 4 showing that if userAccountContol has bits UF_WORKSTATION_TRUST_ACCOUNT UF_PARTIAL_SECRETS_ACCOUNT , the primaryGroupId attribute MUST be updated with DOMAIN_GROUP_RID_READONLY_CONTROLLERS. We are in the process to update the document. The changes will appear in the future release of the document. Please let us know if you have any further question. If not, I will consider this issue resolved. Thanks! Hongwei -Original Message- From: Matthias Dieter Wallnöfer [mailto:m...@samba.org] Sent: Wednesday, September 15, 2010 6:09 AM To: Interoperability Documentation Help Cc: cifs-proto...@samba.org Subject: Incompleteness in MS-SAMR section 3.1.1.8.1 objectClass Dear dochelp team, starting with Windows Server 2008 there has been introduced the UF_PARTIAL_SECURITY flag As far as we (s4 people) found out this also impacts the objectclass trigger described in MS-SAMR 3.1.1.8.1. For example if set on userAccountControl it switches the primaryGroupID to DOMAIN_GROUP_RID_READONLY_DCS. We would appreciate if the specified section could be enhanced regarding it. Thanks, Matthias Wallnöfer ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] backup protocol
Matthieu, This is good information that narrows the scope of the problem. I will check it and get back to you shortly. Thanks! Hongwei -Original Message- From: Matthieu Patou [mailto:m...@samba.org] Sent: Wednesday, September 22, 2010 1:26 PM To: Sebastian Canevari Cc: cifs-proto...@samba.org; Interoperability Documentation Help; Darryl Welch; Hongwei Sun Subject: Re: backup protocol Hi Sebastian, I made more investigation this night and after realizing that the guid of the certificate was stored in reverse order in different fields like serialNumber field in the certificate I tried to give a try and reverse the bytes of the blob before trying to decrypt it. And it turns out that I managed to uncrypt the blob when doing so (please see the file secret.cr.decrypted that really looks like an encrypted_secret version 2 struct). I also attached the permuted version of the blob. Can you check and told me if the documentation should state that the encrypted_struct should be reverted. I also think that the documentation should in the behavior notes states that the serialNumber contains the guid of the certificate but in reverse byte order. Regards. Matthieu. On 22/09/2010 20:34, Sebastian Canevari wrote: Thanks Matthieu! Someone from my team will get in touch with you shortly. Thanks and regards, Sebastian Sebastian Canevari Escalation Engineer, US-CSS DSC PROTOCOL TEAM 7100 N Hwy 161, Irving, TX - 75039 Las Colinas - LC2 Tel: +1 469 775 7849 e-mail: seba...@microsoft.com -Original Message- From: Matthieu Patou [mailto:m...@samba.org] Sent: Tuesday, September 21, 2010 8:56 PM To: cifs-proto...@samba.org; Interoperability Documentation Help Cc: Darryl Welch Subject: backup protocol Hello dochelp, I would like to have some confirmation on backup protocol, here is the dump as the samba server will receive it from a windows client to unwrap a secret. ./bin/ndrdump backupkey bkrp_BackupKey_debug in ~/workspace/samba/tcpdump/bkrp/bkrp_in pull returned NT_STATUS_OK WARNING! 52 unread bytes [] 8A E3 13 71 02 F4 36 71 02 40 28 00 30 7C DE 3D ...q..6q .@(.0|.= [0010] 5D 16 D1 11 AB 8F 00 80 5F 14 DB 40 01 00 00 00 ]... _...@ [0020] 04 5D 88 8A EB 1C C9 11 9F E8 08 00 2B 10 48 60 .].. +.H` [0030] 02 00 00 00 bkrp_BackupKey_debug: struct bkrp_BackupKey in: struct bkrp_BackupKey guidActionAgent : * guidActionAgent : 47270c64-2fc7-499b-ac5b-0e37cdce899a data_in : * data_in: struct bkrp_client_side_wrapped version : 0x0002 (2) encrypted_secret_len : 0x0100 (256) access_check_len : 0x0058 (88) guid : a1dc8bbd-743f-473e-8d00-0a4742df76bd encrypted_secret: ARRAY(256) [0] : 0x30 (48) [1] : 0xe5 (229) [2] : 0x9a (154) [3] : 0x15 (21) [4] : 0x1b (27) [5] : 0x59 (89) [6] : 0xb8 (184) [7] : 0x1e (30) [8] : 0xb6 (182) [9] : 0xb8 (184) [10] : 0x2a (42) [11] : 0xd0 (208) [12] : 0x9f (159) [13] : 0x30 (48) [14] : 0xaa (170) [15] : 0xb3 (179) [16] : 0x12 (18) [17] : 0x9a (154) [18] : 0x98 (152) [19] : 0x55 (85) [20] : 0x63 (99) [21] : 0xd2 (210) [22] : 0x11 (17) [23] : 0xe4 (228) [24] : 0x41 (65) [25] : 0x00 (0) [26] : 0xdb (219) [27] : 0x37 (55) [28] : 0x9c (156) [29] : 0xd9 (217
[cifs-protocol] [REG:110092263101306] RE: backup protocol
Matthieu, After checking the logic in the code, I found that Windows clients will reverse the EncryptedSecret part in the Client-Side-Wrapped_Secret structure (2.2.2 MS-BKRP). This matches what you have found. I will file a request to have it confirmed and updated into the document. As of the GUID field in Client-Side-Wrapped_Secret structure, it is not in reverse byte order. As documented in item 10 of client-side wrapping logic in 3.2.4.1 MS-BKRP: 10. Copy the GUID of the server public key to guidKey. This value MUST be retrieved from the SubjectUniqueID field of the server's ClientWrap public key certificate, as specified in [X509] section 2.2.1 It is clear that the GUID is copied from SubjectUniqueID in a certificate , not SerialNumber in a certificate. This is also confirmed by code review. Please verify this against the public key certificate you are using. Please let me know if you have any further questions. Thanks! Hongwei -Original Message- From: Matthieu Patou [mailto:m...@samba.org] Sent: Wednesday, September 22, 2010 1:26 PM To: Sebastian Canevari Cc: cifs-proto...@samba.org; Interoperability Documentation Help; Darryl Welch; Hongwei Sun Subject: Re: backup protocol Hi Sebastian, I made more investigation this night and after realizing that the guid of the certificate was stored in reverse order in different fields like serialNumber field in the certificate I tried to give a try and reverse the bytes of the blob before trying to decrypt it. And it turns out that I managed to uncrypt the blob when doing so (please see the file secret.cr.decrypted that really looks like an encrypted_secret version 2 struct). I also attached the permuted version of the blob. Can you check and told me if the documentation should state that the encrypted_struct should be reverted. I also think that the documentation should in the behavior notes states that the serialNumber contains the guid of the certificate but in reverse byte order. Regards. Matthieu. On 22/09/2010 20:34, Sebastian Canevari wrote: Thanks Matthieu! Someone from my team will get in touch with you shortly. Thanks and regards, Sebastian Sebastian Canevari Escalation Engineer, US-CSS DSC PROTOCOL TEAM 7100 N Hwy 161, Irving, TX - 75039 Las Colinas - LC2 Tel: +1 469 775 7849 e-mail: seba...@microsoft.com -Original Message- From: Matthieu Patou [mailto:m...@samba.org] Sent: Tuesday, September 21, 2010 8:56 PM To: cifs-proto...@samba.org; Interoperability Documentation Help Cc: Darryl Welch Subject: backup protocol Hello dochelp, I would like to have some confirmation on backup protocol, here is the dump as the samba server will receive it from a windows client to unwrap a secret. ./bin/ndrdump backupkey bkrp_BackupKey_debug in ~/workspace/samba/tcpdump/bkrp/bkrp_in pull returned NT_STATUS_OK WARNING! 52 unread bytes [] 8A E3 13 71 02 F4 36 71 02 40 28 00 30 7C DE 3D ...q..6q .@(.0|.= [0010] 5D 16 D1 11 AB 8F 00 80 5F 14 DB 40 01 00 00 00 ]... _...@ [0020] 04 5D 88 8A EB 1C C9 11 9F E8 08 00 2B 10 48 60 .].. +.H` [0030] 02 00 00 00 bkrp_BackupKey_debug: struct bkrp_BackupKey in: struct bkrp_BackupKey guidActionAgent : * guidActionAgent : 47270c64-2fc7-499b-ac5b-0e37cdce899a data_in : * data_in: struct bkrp_client_side_wrapped version : 0x0002 (2) encrypted_secret_len : 0x0100 (256) access_check_len : 0x0058 (88) guid : a1dc8bbd-743f-473e-8d00-0a4742df76bd encrypted_secret: ARRAY(256) [0] : 0x30 (48) [1] : 0xe5 (229) [2] : 0x9a (154) [3] : 0x15 (21) [4] : 0x1b (27) [5] : 0x59 (89) [6] : 0xb8 (184) [7] : 0x1e (30) [8] : 0xb6 (182) [9] : 0xb8 (184) [10] : 0x2a (42) [11] : 0xd0 (208) [12] : 0x9f (159) [13] : 0x30 (48) [14] : 0xaa (170) [15] : 0xb3 (179) [16] : 0x12 (18
Re: [cifs-protocol] [REG:110092263101306] RE: backup protocol
Matthieu, What I meant is that the guidGUID field in client-side-wrapped-secret structure is only dependent on the SubjectUniqueID field in the public key certificate received from server. Actually the document states that all other fields (and extensions, if any) of the certificate are populated in implementation-specific ways and SHOULD be ignored by the client, but MS-BKRP still shows how these other fields are populated by the server in the Windows behavior note 5. I also took a look at the certificate you attached with your e-mail, I got the following output using certutil: X509 Certificate: Version: 3 Serial Number: bd76df42470a008d473e743fa1dc8bbd Subject Unique Id: bd 8b dc a1 3f 74 3e 47 8d 00 0a 47 42 df 76 bd ?tG...GB.v. We can see that SerialNumber and SubjectUniqueID are in reversed order. Does this mean that the SubjectUniqueID is in the same order as the GUID of certificate in AD as you refer to ? By the way, What is the GUID of certificate in AD ? As I know, there is no GUID field in a X.509 certificate. The RSA key pairs are saved in a LSA global secret named G$BCKUPKEY_guid on DC. Is this the guid you are referring to ? If the certificate you attached is received from a Windows server, we may need to update the Windows Behavior note 5 to state that SerialNumber and subjectUnique Id is in reversed order, instead of identical. Please confirm so I can follow up with a document update request. Hopefully this should not affect interoperability. Thanks! Hongwei -Original Message- From: Matthieu Patou [mailto:m...@samba.org] Sent: Wednesday, September 22, 2010 9:46 PM To: Hongwei Sun Cc: Sebastian Canevari; cifs-proto...@samba.org; Darryl Welch; MSSolve Case Email Subject: Re: [REG:110092263101306] RE: backup protocol On 23/09/2010 03:27, Hongwei Sun wrote: Matthieu, After checking the logic in the code, I found that Windows clients will reverse the EncryptedSecret part in the Client-Side-Wrapped_Secret structure (2.2.2 MS-BKRP). This matches what you have found. I will file a request to have it confirmed and updated into the document. Thanks. As of the GUID field in Client-Side-Wrapped_Secret structure, it is not in reverse byte order. As documented in item 10 of client-side wrapping logic in 3.2.4.1 MS-BKRP: 10. Copy the GUID of the server public key to guidKey. This value MUST be retrieved from the SubjectUniqueID field of the server's ClientWrap public key certificate, as specified in [X509] section 2.2.1 It is clear that the GUID is copied from SubjectUniqueID in a certificate , not SerialNumber in a certificate. This is also confirmed by code review. Please verify this against the public key certificate you are using. In section Product behavior we have this note: 5 Section 2.2.1: ... The serialNumber field is identical to the subjectUniqueID field. ... Furthermore if you have a look at the certificate in DER format that I attached to my first email you'll find that the serialNumber is popultated with a 16 bytes array that once reverted is the GUID of the certificate in the AD. Matthieu. Please let me know if you have any further questions. Thanks! Hongwei -Original Message- From: Matthieu Patou [mailto:m...@samba.org] Sent: Wednesday, September 22, 2010 1:26 PM To: Sebastian Canevari Cc: cifs-proto...@samba.org; Interoperability Documentation Help; Darryl Welch; Hongwei Sun Subject: Re: backup protocol Hi Sebastian, I made more investigation this night and after realizing that the guid of the certificate was stored in reverse order in different fields like serialNumber field in the certificate I tried to give a try and reverse the bytes of the blob before trying to decrypt it. And it turns out that I managed to uncrypt the blob when doing so (please see the file secret.cr.decrypted that really looks like an encrypted_secret version 2 struct). I also attached the permuted version of the blob. Can you check and told me if the documentation should state that the encrypted_struct should be reverted. I also think that the documentation should in the behavior notes states that the serialNumber contains the guid of the certificate but in reverse byte order. Regards. Matthieu. On 22/09/2010 20:34, Sebastian Canevari wrote: Thanks Matthieu! Someone from my team will get in touch with you shortly. Thanks and regards, Sebastian Sebastian Canevari Escalation Engineer, US-CSS DSC PROTOCOL TEAM 7100 N Hwy 161, Irving, TX - 75039 Las Colinas - LC2 Tel: +1 469 775 7849 e-mail: seba...@microsoft.com -Original Message- From: Matthieu Patou [mailto:m...@samba.org] Sent: Tuesday, September 21, 2010 8:56 PM To: cifs-proto...@samba.org; Interoperability Documentation Help Cc: Darryl Welch Subject: backup protocol Hello dochelp
Re: [cifs-protocol] [REG:110091558099846] RE: Incompleteness in MS-SAMR section 3.1.1.8.1 objectClass
Matthias,
This seems a new issue even it is in the same section of the document. We
will create a new case to keep track it. If there is a new issue in our
communication in the future , please also copy docHelp, which is monitored by
our team, so it will not be missed in case I am out of office or so.
As of this issue, could you give a little more description about the
blackbox test which reproduces the behavior ?
Thanks!
Hongwei
-Original Message-
From: Matthias Dieter Wallnöfer [mailto:m...@samba.org]
Sent: Monday, October 11, 2010 11:29 AM
To: Hongwei Sun
Cc: cifs-proto...@samba.org; MSSolve Case Email
Subject: Re: [REG:110091558099846] RE: Incompleteness in MS-SAMR section
3.1.1.8.1 objectClass
Hongwei,
I think I've found another issue: always MS-SAMR 3.1.1.8.1 objectClass
trigger - this time item 1.5.
Windows doesn't seem to add always UF_PASSWD_NOT_REQD when objects using
UF_WORKSTATION_TRUST_ACCOUNT are created. We've a blackbox test which
reproduces this. Probably there is some explaination missing; that means
under which cases PASSWD_NOT_REQD is added.
Greets,
Matthias
Hongwei Sun wrote:
Matthias,
Following up on this documentation update, I attached the changes made to
the MS-ADTS and MS-DRSR.
BEFORE ---
3.1.1.3.2.41 tokenGroups
Returns the SIDs contained in the security context as which the client has
authenticated the LDAP connection. See section 5.1.3.
AFTER ---
3.1.1.3.2.41 tokenGroups
Returns the SIDs contained in the security context as which the client has
authenticated the LDAP connection. Refer to section 5.1.3 for details on LDAP
Authorization. Refer to section 3.1.1.4.5.19 for details on the algorithm
used to compute this attribute.
BEFORE ---
3.1.1.4.9.6 DomainOf
procedure DomainOf(o: DSName): DSName
This procedure returns the DSName of the domain NC to which the given DSName
o belongs. It returns null upon failure.
3.1.1.4.9.7 GetDSNameFromPrimaryGroupId
procedure GetDSNameFromPrimaryGroupId(rid: Rid): DSName
This procedure constructs a SID s consisting of the domain SID of the DC's
default domain and the given relative identifier (RID) rid, and returns the
DSName of the object o for which o!objectSid = s. If no such object o exists,
then this procedure will return null.
AFTER ---
3.1.1.4.9.6 DomainOf
procedure DomainOf(o: DSName): DSName
This procedure returns the DSName of the domain NC to which the given DSName
o belongs. It returns null upon failure.
content added
3.1.1.4.9.7 GetDSNameOfEnterpriseRODCsGroup
procedure GetDSNameOfEnterpriseReadonlyDomainControllerGroup(): DSName
This procedure constructs a SID s consisting of the domain SID of the root
domain and the relative identifier (RID) of the Enterprise Read-only Domain
Controllers Group (as defined in section 7.1.1.6.14), and returns the DSName
of the object o for which o! objectSid = s. If no such object o exists, this
procedure returns null.
3.1.1.4.9.8 GetDSNameFromPrimaryGroupId
procedure GetDSNameFromPrimaryGroupId(rid: Rid): DSName
This procedure constructs a SID s consisting of the domain SID of the DC's
default domain and the given relative identifier (RID) rid, and returns the
DSName of the object o for which o!objectSid = s. If no such object o exists,
then this procedure will return null.
BEFORE ---
3.1.1.4.9.10 GetMemberships Method
. . .
In the following pseudocode, the SID type is specified in [MS-DRDM] section
5.126, the IsGC procedure is specified in [MS-DRDM] section 5.67, and the
DefaultNC procedure is specified in [MS-DRDM] section 5.20.
. . .
/* Get the initial result set from the graph. */
wSet := {}
for i := 0 to msgIn.ppDsNames.cDsNames - 1
u := msgIn.ppDsNames[i]
if u in vSet then
/* Get the subgraph by applying the predicate IsMatchedGroup
* on each element in the vertex set, plus u itself. */
uSet := {u} + select all v from vSet where
IsMatchedGroup(v, op, msgIn.pLimitingDomain^)
if transitive then
wSet := wSet + (Closure(uSet, aSet, u) - {u})
else
wSet := wSet + (Neighbors(uSet, aSet, u) - {u})
endif
endif
endfor
. . .
AFTER ---
3.1.1.4.9.11 GetMemberships Method
. . .
In the following pseudocode, the ADS_UF_WORKSTATION_TRUST_ACCOUNT and
ADS_UF_PARTIAL_SECRETS_ACCOUNT flags are specified in section 2.2.15, the
userAccountControl attribute is specified in [MS-ADA3] section 2.341, the SID
type is specified in [MS-DRDM] section 5.126, the IsGC procedure is specified
in [MS-DRDM] section 5.67, and the DefaultNC procedure is specified in
[MS-DRDM] section 5.20.
. . .
/* Get the initial result set from the graph. */
wSet := {}
for i := 0 to msgIn.ppDsNames.cDsNames - 1
u := msgIn.ppDsNames[i]
if u in vSet then
/* Get the subgraph by applying the predicate IsMatchedGroup
* on each element in the vertex set, plus u itself. */
uSet := {u
Re: [cifs-protocol] Please include bitfield names in MS-NRPC LogonParameters
Andrew, One of our team member will work on this case and let you know when the investigation is done. Thanks! Hongwei -Original Message- From: cifs-protocol-boun...@cifs.org [mailto:cifs-protocol-boun...@cifs.org] On Behalf Of Andrew Bartlett Sent: Thursday, November 04, 2010 4:03 PM To: Interoperability Documentation Help Cc: cifs-proto...@samba.org Subject: [cifs-protocol] Please include bitfield names in MS-NRPC LogonParameters In 2.2.1.4.15 NETLOGON_LOGON_IDENTITY_INFO we have the description of LogonParameters. These values have well-known names, see http://msdn.microsoft.com/en-us/library/aa378767%28VS.85%29.aspx Can you please include these names an in particular the associated values in the WSPP docs, so that we can find the documentation without manually parsing the bit-field? Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] [REG:110120936517934] RE: Please describe MS-LSAD 2.2.4.19 AuthenticationOptions
Andrew, There is only one bit defined for this value. That is bit POLICY_KERBEROS_VALIDATE_CLIENT (0x0080). All other bits SHOULD be set to 0 and ignored upon receipt. I will file a request to add the actual hex value to POLICY_KERBEROS_VALIDATE_CLIENT. Thanks! Hongwei -Original Message- From: Andrew Bartlett [mailto:abart...@samba.org] Sent: Wednesday, December 08, 2010 8:38 PM To: Interoperability Documentation Help Cc: cifs-proto...@samba.org Subject: Re: [cifs-protocol] Please describe MS-LSAD 2.2.4.19 AuthenticationOptions On Thu, 2010-12-09 at 13:35 +1100, Andrew Bartlett wrote: On Thu, 2010-12-09 at 12:09 +1100, Andrew Bartlett wrote: MS-LSAD 2.2.4.19 states: AuthenticationOptions: Optional flags that affect validations performed during authentication. What are these optional flags, where and how are they stored, and what do they do? I was put off by the document formatting. All the information I need is there and in MS-KILE. ...almost all. I need the actual value for the bitfield. Can you please include the constant value in hexadecimal for POLICY_KERBEROS_VALIDATE_CLIENT I presume it is 0x0080. Thanks. -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [Pfif] [REG:110011477385004] RE: userParameters attribute
Andrew, The request opened is still pending. I will follow up with the corresponding product teams. I will keep you posted. Thanks! Hongwei -Original Message- From: Andrew Bartlett [mailto:abart...@samba.org] Sent: Sunday, May 22, 2011 10:50 PM To: Hongwei Sun Cc: p...@tridgell.net; cifs-proto...@samba.org; Obaid Farooqi; MSSolve Case Email; Michael Ströder Subject: Re: [Pfif] [cifs-protocol] [REG:110011477385004] RE: userParameters attribute On Mon, 2010-06-21 at 22:54 +, Hongwei Sun wrote: Andrew, Sorry about the delay to give you a confirmation. We have been spending time to review the usage of UserParameters in other Windows components based on the information you provided. We found that this attribute is indeed still used by at least one other Microsoft product, such as RAS Server. The related product team is working on this to find how to document it. During my vacation, I will ask one of my team member (Obaid) to monitor the progress and send you the update when it is available. Out of pure curiosity, did this ever turn into documentation? Andrew Bartlett -- Andrew Bartletthttp://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
