Re: [cifs-protocol] Please clarify LSA and OsVersion behaviour in MS-NRPC (SRX090727600015)
On Mon, 2009-09-28 at 13:22 +, Bill Wesse wrote: > Good morning Andrew - yes, NetrLogonGetDomainInfo bypasses the > servicePrincipalName constraints (as Hongwei noted). This applies to Windows > 2003/2003 R2, and was fixed in Windows 2008 and beyond. > > This is currently a bug against Windows 2003, but no hotfix has yet been > produced. I will be glad to alert you to when this occurs. > > Here is the response Hongwei provided Thursday, September 10, 2009 8:40 AM: > > We confirmed that Windows server 2008 and later systems addressed the problem > by implementing validation of the DNSHostName and SPN in > NetrLogonGetDomainInfo to enforce the same constraints as specified in > section 3.1.1.5.3.1.1.2(dNSHostName) and > 3.1.1.5.3.1.1.4(servicePrincipalName) in MS-ADTS. I'm sorry, I must not have been clear in my point: > Did we determine earlier that these updates occur regardless of the access > control on the object (confirmed with AD Dev team, but I don't think it's in > the docs). I refer here to the access control that would normally be imposed by the nTSecurityDescriptor and enforced over LDAP. It is my understanding (discussion with Nathan Muggli) that these are done as 'SYSTEM' (not the actual workstation account), but I don't recall that being in the doc. (This isn't a security hole, because you can only update your own record, but it's important to note for those doing an ACL implementation). Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. signature.asc Description: This is a digitally signed message part ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Please clarify LSA and OsVersion behaviour in MS-NRPC (SRX090727600015)
Thanks for the clarification Andrew; sorry I didn't. I have created a new case for this, and will begin work shortly: SRX091001600015 "[MS-ADTS] servicePrincipalName nTSecurityDescriptor constraints" I will look into object security / impersonation, including all of the below (with first effort on servicePrincipalName, of course), and get back to you as soon as I can. My first thought is that the Windows DS Agent simply impersonates 'SYSTEM' - but as you noted, undocumented (which probably classifies this as a behavior note). [MS-ADTS] 3.1.1.5.3.1.1 Validated Writes 3.1.1.5.3.1.1.1 Member 3.1.1.5.3.1.1.2 dNSHostName 3.1.1.5.3.1.1.3 msDS-AdditionalDnsHostName 3.1.1.5.3.1.1.4 servicePrincipalName 3.1.1.5.3.1.1.5 msDS-Behavior-Version 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: Thursday, October 01, 2009 6:52 AM To: Bill Wesse Cc: p...@tridgell.net; cifs-proto...@samba.org; Matthias Dieter Wallnöfer Subject: RE: [cifs-protocol] Please clarify LSA and OsVersion behaviour in MS-NRPC (SRX090727600015) On Mon, 2009-09-28 at 13:22 +, Bill Wesse wrote: > Good morning Andrew - yes, NetrLogonGetDomainInfo bypasses the > servicePrincipalName constraints (as Hongwei noted). This applies to Windows > 2003/2003 R2, and was fixed in Windows 2008 and beyond. > > This is currently a bug against Windows 2003, but no hotfix has yet been > produced. I will be glad to alert you to when this occurs. > > Here is the response Hongwei provided Thursday, September 10, 2009 8:40 AM: > > We confirmed that Windows server 2008 and later systems addressed the problem > by implementing validation of the DNSHostName and SPN in > NetrLogonGetDomainInfo to enforce the same constraints as specified in > section 3.1.1.5.3.1.1.2(dNSHostName) and > 3.1.1.5.3.1.1.4(servicePrincipalName) in MS-ADTS. I'm sorry, I must not have been clear in my point: > Did we determine earlier that these updates occur regardless of the access > control on the object (confirmed with AD Dev team, but I don't think it's in > the docs). I refer here to the access control that would normally be imposed by the nTSecurityDescriptor and enforced over LDAP. It is my understanding (discussion with Nathan Muggli) that these are done as 'SYSTEM' (not the actual workstation account), but I don't recall that being in the doc. (This isn't a security hole, because you can only update your own record, but it's important to note for those doing an ACL implementation). 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] CAR: DS_FLAG Option bits
Hi, We've been looking at the DS_FLAG option bits returned by a w2k8-r2 server in CLDAP (see MS-ADTS section 7.3.1.2). We've found that a w2k8-r2 domain controller for a single domain in a forest returns 0x33fd. Can you tell us why it doesn't add the DS_DNS_CONTROLLER_FLAG, DS_DNS_DOMAIN_FLAG and DS_DNS_FOREST_FLAG bits? The description of those bits would seem to match the windows DC, so we're wondering if perhaps we've misunderstood them. In 7.3.3.2 it says: - If the server has a DNS name, the DS_DNS_CONTROLLER_FLAG bit is set. - If the DnsDomain value specified in the search filter is the DNS name of the default NC, the DS_DNS_DOMAIN_FLAG bit is set. - If the DnsDomain value specified in the search filter is the forest name, the DS_DNS_FOREST_FLAG bit is set. My test w2k8-r2 DC definately has a DNS name, and the search filter was for the default NC, and it is the forest name, so I expected all 3 bits to be set. See http://samba.org/tridge/sniffs/w2k8b-join-w2k8-dc.cap frame 14. The two machines are both w2k8-r2. The DC is 10.0.0.4. Cheers, Tridge ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
