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: [email protected]; 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: [email protected]<mailto:[email protected]>; 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: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Nadezhda Ivanova Sent: Monday, October 7, 2013 5:55 AM To: Interoperability Documentation Help Cc: [email protected]<mailto:[email protected]> 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 [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
