[cifs-protocol] of SupportedEncTypes and msDS-SupportedEncryptionTypes
Hello, Back in august and september we discuss in case SRX090808600017 about supportedEncTypes and I was quite happy with your answer. I'm coming back on this subject for two details: * this blog entry (of msdn) http://blogs.msdn.com/openspecification/archive/2009/09/12/msds-supportedencryptiontypes-episode-1-computer-accounts.aspx says :" 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." It means that when I join a w2k8 domain with a XP workstation that the DC will create a computer object for this XP workstation and set the msDS-SupportedEncryptionTypes attribute ? if so to which value ? On my tests when I join a w2k3 server to a w2k8 domain the attribute SupportedEncryptionTypes is not set. Can this point be clarified and if possible written in a formal document This entry also state: " When the KDC checks the attribute to decide what encryption algorithm to use in order to encrypt the ticket, it could find basically two scenarios: 1) The attribute is populated 2) The attribute is empty If the attribute is populated, then the deal is done since the KDC can determine the best common algorithm to encrypt the ticket with the value present. However, if the attribute is empty then the KDC will have to work harder being the next step to check another attribute. This attribute is defined in MS-ADA3 (section 2.341) and described in MS-ADTS (section 2.2.15) and it’s called userAccountControl. This attribute is also a 4 byte Bit Mask that defines many aspects of the account but the only one the KDC is interested in is the DK (ADS_UF_USE_DES_KEY_ONLY ) bit. This bit defines what legacy encryption method will be used: 1) If the bit is set, then only DES will be used 2) If the bit is NOT set, then DES and RC4 can be used This check is especially relevant in domains that have Win7 and Windows Server 2008 R2 machines joined because those two newer OSs disable their bit by default so older DES is not an option for them." * What is the exact meaning of ADS_UF_USE_DES_KEY_ONLY ? if a w2k8 server acting as a domain member within a w2k8 domain has this DK bit set, will the DC not use AES but only DES with it ? * "This check is especially relevant in domains that have Win7 and Windows Server 2008 R2 machines joined because those two newer OSs disable their bit by default so older DES is not an option for them.", well it seems that a w2k3 server member of w2k8 domain do not have this bit set also (userAccountControl=4096 => only WT flag set). * Also neither MS-LSAD nor MS-NRPC talk about the link between the attribute msDS-SupportedEncryptionTypes stored in the AD and the fact that it's returned as SupportedEncTypes in NETLOGON_DOMAIN_INFO call. I can understand that it can be called "secret" of implementation but when after a workstation tries to update this attribute to let the DC know what are the supported encoding it's better to clarify the link. Thank you for help with clarifying those points. Matthieu. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] of SupportedEncTypes and msDS-SupportedEncryptionTypes
Hi Matthieu, Thanks for the follow-up questions regarding the supported encryption types blog entry from September. One of the Open Specification Documentation support team will be in touch with you shortly. Best regards, Tom Jebo Microsoft Open Specification Documentation Support -Original Message- From: Matthieu Patou [mailto:mat+informatique.sa...@matws.net] Sent: Sunday, December 20, 2009 7:01 AM To: cifs-proto...@samba.org; Interoperability Documentation Help; p...@tridgell.net Subject: of SupportedEncTypes and msDS-SupportedEncryptionTypes Hello, Back in august and september we discuss in case SRX090808600017 about supportedEncTypes and I was quite happy with your answer. I'm coming back on this subject for two details: * this blog entry (of msdn) http://blogs.msdn.com/openspecification/archive/2009/09/12/msds-supportedencryptiontypes-episode-1-computer-accounts.aspx says :" 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." It means that when I join a w2k8 domain with a XP workstation that the DC will create a computer object for this XP workstation and set the msDS-SupportedEncryptionTypes attribute ? if so to which value ? On my tests when I join a w2k3 server to a w2k8 domain the attribute SupportedEncryptionTypes is not set. Can this point be clarified and if possible written in a formal document This entry also state: " When the KDC checks the attribute to decide what encryption algorithm to use in order to encrypt the ticket, it could find basically two scenarios: 1) The attribute is populated 2) The attribute is empty If the attribute is populated, then the deal is done since the KDC can determine the best common algorithm to encrypt the ticket with the value present. However, if the attribute is empty then the KDC will have to work harder being the next step to check another attribute. This attribute is defined in MS-ADA3 (section 2.341) and described in MS-ADTS (section 2.2.15) and it's called userAccountControl. This attribute is also a 4 byte Bit Mask that defines many aspects of the account but the only one the KDC is interested in is the DK (ADS_UF_USE_DES_KEY_ONLY ) bit. This bit defines what legacy encryption method will be used: 1) If the bit is set, then only DES will be used 2) If the bit is NOT set, then DES and RC4 can be used This check is especially relevant in domains that have Win7 and Windows Server 2008 R2 machines joined because those two newer OSs disable their bit by default so older DES is not an option for them." * What is the exact meaning of ADS_UF_USE_DES_KEY_ONLY ? if a w2k8 server acting as a domain member within a w2k8 domain has this DK bit set, will the DC not use AES but only DES with it ? * "This check is especially relevant in domains that have Win7 and Windows Server 2008 R2 machines joined because those two newer OSs disable their bit by default so older DES is not an option for them.", well it seems that a w2k3 server member of w2k8 domain do not have this bit set also (userAccountControl=4096 => only WT flag set). * Also neither MS-LSAD nor MS-NRPC talk about the link between the attribute msDS-SupportedEncryptionTypes stored in the AD and the fact that it's returned as SupportedEncTypes in NETLOGON_DOMAIN_INFO call. I can understand that it can be called "secret" of implementation but when after a workstation tries to update this attribute to let the DC know what are the supported encoding it's better to clarify the link. Thank you for help with clarifying those points. Matthieu. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] of SupportedEncTypes and msDS-SupportedEncryptionTypes
Good morning Matthieu - We have created the below case to track our work against your questions: SRX091220600031 [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes usage I will begin my investigation this morning, and will advise you of my progress by close of business tomorrow (Tuesday Dec 22 GMT-5) at the latest. I confirm the msDS-SupportedEncryptionTypes attribute is not set when a Windows 2000 or Windows XP client joins a Windows 2008 domain. I will next check the msDS-SupportedEncryptionTypes attribute with a Windows 2003 server on a 2008 domain, and expect to verify the behavior within several hours (once my virtual machine has completed installation). 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: Matthieu Patou [mailto:mat+informatique.sa...@matws.net] Sent: Sunday, December 20, 2009 7:01 AM To: cifs-proto...@samba.org; Interoperability Documentation Help; p...@tridgell.net Subject: of SupportedEncTypes and msDS-SupportedEncryptionTypes Hello, Back in august and september we discuss in case SRX090808600017 about supportedEncTypes and I was quite happy with your answer. I'm coming back on this subject for two details: * this blog entry (of msdn) http://blogs.msdn.com/openspecification/archive/2009/09/12/msds-supportedencryptiontypes-episode-1-computer-accounts.aspx says :" 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." It means that when I join a w2k8 domain with a XP workstation that the DC will create a computer object for this XP workstation and set the msDS-SupportedEncryptionTypes attribute ? if so to which value ? On my tests when I join a w2k3 server to a w2k8 domain the attribute SupportedEncryptionTypes is not set. Can this point be clarified and if possible written in a formal document This entry also state: " When the KDC checks the attribute to decide what encryption algorithm to use in order to encrypt the ticket, it could find basically two scenarios: 1) The attribute is populated 2) The attribute is empty If the attribute is populated, then the deal is done since the KDC can determine the best common algorithm to encrypt the ticket with the value present. However, if the attribute is empty then the KDC will have to work harder being the next step to check another attribute. This attribute is defined in MS-ADA3 (section 2.341) and described in MS-ADTS (section 2.2.15) and it's called userAccountControl. This attribute is also a 4 byte Bit Mask that defines many aspects of the account but the only one the KDC is interested in is the DK (ADS_UF_USE_DES_KEY_ONLY ) bit. This bit defines what legacy encryption method will be used: 1) If the bit is set, then only DES will be used 2) If the bit is NOT set, then DES and RC4 can be used This check is especially relevant in domains that have Win7 and Windows Server 2008 R2 machines joined because those two newer OSs disable their bit by default so older DES is not an option for them." * What is the exact meaning of ADS_UF_USE_DES_KEY_ONLY ? if a w2k8 server acting as a domain member within a w2k8 domain has this DK bit set, will the DC not use AES but only DES with it ? * "This check is especially relevant in domains that have Win7 and Windows Server 2008 R2 machines joined because those two newer OSs disable their bit by default so older DES is not an option for them.", well it seems that a w2k3 server member of w2k8 domain do not have this bit set also (userAccountControl=4096 => only WT flag set). * Also neither MS-LSAD nor MS-NRPC talk about the link between the attribute msDS-SupportedEncryptionTypes stored in the AD and the fact that it's returned as SupportedEncTypes in NETLOGON_DOMAIN_INFO call. I can understand that it can be called "secret" of implementation but when after a workstation tries to update this attribute to let the DC know what are the supported encoding it's better to clarify the link. Thank you for help with clarifying those points. Matthieu. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] of SupportedEncTypes and msDS-SupportedEncryptionTypes
Hello bill Good morning Matthieu - We have created the below case to track our work against your questions: SRX091220600031 [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes usage I will begin my investigation this morning, and will advise you of my progress by close of business tomorrow (Tuesday Dec 22 GMT-5) at the latest. I confirm the msDS-SupportedEncryptionTypes attribute is not set when a Windows 2000 or Windows XP client joins a Windows 2008 domain. I will next check the msDS-SupportedEncryptionTypes attribute with a Windows 2003 server on a 2008 domain, and expect to verify the behavior within several hours (once my virtual machine has completed installation). In fact that's not only w2k/xp/w2k3 it's the whole range. My assumption is that this phrase :"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" is false and that when the computer object is created it is created without this attribute and then systems newer or equal to vista/windows 2k8 are modifying this attribute to set it to the exact value that they support. Matthieu. 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: Matthieu Patou [mailto:mat+informatique.sa...@matws.net] Sent: Sunday, December 20, 2009 7:01 AM To: cifs-proto...@samba.org; Interoperability Documentation Help; p...@tridgell.net Subject: of SupportedEncTypes and msDS-SupportedEncryptionTypes Hello, Back in august and september we discuss in case SRX090808600017 about supportedEncTypes and I was quite happy with your answer. I'm coming back on this subject for two details: * this blog entry (of msdn) http://blogs.msdn.com/openspecification/archive/2009/09/12/msds-supportedencryptiontypes-episode-1-computer-accounts.aspx says :" 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." It means that when I join a w2k8 domain with a XP workstation that the DC will create a computer object for this XP workstation and set the msDS-SupportedEncryptionTypes attribute ? if so to which value ? On my tests when I join a w2k3 server to a w2k8 domain the attribute SupportedEncryptionTypes is not set. Can this point be clarified and if possible written in a formal document This entry also state: " When the KDC checks the attribute to decide what encryption algorithm to use in order to encrypt the ticket, it could find basically two scenarios: 1) The attribute is populated 2) The attribute is empty If the attribute is populated, then the deal is done since the KDC can determine the best common algorithm to encrypt the ticket with the value present. However, if the attribute is empty then the KDC will have to work harder being the next step to check another attribute. This attribute is defined in MS-ADA3 (section 2.341) and described in MS-ADTS (section 2.2.15) and it's called userAccountControl. This attribute is also a 4 byte Bit Mask that defines many aspects of the account but the only one the KDC is interested in is the DK (ADS_UF_USE_DES_KEY_ONLY ) bit. This bit defines what legacy encryption method will be used: 1) If the bit is set, then only DES will be used 2) If the bit is NOT set, then DES and RC4 can be used This check is especially relevant in domains that have Win7 and Windows Server 2008 R2 machines joined because those two newer OSs disable their bit by default so older DES is not an option for them." * What is the exact meaning of ADS_UF_USE_DES_KEY_ONLY ? if a w2k8 server acting as a domain member within a w2k8 domain has this DK bit set, will the DC not use AES but only DES with it ? * "This check is especially relevant in domains that have Win7 and Windows Server 2008 R2 machines joined because those two newer OSs disable their bit by default so older DES is not an option for them.", well it seems that a w2k3 server member of w2k8 domain do not have this bit set also (userAccountControl=4096 => only WT flag set). * Also neither MS-LSAD nor MS-NRPC talk about the link between the attribute msDS-SupportedEncryptionTypes stored in the AD and the fact that it's returned as SupportedEncTypes in NETLOGON_DOMAIN_INFO call. I can understand that it can be called "secret" of implementation but when after a workstation tries to update this attribute to let the DC know what are the supported encoding it's better to clarify the link. Thank you for help with clarifying those points. Matthieu. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/list
Re: [cifs-protocol] of SupportedEncTypes and msDS-SupportedEncryptionTypes
I agree with you - the blog entry is wrong, and your statement is correct - the network capture frame details below illustrate this (a Windows 2008 client joining a 2008 domain). I am cc'ing Sebastian, since he owns the blog entry. In fact that's not only w2k/xp/w2k3 it's the whole range. My assumption is that this phrase :"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" is false and that when the computer object is created it is created without this attribute and then systems newer or equal to vista/windows 2k8 are modifying this attribute to set it to the exact value that they support. Frame: Number = 634, Captured Frame Length = 254, MediaType = ETHERNET + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-15-5D-04-7B-09],SourceAddress:[00-15-5D-04-7B-14] + Ipv4: Src = 192.168.0.11, Dest = 192.168.0.10, Next Protocol = TCP, Packet ID = 102, Total IP Length = 240 + Tcp: Flags=...AP..., SrcPort=49166, DstPort=LDAP(389), PayloadLen=200, Seq=4221789663 - 4221789863, Ack=3194344992, Win=512 (scale factor 0x8) = 131072 - Ldap: Modify Request, MessageID: 5, Object: CN=2008R2VMDC2,CN=Computers,DC=2008R2DOMAIN,DC=COM + SASLBuffer: - Parser: Modify Request, MessageID: 5 + ParserHeader: + MessageID: 5 + OperationHeader: Modify Request, 6(0x6) - ModifyRequest: Object: CN=2008R2VMDC2,CN=Computers,DC=2008R2DOMAIN,DC=COM + Object: CN=2008R2VMDC2,CN=Computers,DC=2008R2DOMAIN,DC=COM - LoopSeq: + OuterSequenceHeader: - Modification: + InnerSequence: + Operation: Replace, 2(0x2) - Modification: msDS-SupportedEncryptionTypes=( 28 ) + PartialAttributeHeader: 0x1 + Type: msDS-SupportedEncryptionTypes + AttributeValuesHeader: - Attribute: 28 + AsnOctetStringHeader: OctetStream: 28 - Controls: + ControlsHeader: + ControlHeader: + ControlType: 1.2.840.113556.1.4.1413 (LDAP_SERVER_PERMISSIVE_MODIFY_OID) + ControlValueHeader: 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: Matthieu Patou [mailto:mat+informatique.sa...@matws.net] Sent: Monday, December 21, 2009 11:22 AM To: Bill Wesse Cc: cifs-proto...@samba.org; p...@tridgell.net Subject: Re: of SupportedEncTypes and msDS-SupportedEncryptionTypes Hello bill > Good morning Matthieu - We have created the below case to track our work > against your questions: > > SRX091220600031 [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes usage > > I will begin my investigation this morning, and will advise you of my > progress by close of business tomorrow (Tuesday Dec 22 GMT-5) at the latest. > > I confirm the msDS-SupportedEncryptionTypes attribute is not set when a > Windows 2000 or Windows XP client joins a Windows 2008 domain. > > I will next check the msDS-SupportedEncryptionTypes attribute with a Windows > 2003 server on a 2008 domain, and expect to verify the behavior within > several hours (once my virtual machine has completed installation). > In fact that's not only w2k/xp/w2k3 it's the whole range. My assumption is that this phrase :"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" is false and that when the computer object is created it is created without this attribute and then systems newer or equal to vista/windows 2k8 are modifying this attribute to set it to the exact value that they support. Matthieu. > 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: Matthieu Patou [mailto:mat+informatique.sa...@matws.net] > Sent: Sunday, December 20, 2009 7:01 AM > To: cifs-proto...@samba.org; Interoperability Documentation Help; > p...@tridgell.net > Subject: of SupportedEncTypes and msDS-SupportedEncryptionTypes > > Hello, > > Back in august and september we discuss in case SRX090808600017 about > supportedEncTypes and I was quite happy with your answer. > > I'm coming back on this subject for two details: > > * this blog entry (of msdn) > http://blogs.msdn.com/openspecification/archive/2009/09/12/msds-supportedencryptiontypes-episode-1-computer-accounts.aspx > says :" 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." It means > that when I join a w2k8 domain with a XP workstation that the DC will > create a computer object
