|
Not sure if it makes sense, but this could potentially be combined
with the confidential flag – RODCs wouldn’t cache any confidential attributes,
unless a “Confidential Data Caching Policy” would allow them to do so… The confidential flag is already used by the Digital Identity
Management Service (DIMS) for the Credential Roaming feature. And instead of
adding yet another flag to differentiate attributes which contain secrets or
sensitive data, this may just be the right flag. Granted, none of this will make life easier for app developers. /Guido From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Brian Puhl You’re right Joe – that the RODC PAS would complicate things for
the developers. The “easy” solution would be for developers to use the
writeable flag when connecting to a DC, then they’d be guaranteed to not get an
RODC…but even that isn’t a great solution, and if we get the RODC GC it only becomes
more complex. For general background though, the justification for the RODC PAS
DCR is actually that there are numerous attributes which contain password hash,
or password-like data. Because these attributes aren’t part of the
pre-defined list of “secrets”, they are replicated normally rather than
“on-demand” via the PRP. It wouldn’t do me much good to prevent
replication of 5 password attributes, when a 6th one which also
includes a hash gets pushed down through normal replication. There needs
to be a way for an administrator to define where these secrets live and protect
them accordingly. I’ve broached the topic of using this method to protect PII data a
couple of times in relation to some RODC work we’re doing internally, and the
response is always that it’s firmly in the realm of “unsupported” followed with
a “that’d be a bad idea” and some serious head shaking – simply because of the
way applications behave. Brian From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of joe I am not sure if I understand where you are going but let me
explain where I am coming from. First, the passwords being there or not being there is not
important for this talk, that is already built in and will be there, now the
discussion is around everything versus an RODC PAS. Everything is already there as well but is an important option
because it will be the most used option. Actually I expect to see a ton of
RODCs deployed that are configured as replicate everything including passwords
so that people get the RO part of the benefit and they don't have to worry
about replicating bad stuff back into the "real directory" and not
have to worry about password caching management, if someone logs on somewhere,
the password is cached there, bob's your uncle have a nice day. So now we get down to replicating a portion of the normal attribute
set. Why would you want to do this? Because you want to minimize the traffic to
WAN sites and/or reduced info in some locations in case of compromise. For
instance, if the email addresses of everyone in the company isn't on a DC in a
WAN site and someone steals that DC hoping to get those email addresses, they
are SOL; they missed. However, now think about this from a application
developer standpoint and it is the same issue that exists with GCs only worse
because it is DCs. If an app developer wants to find something, they need to
understand what they can actually find in the GC in terms of what attributes
are populated. Maybe they (a) put in a requirement and hope people follow it,
maybe they (b) actually try to verify it, maybe they (c) say screw that and
query a DC instead because they know all of the data is there for a full query.
>From what I have seen the likely cases for an app that can handle any query is
C, A, and in the absolute blue moon case B. Usually the app will just fail to
find what it needs if you specify an attribute that isn't in the GC. How does
Exchange do it??? So there are hybrids like where certain things that people
KNOW will always be in GC PAS and they will set it up so that queries using
those things will use a GC and everything else will go to a DC. We already know
that the same override that exists for the GC PAS would have to exist for an
RODC PAS so why not just make that the other option and be done with it? I
don't really see the majority of developers doing this any better with RODCs
than they do with GCs and so it seems like a lot of make work to allow for the
flexible handling of that if you just say these are the options. Again also the password thing isn't even worried about at the app
level since apps can play with those anyway. joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick Um, why? What value at this point? Last I checked it supports limited applications that might
want that information. And if you follow ~Eric's logic, they want to be secure
out of the box. That would indicate that they want it to be as minimal as
possible until and unless told otherwise. To put that information in there by default might be counter
to that. Now, if you had some templates or something so that we
didn't have to work on the carpal tunnel, that would be something....:) On 7/30/06, joe <[EMAIL PROTECTED]> wrote: RE: RODC PAS.... Oi, that will add some nice complexity to all of this... :) If I was looking to implement that I think I would look at doing it
in four levels so people don't shoot themselves... Everything, everything but
password info, core NOS info required for auth/authz with passwords, core
NOS w/o passwords. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED]
[mailto:
[EMAIL PROTECTED]] On Behalf Of Dmitri Gavrilov
The set of passwords that *can*
be sent down to the RODC is controlled by password replication policy. The
passwords are sent down by RODC's request, but the hub also checks whether the
user (whose pwd is being requested) actually attempted to authenticate at RODC
(the hub can induce this info from the traffic is sees). The pwd hash is sent
down only if both are satisfied: pwd policy allows it and the user actually
attempted to logon there. Pwd policy is "empty"
by default, i.e. nobody is in "allowed to reveal" list. It is admin's
responsibility to populate this list. We might have some UI that helps with
this process. Once the hash is sent down,
there's no way to remove it from RODC, basically because we do not trust that
RODC will remove it, even if instructed to do so. Therefore, the only way to
"expire" the hash is to change the password. We store the list of
passwords that were sent down to RODC in an attribute on the RODC computer
object (the hub DC updates the list when it sends a pwd). So, if the RODC is
stolen, you can enumerate whose passwords were down there, and make these users
reset their passwords. There's a constructed attribute that returns only the
users whose * current* passwords appear to be on the RODC. WRT what data is sent down –
currently, we send everything, sans a handful of "secret" attributes,
which are controlled by pwd replication policy. There's a DCR to be able to
configure the list of attributes that can go down to RODC (aka RODC PAS), but
it is not yet clear if we will get it done or not. Note that the client
data access story on RODC becomes quite convoluted because you don't know if
you are seeing the whole object or only a subset of it. We do not normally issue
referrals due to "partial reads". From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
On Behalf Of [EMAIL PROTECTED] RODC stores password hashes only
for a pre defined list of users and they are not stored on a permanent basis.
[I'm unclear how the latter is achieved.] The goal is such that if the RODC
were removed from the office then no password secrets could be extracted from
that machine. neil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
On Behalf Of Al Mulnick The part that makes me wonder about the "story" is if it stores no
secrets is the server doing anything for me? Is there a point to deploying
the server in a remote office other than just being able to point to it in the
closet and say, "see, I do to earn my paycheck!" I'm sure there's more, but I don't yet know which parts are public
information and which are NDA. Can you tell I'm concerned about the story being created? I like stories;
don't get me wrong. But I'm concerned that the story being spun up might
be missing the mark and lead a few people astray. Safe to note that there are some features that differentiate the RODC from a
NT4 BDC and that make it appealing in some cases. But if it actually does not store anything locally, ever, then I'm not sure
it's worth the time to deploy one now is it? Al
On 7/27/06, Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] <[EMAIL PROTECTED]>
wrote: FYI: PLEASE READ: The information contained in
this email is confidential and intended for the named recipient(s) only. If
you are not an intended recipient of this email please notify the
sender immediately and delete your copy from your system. You must not copy,
distribute or take any further action in reliance on it. Email is not a
secure method of communication and Nomura International plc ('NIplc') will not,
to the extent permitted by law, accept responsibility or liability for (a)
the accuracy or completeness of, or (b) the presence of any virus, worm or
similar malicious or disabling code in, this message or any attachment(s) to
it. If verification of this email is sought then please request a hard
copy. Unless otherwise stated this email: (1) is not, and should not be
treated or relied upon as, investment research; (2) contains views or
opinions that are solely those of the author and do not necessarily represent
those of NIplc; (3) is intended for informational purposes only and is not a
recommendation, solicitation or offer to buy or sell securities or related
financial instruments. NIplc does not provide investment services to
private customers. Authorised and regulated by the Financial Services
Authority. Registered in England no. 1550505 VAT No. 447 2492 35. Registered
Office: 1 St Martin's-le-Grand, London, EC1A 4NP. A member of the Nomura
group of companies. |
- RE: [ActiveDir] Read-Only D... Grillenmeier, Guido
- Re: [ActiveDir] Read-O... Al Mulnick
- RE: [ActiveDir] Read-O... joe
- RE: [ActiveDir] Read-O... Grillenmeier, Guido
- RE: [ActiveDir] Re... Nathan Muggli
- RE: [ActiveDir... joe
- RE: [Activ... Laura A. Robinson
- RE: [ActiveDir] Read-O... joe
- RE: [ActiveDir] Re... David Adner
- Re: [ActiveDir] Read-O... Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]
- RE: [ActiveDir] Read-O... Grillenmeier, Guido
- RE: [ActiveDir] Re... Eric Fleischman
