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 <edg...@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-proto...@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-proto...@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.sa...@gmail.com > [mailto:nivanova.sa...@gmail.com<nivanova.sa...@gmail.com>] > *On Behalf Of *Nadezhda Ivanova > *Sent:* Monday, October 7, 2013 5:55 AM > *To:* Interoperability Documentation Help > *Cc:* cifs-proto...@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**** >
_______________________________________________ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol