Re: Change the RID Pool on a DC

From: Mike Brannigan [MSFT] (mikebran_at_online.microsoft.com)
Date: 05/19/04 

Date: Wed, 19 May 2004 22:09:18 +0100

Nicolas,

The problem you are trying to solve is appears to be being caused by a
simple process issue.
You imply that for some reason the client backup up the system and then
recreates the users and restores the data etc and thus you have an issue
fixing up all the ACLs.
The problem here is the recreation of the user accounts.
This is not necessary. If they are backing up the system state they will be
bale to restore all the directory object as they were at backup and thus
holding there SIDs that you see on the ACLs.

Your solution would also relies on the end user recreating the user accounts
in precisely the same order as they were initially created an non guaranteed
assumption. 

-- 
Regards,
Mike
--
Mike Brannigan [Microsoft]
This posting is provided "AS IS" with no warranties, and confers no
rights
Please note I cannot respond to e-mailed questions, please use these 
newsgroups
"Nicolas Diétrich" <nicolas.dietrich@NOSPAM.rightvision.com> wrote in 
message news:f45b01c43dc5$e80e00e0$a601280a@phx.gbl...
Mike,
I will try to be a bit more precise.
"You are talking about producing a system that you are
selling to clients that may not be supportable by
Microsoft."
At this stage, we only make investigations on what
solution could fit our needs.
Sure we care about the supporting state of it at MS
before taking such decision.
"I assume you are selling this is an OEM solution and
your company is being fully responsible for all issues of
support?"
Exactly.
"If this results in a server with identical Domain SIDs
and RIDs then you are violating certain basic security
principles of Windows especially if a client purchased 2
or more of these systems.
This may not be correct since I am not entirely sure I
understand your delivery process and this issue of why
you need to alter the RID pool."
Don't worry, sure we ship each server with unique SID...
But our problematic is special because we have to think
with a 2 sides problematic : in the factory-side steps,
and in the client-side steps.
We make each server unique by changing its SID and other
parameters during the factory steps.
Why can't we use standard tools ?
Our problematic occurs when one of our clients backups
its system (so one of the client-side steps), recreates
its users, and restores its datas.
The datas are secured through their security descriptor,
linked to the users SID (relative to our client's server
unique SID).
If our client recreates its users with a messy order,
then the data security are corrupted, and a user cannot
any more access its data (if this recreated user has not
the same SID as before).
So we have many ways to manage our backup/restore
problematic:
1/ Like your proposition to modify NTFS rights on the
datas to fit to the new users identifier.
The problem is that the datas are not only on our server,
there are tapped backuped datas, clients computers datas,
etc...
So we cannot be sure that all linked datas will be
changed with the good rights.
2/ To modify the server SID just before the restoration
and use the SIDHistory features to be sure each user will
get back its data.
We cannot for another complicated reason, we have a
factory reset, which will restore an image of the system.
In this case, the SIDHistory features will be lost, and
we'll have the same issue (users can not access their
data).
3/ To be sure to recreate the old users with the old SID.
That's the way we investigate to try to control the RID
pool.
Thanks for your help, but be sure we thought a lot about
all of this, and we would only want to have the possible
solutions to take a decision.
Best regards,
Nicolas Diétrich
RightVision
France
>-----Original Message-----
>Nicolas,
>
>You are talking about producing a system that you are
selling to clients
>that may not be supportable by Microsoft.
>
>I assume you are selling this is an OEM solution and
your company is being
>fully responsible for all issues of support?
>
>I cannot see why you cannot build and deploy these
solution using the
>standard tools as discussed.
>Can you explain in more detail why you need to modify
the RID pool on the
>server being delivered.
>If this results in a server with identical Domain SIDs
and RIDs then you are
>violating certain basic security principles of Windows
especially if a
>client purchased 2 or more of these systems.
>This may not be correct since I am not entirely sure I
understand your
>delivery process and this issue of why you need to alter
the RID pool.
>
>
>-- 
>Regards,
>
>Mike
>--
>Mike Brannigan [Microsoft]
>
>This posting is provided "AS IS" with no warranties, and
confers no
>rights
>
>Please note I cannot respond to e-mailed questions,
please use these
>newsgroups
>
>"Nicolas Diétrich"
<nicolas.dietrich@NOSPAM.rightvision.com> wrote in
>message news:ef0101c43d7e$0395d060$a401280a@phx.gbl...
>Thank you a lot for all your responses.
>
>
>We thought a lot about how to make this using supported
>tools, but we can definitively not.
>Our appliances are headless (without Screen & Keyboard)
>and this process should take place on the client side
>(deployed by a silent patch), so we have no way to use
>sysprep.
>
>Sure we know how to create users through LDIF, ADSI, or
>other API, and how to reset NTFS rights, that's not our
>problem.
>
>
>I already thought about injecting some code in LSASS
>(with Detours - MS Research) to find the API used by DSA
>to set it but it and to see its execution context.
>If I have some time I will do it today to see if I can
>get some usefull information (I will try to hook
>GetProcAddress and maybe a IDispatch hook to get
>SetObjectAttributes calls).
>
>I was wondering too if this ACCESS_DENIED would happen
>with a SYSTEM user impersonation (through an NT Service
>for example).
>
>
>I think I will try a bit more to have informations on
>this mecanism, but thank a lot for your answers.
>
>
>Best regards,
>
>Nicolas Diétrich
>RightVision
>
>>-----Original Message-----
>>You can't do this by any supported API. You could
>possibly do it by hacking
>>LSASS (code injection) but that is very evil and would
>be completely unsupported.
>>
>>--
>>Joe Richards Microsoft MVP Windows Server Directory
>Services
>>www.joeware.net
>>
>>
>>
>>Nicolas Diétrich wrote:
>>> Hello Mike,
>>>
>>>
>>> Thanks for your quick answer.
>>>
>>> In fact, we construct Internet Appliances based on
>Small
>>> Business Server 2003 (http://www.rightvision.com).
>>>
>>> Our masters are duplicated with Symantec Ghost for the
>>> deployment, and we propose system backup / restore
>>> features. This backup / restore saves and restores a
>lot
>>> of things, including created AD users, computers, and
>a
>>> full system state and data store.
>>>
>>> To be able to restore users data folders and their
>>> affiliated NTFS rights, we need to be able to manage
>the
>>> SID of newly AD created users (to be sure a specified
>>> user will get a specified SID).
>>>
>>> Sure we know SysPrep, NewSID (sysinternals), and the
>>> other ways to manage the Domain part of the SID to
>have a
>>> newly created SID Domain Part.
>>>
>>> We also are aware of the SIDHistory features, but
>after a
>>> lot of reflexion, it cannot fit to our needs.
>>>
>>> We need to be able to read and to modify the RID Scope
>of
>>> our server (SBS2K3, so a 5 FSMO roles).
>>>
>>> I understand our problematic is really specific, but
>it's
>>> fully thinked, and MS France is aware of our
>problematic.
>>>
>>> So do you think there's a way to do this, either by
>>> changing some AD Attributes, by calling a DSA specific
>>> method, or any other way ?
>>>
>>>
>>> Thanks by advance, regards,
>>>
>>> Nicolas Diétrich
>>> RightVision
>>> France
>>>
>>>
>>>>-----Original Message-----
>>>>"Nicolas Diétrich"
>>>
>>> <nicolas.dietrich@NOSPAM.rightvision.com> wrote in
>>>
>>>>message news:e79601c43cb6$dcdb71e0$a501280a@phx.gbl...
>>>>
>>>>>Hello,
>>>>>Is there any way to change the RID Pool of an RID
>Master
>>>>>Domain Controller (Windows 2003 Server)?
>>>>
>>>>
>>>>Nicolas,
>>>>
>>>>Why do you want to change the RID pool on a DC ?
>>>>Has some condition occurred that leads you to believe
>>>
>>> you need to do this?
>>>
>>>>Please provide more information about what has
>happened
>>>
>>> and what you are
>>>
>>>>trying to do.
>>>>
>>>>-- 
>>>>Regards,
>>>>
>>>>Mike
>>>>--
>>>>Mike Brannigan [Microsoft]
>>>>
>>>>This posting is provided "AS IS" with no warranties,
>and
>>>
>>> confers no
>>>
>>>>rights
>>>>
>>>>Please note I cannot respond to e-mailed questions,
>>>
>>> please use these
>>>
>>>>newsgroups
>>>>
>>>>"Nicolas Diétrich"
>>>
>>> <nicolas.dietrich@NOSPAM.rightvision.com> wrote in
>>>
>>>>message news:e79601c43cb6$dcdb71e0$a501280a@phx.gbl...
>>>>Hello,
>>>>
>>>>
>>>>Is there any way to change the RID Pool of an RID
>Master
>>>>Domain Controller (Windows 2003 Server)?
>>>>
>>>>I've already tried to change through ADSIEdit and by
>>>>scripting the RIDSet attributes (rIDNextRID,
>>>>rIDPreviousAllocationPool), but these attributes are
>hold
>>>>by the System (DSA), and I've got an ACCESS_DENIED or
a
>>>>Constraint Violation Error.
>>>>
>>>>
>>>>Dim objRIDSet
>>>>
>>>>Set objRIDSet = GetObject
>>>>("LDAP://myserver.domain.local/CN=RID
>>>>Set,CN=SERVER,OU=Domain
>Controllers,DC=domain,DC=local")
>>>>
>>>>Msgbox "Currently set rIDNextRID:" &
>objRIDSet.rIDNextRID
>>>>
>>>>objRIDSet.rIDNextRID = objRIDSet.rIDNextRID + 10
>>>>
>>>>objRIDSet.SetInfo
>>>>
>>>>Set objRIDSet = Nothing
>>>>
>>>>
>>>>I also tried to change its read only state from the
>>>>schema, but changing the SystemOnly attribute from the
>>>>RID-Next-RID and the RID-Set attributes & class
schema,
>>>>but I also have an error (This attribute is owned by
>the
>>>>system).
>>>>
>>>>
>>>>So I took a look at ntdsa.dll, where I found
>undocumented
>>>>functions like DsUpdateOnPDC(), SampSetDsa(), etc...
>>>>
>>>>
>>>>Is there any proper way to change the RID Pool on a
>>>>domain controller ?
>>>>
>>>>How the DSA changes this attribute by itself ?
>>>>
>>>>
>>>>Thanks by advance,
>>>>
>>>>Cheers,
>>>>
>>>>
>>>>Nicolas Diétrich
>>>>RightVision
>>>>France
>>>>
>>>>
>>>>.
>>>
>>>>
>>.
>>
>
>
>.
>