|
To be clear as your comments don’t
seem to indicate the “why” as much as Nathan’s did, we were
less interested in the bandwidth savings and more interested in the accuracy of
the list. Non-LVR link values have a value loss potential on conflicted write
across DCs. ~Eric From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido > 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= CN=Server Operators,CN= CN=Backup Operators,CN= CN=Administrators,CN= The common allow group is empty by
default. The common deny group contains the
following members: CN= CN=Group Policy Creator Owners,CN=Users,DC=X; CN=Domain Admins,CN=Users,DC=rX CN=Cert Publishers,CN=Users,DC=X CN= 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
