|
We thought about using the confidential
flag as the denotation for the RO-PAS, but that would break too many
applications. The RO-PAS would only be for applications
that wanted to protect their secrets from replicating to a RODC. DIMS (aka cred
roaming) is a prime example. Most likely if RO-PAS happens it will be a “negative”
PAS in that the marking in the schema would mean that the attr is NOT
replicated. That way new vanilla attributes are replicated to a RODC which
would minimize app compat. -Nathan Muggli RODC Program Manager From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido 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 no.
1550505 VAT No. 447 2492 35. Registered Office: 1 |
- RE: [ActiveDir] Read-Only D... Nathan Muggli
- RE: [ActiveDir] Read-O... joe
- RE: [ActiveDir] Re... Laura A. Robinson
- Re: [ActiveDir] Read-O... Al Mulnick
- RE: [ActiveDir] Read-O... joe
- RE: [ActiveDir] Re... David Adner
- RE: [ActiveDir] Read-O... joe
- Re: [ActiveDir] Read-O... Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]
