|
Hey Brian, good to see your name on the
list...
I got pinged offline on the basis behind this
functionality. I admit to being a little shocked that someone was tossing
password type info into other attributes especially with AD being so generally
open to viewing, especially when using the Pre-W2K Compat group with
auth'ed users allowed to see all attributes by default which most domains
still seem to be in due to fears in what will break if it is turned off. If this
is purely based on security concerns, I would be more apt to tell people to
install ADAM on the DCs and put the data there. At least you know that is
severely locked down by default and not having to be worried what side direction
someone might come in and pop you from.
From the standpoint of less crap being sent down to WAN DCs
I like the idea. I realize I can't have branch level replication but at least
being able to weed out all of the non-essential attributes would be a nice start
for tiny branches with 10 users in domains with tens of thousands of users. I
actually recently had to say it didn't make any sense to move from Novell to AD
for a customer because of that very issue. You can't imagine how much that
pained me to say. In cases like that if there is no real strategic reason to
move to AD, it is better to stay on Novell because of the replication
model.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Puhl Sent: Monday, July 31, 2006 4:05 AM To: [email protected] Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core 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
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]
- RE: [ActiveDir] Read-O... Grillenmeier, Guido
- RE: [ActiveDir] Re... Eric Fleischman
