[cifs-protocol] [REG113100710843173]: Question about LDAP delete operation on Administrator and other built-in accounts

Nadezhda Ivanova nivanova at samba.org
Wed Oct 9 07:54:26 MDT 2013


Hi Edgar,
It seems from the references you provided that there aren't additional
restrictions - other than rid > 1000, which was my original question.
Thank you for your help!

Regards,
Nadya


On Wed, Oct 9, 2013 at 1:13 AM, Edgar Olougouna <edgaro at microsoft.com>wrote:

>  Nadia,****
>
> It was nice working with the team at the IO lab. Please find the
> references and explanation as follows. ****
>
> Your observation is correct. The restriction is relevant as specified in
> MS-ADTS. The Delete Operation constraints ([MS-ADTS] 3.1.1.5.5) has a
> clause on SAM-specific objects.****
>
> ** **
>
> After reviewing the source code and documents, I have opened a technical
> document issue to request further details regarding the 1000 value.
> Well-known accounts have a RID value that is less than 1000. Consequently
> SAMR uses 1000 as the minimum domain RID for rIDAvailablePool. ****
>
> The builtin account RID check applies to SamrDeleteAlias(),
> SamrDeleteGroup() and SamrDeleteUser.****
>
> ** **
>
> Let’s me know whether this helps!****
>
> ** **
>
> [MS-ADTS]****
>
> 3.1.1.5.5   Delete Operation****
>
> 3.1.1.5.5.5   Constraints****
>
> http://msdn.microsoft.com/en-us/library/cc223485.aspx****
>
> **·        **If the object being deleted is a SAM-specific object
> (section 3.1.1.5.2.3<http://msdn.microsoft.com/en-us/library/cc223445.aspx>),
> additional constraints apply (see [MS-SAMR] section 3.1.5.7<http://msdn.microsoft.com/en-us/library/cc245800.aspx>
> ).****
>
> 3.1.1.5.2.3 Special Classes and Attributes****
>
> http://msdn.microsoft.com/en-us/library/cc223445.aspx****
>
> This section defines three sets of object classes: LSA-specific object
> classes, SAM-specific object classes, and schema object classes. These sets
> are mentioned elsewhere in the specification, because special processing is
> applied to instances of these classes.****
>
> Each set includes both the specific object classes mentioned here and any
> subclasses of these object classes.****
>
> **·        **LSA-specific object classes: secret<http://msdn.microsoft.com/en-us/library/cc221792.aspx>,
> trustedDomain <http://msdn.microsoft.com/en-us/library/cc221820.aspx>(originating updates only, in AD DS only).
> ****
>
> **·        **SAM-specific object classes: group<http://msdn.microsoft.com/en-us/library/cc221861.aspx>,
> samDomain <http://msdn.microsoft.com/en-us/library/cc221779.aspx>,
> samServer <http://msdn.microsoft.com/en-us/library/cc221789.aspx>, user<http://msdn.microsoft.com/en-us/library/cc221822.aspx>(originating updates only, in AD DS only).
> ****
>
> **·        **Schema object classes: attributeSchema<http://msdn.microsoft.com/en-us/library/cc221662.aspx>,
> classSchema <http://msdn.microsoft.com/en-us/library/cc221755.aspx>(originating and replicated updates).
> ****
>
> This section also defines one set of attributes: foreign principal object
> (FPO)<http://msdn.microsoft.com/en-us/library/b645c125-a7da-4097-84a1-2fa7cea07714#fpo>-enabled
> attributes. This set is mentioned elsewhere in the specification, because
> special processing is applied to instances of these attributes.****
>
> **·        **FPO-enabled attributes: member<http://msdn.microsoft.com/en-us/library/cc220525.aspx>,
> msDS-MembersForAzRole<http://msdn.microsoft.com/en-us/library/cc220305.aspx>,
> msDS-NeverRevealGroup<http://msdn.microsoft.com/en-us/library/cc220317.aspx>,
> msDS-NonMembers <http://msdn.microsoft.com/en-us/library/cc220319.aspx>,
> msDS-RevealOnDemandGroup<http://msdn.microsoft.com/en-us/library/cc220364.aspx>,
> msDS-ServiceAccount<http://msdn.microsoft.com/en-us/library/cc221226.aspx>.
> ****
>
> ** **
>
> [MS-SAMR]****
>
> 3.1.5.7 Delete Pattern****
>
> http://msdn.microsoft.com/en-us/library/cc245800.aspx****
>
> 3.1.5.7.1   SamrDeleteGroup (Opnum 23)****
>
> 5.  If the RID of G's objectSid attribute is less than 1000, an error
> MUST be returned.****
>
> 3.1.5.7.2   SamrDeleteAlias (Opnum 30)****
>
> 5.  If the RID of A's objectSid attribute value is less than 1000, an
> error MUST be returned.****
>
> 3.1.5.7.3 SamrDeleteUser (Opnum 35)****
>
> 5. If the RID of U's *objectSid* attribute value is less than 1000, an
> error MUST be returned.****
>
> ** **
>
> [MS-DRSR]****
>
> ** **
>
> 4.1.10.5.12 ProcessFsmoRoleRequest****
>
> http://msdn.microsoft.com/en-us/library/dd207744.aspx****
>
> …****
>
>   /* Locate or create the RID Set object for the client DC. */****
>
>   serverObj := clientDsaObj!parent****
>
>   clientComputerObj := serverObj!serverReference****
>
>   if clientComputerObj!rIDSetReference = null then****
>
>     clientRidSetObj := An implementation defined DSName in the****
>
>         default NC such that not ObjExists(clientRidSetObj)****
>
>     Create object with DSName clientRidSetObject such that****
>
>         rIDSet in clientRidSetObject!objectClass****
>
>     /* Windows Behavior: Windows sets clientRidSetObj to be a child****
>
>      * of clientComputerObj. */****
>
>     clientComputerObj!rIDSetReference := clientRidSetObj****
>
>   else****
>
>     clientRidSetObj := clientComputerObj!rIDSetReference****
>
>   endif****
>
>   /* Get the current RID allocation for the client DC. */****
>
>   ridAllocLoHi := clientRidSetObj!rIDAllocationPool****
>
>   ridAvailHi := most significant 32 bits of ridAvailLoHi****
>
>   ridReqHi := most significant 32 bits of msgIn.liFsmoInfo****
>
>   if ridAllocLoHi = 0 or ridAvailHi = 0 or ridReqHi ≥ ridAvailHi then****
>
>     /* The client DC has indeed exhausted its current allocation,****
>
>      * according to our records. */****
>
> ** **
>
>     /* Get the range of RIDs that have not yet been allocated to any****
>
>      * DC. */****
>
>     ridAvailLoHi := fsmoObj!rIDAvailablePool****
>
>     ridAvailLo := least significant 32 bits of ridAvailLoHi****
>
>     ridAvailHi := most significant 32 bits of ridAvailLoHi****
>
> ** **
>
>     /* Select a subset of the unallocated RIDs and allocate them to****
>
>      * the client. */****
>
>     Assign a value to ridAllocHi according to any implementation-****
>
>        defined policy such that ridAvailLo < ridAllocHi < ridAvailHi.****
>
>     /* Windows Behavior: By default, Windows sets ridAllocHi to****
>
>      * ridAvailLo + 500. */****
>
>     ridAllocLoHi := ridAvailLo as least significant 32 bits and****
>
>         ridAllocHi as most significant 32 bits****
>
>     ridAvailLo := ridAllocHi + 1****
>
>     ridAvailLoHi := ridAvailLo as least significant 32 bits and****
>
>         ridAvailHi as most significant 32 bits****
>
>     fsmoObj!rIDAvailablePool := ridAvailLoHi****
>
>     clientRidSetObj!rIDAllocationPool := ridAllocLoHi****
>
>     msgOut.liFsmoInfo := ridAllocLoHi****
>
>   endif****
>
> …****
>
> ** **
>
> Thanks,****
>
> Edgar****
>
> ** **
>
> *From:* Edgar Olougouna
> *Sent:* Monday, October 07, 2013 11:37 AM
>
> *To:* Nadezhda Ivanova
> *Cc:* cifs-protocol at samba.org; MSSolve Case Email
> *Subject:* RE: [REG113100710843173]: Question about LDAP delete operation
> on Administrator and other built-in accounts****
>
>  ** **
>
> Nadia,****
>
> ** **
>
> I will investigate this and follow-up.****
>
> ** **
>
> Regards,****
>
> Edgar****
>
> ** **
>
> *From:* Bryan Burgin
> *Sent:* Monday, October 07, 2013 11:25 AM
> *To:* Nadezhda Ivanova
> *Cc:* cifs-protocol at samba.org; MSSolve Case Email
> *Subject:* [REG113100710843173]: Question about LDAP delete operation on
> Administrator and other built-in accounts****
>
>  ** **
>
> [-dochelp; +casemail]****
>
> ** **
>
> Hi Nadezhda,****
>
> ** **
>
> Thank you for your question.  We created SR 113100710843173 to track this
> issue.  An engineer from the Protocols will contact you soon.****
>
> ** **
>
> Bryan****
>
> ** **
>
> *From:* nivanova.samba at gmail.com [mailto:nivanova.samba at gmail.com<nivanova.samba at gmail.com>]
> *On Behalf Of *Nadezhda Ivanova
> *Sent:* Monday, October 7, 2013 5:55 AM
> *To:* Interoperability Documentation Help
> *Cc:* cifs-protocol at samba.org
> *Subject:* Question about LDAP delete operation on Administrator and
> other built-in accounts****
>
> ** **
>
> Hi,****
>
> At the I/O Lab we asked about the restrictions that apply on performing a
> delete operation on built-in accounts. To explain the correct behavior,
> Edgar kindly supplied the following references:
> "****
>
> 3.1.1.5.5.1.1 Tombstone Requirements****
>
> http://msdn.microsoft.com/en-us/library/cc223481.aspx****
>
> ** **
>
> A protected object may not be deleted and transformed into a tombstone
> (see Protected Objects (section
> <http://msdn.microsoft.com/en-us/library/cc223483.aspx>3.1.1.5.5.3<http://msdn.microsoft.com/en-us/library/cc223483.aspx>
> ) <http://msdn.microsoft.com/en-us/library/cc223483.aspx>).****
>
>  ****
>
> 3.1.1.5.5.3 Protected Objects****
>
> http://msdn.microsoft.com/en-us/library/cc223483.aspx****
>
>  ****
>
> 3.1.1.6.1.2 Protected Objects****
>
> http://msdn.microsoft.com/en-us/library/dd240058.aspx****
>
> …****
>
> o   well-known security principals:****
>
> §  of class user <http://msdn.microsoft.com/en-us/library/cc221822.aspx>with RID = DOMAIN_USER_RID_ADMIN
>
> "****
>
> However, some testing revealed that the last reference which we hoped
> would explain why the Administrator should not be deleted, appears to not
> be relevant to the case. Delete operation on any built-in account or
> predefined domain rid returns LDAP error 80, and the group membership does
> not really affect the deletion of users or groups.****
>
> So after some digging, I found this:
>
>
> http://msdn.microsoft.com/en-us/library/cc245803.aspx****
>
> Namely: If the RID of U's * objectSid* attribute value is less than 1000,
> an error MUST be returned.****
>
> Could you please confirm that this is indeed the only restriction relevant
> to the case?****
>
> Best Regards,****
>
> Nadezhda Ivanova****
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20131009/ceac6b6c/attachment-0001.html>


More information about the cifs-protocol mailing list