|
> RODCs require Win2k03 FFM. This is so that we can guarantee a
higher degree > of accuracy for the password reveal list (msDS-RevealedUsers
and the constructed > version msDS-RevealedList) due to LVR Been thinking more about the requirement for the Windows Server
2003 Forest Functional Level (FFL2) to deploy RODCs… It certainly
makes sense to leverage LVR (linked value replication) to reduce the amount of
data being replicated around and to eliminate the “5000” values replication
limit due to the limit of the jet-db version store. Just wondering how many companies are still running a pure Win2000
AD forest and want to upgrade directly to Longhorn (skipping deployment of
Windows Server 2003 DCs)? Do they realize that they will not be able to
deploy RODCs prior to first upgrading or replacing ALL Win2000 DCs in the
forest with writeable Longhorn DCs? They will then be able to switch to FFL3 (Longhorn Server) and in a
second phase of the upgrade project they can take care of deploying
RODCs. And since you can’t just switch the mode of a writeable DC
to an RODC (and vice versa), this usually means to de-promote the writeable LH
DCs and then to re-promote them as RODCs (where you want them – for
example you’ll still want writeable DCs in your hub sites). Naturally
this de-promo and re-promo process can be scripted, but it’s still an
extra phase in the project that takes time and efforts and must be planned appropriately. Companies who have already upgraded to Win2003 and are running at
Win2003 FFL will have less of an issue – they will be able to deploy
RODCs right into their existing Win2003 forests. The PDC of the respective
domain must run Longhorn, but that’s a small price to pay. So, it would be good to get some feedback from this list, A. how many of you are planning to upgrade your AD directly from
Win2000 to Longhorn Server? B. how many are planning to upgrade from Windows2003 FFL? C. how many think they are still in-between (have Win2003 AD, but couldn’t
yet reach Win2003 FFL for some reason, such as some Win2000 or WinNT DCs still
hanging around)? Thanks, Guido From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Nathan Muggli PRP = Password Replication Policy Yes the tool will directly populate the Allow or Deny attributes
(msDS-RevealOnDemandGroup and msDS-NeverRevealGroup respectively) with the
security principal. Ideally the users\computers would be put into a group, and
then the group added to the Allow list. That way you only have to manipulate
the group and not the attributes. The tool will most likely support a generic
“add” operation to add a group (or user\comptuer) to the Allow\Deny
list and then you could use whatever group manipulation tool you wanted. RODCs require Win2k03 FFM. This is so that we can guarantee a
higher degree of accuracy for the password reveal list (msDS-RevealedUsers and
the constructed version msDS-RevealedList) due to LVR. Interesting suggestion on the BL for
msDS-RevealOnDemandGroup\msDS-NeverRevealGroup. The only issue I see with that
is if groups are used instead of individual users\computers. I don’t
think it’s as useful to see a BL on a group since you really want to see
the user. However, that said, we are providing a new RootDSE operation called
“verify cacheability” that will return three values (allowed,
explicitly denied, and not on deny or allow). Its input will be a security
principal and a rodc, so while PRP knowledge won’t be stored on the
user\computer you can easily check a given user to see if they are cacheable at
a given RODC. There are two new links on the user\computer objects related to
RODCs. One is msDS-AuthenticatedAtDC (which is actually the FL to
msDS-AuthenticatedToAccountlist for performance reasons). The other as you
pointed out is msDS-RevealedDSAs which shows which RODCs the user\computer has
been cached at. Since the PRP is per RODC, we do stamp a “common” group
for both allow and deny by default on every RODC promotion to aid in
one-to-many management (ie for service accounts, etc). The new groups (which
are created when the PDC is upgraded to LH) are “Domain RODC Password
Replication Allowed Group” and “Domain RODC Password Replication
Denied Group”. So the current default PRP on RODC promotion looks like this: msDS-RevealOnDemandGroup: CN=Domain RODC
Password Replication Allowed Group,CN=Users,DC=X msDS-NeverRevealGroup: CN=Domain RODC Password Replication
Denied Group,CN=Users,DC=X CN=Account Operators,CN=Builtin,DC=X CN=Server Operators,CN=Builtin,DC=X CN=Backup Operators,CN=Builtin,DC=X CN=Administrators,CN=Builtin,DC=X The common allow group is empty by default. The common deny group contains the following members: CN=Enterprise Read-only Domain
Controllers,CN=WellKnown Security Principals,CN=Configuration,DC=X CN=Group Policy Creator
Owners,CN=Users,DC=X; CN=Domain Admins,CN=Users,DC=rX CN=Cert Publishers,CN=Users,DC=X CN=Enterprise Admins,CN=Users,DC=X CN=Schema Admins,CN=Users,DC=X CN=krbtgt,CN=Users,DC=X -Nathan Muggli RODC Program Manager From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier,
Guido Great information Nathan – thanks! Certainly good to know how the msDS-AuthenticatedToAccountlist
attribute is updated. What does PRP stand for? And is it correct to say that the PRP move feature in
repadmin would directly populate the Password “caching” Policy of the RODC servers
with each security principal (users, computers) that have authenticated to the
RODC (as opposed to using some RODC specific security group)? Which means that
all of these account references would be stored in the msDS-RevealOnDemandGroup
attribute… Hmm, while thinking about this, I wondered if this is only
appropriate for smaller or even for larger environments. I was thinking about possible limitation regarding how many entries
could exist in the msDS-RevealOnDemandGroup multivalue attribute and if
they’d be replicated as a blob – but from checking the schema, this
is a linked attribute so I assume it also supports LVR (assuming at least FFL2;
which I don’t think is a requirement for RODC). Thus – once FFL2 is
reached – there should be no limit as to the number of accounts to
populate that attribute with. So basically – if my assumptions regarding LVR capabilities
of this attribute are correct, the msDS-RevealOnDemandGroup could be seen as
the most appropriate attribute to populate the accounts directly, unless I
really want to use or already have a security group. This way, I
don’t have to add another group to any users’ token. This would be
cool – even without repadmin’s PRP move feature, we could
auto-populate the msDS-RevealOnDemandGroup attributes of the respective RODCs
based on other queries, such as office etc. or a combination of the results
including the Auth2 entries. The only downside would maybe be that there is no back-link to the
objects, so I couldn’t check a user account and see which RODC allows
to cache its password (I know I can check the msDS-RevealedDSAs attribute
to see where a user pwd has been cached). This looks very promising! /Guido <snip> |
- RE: [ActiveDir] Read-Only Domain Controller and Server... Grillenmeier, Guido
- RE: [ActiveDir] Read-Only Domain Controller and S... Eric Fleischman
