Re: [cifs-protocol] Status: SRX091220600031 [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes usage
Hello again Matthieu - here are my follow ups to the unanswered questions. == Unanswered Question 1 == Sorry I don't really understand the change introduced, can you be just more clear and just say that there is a link between msDS-SupportedEncryptionTypes and SupportedEncTypes, as the first one is updated by the capable workstation upon reception of an incorrect value in the second one. Response: I have added your suggestion to the TDI against [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes (http://msdn.microsoft.com/en-us/library/cc223853(PROT.13).aspx). References: msDS-SupportedEncryptionTypes [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes http://msdn.microsoft.com/en-us/library/cc223853(PROT.13).aspx SupportedEncTypes [MS-NRPC] 3.5.5.3.9 NetrLogonGetDomainInfo (Opnum 29) http://msdn.microsoft.com/en-us/library/cc237247(PROT.13).aspx [MS-NRPC] 2.2.1.3.11 NETLOGON_DOMAIN_INFO http://msdn.microsoft.com/en-us/library/cc237052(PROT.13).aspx == Unanswered Question 2 == Also one last question: the very first time the SupportedEncTypes is returned, if the DC has no information about the workstation, what should be returned? 0x00 or 0xFF or something else. Response: As you have noted, NetrLogonGetDomainInfo behavior on this point is not documented (and a debug would be necessary for me to dig into actual behavior, since the calls are encrypted). Please confirm (or update) the accuracy of my rewording reflects you needs properly. Also, please advise me how this impacts your implementation - is that blocking work? I expect to create a new case and TDI for this, once you respond. References: [MS-NRPC] 3.5.5.3.9 NetrLogonGetDomainInfo (Opnum 29) http://msdn.microsoft.com/en-us/library/cc237247(PROT.13).aspx [MS-NRPC] 2.2.1.3.11 NETLOGON_DOMAIN_INFO http://msdn.microsoft.com/en-us/library/cc237052(PROT.13).aspx 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 -Original Message- From: Bill Wesse Sent: Monday, January 11, 2010 1:46 PM To: 'Matthieu Patou' Cc: cifs-proto...@samba.org; p...@tridgell.net; Sebastian Canevari Subject: RE: Status: SRX091220600031 [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes usage Good afternoon Matthieu - holidays are good! I've attached a pdf with some changes I am proposing to Sebastian concerning updates to the blog entry. Also, I have (hopefully adequate) answers to your first two questions (I will be working on the last ones about the doc cross-refs & NETLOGON_DOMAIN_INFO, as I have some diligence to do on NETLOGON_DOMAIN_INFO). == Unanswered questions == Sorry I don't really understand the change introduced, can you be just more clear and just say that there is a link between ms-SupportedEncryptionTypes and SupportedEncTypes as the first one is updated by the capable workstation upon reception of an incorrect value in the second one. Also one last question: the very first time the SupportedEncTypes is returned as the DC as no information about the workstation what should be returned ? 0x00 of 0xFF or something else. == Answers... == Question 1 == First this page "http://blogs.msdn.com/openspecification/archive/2009/09/12/msds-supportedencryptiontypes-episode-1-computer-accounts.aspx"; still state "Although this attribute is present in all the computer objects of the domain regardless of the version of the OS the physical machines have installed, not all of them are aware of its existence hence, older versions (2003 and earlier) do not populate it at any time." even if you just said that this added by some version (vista/w2k8 and higher) will it be updated ? Also you are basically saying that having ADS_UF_USE_DES_KEY_ONLY don't make any difference because the content of msDS-SupportedEncryptionTypes will not present for everything up to XP/w2k3r2, then 1F for vista/w2k8 then 1C for w7/w2k8r2. == Response 1 == I have attached an update to the blog (also as a change proposal to Sebastian), which removes that 'attribu
Re: [cifs-protocol] LDAP_SERVER_SD_FLAGS_OID control and search request
Yeah it's good, On 12/01/2010 21:18, Sebastian Canevari wrote: Hi Matthieu, I do not know if you have already seen these messages since I have received a reply from the server stating that they could not be delivered to mat+informatique. Please let me know if you have received the emails and if you think that they cover your question. Thanks! Sebastian Sebastian Canevari Senior Support 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: Sebastian Canevari Sent: Thursday, January 07, 2010 2:18 PM To: 'Matthieu Patou' Cc: 'cifs-proto...@samba.org'; 'p...@tridgell.net' Subject: RE: LDAP_SERVER_SD_FLAGS_OID control and search request Here goes again, I've gotten a Delayed delivery notice. Sebastian Canevari Senior Support 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: Sebastian Canevari Sent: Wednesday, January 06, 2010 3:32 PM To: 'Matthieu Patou' Cc: cifs-proto...@samba.org; p...@tridgell.net Subject: RE: LDAP_SERVER_SD_FLAGS_OID control and search request Hi Matthieu, The ADTS document will include changes in its section 7.1.3.2 SD Flags Control. This is the new text for the section: 7.1.3.2 SD Flags Control When performing an LDAP operation (add, modify or search), the client may supply an SD flags control LDAP_SERVER_SD_FLAGS_OID (section 3.1.1.3.4.1.11) with the operation. The value of the control is an integer, which is used to identify which security descriptor (SD) parts the client intends to read or modify. When the control is not specified, then the default value of 15 (0x000F) is used. The SD parts are identified using the following bit values: OWNER_SECURITY_INFORMATION, GROUP_SECURITY_INFORMATION, DACL_SECURITY_INFORMATION, SACL_SECURITY_INFORMATION, which correspond to OWNER, GROUP, DACL and SACL SD fields, respectively. If the LDAP_SERVER_SD_FLAGS_OID control is present in an LDAP search request, the server returns an SD with the parts specified in the control when the SD attribute name is explicitly mentioned in the requested attribute list, or the requested attribute list is empty, or the requested attribute list contains an asterisk(*). Without the presence of this control, the server returns an SD only when the SD attribute name is explicitly mentioned in the requested attribute list. For update operations, the bits identify which SD parts are affected by the operation. Note that the client may supply values for other (or all) SD fields. However, the server only updates the fields that are identified by the SD control. The remaining fields are ignored. The wording may vary slightly. Please let me know if this addresses your request. Thanks and regards, Sebastian Sebastian Canevari Senior Support 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:mat+informatique.sa...@matws.net] Sent: Saturday, December 19, 2009 3:43 AM To: Sebastian Canevari Cc: cifs-proto...@samba.org; p...@tridgell.net Subject: Re: LDAP_SERVER_SD_FLAGS_OID control and search request Hi Sebastian, Hi Matthieu, If I have understood your question correctly, the answer for it can be found in section 3.1.1.3.4.1.11 LDAP_SERVER_SD_FLAGS_OID of MS-ADTS. The version online, already has this information on the section (http://msdn.microsoft.com/en-us/library/cc223323(PROT.10).aspx ). Please let me know if this addresses your question or if I have misunderstood your request. I read this page, maybe it's implicit that if this control is specified then the nTSecurityDescriptor must be returned with requested parts (accordingly to what has been requested) even if the this attribute has not been requested explicitly in the attribute list. If so can you state it clearly, because as far as I understand (and see) nTSecurityDescriptor is not returned by default if you do not explicitly request it. Matthieu. Thanks and regards, Sebastian Canevari Senior Support 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: Sebastian Canevari Sent: Friday, December 18, 2009 1:55 PM To: Matthieu Patou; cifs-proto...@samba.org; Interoperability Documentation Help; p...@tridgell.net Subject: RE: LDAP_SERVER_SD_FLAGS_OID control and search request Hi Matthieu, I'll be helping you with this issue. Thanks and regards, Sebastian Canevari Senior Support 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 -
Re: [cifs-protocol] Status: SRX091220600031 [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes usage
Hi bill, It seems quite ok ! About question2 what we see is mostly 0xFF on server supporting this attribute (w2k8 and upper). Also as a tip for decoding encrypted with schannel you can use dev version of wireshark, we wrote some patch to decode this kind of traffic. Of course you will need keytab with passwords of workstation for decoding. This can be obtain with the net vampire of samba3 ! Matthieu. On 12/01/2010 18:38, Bill Wesse wrote: Hello again Matthieu - here are my follow ups to the unanswered questions. == Unanswered Question 1 == Sorry I don't really understand the change introduced, can you be just more clear and just say that there is a link between msDS-SupportedEncryptionTypes and SupportedEncTypes, as the first one is updated by the capable workstation upon reception of an incorrect value in the second one. Response: I have added your suggestion to the TDI against [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes (http://msdn.microsoft.com/en-us/library/cc223853(PROT.13).aspx). References: msDS-SupportedEncryptionTypes [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes http://msdn.microsoft.com/en-us/library/cc223853(PROT.13).aspx SupportedEncTypes [MS-NRPC] 3.5.5.3.9 NetrLogonGetDomainInfo (Opnum 29) http://msdn.microsoft.com/en-us/library/cc237247(PROT.13).aspx [MS-NRPC] 2.2.1.3.11 NETLOGON_DOMAIN_INFO http://msdn.microsoft.com/en-us/library/cc237052(PROT.13).aspx == Unanswered Question 2 == Also one last question: the very first time the SupportedEncTypes is returned, if the DC has no information about the workstation, what should be returned? 0x00 or 0xFF or something else. Response: As you have noted, NetrLogonGetDomainInfo behavior on this point is not documented (and a debug would be necessary for me to dig into actual behavior, since the calls are encrypted). Please confirm (or update) the accuracy of my rewording reflects you needs properly. Also, please advise me how this impacts your implementation - is that blocking work? I expect to create a new case and TDI for this, once you respond. References: [MS-NRPC] 3.5.5.3.9 NetrLogonGetDomainInfo (Opnum 29) http://msdn.microsoft.com/en-us/library/cc237247(PROT.13).aspx [MS-NRPC] 2.2.1.3.11 NETLOGON_DOMAIN_INFO http://msdn.microsoft.com/en-us/library/cc237052(PROT.13).aspx 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 -Original Message- From: Bill Wesse Sent: Monday, January 11, 2010 1:46 PM To: 'Matthieu Patou' Cc: cifs-proto...@samba.org; p...@tridgell.net; Sebastian Canevari Subject: RE: Status: SRX091220600031 [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes usage Good afternoon Matthieu - holidays are good! I've attached a pdf with some changes I am proposing to Sebastian concerning updates to the blog entry. Also, I have (hopefully adequate) answers to your first two questions (I will be working on the last ones about the doc cross-refs& NETLOGON_DOMAIN_INFO, as I have some diligence to do on NETLOGON_DOMAIN_INFO). == Unanswered questions == Sorry I don't really understand the change introduced, can you be just more clear and just say that there is a link between ms-SupportedEncryptionTypes and SupportedEncTypes as the first one is updated by the capable workstation upon reception of an incorrect value in the second one. Also one last question: the very first time the SupportedEncTypes is returned as the DC as no information about the workstation what should be returned ? 0x00 of 0xFF or something else. == Answers... == Question 1 == First this page "http://blogs.msdn.com/openspecification/archive/2009/09/12/msds-supportedencryptiontypes-episode-1-computer-accounts.aspx"; still state "Although this attribute is present in all the computer objects of the domain regardless of the version of the OS the physical machines have installed, not all of them are aware of its existence hence, older versions (2003 and earlier) do not populate it at any time." even if you just said that this added by some version (vista/w2k8 and higher) will it be updated ? Also you are basically saying that having ADS_UF_USE_DES_KEY_ONLY d
Re: [cifs-protocol] Status: SRX091220600031 [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes usage
Thanks Matthieu - I will create the new case for the below...(I'm just lazy about Wireshark/keytab, I guess). Could you advise me on how this impacts your implementation progess (this is important for the TDI priority)? Also, I agree NETLOGON_DOMAIN_INFO.SupportedEncTypes returned from (Windows 2008 R2) NetrLogonGetDomainInfo as 0x (a.k.a. (ULONG)-1) is not documented. I think this should indicate to the client that an update to SupportedEncTypes is needed. Also note that an incoming value of 0 also means a client is pre-Vista (Windows), and/or is ignorant of the msDS-SupportedEncryptionTypes attribute. That, of course, will be the gist of what will go into the TDI for the new case. > == > Unanswered Question 2 > == > > Also one last question: the very first time the SupportedEncTypes is > returned, if the DC has no information about the workstation, what should be > returned? 0x00 or 0xFF or something else. > > Response: > > As you have noted, NetrLogonGetDomainInfo behavior on this point is not > documented (and a debug would be necessary for me to dig into actual > behavior, since the calls are encrypted). > > Please confirm (or update) the accuracy of my rewording reflects you needs > properly. Also, please advise me how this impacts your implementation - is > that blocking work? I expect to create a new case and TDI for this, once you > respond. > > References: > > [MS-NRPC] 3.5.5.3.9 NetrLogonGetDomainInfo (Opnum 29) > http://msdn.microsoft.com/en-us/library/cc237247(PROT.13).aspx > > [MS-NRPC] 2.2.1.3.11 NETLOGON_DOMAIN_INFO > http://msdn.microsoft.com/en-us/library/cc237052(PROT.13).aspx > 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 -Original Message- From: Matthieu Patou [mailto:mat+informatique.sa...@matws.net] Sent: Tuesday, January 12, 2010 2:08 PM To: Bill Wesse Cc: cifs-proto...@samba.org; p...@tridgell.net; Sebastian Canevari Subject: Re: Status: SRX091220600031 [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes usage Hi bill, It seems quite ok ! About question2 what we see is mostly 0xFF on server supporting this attribute (w2k8 and upper). Also as a tip for decoding encrypted with schannel you can use dev version of wireshark, we wrote some patch to decode this kind of traffic. Of course you will need keytab with passwords of workstation for decoding. This can be obtain with the net vampire of samba3 ! Matthieu. On 12/01/2010 18:38, Bill Wesse wrote: > Hello again Matthieu - here are my follow ups to the unanswered questions. > > == > Unanswered Question 1 > == > Sorry I don't really understand the change introduced, can you be just more > clear and just say that there is a link between msDS-SupportedEncryptionTypes > and SupportedEncTypes, as the first one is updated by the capable workstation > upon reception of an incorrect value in the second one. > > Response: > > I have added your suggestion to the TDI against [MS-ADTS] 7.1.6.7.3 > msDs-supportedEncryptionTypes > (http://msdn.microsoft.com/en-us/library/cc223853(PROT.13).aspx). > > References: > > msDS-SupportedEncryptionTypes > [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes > http://msdn.microsoft.com/en-us/library/cc223853(PROT.13).aspx > > SupportedEncTypes > [MS-NRPC] 3.5.5.3.9 NetrLogonGetDomainInfo (Opnum 29) > http://msdn.microsoft.com/en-us/library/cc237247(PROT.13).aspx > > [MS-NRPC] 2.2.1.3.11 NETLOGON_DOMAIN_INFO > http://msdn.microsoft.com/en-us/library/cc237052(PROT.13).aspx > > == > Unanswered Question 2 > == > > Also one last question: the very first time the SupportedEncTypes is > returned, if the DC has no information about the workstation, what should be > returned? 0x00 or 0xFF or something else. > > Response: > > As you have noted, NetrLogonGetDomainInfo behavior on this point is not > documented (and a debug would be necessary for me to dig into actual > behavior, since the calls are encrypted). > > Please confirm (or update) the accuracy of my rewording reflects you needs > properly. Also, please advise me how this impacts your implementation - is > that blocking work? I expect to create a new case and TDI for this, once you > respond. > > References: > > [MS-NRPC] 3.5.5.3.9 NetrLogonGetDomainInfo (Opnum 29) > http://msdn.microsoft.com/en-us/library/cc237247(PROT.13).aspx > > [MS-NRPC] 2.2.1.3.11 NETLOGON_DOMAIN_INFO > http:/
Re: [cifs-protocol] Status: SRX091220600031 [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes usage
On 12/01/2010 23:47, Bill Wesse wrote: Thanks Matthieu - I will create the new case for the below...(I'm just lazy about Wireshark/keytab, I guess). Could you advise me on how this impacts your implementation progess (this is important for the TDI priority)? In fact we had at the begining (september 2009) a default "sensible" value that was DES_CBC_CRC | DES_CBC_MD5 | RC4_HMAC_MD5 when we didn't have any information. But it seems that it caused pb when a w2k8 server made a dcpromo to a S4 domain. so now we return 0x. But we wanted to settle on which was the good value and to know if had any idea that this behavior will change anytime soon ! Also, I agree NETLOGON_DOMAIN_INFO.SupportedEncTypes returned from (Windows 2008 R2) NetrLogonGetDomainInfo as 0x (a.k.a. (ULONG)-1) is not documented. I think this should indicate to the client that an update to SupportedEncTypes is needed. it seems to do its job as w2k8 at least send just after a ldap request for modifying the msDS-SupportedEncryptionTypes. Also note that an incoming value of 0 also means a client is pre-Vista (Windows), and/or is ignorant of the msDS-SupportedEncryptionTypes attribute. That, of course, will be the gist of what will go into the TDI for the new case. Regards. Matthieu. == Unanswered Question 2 == Also one last question: the very first time the SupportedEncTypes is returned, if the DC has no information about the workstation, what should be returned? 0x00 or 0xFF or something else. Response: As you have noted, NetrLogonGetDomainInfo behavior on this point is not documented (and a debug would be necessary for me to dig into actual behavior, since the calls are encrypted). Please confirm (or update) the accuracy of my rewording reflects you needs properly. Also, please advise me how this impacts your implementation - is that blocking work? I expect to create a new case and TDI for this, once you respond. References: [MS-NRPC] 3.5.5.3.9 NetrLogonGetDomainInfo (Opnum 29) http://msdn.microsoft.com/en-us/library/cc237247(PROT.13).aspx [MS-NRPC] 2.2.1.3.11 NETLOGON_DOMAIN_INFO http://msdn.microsoft.com/en-us/library/cc237052(PROT.13).aspx 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 -Original Message- From: Matthieu Patou [mailto:mat+informatique.sa...@matws.net] Sent: Tuesday, January 12, 2010 2:08 PM To: Bill Wesse Cc: cifs-proto...@samba.org; p...@tridgell.net; Sebastian Canevari Subject: Re: Status: SRX091220600031 [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes usage Hi bill, It seems quite ok ! About question2 what we see is mostly 0xFF on server supporting this attribute (w2k8 and upper). Also as a tip for decoding encrypted with schannel you can use dev version of wireshark, we wrote some patch to decode this kind of traffic. Of course you will need keytab with passwords of workstation for decoding. This can be obtain with the net vampire of samba3 ! Matthieu. On 12/01/2010 18:38, Bill Wesse wrote: Hello again Matthieu - here are my follow ups to the unanswered questions. == Unanswered Question 1 == Sorry I don't really understand the change introduced, can you be just more clear and just say that there is a link between msDS-SupportedEncryptionTypes and SupportedEncTypes, as the first one is updated by the capable workstation upon reception of an incorrect value in the second one. Response: I have added your suggestion to the TDI against [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes (http://msdn.microsoft.com/en-us/library/cc223853(PROT.13).aspx). References: msDS-SupportedEncryptionTypes [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes http://msdn.microsoft.com/en-us/library/cc223853(PROT.13).aspx SupportedEncTypes [MS-NRPC] 3.5.5.3.9 NetrLogonGetDomainInfo (Opnum 29) http://msdn.microsoft.com/en-us/library/cc237247(PROT.13).aspx [MS-NRPC] 2.2.1.3.11 NETLOGON_DOMAIN_INFO http://msdn.microsoft.com/en-us/library/cc237052(PROT.13).aspx == Unanswered Question 2 == Also one last question: the very first time the SupportedEncTypes is returned, if the DC has no information about the workstation, what should be returned? 0x00 or 0xFF or something else. Response: As you have noted, NetrLogonGetDomainInfo behavior on this point is not documented (and a debug would be necessary for me to dig into
Re: [cifs-protocol] Status: SRX091220600031 [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes usage
For the moment, I think 0x is a workable return value, but cannot be authoritative on this (I am obliged to leave that to product development, of course). I will continue my work on this in the new case [REG:110011276087815]; I have scheduled myself for a code dive tomorrow (to see when 2008R2 does this - some client SPN registration results impact setting the return value to 0x), followed by a TDI submission. 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 -Original Message- From: Matthieu Patou [mailto:mat+informatique.sa...@matws.net] Sent: Tuesday, January 12, 2010 5:05 PM To: Bill Wesse Cc: cifs-proto...@samba.org; p...@tridgell.net Subject: Re: Status: SRX091220600031 [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes usage On 12/01/2010 23:47, Bill Wesse wrote: > Thanks Matthieu - I will create the new case for the below...(I'm just lazy > about Wireshark/keytab, I guess). > > Could you advise me on how this impacts your implementation progess (this is > important for the TDI priority)? > In fact we had at the begining (september 2009) a default "sensible" value that was DES_CBC_CRC | DES_CBC_MD5 | RC4_HMAC_MD5 when we didn't have any information. But it seems that it caused pb when a w2k8 server made a dcpromo to a S4 domain. so now we return 0x. But we wanted to settle on which was the good value and to know if had any idea that this behavior will change anytime soon ! > Also, I agree NETLOGON_DOMAIN_INFO.SupportedEncTypes returned from (Windows > 2008 R2) NetrLogonGetDomainInfo as 0x (a.k.a. (ULONG)-1) is not > documented. I think this should indicate to the client that an update to > SupportedEncTypes is needed. > > it seems to do its job as w2k8 at least send just after a ldap request for modifying the msDS-SupportedEncryptionTypes. > Also note that an incoming value of 0 also means a client is pre-Vista > (Windows), and/or is ignorant of the msDS-SupportedEncryptionTypes attribute. > That, of course, will be the gist of what will go into the TDI for the new > case. > > Regards. Matthieu. >> == >> Unanswered Question 2 >> == >> >> Also one last question: the very first time the SupportedEncTypes is >> returned, if the DC has no information about the workstation, what should be >> returned? 0x00 or 0xFF or something else. >> >> Response: >> >> As you have noted, NetrLogonGetDomainInfo behavior on this point is not >> documented (and a debug would be necessary for me to dig into actual >> behavior, since the calls are encrypted). >> >> Please confirm (or update) the accuracy of my rewording reflects you needs >> properly. Also, please advise me how this impacts your implementation - is >> that blocking work? I expect to create a new case and TDI for this, once you >> respond. >> >> References: >> >> [MS-NRPC] 3.5.5.3.9 NetrLogonGetDomainInfo (Opnum 29) >> http://msdn.microsoft.com/en-us/library/cc237247(PROT.13).aspx >> >> [MS-NRPC] 2.2.1.3.11 NETLOGON_DOMAIN_INFO >> http://msdn.microsoft.com/en-us/library/cc237052(PROT.13).aspx >> >> > 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 > > > -Original Message- > From: Matthieu Patou [mailto:mat+informatique.sa...@matws.net] > Sent: Tuesday, January 12, 2010 2:08 PM > To: Bill Wesse > Cc: cifs-proto...@samba.org; p...@tridgell.net; Sebastian Canevari > Subject: Re: Status: SRX091220600031 [MS-ADTS] 7.1.6.7.3 > msDs-supportedEncryptionTypes usage > > Hi bill, > > It seems quite ok ! > > About question2 what we see is mostly 0xFF on server supporting this > attribute (w2k8 and upper). > > Also as a tip for decoding encrypted with schannel you can use dev > version of wireshark, we wrote some patch to decode this kind of traffic. > Of course you will need keytab with passwords of workstation for > decoding. This can be obtain with the net vampire of samba3 ! > > Matthieu. > > > On 12/01/2010 18:38, Bill Wesse wrote: > >> Hello again Matthieu - here are my follow ups to the unanswered questions. >> >> == >> Unanswered Question 1 >> == >> Sorry I don't really understand the change introduced, can you be just more >> clear and just say that there is a link between >> msDS-SupportedEncryptionTypes and SupportedEncTypes, as the first one is >> updated by the capable workstation upon reception of an incorrect val
