[cifs-protocol] Status: SRX091201600038 [MS-ADTS] LDAPControl not applied on add

Bill Wesse billwe at microsoft.com
Fri Dec 18 09:00:28 MST 2009


Good morning Nadya - I have created a Technical Document Issue (TDI) concerning your observation that ldap add operations ignore the LDAP_SERVER_SD_FLAGS_OID control.

I have checked our implementation sources, which appears to support your conclusion. I expect we will be updating [MS-ADTS] 7.1.3.2 SD Flags Control (http://msdn.microsoft.com/en-us/library/cc223733(PROT.13).aspx ) accordingly.

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: Bill Wesse
Sent: Tuesday, December 01, 2009 9:13 AM
To: 'Nadezhda Ivanova'
Cc: cifs-protocol at samba.org
Subject: RE: [cifs-protocol] Need some help with LDAP_SERVER_SD_FLAGS_OID control (SRX091119600169)

Good morning Nadya - thanks for the feedback on SRX091119600169; I will archive that case.

Concerning your next question, I have created the below case - and yes, please send me the script & network capture.

SRX091201600038 [MS-ADTS] LDAPControl not applied on add

When I create a new object and provide the control, the control does not have any effect even though it is mentioned in the documentation that it operates on add as well. The new object's descriptor is created as though the control is not sent at all, and no error is returned. I do provide a security descriptor with the request, so it's not the case where it is ignored...


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: Nadezhda Ivanova [mailto:nadezhda.ivanova at postpath.com]
Sent: Tuesday, December 01, 2009 4:18 AM
To: Bill Wesse
Cc: cifs-protocol at samba.org
Subject: Re: [cifs-protocol] Need some help with LDAP_SERVER_SD_FLAGS_OID control (SRX091119600169)

Hi Bill,
There are no issues with the LDAP_SERVER_SD_FLAGS_OID when sent with an LDAP modify - it behaves as documented. The issue here is that it does not seem to have any effect when sent with an LDAP add. Therefore I cannot send you a dump of the object before modification, because it hasn't been created yet :).
Again, just to be sure we understand the issue:
When I modify the descriptor of an existing object providing this control, the server behaves as documented, everything is in order.
When I create a new object and provide the control, the control does not have any effect even though it is mentioned in the documentation that it operates on add as well. The new object's descriptor is created as though the control is not sent at all, and no error is returned. I do provide a security descriptor with the request, so its not the case where it is ignored...
If you like, I can send you some script of the way I am creating the object, and a network capture?

About the second question - I did look in ADTS for explanation, but I guess I missed it :). Thank a lot, I believe that answers the question.

Regards,
Nadya
----- Original Message -----
> From: Bill Wesse <billwe at microsoft.com>
> To: Nadezhda Ivanova <nadezhda.ivanova at postpath.com>
> Cc: cifs-protocol at samba.org <cifs-protocol at samba.org>
> Sent: Monday, November 30, 2009 9:51:11 PM GMT+0200 Europe;Athens
> Subject: RE: [cifs-protocol] Need some help with LDAP_SERVER_SD_FLAGS_OID control (SRX091119600169)

> > Hello Nadya - here is the response information for your questions. The
> first question will undoubtedly need to be handled under a new service
> request. For the second one, please let me know if that answers
> everything (if so, I will consider SRX091119600169 resolved).
>
> =======================================================================
> =======
> Question:
>
> When I execute the test against a Win2008, domain functional level
> 2008, it actually fails. All of the fields of the provided security
> descriptor are applied, not only the ones specified by the control.
> Maybe there is some additional configuration and condition for the
> control to be taken into account?
>
> Response:
>
> I have examined our implementation of this, and find no relevant
> changes. I did not find anything involved with configuration that
> should affect the way security descriptor flags are treated. The LDAP
> server code handling for LDAP_SERVER_SD_FLAGS_OID is essentially
> unchanged from Windows 2003 through 2008R2.
>
> Could you please send me an 'dsacls CN=,...' dump of an updated object
> (before and after the update), as well as a network capture? I will
> create a new case upon receipt of that data.
>
> =======================================================================
> =======
> Question:
>
> I do not get LDAP_UNAVAILABLE_CRIT_EXTENSION, as described in
> http://msdn.microsoft.com/en-us/library/aa367025(VS.85).aspx Using
> Controls
>
>    Each extended control has a Criticality flag, represented by the
>    ldctl_iscritical field of the LDAPControl structure. If this flag
> is set to
>    TRUE, then the server will return a LDAP_UNAVAILABLE_CRIT_EXTENSION
> error
>    code if the server does not support the request control when
> attempting an
>    API call that includes the control. Using extended controls on a
> LDAP
>    version 2 connection will also fail with this return code.
>
> Response:
>
> Behavior of an update operation when this control is specified is
> detailed in [MS-ADTS], section 7.1.3.2.
>
> If, during an update, no SD is provided and the control is provided,
> then the control is used to specify which (non-existent) parts of the
> (non-existent) SD are to be used in the update operation.  Since that
> specifies no actual change in the update operation (that is, no new
> data for an SD is provided), the control is trivially being honored,
> and as such no error is returned, regardless of criticality.
> Essentially, the update operation (at least with respect to SDs) is a
> no-op.
>
> Explicitly, during an add operation, if no security descriptor is
> provided by the client, then specifying what parts of the security
> descriptor are relevant has no observable behavior, and is not an
> error.
>
> LDAP_CONTROL_REFERRALS (OID 1.2.840.113556.1.4.616) is never passed to
> the server, and the server neither parses nor understands it.  It
> affects only the client side implementation of an LDAP client library.
>  Specifically, it controls whether a client library should chase
> referrals returned by a DC or not.  As this is client behavior only
> and not part of the server protocol, it does not fall under the scope
> of MS-ADTS.
>
>
> 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: Bill Wesse
> Sent: Friday, November 20, 2009 3:25 PM
> To: 'Nadezhda Ivanova'
> Cc: cifs-protocol at samba.org
> Subject: RE: [cifs-protocol] Need some help with
> LDAP_SERVER_SD_FLAGS_OID control (SRX091119600169)
>
> Glad to help. I will look into the security descriptor handling. Have
> you seen anything different at lower functional levels (like only the
> specified sd parts being applied)?
>
> 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: Nadezhda Ivanova [mailto:nadezhda.ivanova at postpath.com]
> Sent: Friday, November 20, 2009 1:21 PM
> To: Bill Wesse
> Cc: cifs-protocol at samba.org
> Subject: Re: [cifs-protocol] Need some help with
> LDAP_SERVER_SD_FLAGS_OID control (SRX091119600169)
>
> Hi Bill,
> Thank you for your answer! The problem is, when I execute the test
> against a Win2008, domain functional level 2008, it actually fails.
> All of the fields of the provided security descriptor are applied, not
> only the ones specified by the control. Maybe there is some additional
> configuration and condition for the control to be taken into account?
>
> Best Regards,
> Nadya
> ----- Original Message -----
> > From: Bill Wesse <billwe at microsoft.com>
> > To: Nadezhda Ivanova <nadezhda.ivanova at postpath.com>
> > Cc: cifs-protocol at samba.org <cifs-protocol at samba.org>
> > Sent: Friday, November 20, 2009 7:22:08 PM GMT+0200 Europe;Athens
> > Subject: RE: [cifs-protocol] Need some help with
> LDAP_SERVER_SD_FLAGS_OID control (SRX091119600169)
>
> > > Just following up to clarify where we are on this, since I missed
> a
> > beat yesterday, and didn't consider the 'add with security' case
> > fully.
> >
> > I think the first question is the only open item.
> >
> >
> =======================================================================
>
> > =======
> > Q: I do not get  LDAP_UNAVAILABLE_CRIT_EXTENSION, as described in
> >    http://msdn.microsoft.com/en-us/library/aa367025(VS.85).aspx
> >    Using Controls
> >       Each extended control has a Criticality flag, represented by
> the
> >    ldctl_iscritical field of the LDAPControl structure. If this flag
>
> > is set to
> >    TRUE, then the server will return a
> LDAP_UNAVAILABLE_CRIT_EXTENSION
> > error
> >    code if the server does not support the request control when
> > attempting an
> >    API call that includes the control. Using extended controls on a
> > LDAP
> >    version 2 connection will also fail with this return code.
> >
> > A: I am awaiting confirmation on the following:
> >
> >    LDAP_CONTROL_REFERRALS is required with LDAP_SERVER_SD_FLAGS_OID;
>
> > if not present,
> >    LDAP_UNAVAILABLE_CRIT_EXTENSION is returned.
> >
> >
> =======================================================================
>
> > =======
> > Q: Is this control relevant for an LDAP add request?
> > A: Yes (per your test).
> >
> >
> =======================================================================
>
> > =======
> > Q: What should be the behavior for an LDAP add?
> > A: Application of the provided security descriptor to the new
> object.
> >    Your test matches perfectly:
> >
> > I create an OU, providing a descriptor that has OwnerSid, GroupSid,
> > Sacl and Dacl, and the OWNER_SECURITY_INFORMATION flag raised in the
>
> > control. I read back the descriptor of the OU. I expect that the
> ACEs
> > provided in the Sacl and Dacl will not be part of the OUs descriptor,
>
> > and the GroupSid will be the default. However, all 4 fields contain
> > the data provided with the add request. The same test worked great
> for
> > the modify request. I hope this info helps.
> >
> >
> > 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: Bill Wesse
> > Sent: Friday, November 20, 2009 10:07 AM
> > To: 'Nadezhda Ivanova'
> > Cc: cifs-protocol at samba.org
> > Subject: RE: [cifs-protocol] Need some help with
> > LDAP_SERVER_SD_FLAGS_OID control (SRX091119600169)
> >
> > The info indeed helps - and you are completely correct concerning
> the
> > LDAP_SERVER_SD_FLAGS_OID control. I took the references I supplied
> too
> > literally - and didn't read far enough - of course that would be
> > necessary to set security on a new object, if the default is not
> what
> > is needed.
> >
> > I am still waiting on information about the conditions that would
> > return LDAP_UNAVAILABLE_CRIT_EXTENSION.
> >
> > 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: Nadezhda Ivanova [mailto:nadezhda.ivanova at postpath.com]
> > Sent: Thursday, November 19, 2009 4:42 PM
> > To: Bill Wesse
> > Cc: cifs-protocol at samba.org
> > Subject: Re: [cifs-protocol] Need some help with
> > LDAP_SERVER_SD_FLAGS_OID control (SRX091119600169)
> >
> > P.S. In the links you sent me,
> > http://msdn.microsoft.com/en-us/library/cc223323(PROT.13).aspx
> > add is mentioned as well:
> > "It is also used with LDAP Add and Modify requests to control the
> > portion of a Windows security descriptor to modify. The DC modifies
> > only the specified portion of the security descriptor."
> >
> > Perhaps my test is wrong? I create an OU, providing a descriptor
> that
> > has OwnerSid, GroupSid, Sacl and Dacl, and the
> > OWNER_SECURITY_INFORMATION flag raised in the control. I read back
> the
> > descriptor of the OU. I expect that the ACEs provided in the Sacl
> and
> > Dacl will not be part of the OUs descriptor, and the GroupSid will
> be
> > the default. However, all 4 fields contain the data provided with
> the
> > add request. The same test worked great for the modify request. I
> hope
> > this info helps.
> >
> > Regards,
> > Nadya
> > ----- Original Message -----
> > > From: cifs-protocol-bounces at cifs.org
> > <cifs-protocol-bounces at cifs.org>
> > > To: billwe at microsoft.com <billwe at microsoft.com>, Nadezhda Ivanova
> > <nadezhda.ivanova at postpath.com>
> > > Cc: cifs-protocol at samba.org <cifs-protocol at samba.org>
> > > Sent: Thursday, November 19, 2009 11:30:59 PM GMT+0200
> Europe;Athens
> > > Subject: Re: [cifs-protocol] Need some help with
> > LDAP_SERVER_SD_FLAGS_OID control (SRX091119600169)
> >
> > > > Hi Bill,
> > > It's definitely not just used for searches. Some management tools
> > such
> > > as Active Directory Users and Computers send this control along
> with
> > a
> > > modify request - we have a bug about this in bugzilla:
> > > https://bugzilla.samba.org/show_bug.cgi?id=6401
> > > I have proven with tests that in modify requests the control is
> > taken
> > > into account, and only the specified parts of the descriptor are
> > > modified. I have already implemented it for the modify request.
> > > However, I cannot implement it for the add request until I know if
>
> > > there is actually anything to be done for add, and if there is,
> how
> > it
> > > should work. My tests have shown no effect for add requests, but
> > since
> > > it is mentioned in the MS-ADTS, I thought maybe I am missing
> > > something. So, this only blocks my progress if there is something
> to
> >
> > > be done for the add request, otherwise, it does not. It is not
> very
> > > urgent, though, it can wait a bit if you have other priorities.
> > >
> > > Regards,
> > > Nadya
> > > ----- Original Message -----
> > > > From: Bill Wesse <billwe at microsoft.com>
> > > > To: Nadezhda Ivanova <nadezhda.ivanova at postpath.com>
> > > > Cc: cifs-protocol at samba.org <cifs-protocol at samba.org>
> > > > Sent: Thursday, November 19, 2009 10:23:06 PM GMT+0200
> > Europe;Athens
> > > > Subject: RE: Need some help with LDAP_SERVER_SD_FLAGS_OID
> control
> > > (SRX091119600169)
> > >
> > > > > Nadya - I don't think the LDAP_SERVER_SD_FLAGS_OID control
> > should
> > > have
> > > > any effect during an add operation, since the flags for the
> > control
> > > > indicate which security descriptor parts to retrieve during a
> > search,
> > >
> > > > which should explain why LDAP_UNAVAILABLE_CRIT_EXTENSION is not
> > > being
> > > > returned (assuming the add succeeded).
> > > >
> > > > I have filed a TDI to obtain authoritative information
> concerning
> > > this,
> > > >  and will update you with results as they develop.
> > > >
> > > > Could you advise me concerning how much this impacts progress on
>
> > > your
> > > > implementation?
> > > >
> > > > References:
> > > >
> > > > [MS-ADTS] 3.1.1.3.4.1.11 LDAP_SERVER_SD_FLAGS_OID
> > > > http://msdn.microsoft.com/en-us/library/cc223323(PROT.13).aspx
> > > >
> > > > The LDAP_SERVER_SD_FLAGS_OID control is used with an LDAP Search
> > > > request to control the portion of a Windows Security Descriptor
> to
> > > > retrieve.
> > > >
> > > > LDAP_SERVER_SD_FLAGS_OID Control Code
> > > > http://msdn.microsoft.com/en-us/library/aa366987(VS.85).aspx
> > > >
> > > > The security information flags indicate which security
> descriptor
> > > > parts to retrieve during a search.
> > > >
> > > > 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: Bill Wesse
> > > > Sent: Thursday, November 19, 2009 2:07 PM
> > > > To: 'Nadezhda Ivanova'
> > > > Cc: cifs-protocol at samba.org
> > > > Subject: RE: Need some help with LDAP_SERVER_SD_FLAGS_OID
> control
> > > > (SRX091119600169)
> > > >
> > > > Hi Nadya - I will be your contact for this one. Here is the case
> > > > number:
> > > >
> > > > SRX091119600169: [MS-ADTS] 7.1.3.2 LDAP_SERVER_SD_FLAGS_OID
> > > >
> > > > I will begin my investigation today!
> > > >
> > > > 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: Nadezhda Ivanova [mailto:nadezhda.ivanova at postpath.com]
> > > > Sent: Thursday, November 19, 2009 12:34 PM
> > > > To: Interoperability Documentation Help
> > > > Cc: cifs-protocol at samba.org
> > > > Subject: Need some help with LDAP_SERVER_SD_FLAGS_OID control
> > > >
> > > > Hello,
> > > > I have been working on the implementation of
> > > LDAP_SERVER_SD_FLAGS_OID
> > > > in Samba, and I have a question. Is this control relevant for an
>
> > > LDAP
> > > > add request? I have been testing against Win2008. Adding this
> > > control
> > > > to the request does not seem to have any effect. When I set it
> to
> > > > Critical, I do not get  LDAP_UNAVAILABLE_CRIT_EXTENSION, as
> > > described
> > > > in
> > http://msdn.microsoft.com/en-us/library/aa367025%28VS.85%29.aspx
> > > > At the same tine, in MS-ADTS, section 7.1.3.2 SD Flags Control,
> it
> > > > says:
> > > > "When performing an LDAP operation (add, modify or search), the
> > > client
> > > > may supply an SD flags
> > > > control LDAP_SERVER_SD_FLAGS_OID with the operation."
> > > >
> > > > So, if the control is valid for an LDAP add, what should be the
> > > > behavior?
> > > >
> > > > Best Regards,
> > > > Nadezhda Ivanova
> > > _______________________________________________
> > > cifs-protocol mailing list
> > > cifs-protocol at cifs.org
> > > https://lists.samba.org/mailman/listinfo/cifs-protocol



More information about the cifs-protocol mailing list