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: [email protected]
-----Original Message-----
From: Sebastian Canevari
Sent: Thursday, January 07, 2010 2:18 PM
To: 'Matthieu Patou'
Cc: '[email protected]'; '[email protected]'
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: [email protected]
-----Original Message-----
From: Sebastian Canevari
Sent: Wednesday, January 06, 2010 3:32 PM
To: 'Matthieu Patou'
Cc: [email protected]; [email protected]
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
(0x0000000F) 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: [email protected]
-----Original Message-----
From: Matthieu Patou [mailto:[email protected]]
Sent: Saturday, December 19, 2009 3:43 AM
To: Sebastian Canevari
Cc: [email protected]; [email protected]
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: [email protected]
-----Original Message-----
From: Sebastian Canevari
Sent: Friday, December 18, 2009 1:55 PM
To: Matthieu Patou; [email protected]; Interoperability
Documentation Help; [email protected]
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: [email protected]
-----Original Message-----
From: Matthieu Patou [mailto:[email protected]]
Sent: Friday, December 18, 2009 10:36 AM
To: [email protected]; Interoperability Documentation Help;
[email protected]
Subject: LDAP_SERVER_SD_FLAGS_OID control and search request
Hello,
While testing ADUC I found that this tool is using the control
LDAP_SERVER_SD_FLAGS_OID when requesting object with no attributes (ie.
CN=Users,DC=home,DC=matws,DC=net) and expect to receive the
nTSecurityDescriptor.
Of course if you do not provide this control the nTSecurityDescriptor is not
returned.
I tested this behavior with w2k3r2 and it is how this server behave.
Can you confirm that it's the expected behavior for this control and if
possible can you document it if it's not already done.
Regards.
Matthieu.
