| Author | Messages | |
sbradcpa
Posts:496
 | | 07/27/2006 4:58 AM |
| FYI:
http://blogs.msdn.com/jolson/archive/2006/07/27/679801.aspx
Read-Only Domain Controller and Server Core
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx | | | |
| amulnick
Posts:163
| | 07/28/2006 3:07 AM |
| 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] wrote:
FYI:http://blogs.msdn.com/jolson/archive/2006/07/27/679801.aspx
Read-Only Domain Controller and Server CoreList info : http://www.activedir.org/List.aspxList FAQ :
http://www.activedir.org/ListFAQ.aspxList archive: http://www.activedir.org/ml/threads.aspx | | | |
| AD000001290
Posts:0
| | 07/28/2006 3:23 AM |
| 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Al
MulnickSent: 28 July 2006 16:08To:
ActiveDir@xxxxxxxxxxxxxxxxxxSubject: Re: [ActiveDir] Read-Only Domain
Controller and Server Core
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] sbradcpa@xxxxxxxxxxx> wrote:
FYI:http://blogs.msdn.com/jolson/archive/2006/07/27/679801.aspx
Read-Only
Domain Controller and Server CoreList info :
http://www.activedir.org/List.aspxList
FAQ : http://www.activedir.org/ListFAQ.aspxList
archive: http://www.activedir.org/ml/threads.aspxPLEASE 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. | | | |
| dmitrig@xxxx.yyy
| | 07/28/2006 4:48 AM |
| 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:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On
Behalf Of neil.ruston@xxxxxxxxxxxxx
Sent: Friday, July 28, 2006 8:22 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Al Mulnick
Sent: 28 July 2006 16:08
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] Read-Only Domain Controller and Server Core
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]
wrote:
FYI:
http://blogs.msdn.com/jolson/archive/2006/07/27/679801.aspx
Read-Only Domain Controller
and Server Core
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
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. | | | |
| efleis1
Posts:0
| | 07/28/2006 5:04 AM |
| To add a bit more¦
> The part that makes me
wonder about the "story" is if it stores no secrets is the server
doing anything for me?
The short answer is yes.
The bulk of the work that a DC does, even
in the auth code path, may not involve the secret. So even if the secret
checking work is outsourced to a hub DC, there is a lot more work
that the local DC can perform for the user. For example, if it is an
interactive logon, consider all of the GP work alone that is done that is now
local.
At the end of the day, you have a knob¦.you
can make real security trade-offs based upon what attack surface you can accept
& mitigate, what administrative story you want, etc. You get to choose what
secrets end up on the RODC. The product is built such that you can turn these
knobs as you see fit but the default knob setting is more secure.
I hope between my response and Dmitri™s
you are clear that the belief that it stores nothing locally is
incorrect. If more clarity is required please just holler.
~Eric
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On
Behalf Of Dmitri Gavrilov
Sent: Friday, July 28, 2006 9:48
AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only
Domain Controller and Server Core
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On
Behalf Of neil.ruston@xxxxxxxxxxxxx
Sent: Friday, July 28, 2006 8:22
AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only
Domain Controller and Server Core
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:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Al Mulnick
Sent: 28 July 2006 16:08
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] Read-Only
Domain Controller and Server Core
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] sbradcpa@xxxxxxxxxxx> wrote:
FYI:
http://blogs.msdn.com/jolson/archive/2006/07/27/679801.aspx
Read-Only Domain Controller
and Server Core
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
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. | | | |
| amulnick
Posts:163
| | 07/28/2006 5:23 AM |
| Or is that something that some admin can configure and hurt themselves? Better yet, if that were true, is there any value left in the RODC that can't get a password hash?
On 7/28/06, Dmitri Gavrilov wrote:
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of
neil.ruston@xxxxxxxxxxxxxSent: Friday, July 28, 2006 8:22 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core
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:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of
Al MulnickSent: 28 July 2006 16:08To: ActiveDir@xxxxxxxxxxxxxxxxxxSubject:
Re: [ActiveDir] Read-Only Domain Controller and Server Core
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] wrote:
FYI:http://blogs.msdn.com/jolson/archive/2006/07/27/679801.aspx
Read-Only Domain Controller and Server CoreList info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspxList archive:
http://www.activedir.org/ml/threads.aspx
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. | | | |
| amulnick
Posts:163
| | 07/28/2006 5:33 AM |
| Authentication and name resolution are my biggest uses for a local DC in a branch. Outside of Exchange of course. Everything else I try to keep as compartmentalized as I can because if my WAN is a concern such that I can't use authentication across the wire (or can't trust it) then I have some big concerns about the branch environment and how autonomous it is.
Outside of "GP work" what else comes to mind that is off-loaded to the local site that you can think of?
Perhaps I'm looking at this sideways?
On 7/28/06, Eric Fleischman wrote:
To add a bit more¦
> The part that makes me wonder about the "story" is if it stores no secrets is the server doing anything for me?
The short answer is yes.
The bulk of the work that a DC does, even in the auth code path, may not involve the secret. So even if the secret checking work is "outsourced" to a hub DC, there is a lot more work that the local DC can perform for the user. For example, if it is an interactive logon, consider all of the GP work alone that is done that is now local.
At the end of the day, you have a knob¦.you can make real security trade-offs based upon what attack surface you can accept & mitigate, what administrative story you want, etc. You get to choose what secrets end up on the RODC. The product is built such that you can turn these knobs as you see fit but the default knob setting is "more secure".
I hope between my response and Dmitri's you are clear that the belief that it stores "nothing locally" is incorrect. If more clarity is required please just holler.
~Eric
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of Dmitri GavrilovSent: Friday, July 28, 2006 9:48 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core
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:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of neil.ruston@xxxxxxxxxxxxxSent:
Friday, July 28, 2006 8:22 AMTo: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core
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:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Al MulnickSent: 28 July 2006 16:08
To: ActiveDir@xxxxxxxxxxxxxxxxxxSubject:
Re: [ActiveDir] Read-Only Domain Controller and Server Core
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] wrote:
FYI:
http://blogs.msdn.com/jolson/archive/2006/07/27/679801.aspx Read-Only Domain Controller and Server CoreList info :
http://www.activedir.org/List.aspxList FAQ : http://www.activedir.org/ListFAQ.aspxList archive:
http://www.activedir.org/ml/threads.aspx
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. | | | |
| efleis1
Posts:0
| | 07/28/2006 7:42 AM |
| Hi Al,
Take your workstation and take a sniff of
a logon. All traffic you throw at the DC will work against the RODC. The only
WAN traffic in that scenario would be the auth itself, a tiny amt of work. (assuming
GC and all that is satisfied locally)
So, the statement that authentication is
your biggest use is true, kinda¦you need to more carefully define the
operation. I suspect you don™t mean auth in the Kerberos sense, you mean user
logon really. Unless your branch has a bunch of apps that do Kerb work
and no clients¦.then you can correct me and we have a totally different
conversation on our hands. :)
Answering some questions of yours, from
this and other forks of the thread¦..
> What conditions would
make it so that the password policy would be configured such that the password
replication
> was not allowed?
There is a policy (not group policy,
administrative one defined in AD itself) which defines what can be cached there
and what can not. The statement made (I think first by Dmitri, but I then
commented on it further) was that by default, this policy allows almost nothing
to be cached. You could tweak this in your enterprise and change what is cached,
anything from the near-nothing default to almost every secret in the domain. You
can choose.
> Would that just be that
the RODC is no longer trusted (i.e. it was abducted or otherwise compromised?)
Well, we never know if an RODC was
compromised. Rather, RODC was built such that you the admin can assume they are
compromised, and fully understand the scope of compromise in your enterprise
should it happen one day, and respond to said event.
So, I say you should look at this problem
the other way¦. Treat your RODCs as if
they were about to get compromised, then make real decisions around how much
work the recovery from said compromise would be vs. actually having an
environment that is useful, reliable, easy to manage, etc. That™s what I was
talking about re: the knobs¦.you can turn said knobs and make decisions
that work for you. And we™ll have documentation that will help you do
this.
> Or is that something that some admin can configure and hurt
themselves? Better yet, if that were true, is there any value left in the
> RODC that can't get a password hash?
I think I answered this but please holler
if it is still unclear.
> Outside of "GP
work" what else comes to mind that is off-loaded to the local site that
you can think of?
Take a network sniff of your clients
talking to your DCs for a day. Almost all of that stuff. J You could have apps, you
have logon itself, etc.
> Perhaps I'm looking at
this sideways?
Every environment is different. It is
entirely possible that a secret-less RODC is totally uninteresting in your enterprise.
That said, I would argue that you probably haven™t done enough
investigation yet to really know if that™s true or not¦it™s
not personal, why would you? This has likely never been relevant. Almost no one
does this sort of analysis unless they absolutely have to.
Take some data, please report back to us.
I™d love to look at said data with you if you™re unclear as to what
would fall in what bucket.
Hope this helps. Please holler back with
questions.
~Eric
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On
Behalf Of Al Mulnick
Sent: Friday, July 28, 2006 10:34
AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] Read-Only
Domain Controller and Server Core
More clarity is always welcome.
I suspect I'm trying to get my mind around the GPO providing that much
value that I would want to put a DC in the local brach as part of the design
vs. trying really hard to use as little of the GPO as possible and making sure
that the changes are as infrequent as possible.
Authentication and name resolution are my biggest uses for a local DC in
a branch. Outside of Exchange of course. Everything else I try to keep as
compartmentalized as I can because if my WAN is a concern such that I can't use
authentication across the wire (or can't trust it) then I have some big
concerns about the branch environment and how autonomous it is.
Outside of "GP work" what else comes to mind that is
off-loaded to the local site that you can think of?
Perhaps I'm looking at this sideways?
On 7/28/06, Eric
Fleischman
wrote:
To add a bit more¦
> The part that makes me wonder about the
"story" is if it stores no secrets is the server doing anything for
me?
The short answer is yes.
The bulk of the work that a DC does, even in the auth code
path, may not involve the secret. So even if the secret checking work is
"outsourced" to a hub DC, there is a lot more work that the local DC
can perform for the user. For example, if it is an interactive logon, consider
all of the GP work alone that is done that is now local.
At the end of the day, you have a knob¦.you can make
real security trade-offs based upon what attack surface you can accept &
mitigate, what administrative story you want, etc. You get to choose what
secrets end up on the RODC. The product is built such that you can turn these
knobs as you see fit but the default knob setting is "more secure".
I hope between my response and Dmitri's you are clear that
the belief that it stores "nothing locally" is incorrect. If more
clarity is required please just holler.
~Eric
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of Dmitri Gavrilov
Sent: Friday, July 28, 2006 9:48
AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE:
[ActiveDir] Read-Only Domain Controller and Server Core
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of neil.ruston@xxxxxxxxxxxxx
Sent: Friday, July 28, 2006 8:22
AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only
Domain Controller and Server Core
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On
Behalf Of Al Mulnick
Sent: 28 July 2006 16:08
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] Read-Only
Domain Controller and Server Core
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] wrote:
FYI:
http://blogs.msdn.com/jolson/archive/2006/07/27/679801.aspx
Read-Only Domain Controller
and Server Core
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
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. | | | |
| GuidoG
Posts:114
| | 07/28/2006 8:33 AM |
| Could be worth to note that an RODC can also be a DNS server for
the respective BO. As it is designed for one-way replication from a writeable
DC, it does not allow direct dynamic updates of DNS records that are requested
to be updated by clients that use the RODC as a DNS server (same is true for
password changes) => these are basically forwarded to the next writeable DC
and then replicated back to the RODC. Sounds complicated, but makes sense as the
RODC should be regarded as an untrusted DC.
I am certainly a friend of combining RODC with Server Core for BO
environments. Combine this with the Admin Separation features of RODC and you
have a great BO story. Admin Separation means that you can make a non-domain
admin a member of the local admin group on an RODC, without granting him/her
admin rights in AD. Server Core will obviously not only be useful for BOs “
they can also host writeable DCs in a company™s datacenters.
Biggest challenge I see is configuring the policies for storing
credentials on RODCs “ it™s the typical challenge of matching
mobile objects (users and notebooks) to non-mobile devices (an RODC in a site).
And currently this is all based on group memberships. I hope to see an option coming
up to use OU™s instead.
I do agree with Al, that the original blog entry that started this
discussion was a little misleading and didn™t do the features of RODC
justice.
/Guido
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Eric Fleischman
Sent: Friday, July 28, 2006 9:42 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core
Hi Al,
Take your workstation and take a sniff of a logon. All traffic you
throw at the DC will work against the RODC. The only WAN traffic in that
scenario would be the auth itself, a tiny amt of work. (assuming GC and all
that is satisfied locally)
So, the statement that authentication is your biggest use is true,
kinda¦you need to more carefully define the operation. I suspect you
don™t mean auth in the Kerberos sense, you mean user logon
really. Unless your branch has a bunch of apps that do Kerb work and no
clients¦.then you can correct me and we have a totally different
conversation on our hands. :)
Answering some questions of yours, from this and other forks of the
thread¦..
> What conditions would make it so that the password
policy would be configured such that the password replication
> was not allowed?
There is a policy (not group policy, administrative one defined in
AD itself) which defines what can be cached there and what can not. The
statement made (I think first by Dmitri, but I then commented on it further)
was that by default, this policy allows almost nothing to be cached. You could
tweak this in your enterprise and change what is cached, anything from the
near-nothing default to almost every secret in the domain. You can choose.
> Would that just be that the RODC is no longer trusted
(i.e. it was abducted or otherwise compromised?)
Well, we never know if an RODC was compromised. Rather, RODC was
built such that you the admin can assume they are compromised, and fully
understand the scope of compromise in your enterprise should it happen one day,
and respond to said event.
So, I say you should look at this problem the other way¦.
Treat your RODCs as if they were about to get compromised, then make
real decisions around how much work the recovery from said compromise would be
vs. actually having an environment that is useful, reliable, easy to manage,
etc. That™s what I was talking about re: the knobs¦.you can turn
said knobs and make decisions that work for you. And we™ll have documentation
that will help you do this.
> Or is that something that some admin can configure and
hurt themselves? Better yet, if that were true, is there any value left in the
> RODC that can't get a password hash?
I think I answered this but please holler if it is still unclear.
> Outside of "GP work" what else comes to mind
that is off-loaded to the local site that you can think of?
Take a network sniff of your clients talking to your DCs for a day.
Almost all of that stuff. J You could have apps, you have logon itself, etc.
> Perhaps I'm looking at this sideways?
Every environment is different. It is entirely possible that a
secret-less RODC is totally uninteresting in your enterprise. That said, I
would argue that you probably haven™t done enough investigation yet to
really know if that™s true or not¦it™s not personal, why
would you? This has likely never been relevant. Almost no one does this sort of
analysis unless they absolutely have to.
Take some data, please report back to us. I™d love to look at
said data with you if you™re unclear as to what would fall in what
bucket.
Hope this helps. Please holler back with questions.
~Eric
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On
Behalf Of Al Mulnick
Sent: Friday, July 28, 2006 10:34 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] Read-Only Domain Controller and Server Core
More clarity is always welcome.
I suspect I'm trying to get my mind around the GPO providing
that much value that I would want to put a DC in the local brach as part of the
design vs. trying really hard to use as little of the GPO as possible and
making sure that the changes are as infrequent as possible.
Authentication and name resolution are my biggest uses for a
local DC in a branch. Outside of Exchange of course. Everything else I
try to keep as compartmentalized as I can because if my WAN is a concern such
that I can't use authentication across the wire (or can't trust it) then I have
some big concerns about the branch environment and how autonomous it is.
Outside of "GP work" what else comes to mind that
is off-loaded to the local site that you can think of?
Perhaps I'm looking at this sideways?
On 7/28/06, Eric Fleischman
wrote:
To
add a bit more¦
>
The part that makes me wonder about the "story" is if it
stores no secrets is the server doing anything for me?
The
short answer is yes.
The
bulk of the work that a DC does, even in the auth code path, may not involve
the secret. So even if the secret checking work is "outsourced" to a
hub DC, there is a lot more work that the local DC can perform for the user.
For example, if it is an interactive logon, consider all of the GP work alone
that is done that is now local.
At
the end of the day, you have a knob¦.you can make real security
trade-offs based upon what attack surface you can accept & mitigate, what
administrative story you want, etc. You get to choose what secrets end up on
the RODC. The product is built such that you can turn these knobs as you see
fit but the default knob setting is "more secure".
I
hope between my response and Dmitri's you are clear that the belief that it
stores "nothing locally" is incorrect. If more clarity is required
please just holler.
~Eric
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of Dmitri Gavrilov
Sent: Friday, July 28, 2006 9:48 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only Domain Controller and
Server Core
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of neil.ruston@xxxxxxxxxxxxx
Sent: Friday, July 28, 2006 8:22 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Al Mulnick
Sent: 28 July 2006 16:08
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] Read-Only Domain Controller and Server Core
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] sbradcpa@xxxxxxxxxxx>
wrote:
FYI:
http://blogs.msdn.com/jolson/archive/2006/07/27/679801.aspx
Read-Only Domain Controller
and Server Core
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
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. | | | |
| efleis1
Posts:0
| | 07/28/2006 9:02 AM |
| > And currently this is all based on group memberships. I hope to see an option
coming up to use OU™s instead.
To be clear, OUs are a Guido likes
the way this looks feature, not a this helps the problem feature.
The crux of the problem is figuring out
who to cache on a given RODC. If you know this¦by OU membership or
something else¦constructing a group with said membership is trivial. However,
if you don™t know this, OU based policy is not going to help.
With that, I™ll state in public that
my vote is not to build OU based policy. Why? Because it doesn™t fix the
problem. Instead, I want to spend our engineering dollars building tools to
help users find who should be cached where¦ie, tackling the problem
itself head on. Whether you then organize by OU or just populate groups is the
easy part.
~Eric
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Grillenmeier, Guido
Sent: Friday, July 28, 2006 1:33
PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only
Domain Controller and Server Core
Could be worth to note that an RODC can
also be a DNS server for the respective BO. As it is designed for one-way
replication from a writeable DC, it does not allow direct dynamic updates of
DNS records that are requested to be updated by clients that use the RODC as a
DNS server (same is true for password changes) => these are basically
forwarded to the next writeable DC and then replicated back to the RODC. Sounds
complicated, but makes sense as the RODC should be regarded as an
untrusted DC.
I am certainly a friend of combining
RODC with Server Core for BO environments. Combine this with the Admin
Separation features of RODC and you have a great BO story. Admin Separation
means that you can make a non-domain admin a member of the local admin group on
an RODC, without granting him/her admin rights in AD. Server Core will
obviously not only be useful for BOs “ they can also host writeable DCs
in a company™s datacenters.
Biggest challenge I see is configuring
the policies for storing credentials on RODCs “ it™s the typical
challenge of matching mobile objects (users and notebooks) to non-mobile
devices (an RODC in a site). And currently this is all based on group
memberships. I hope to see an option coming up to use OU™s instead.
I do agree with Al, that the original
blog entry that started this discussion was a little misleading and
didn™t do the features of RODC justice.
/Guido
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Eric Fleischman
Sent: Friday, July 28, 2006 9:42
PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only
Domain Controller and Server Core
Hi Al,
Take your workstation and take a sniff of
a logon. All traffic you throw at the DC will work against the RODC. The only
WAN traffic in that scenario would be the auth itself, a tiny amt of work.
(assuming GC and all that is satisfied locally)
So, the statement that authentication is
your biggest use is true, kinda¦you need to more carefully define the
operation. I suspect you don™t mean auth in the Kerberos sense, you mean
user logon really. Unless your branch has a bunch of apps that do
Kerb work and no clients¦.then you can correct me and we have a totally
different conversation on our hands. :)
Answering some questions of yours, from
this and other forks of the thread¦..
> What conditions would
make it so that the password policy would be configured such that the password
replication
> was not allowed?
There is a policy (not group policy,
administrative one defined in AD itself) which defines what can be cached there
and what can not. The statement made (I think first by Dmitri, but I then
commented on it further) was that by default, this policy allows almost nothing
to be cached. You could tweak this in your enterprise and change what is
cached, anything from the near-nothing default to almost every secret in the
domain. You can choose.
> Would that just be that
the RODC is no longer trusted (i.e. it was abducted or otherwise compromised?)
Well, we never know if an RODC was
compromised. Rather, RODC was built such that you the admin can assume they are
compromised, and fully understand the scope of compromise in your enterprise
should it happen one day, and respond to said event.
So, I say you should look at this problem
the other way¦. Treat your RODCs as if
they were about to get compromised, then make real decisions around how much
work the recovery from said compromise would be vs. actually having an
environment that is useful, reliable, easy to manage, etc. That™s what I
was talking about re: the knobs¦.you can turn said knobs and make
decisions that work for you. And we™ll have documentation that will help
you do this.
> Or is that something that some admin can configure and hurt
themselves? Better yet, if that were true, is there any value left in the
> RODC that can't get a password hash?
I think I answered this but please holler
if it is still unclear.
> Outside of "GP
work" what else comes to mind that is off-loaded to the local site that
you can think of?
Take a network sniff of your clients
talking to your DCs for a day. Almost all of that stuff. J You could have apps, you
have logon itself, etc.
> Perhaps I'm looking at
this sideways?
Every environment is different. It is
entirely possible that a secret-less RODC is totally uninteresting in your
enterprise. That said, I would argue that you probably haven™t done
enough investigation yet to really know if that™s true or not¦it™s
not personal, why would you? This has likely never been relevant. Almost no one
does this sort of analysis unless they absolutely have to.
Take some data, please report back to us.
I™d love to look at said data with you if you™re unclear as to what
would fall in what bucket.
Hope this helps. Please holler back with
questions.
~Eric
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Al Mulnick
Sent: Friday, July 28, 2006 10:34
AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] Read-Only
Domain Controller and Server Core
More clarity is always welcome.
I suspect I'm trying to get my mind around the GPO providing that much
value that I would want to put a DC in the local brach as part of the design
vs. trying really hard to use as little of the GPO as possible and making sure
that the changes are as infrequent as possible.
Authentication and name resolution are my biggest uses for a local DC
in a branch. Outside of Exchange of course. Everything else I try to keep
as compartmentalized as I can because if my WAN is a concern such that I can't
use authentication across the wire (or can't trust it) then I have some big
concerns about the branch environment and how autonomous it is.
Outside of "GP work" what else comes to mind that is
off-loaded to the local site that you can think of?
Perhaps I'm looking at this sideways?
On 7/28/06, Eric
Fleischman
wrote:
To add a bit more¦
> The part that makes me wonder about the
"story" is if it stores no secrets is the server doing anything for
me?
The short answer is yes.
The bulk of the work that a DC does, even in the auth code
path, may not involve the secret. So even if the secret checking work is
"outsourced" to a hub DC, there is a lot more work that the local DC
can perform for the user. For example, if it is an interactive logon, consider
all of the GP work alone that is done that is now local.
At the end of the day, you have a knob¦.you can make
real security trade-offs based upon what attack surface you can accept &
mitigate, what administrative story you want, etc. You get to choose what
secrets end up on the RODC. The product is built such that you can turn these
knobs as you see fit but the default knob setting is "more secure".
I hope between my response and Dmitri's you are clear that
the belief that it stores "nothing locally" is incorrect. If more
clarity is required please just holler.
~Eric
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of Dmitri Gavrilov
Sent: Friday, July 28, 2006 9:48
AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE:
[ActiveDir] Read-Only Domain Controller and Server Core
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of neil.ruston@xxxxxxxxxxxxx
Sent: Friday, July 28, 2006 8:22
AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only
Domain Controller and Server Core
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On
Behalf Of Al Mulnick
Sent: 28 July 2006 16:08
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] Read-Only
Domain Controller and Server Core
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] wrote:
FYI:
http://blogs.msdn.com/jolson/archive/2006/07/27/679801.aspx
Read-Only Domain Controller
and Server Core
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
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. | | | |
| efleis1
Posts:0
| | 07/28/2006 9:03 AM |
| Hehe, nice, I said OU membership instead
of being in the OU. The terms are easy to mix up. ;)
From: Eric Fleischman
Sent: Friday, July 28, 2006 2:02
PM
To: 'ActiveDir@xxxxxxxxxxxxxxxxxx'
Subject: RE: [ActiveDir] Read-Only
Domain Controller and Server Core
> And currently this is all based on group memberships. I hope to see an option
coming up to use OU™s instead.
To be clear, OUs are a Guido likes
the way this looks feature, not a this helps the problem
feature.
The crux of the problem is figuring out
who to cache on a given RODC. If you know this¦by OU membership or
something else¦constructing a group with said membership is trivial.
However, if you don™t know this, OU based policy is not going to help.
With that, I™ll state in public that
my vote is not to build OU based policy. Why? Because it doesn™t fix the
problem. Instead, I want to spend our engineering dollars building tools to
help users find who should be cached where¦ie, tackling the problem
itself head on. Whether you then organize by OU or just populate groups is the
easy part.
~Eric
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Grillenmeier, Guido
Sent: Friday, July 28, 2006 1:33
PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only
Domain Controller and Server Core
Could be worth to note that an RODC can
also be a DNS server for the respective BO. As it is designed for one-way
replication from a writeable DC, it does not allow direct dynamic updates of
DNS records that are requested to be updated by clients that use the RODC as a
DNS server (same is true for password changes) => these are basically
forwarded to the next writeable DC and then replicated back to the RODC. Sounds
complicated, but makes sense as the RODC should be regarded as an
untrusted DC.
I am certainly a friend of combining
RODC with Server Core for BO environments. Combine this with the Admin
Separation features of RODC and you have a great BO story. Admin Separation
means that you can make a non-domain admin a member of the local admin group on
an RODC, without granting him/her admin rights in AD. Server Core will
obviously not only be useful for BOs “ they can also host writeable DCs
in a company™s datacenters.
Biggest challenge I see is configuring
the policies for storing credentials on RODCs “ it™s the typical
challenge of matching mobile objects (users and notebooks) to non-mobile
devices (an RODC in a site). And currently this is all based on group
memberships. I hope to see an option coming up to use OU™s instead.
I do agree with Al, that the original
blog entry that started this discussion was a little misleading and
didn™t do the features of RODC justice.
/Guido
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Eric Fleischman
Sent: Friday, July 28, 2006 9:42
PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only
Domain Controller and Server Core
Hi Al,
Take your workstation and take a sniff of
a logon. All traffic you throw at the DC will work against the RODC. The only
WAN traffic in that scenario would be the auth itself, a tiny amt of work. (assuming
GC and all that is satisfied locally)
So, the statement that authentication is
your biggest use is true, kinda¦you need to more carefully define the
operation. I suspect you don™t mean auth in the Kerberos sense, you mean
user logon really. Unless your branch has a bunch of apps that do
Kerb work and no clients¦.then you can correct me and we have a totally
different conversation on our hands. :)
Answering some questions of yours, from
this and other forks of the thread¦..
> What conditions would
make it so that the password policy would be configured such that the password
replication
> was not allowed?
There is a policy (not group policy,
administrative one defined in AD itself) which defines what can be cached there
and what can not. The statement made (I think first by Dmitri, but I then
commented on it further) was that by default, this policy allows almost nothing
to be cached. You could tweak this in your enterprise and change what is
cached, anything from the near-nothing default to almost every secret in the
domain. You can choose.
> Would that just be that
the RODC is no longer trusted (i.e. it was abducted or otherwise compromised?)
Well, we never know if an RODC was
compromised. Rather, RODC was built such that you the admin can assume they are
compromised, and fully understand the scope of compromise in your enterprise
should it happen one day, and respond to said event.
So, I say you should look at this problem
the other way¦. Treat your RODCs as if
they were about to get compromised, then make real decisions around how much
work the recovery from said compromise would be vs. actually having an
environment that is useful, reliable, easy to manage, etc. That™s what I
was talking about re: the knobs¦.you can turn said knobs and make
decisions that work for you. And we™ll have documentation that will help
you do this.
> Or is that something that some admin can configure and hurt
themselves? Better yet, if that were true, is there any value left in the
> RODC that can't get a password hash?
I think I answered this but please holler
if it is still unclear.
> Outside of "GP
work" what else comes to mind that is off-loaded to the local site that
you can think of?
Take a network sniff of your clients
talking to your DCs for a day. Almost all of that stuff. J You could have apps, you
have logon itself, etc.
> Perhaps I'm looking at
this sideways?
Every environment is different. It is
entirely possible that a secret-less RODC is totally uninteresting in your enterprise.
That said, I would argue that you probably haven™t done enough
investigation yet to really know if that™s true or not¦it™s
not personal, why would you? This has likely never been relevant. Almost no one
does this sort of analysis unless they absolutely have to.
Take some data, please report back to us.
I™d love to look at said data with you if you™re unclear as to what
would fall in what bucket.
Hope this helps. Please holler back with
questions.
~Eric
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Al Mulnick
Sent: Friday, July 28, 2006 10:34
AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] Read-Only
Domain Controller and Server Core
More clarity is always welcome.
I suspect I'm trying to get my mind around the GPO providing that much
value that I would want to put a DC in the local brach as part of the design
vs. trying really hard to use as little of the GPO as possible and making sure
that the changes are as infrequent as possible.
Authentication and name resolution are my biggest uses for a local DC
in a branch. Outside of Exchange of course. Everything else I try to keep
as compartmentalized as I can because if my WAN is a concern such that I can't
use authentication across the wire (or can't trust it) then I have some big
concerns about the branch environment and how autonomous it is.
Outside of "GP work" what else comes to mind that is
off-loaded to the local site that you can think of?
Perhaps I'm looking at this sideways?
On 7/28/06, Eric
Fleischman
wrote:
To add a bit more¦
> The part that makes me wonder about the
"story" is if it stores no secrets is the server doing anything for
me?
The short answer is yes.
The bulk of the work that a DC does, even in the auth code
path, may not involve the secret. So even if the secret checking work is
"outsourced" to a hub DC, there is a lot more work that the local DC
can perform for the user. For example, if it is an interactive logon, consider
all of the GP work alone that is done that is now local.
At the end of the day, you have a knob¦.you can make real
security trade-offs based upon what attack surface you can accept &
mitigate, what administrative story you want, etc. You get to choose what
secrets end up on the RODC. The product is built such that you can turn these
knobs as you see fit but the default knob setting is "more secure".
I hope between my response and Dmitri's you are clear that
the belief that it stores "nothing locally" is incorrect. If more
clarity is required please just holler.
~Eric
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of Dmitri Gavrilov
Sent: Friday, July 28, 2006 9:48
AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE:
[ActiveDir] Read-Only Domain Controller and Server Core
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of neil.ruston@xxxxxxxxxxxxx
Sent: Friday, July 28, 2006 8:22
AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only
Domain Controller and Server Core
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On
Behalf Of Al Mulnick
Sent: 28 July 2006 16:08
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] Read-Only
Domain Controller and Server Core
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] wrote:
FYI:
http://blogs.msdn.com/jolson/archive/2006/07/27/679801.aspx
Read-Only Domain Controller
and Server Core
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
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. | | | |
| amulnick
Posts:163
| | 07/28/2006 10:28 AM |
| I'll ping back if I get lost watching the traces. I appreciate the offer and you guys taking the time to discuss this.
Al
On 7/28/06, Eric Fleischman wrote:
Hi Al,
Take your workstation and take a sniff of a logon. All traffic you throw at the DC will work against the RODC. The only WAN traffic in that scenario would be the auth itself, a tiny amt of work. (assuming GC and all that is satisfied locally)
So, the statement that authentication is your biggest use is true, kinda¦you need to more carefully define the operation. I suspect you don't mean auth in the Kerberos sense, you mean "user logon" really. Unless your branch has a bunch of apps that do Kerb work and no clients¦.then you can correct me and we have a totally different conversation on our hands. :)
Answering some questions of yours, from this and other forks of the thread¦..
> What conditions would make it so that the password policy would be configured such that the password replication
> was not allowed?
There is a policy (not group policy, administrative one defined in AD itself) which defines what can be cached there and what can not. The statement made (I think first by Dmitri, but I then commented on it further) was that by default, this policy allows almost nothing to be cached. You could tweak this in your enterprise and change what is cached, anything from the near-nothing default to almost every secret in the domain. You can choose.
> Would that just be that the RODC is no longer trusted (i.e. it was abducted or otherwise compromised?)
Well, we never know if an RODC was compromised. Rather, RODC was built such that you the admin can assume they are compromised, and fully understand the scope of compromise in your enterprise should it happen one day, and respond to said event.
So, I say you should look at this problem the other way¦. Treat your RODCs as if
they were about to get compromised, then make real decisions around how much work the recovery from said compromise would be vs. actually having an environment that is useful, reliable, easy to manage, etc. That's what I was talking about re: the knobs¦.you can turn said knobs and make decisions that work for you. And we'll have documentation that will help you do this.
> Or is that something that some admin can configure and hurt themselves? Better yet, if that were true, is there any value left in the
> RODC that can't get a password hash?
I think I answered this but please holler if it is still unclear.
> Outside of "GP work" what else comes to mind that is off-loaded to the local site that you can think of?
Take a network sniff of your clients talking to your DCs for a day. Almost all of that stuff.
J You could have apps, you have logon itself, etc.
> Perhaps I'm looking at this sideways?
Every environment is different. It is entirely possible that a secret-less RODC is totally uninteresting in your enterprise. That said, I would argue that you probably haven't done enough investigation yet to really know if that's true or not¦it's not personal, why would you? This has likely never been relevant. Almost no one does this sort of analysis unless they absolutely have to.
Take some data, please report back to us. I'd love to look at said data with you if you're unclear as to what would fall in what bucket.
Hope this helps. Please holler back with questions.
~Eric
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of Al MulnickSent: Friday, July 28, 2006 10:34 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] Read-Only Domain Controller and Server Core
More clarity is always welcome.
I suspect I'm trying to get my mind around the GPO providing that much value that I would want to put a DC in the local brach as part of the design vs. trying really hard to use as little of the GPO as possible and making sure that the changes are as infrequent as possible.
Authentication and name resolution are my biggest uses for a local DC in a branch. Outside of Exchange of course. Everything else I try to keep as compartmentalized as I can because if my WAN is a concern such that I can't use authentication across the wire (or can't trust it) then I have some big concerns about the branch environment and how autonomous it is.
Outside of "GP work" what else comes to mind that is off-loaded to the local site that you can think of?
Perhaps I'm looking at this sideways?
On 7/28/06, Eric Fleischman wrote:
To add a bit more¦
> The part that makes me wonder about the "story" is if it stores no secrets is the server doing anything for me?
The short answer is yes.
The bulk of the work that a DC does, even in the auth code path, may not involve the secret. So even if the secret checking work is "outsourced" to a hub DC, there is a lot more work that the local DC can perform for the user. For example, if it is an interactive logon, consider all of the GP work alone that is done that is now local.
At the end of the day, you have a knob¦.you can make real security trade-offs based upon what attack surface you can accept & mitigate, what administrative story you want, etc. You get to choose what secrets end up on the RODC. The product is built such that you can turn these knobs as you see fit but the default knob setting is "more secure".
I hope between my response and Dmitri's you are clear that the belief that it stores "nothing locally" is incorrect. If more clarity is required please just holler.
~Eric
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of Dmitri GavrilovSent: Friday, July 28, 2006 9:48 AM
To:
ActiveDir@xxxxxxxxxxxxxxxxxx Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core
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:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of neil.ruston@xxxxxxxxxxxxxSent:
Friday, July 28, 2006 8:22 AMTo: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core
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:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Al MulnickSent: 28 July 2006 16:08
To: ActiveDir@xxxxxxxxxxxxxxxxxxSubject:
Re: [ActiveDir] Read-Only Domain Controller and Server Core
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] wrote:
FYI:
http://blogs.msdn.com/jolson/archive/2006/07/27/679801.aspx Read-Only Domain Controller and Server CoreList info :
http://www.activedir.org/List.aspxList FAQ : http://www.activedir.org/ListFAQ.aspxList archive:
http://www.activedir.org/ml/threads.aspx
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. | | | |
| amulnick
Posts:163
| | 07/29/2006 2:06 AM |
| But I'm wondering if you've seen differently? If anyone else sees another way of solving the issue, I'm interested in hearing about it if you can share. I wonder about it because trying to get them to fit into an OU by geography can be a tough approach with lots of touch times. They will constantly move in and out of many different geo's during a given time period. The users move around a lot as well and some have high turnover.
Interesting.
Al
On 7/29/06, Grillenmeier, Guido wrote:
But very useful idle chatter nonetheless ;-)
/Guido
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Eric FleischmanSent:
Saturday, July 29, 2006 8:35 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxxSubject:
RE: [ActiveDir] Read-Only Domain Controller and Server Core
You basically articulated my point for me. J
> And once tools exist to automate this knowledge whether by populating groups or attributes (such as office or address)
> or leveraging an OU structure, it really doesn't matter which mechanism is used to configure the RODC policies.
Yup. My contention is that in many cases, I think this will be non-trivial for customers. They will have trouble knowing where security principals are¦.especially computers. So we need to spend engineering effort here (the Auth2 list should help with this though).
> However, many companies have organized their AD with a geographic OU structure, which doesn't necessarily match
> 100% to their site structure, but certainly gets pretty close
Yes, and because it is not 100%, they'll either need to move users around across their OUs (which has other implications, like on delegation) or use groups to work around it. ;)
My contention is not that OUs are a bad idea for this sort of policy. Only that:
- For many customers they will not work. Groups will work for all customers, even the ones that are already organized by OU¦.simply provision a group with the OU membership and you have it.
- If I ran the world and got to choose ever engineering dollar that we spend, I would want to solve as many problems as I can. Far more customers will have trouble figuring out what security principals are where than there are customers that have a 100% site to OU mapping.
My $0.02. Since I don't make this call, maybe this is idle chatter. ;)
~Eric
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Grillenmeier, Guido
Sent: Friday, July 28, 2006 11:15 PMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject:
RE: [ActiveDir] Read-Only Domain Controller and Server Core
Ofcourse OUs don't fix the underlying challenge of knowing which user belongs to which site. And once tools exist to automate this knowledge whether by populating groups or attributes (such as office or address) or leveraging an OU structure, it really doesn't matter which mechanism is used to configure the RODC policies.
However, many companies have organized their AD with a geographic OU structure, which doesn't necessarily match 100% to their site structure, but certainly gets pretty close. And since the delegation model is often configured such that local admins manage particular aspects of the users and computers in their site, it is a common practice to move a user account from one OU to another when the user is relocated to a different location within the company. As such the OU structure is often a good starting base to build policies for which credentials to replicate to which RODC¦
I do agree that a lot of the same customers tend to have a security group that matches the OU a user is located in, simply because an OU is not a security principal and thus you can't use it for permissioning (another long missed feature from Netware). The problem is that without automation tools (and there are still plenty of customers without these), the "OU-specific users group" won't necessarily be updated as consistently when a User account is moved from one OU to another.
I am sure that at some point it is a performance thing “ not sure how this password replication mechanism actually works in the background, but I think an RODC needs to make decisions at the time of logon of a user: during the logon process the RODC must determine if it should cache (and then continue to replicate) the user's credentials or not. And I guess a user's group-membership is analyzed faster than figuring out the OU that a user belongs to.
Naturally, query based security groups wouldn't help to improve performance, but if you could add some nice processes from MIIS to AD that periodically and dynamically populate AD groups based on LDAP queries (without the need to support another database), this would certainly help. And the I would be all for using groups instead of OUs ;-)
/Guido
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Eric FleischmanSent:
Friday, July 28, 2006 11:02 PMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: RE: [ActiveDir] Read-Only Domain Controller and Server Core
> And currently this is all based on group memberships.
I hope to see an option coming up to use OU's instead.
To be clear, OUs are a "Guido likes the way this looks" feature, not a "this helps the problem" feature.
The crux of the problem is figuring out who to cache on a given RODC. If you know this¦by OU membership or something else¦constructing a group with said membership is trivial. However, if you don't know this, OU based policy is not going to help.
With that, I'll state in public that my vote is not to build OU based policy. Why? Because it doesn't fix the problem. Instead, I want to spend our engineering dollars building tools to help users find who should be cached where¦ie, tackling the problem itself head on. Whether you then organize by OU or just populate groups is the easy part.
~Eric
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Grillenmeier, Guido
Sent: Friday, July 28, 2006 1:33 PMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject:
RE: [ActiveDir] Read-Only Domain Controller and Server Core
Could be worth to note that an RODC can also be a DNS server for the respective BO. As it is designed for one-way replication from a writeable DC, it does not allow direct dynamic updates of DNS records that are requested to be updated by clients that use the RODC as a DNS server (same is true for password changes) => these are basically forwarded to the next writeable DC and then replicated back to the RODC. Sounds complicated, but makes sense as the RODC should be regarded as an "untrusted" DC.
I am certainly a friend of combining RODC with Server Core for BO environments. Combine this with the Admin Separation features of RODC and you have a great BO story. Admin Separation means that you can make a non-domain admin a member of the local admin group on an RODC, without granting him/her admin rights in AD. Server Core will obviously not only be useful for BOs “ they can also host writeable DCs in a company's datacenters.
Biggest challenge I see is configuring the policies for storing credentials on RODCs “ it's the typical challenge of matching mobile objects (users and notebooks) to non-mobile devices (an RODC in a site). And currently this is all based on group memberships. I hope to see an option coming up to use OU's instead.
I do agree with Al, that the original blog entry that started this discussion was a little misleading and didn't do the features of RODC justice.
/Guido
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Eric FleischmanSent:
Friday, July 28, 2006 9:42 PMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: RE: [ActiveDir] Read-Only Domain Controller and Server Core
Hi Al,
Take your workstation and take a sniff of a logon. All traffic you throw at the DC will work against the RODC. The only WAN traffic in that scenario would be the auth itself, a tiny amt of work. (assuming GC and all that is satisfied locally)
So, the statement that authentication is your biggest use is true, kinda¦you need to more carefully define the operation. I suspect you don't mean auth in the Kerberos sense, you mean "user logon" really. Unless your branch has a bunch of apps that do Kerb work and no clients¦.then you can correct me and we have a totally different conversation on our hands. :)
Answering some questions of yours, from this and other forks of the thread¦..
> What conditions would make it so that the password policy would be configured such that the password replication
> was not allowed?
There is a policy (not group policy, administrative one defined in AD itself) which defines what can be cached there and what can not. The statement made (I think first by Dmitri, but I then commented on it further) was that by default, this policy allows almost nothing to be cached. You could tweak this in your enterprise and change what is cached, anything from the near-nothing default to almost every secret in the domain. You can choose.
> Would that just be that the RODC is no longer trusted (i.e. it was abducted or otherwise compromised?)
Well, we never know if an RODC was compromised. Rather, RODC was built such that you the admin can assume they are compromised, and fully understand the scope of compromise in your enterprise should it happen one day, and respond to said event.
So, I say you should look at this problem the other way¦. Treat your RODCs as if they were about to get compromised, then make real decisions around how much work the recovery from said compromise would be vs. actually having an environment that is useful, reliable, easy to manage, etc. That's what I was talking about re: the knobs¦.you can turn said knobs and make decisions that work for you. And we'll have documentation that will help you do this.
> Or is that something that some admin can configure and hurt themselves? Better yet, if that were true, is there any value left in the
> RODC that can't get a password hash?
I think I answered this but please holler if it is still unclear.
> Outside of "GP work" what else comes to mind that is off-loaded to the local site that you can think of?
Take a network sniff of your clients talking to your DCs for a day. Almost all of that stuff. J
You could have apps, you have logon itself, etc.
> Perhaps I'm looking at this sideways?
Every environment is different. It is entirely possible that a secret-less RODC is totally uninteresting in your enterprise. That said, I would argue that you probably haven't done enough investigation yet to really know if that's true or not¦it's not personal, why would you? This has likely never been relevant. Almost no one does this sort of analysis unless they absolutely have to.
Take some data, please report back to us. I'd love to look at said data with you if you're unclear as to what would fall in what bucket.
Hope this helps. Please holler back with questions.
~Eric
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Al MulnickSent:
Friday, July 28, 2006 10:34 AMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: Re: [ActiveDir] Read-Only Domain Controller and Server Core
More clarity is always welcome.
I suspect I'm trying to get my mind around the GPO providing that much value that I would want to put a DC in the local brach as part of the design vs. trying really hard to use as little of the GPO as possible and making sure that the changes are as infrequent as possible.
Authentication and name resolution are my biggest uses for a local DC in a branch. Outside of Exchange of course. Everything else I try to keep as compartmentalized as I can because if my WAN is a concern such that I can't use authentication across the wire (or can't trust it) then I have some big concerns about the branch environment and how autonomous it is.
Outside of "GP work" what else comes to mind that is off-loaded to the local site that you can think of?
Perhaps I'm looking at this sideways?
On 7/28/06, Eric Fleischman wrote:
To add a bit more¦
> The part that makes me wonder about the "story" is if it stores no secrets is the server doing anything for me?
The short answer is yes.
The bulk of the work that a DC does, even in the auth code path, may not involve the secret. So even if the secret checking work is "outsourced" to a hub DC, there is a lot more work that the local DC can perform for the user. For example, if it is an interactive logon, consider all of the GP work alone that is done that is now local.
At the end of the day, you have a knob¦.you can make real security trade-offs based upon what attack surface you can accept & mitigate, what administrative story you want, etc. You get to choose what secrets end up on the RODC. The product is built such that you can turn these knobs as you see fit but the default knob setting is "more secure".
I hope between my response and Dmitri's you are clear that the belief that it stores "nothing locally" is incorrect. If more clarity is required please just holler.
~Eric
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Dmitri GavrilovSent:
Friday, July 28, 2006 9:48 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of
neil.ruston@xxxxxxxxxxxxxSent: Friday, July 28, 2006 8:22 AMTo: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core
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:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto: ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of
Al MulnickSent: 28 July 2006 16:08To: ActiveDir@xxxxxxxxxxxxxxxxxxSubject:
Re: [ActiveDir] Read-Only Domain Controller and Server Core
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] wrote:
FYI:http://blogs.msdn.com/jolson/archive/2006/07/27/679801.aspx
Read-Only Domain Controller and Server CoreList info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspxList archive:
http://www.activedir.org/ml/threads.aspx
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. | | | |
| GuidoG
Posts:114
| | 07/29/2006 4:14 AM |
| Al, that™s basically getting back at what Eric said and the more I
think about it, the more I have to agree: there is only a certain percentage of
companies that are able to setup an OU structure by geography and certainly no
single OU structure will fit for all companies. I have myself worked with quite
a lot of customers, where OUs by location made sense “ but also some that had a
mix of location-OUs for computers and business units-OUs for users. And others
simply adjust it to their helpdesk model “ depending on who needs to manage which
part of the world.
Thinking more about the travel bit, it will be easy to understand
that this doesn™t make the password caching story any easier. If you want full
coverage for WAN outages (which is the main reason that you want to cache the
passwords in the first place), then you may need to match those traveling users
(and computers) to multiple sites “ this is where the fun begins with figuring
out how to handle the password replication policies for RODCs. Granted, OUs
suddenly make less sense, since a user and a computer can only be in a single
OU, but they can belong to multiple groups¦
But at some point you have to weigh the configuration efforts
against the benefits and the probability of WAN outages for your network. I
would argue that 95% of the users in most companies have a main location that
they work in most of the time. Even though they may have 20% to 30% of traveling
users, most of these users won™t travel to different offices all the time (of
course there are companies where this exception would be the rule).
So in an RODC scenario, for 95% of the user base, I would probably plan
on creating of a password replication policy that only allows the RODC in their
main location to cache their passwords “ besides some additional performance
benefits for the local authentication, they can also successfully authenticate
when the WAN is down (which won™t help too much either, if all other services
are centralized, but that™s a different story).
I would then try to figure out who those 5% of always-on-the-road-in-different-offices
users are and add them to a special group. I could then configure all RODCs (maybe
per region) to allow caching the credentials of these users “ and remember they
will only start caching the pwds for users that have actually authenticated at
least once to the respective RODC¦.
/Guido
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On
Behalf Of Al Mulnick
Sent: Saturday, July 29, 2006 4:06 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] Read-Only Domain Controller and Server Core
Agreed. Very useful.
Guido, I'm curious. You mentioned this:
"However,
many companies have organized their AD with a geographic OU structure, which
doesn't necessarily match 100% to their site structure, but certainly gets
pretty close. And since the delegation model is often configured such
that local admins manage particular aspects of the users and computers in their
site, it is a common practice to move a user account from one OU to another
when the user is relocated to a different location within the company. As such
the OU structure is often a good starting base to build policies for which
credentials to replicate to which RODC¦"
How many of your customers do you see that travel between
those sites and what would be the implications in your scenario/s?
This has been a problem that I have seen many times in the
past. I'm just curious what you've seen and how it's been solved.
In my case, I see everything from no technical resource on site (sometimes not
even opposable thumbs that we can count on) to a local administrator.
Often this depends on historical vs. business logic. To date, most designs I
have been involved with have been the 80/20 of "yep, that'll take care of
most of your issues, but there will be exceptions and here's the plan for
that". Some have also favored business unit logical lines.
What I mean by that is a business unit's computing resources are deployed
as cookie cutter as possible with the idea that almost the entire business unit
will not need what a different business unit needs per se. Another factor
is the geographical and co-location of business units and some shared resources
that the units might have. Typically a blend of the two approaches(base for *all*
users anywhere, and business unit centric) has worked out since the
co-location of business units makes sense for some organizations.
But I'm wondering if you've seen differently? If anyone else
sees another way of solving the issue, I'm interested in hearing about it if
you can share. I wonder about it because trying to get them to fit into an OU
by geography can be a tough approach with lots of touch times. They will
constantly move in and out of many different geo's during a given time
period. The users move around a lot as well and some have high turnover.
Interesting.
Al
On 7/29/06, Grillenmeier, Guido
wrote:
But very useful idle chatter nonetheless
;-)
/Guido
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of Eric Fleischman
Sent: Saturday, July 29, 2006 8:35 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only Domain Controller and
Server Core
You basically articulated my point
for me. J
> And once tools exist to
automate this knowledge whether by populating groups or attributes (such as
office or address)
> or leveraging an OU
structure, it really doesn't matter which mechanism is used to configure the
RODC policies.
Yup. My contention is that in many
cases, I think this will be non-trivial for customers. They will have trouble
knowing where security principals are¦.especially computers. So we need to
spend engineering effort here (the Auth2 list should help with this though).
> However, many companies have
organized their AD with a geographic OU structure, which doesn't necessarily
match
> 100% to their site structure,
but certainly gets pretty close
Yes, and because it is not 100%,
they'll either need to move users around across their OUs (which has other
implications, like on delegation) or use groups to work around it. ;)
My contention is not that OUs are
a bad idea for this sort of policy. Only that:
- For many customers they will
not work. Groups will work for all customers, even the ones that are already
organized by OU¦.simply provision a group with the OU membership and you have
it.
- If I ran the world and got to
choose ever engineering dollar that we spend, I would want to solve as many problems
as I can. Far more customers will have trouble figuring out what security
principals are where than there are customers that have a 100% site to OU
mapping.
My $0.02. Since I don't make this
call, maybe this is idle chatter. ;)
~Eric
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of Grillenmeier, Guido
Sent: Friday, July 28, 2006 11:15 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core
Ofcourse OUs don't fix the
underlying challenge of knowing which user belongs to which site. And once
tools exist to automate this knowledge whether by populating groups or
attributes (such as office or address) or leveraging an OU structure, it really
doesn't matter which mechanism is used to configure the RODC policies.
However, many companies have
organized their AD with a geographic OU structure, which doesn't necessarily
match 100% to their site structure, but certainly gets pretty close. And
since the delegation model is often configured such that local admins manage
particular aspects of the users and computers in their site, it is a common
practice to move a user account from one OU to another when the user is
relocated to a different location within the company. As such the OU structure
is often a good starting base to build policies for which credentials to
replicate to which RODC¦
I do agree that a lot of the same
customers tend to have a security group that matches the OU a user is located
in, simply because an OU is not a security principal and thus you can't use it
for permissioning (another long missed feature from Netware). The problem is
that without automation tools (and there are still plenty of customers without
these), the "OU-specific users group" won't necessarily be updated as
consistently when a User account is moved from one OU to another.
I am sure that at some point it is
a performance thing “ not sure how this password replication mechanism actually
works in the background, but I think an RODC needs to make decisions at the
time of logon of a user: during the logon process the RODC must determine if it
should cache (and then continue to replicate) the user's credentials or
not. And I guess a user's group-membership is analyzed faster than
figuring out the OU that a user belongs to.
Naturally, query based security
groups wouldn't help to improve performance, but if you could add some nice
processes from MIIS to AD that periodically and dynamically populate AD groups
based on LDAP queries (without the need to support another database), this
would certainly help. And the I would be all for using groups instead of
OUs ;-)
/Guido
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of Eric Fleischman
Sent: Friday, July 28, 2006 11:02 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core
> And currently this is all based on group
memberships. I hope to see an option coming up to use
OU's instead.
To be clear, OUs are a "Guido
likes the way this looks" feature, not a "this helps the
problem" feature.
The crux of the problem is
figuring out who to cache on a given RODC. If you know this¦by OU membership or
something else¦constructing a group with said membership is trivial. However,
if you don't know this, OU based policy is not going to help.
With that, I'll state in public
that my vote is not to build OU based policy. Why? Because it doesn't fix the
problem. Instead, I want to spend our engineering dollars building tools to
help users find who should be cached where¦ie, tackling the problem itself head
on. Whether you then organize by OU or just populate groups is the easy part.
~Eric
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of Grillenmeier, Guido
Sent: Friday, July 28, 2006 1:33 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core
Could be worth to note that an
RODC can also be a DNS server for the respective BO. As it is designed for
one-way replication from a writeable DC, it does not allow direct dynamic
updates of DNS records that are requested to be updated by clients that use the
RODC as a DNS server (same is true for password changes) => these are
basically forwarded to the next writeable DC and then replicated back to the
RODC. Sounds complicated, but makes sense as the RODC should be regarded as an
"untrusted" DC.
I am certainly a friend of
combining RODC with Server Core for BO environments. Combine this with the
Admin Separation features of RODC and you have a great BO story. Admin
Separation means that you can make a non-domain admin a member of the local
admin group on an RODC, without granting him/her admin rights in AD. Server
Core will obviously not only be useful for BOs “ they can also host writeable
DCs in a company's datacenters.
Biggest challenge I see is
configuring the policies for storing credentials on RODCs “ it's the typical
challenge of matching mobile objects (users and notebooks) to non-mobile
devices (an RODC in a site). And currently this is all based on group
memberships. I hope to see an option coming up to use OU's instead.
I do agree with Al, that the
original blog entry that started this discussion was a little misleading and
didn't do the features of RODC justice.
/Guido
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of Eric Fleischman
Sent: Friday, July 28, 2006 9:42 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core
Hi Al,
Take your workstation and take a
sniff of a logon. All traffic you throw at the DC will work against the RODC.
The only WAN traffic in that scenario would be the auth itself, a tiny amt of
work. (assuming GC and all that is satisfied locally)
So, the statement that
authentication is your biggest use is true, kinda¦you need to more carefully
define the operation. I suspect you don't mean auth in the Kerberos sense, you
mean "user logon" really. Unless your branch has a bunch of apps that
do Kerb work and no clients¦.then you can correct me and we have a totally
different conversation on our hands. :)
Answering some questions of yours,
from this and other forks of the thread¦..
> What conditions would
make it so that the password policy would be configured such that the password
replication
> was not allowed?
There is a policy (not group
policy, administrative one defined in AD itself) which defines what can be
cached there and what can not. The statement made (I think first by Dmitri, but
I then commented on it further) was that by default, this policy allows almost
nothing to be cached. You could tweak this in your enterprise and change what
is cached, anything from the near-nothing default to almost every secret in the
domain. You can choose.
> Would that just be
that the RODC is no longer trusted (i.e. it was abducted or otherwise
compromised?)
Well, we never know if an RODC was
compromised. Rather, RODC was built such that you the admin can assume they are
compromised, and fully understand the scope of compromise in your enterprise
should it happen one day, and respond to said event.
So, I say you should look at this
problem the other way¦. Treat your RODCs as if they were about to get
compromised, then make real decisions around how much work the recovery from
said compromise would be vs. actually having an environment that is useful,
reliable, easy to manage, etc. That's what I was talking about re: the
knobs¦.you can turn said knobs and make decisions that work for you. And we'll
have documentation that will help you do this.
> Or is that something that some admin can configure and hurt themselves?
Better yet, if that were true, is there any value left in the
> RODC that can't get a password hash?
I think I answered this but please
holler if it is still unclear.
> Outside of "GP
work" what else comes to mind that is off-loaded to the local site that
you can think of?
Take a network sniff of your
clients talking to your DCs for a day. Almost all of that stuff. J You could have apps, you have logon itself,
etc.
> Perhaps I'm looking at
this sideways?
Every environment is different. It
is entirely possible that a secret-less RODC is totally uninteresting in your
enterprise. That said, I would argue that you probably haven't done enough
investigation yet to really know if that's true or not¦it's not personal, why
would you? This has likely never been relevant. Almost no one does this sort of
analysis unless they absolutely have to.
Take some data, please report back
to us. I'd love to look at said data with you if you're unclear as to what
would fall in what bucket.
Hope this helps. Please holler
back with questions.
~Eric
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of Al Mulnick
Sent: Friday, July 28, 2006 10:34 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] Read-Only Domain Controller and Server Core
More clarity is always welcome.
I suspect I'm trying to get my mind around the GPO providing that much value
that I would want to put a DC in the local brach as part of the design vs.
trying really hard to use as little of the GPO as possible and making sure that
the changes are as infrequent as possible.
Authentication and name resolution are my biggest uses for a local DC in a
branch. Outside of Exchange of course. Everything else I try to keep as
compartmentalized as I can because if my WAN is a concern such that I can't use
authentication across the wire (or can't trust it) then I have some big
concerns about the branch environment and how autonomous it is.
Outside of "GP work" what else comes to mind that is off-loaded to
the local site that you can think of?
Perhaps I'm looking at this sideways?
On 7/28/06, Eric Fleischman efleis@xxxxxxxxxxxxxxxxxxxxx>
wrote:
To add a bit more¦
> The part that makes me
wonder about the "story" is if it stores no secrets is the server
doing anything for me?
The short answer is yes.
The bulk of the work that a DC
does, even in the auth code path, may not involve the secret. So even if the
secret checking work is "outsourced" to a hub DC, there is a lot more
work that the local DC can perform for the user. For example, if it is an
interactive logon, consider all of the GP work alone that is done that is now
local.
At the end of the day, you have a
knob¦.you can make real security trade-offs based upon what attack surface you
can accept & mitigate, what administrative story you want, etc. You get to
choose what secrets end up on the RODC. The product is built such that you can
turn these knobs as you see fit but the default knob setting is "more
secure".
I hope between my response and
Dmitri's you are clear that the belief that it stores "nothing
locally" is incorrect. If more clarity is required please just holler.
~Eric
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of Dmitri Gavrilov
Sent: Friday, July 28, 2006 9:48 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of neil.ruston@xxxxxxxxxxxxx
Sent: Friday, July 28, 2006 8:22 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Al Mulnick
Sent: 28 July 2006 16:08
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] Read-Only Domain Controller and Server Core
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] sbradcpa@xxxxxxxxxxx>
wrote:
FYI:
http://blogs.msdn.com/jolson/archive/2006/07/27/679801.aspx
Read-Only Domain Controller
and Server Core
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
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. | | | |
| efleis1
Posts:0
| | 07/29/2006 4:23 AM |
| I want to make one other thing clear¦.the
other reason to ship the product in this state is secure by default.
Out of the box, we have no idea what
secrets you will want on the RODC. We don™t know your enterprise or your threat
model. As such, there™s really no good choice¦.we too would be implicitly
turning the knob for better out of the box admin experience vs more secure
out of the box. No good choices.
So, even if you assume that this state is
good for no one (a contention I™ll disagree with, there are some enterprises
that will do this, but that™s not the point), it is still the right state in
which to ship the product.
This is like ordering pizza for every admin
in every forest on the planet.
~Eric
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On
Behalf Of Al Mulnick
Sent: Friday, July 28, 2006 3:28
PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] Read-Only
Domain Controller and Server Core
That's the ~Eric we've come to know :)
Thanks for that view. I'll take your advice and check for the
traffic and rethink the view on the RODC concept. Like you said, it may prove
uninteresting, but after that amount of information from you, Dmitri and Guido,
I'd hate to leave that stone unturned.
I'll ping back if I get lost watching the traces. I appreciate the
offer and you guys taking the time to discuss this.
Al
On 7/28/06, Eric
Fleischman
wrote:
Hi Al,
Take your workstation and take a sniff of a logon. All
traffic you throw at the DC will work against the RODC. The only WAN traffic in
that scenario would be the auth itself, a tiny amt of work. (assuming GC and
all that is satisfied locally)
So, the statement that authentication is your biggest use is
true, kinda¦you need to more carefully define the operation. I suspect you
don't mean auth in the Kerberos sense, you mean "user logon" really.
Unless your branch has a bunch of apps that do Kerb work and no clients¦.then
you can correct me and we have a totally different conversation on our hands.
:)
Answering some questions of yours, from this and other forks
of the thread¦..
> What conditions would make it so that the
password policy would be configured such that the password replication
> was
not allowed?
There is a policy (not group policy, administrative one
defined in AD itself) which defines what can be cached there and what can not.
The statement made (I think first by Dmitri, but I then commented on it
further) was that by default, this policy allows almost nothing to be cached.
You could tweak this in your enterprise and change what is cached, anything
from the near-nothing default to almost every secret in the domain. You can
choose.
> Would that just be that the RODC is no
longer trusted (i.e. it was abducted or otherwise compromised?)
Well, we never know if an RODC was compromised. Rather, RODC
was built such that you the admin can assume they are compromised, and fully
understand the scope of compromise in your enterprise should it happen one day,
and respond to said event.
So, I say you should look at this problem the other way¦.
Treat your RODCs as if they were
about to get compromised, then make real decisions around how much work the
recovery from said compromise would be vs. actually having an environment that
is useful, reliable, easy to manage, etc. That's what I was talking about re:
the knobs¦.you can turn said knobs and make decisions that work for you. And
we'll have documentation that will help you do this.
> Or
is that something that some admin can configure and hurt themselves? Better
yet, if that were true, is there any value left in the
> RODC
that can't get a password hash?
I think I answered this but please holler if it is still
unclear.
> Outside of "GP work" what else
comes to mind that is off-loaded to the local site that you can think of?
Take a network sniff of your clients talking to your DCs for
a day. Almost all of that stuff. J You could have apps, you have logon itself, etc.
> Perhaps I'm looking at this sideways?
Every environment is different. It is entirely possible that
a secret-less RODC is totally uninteresting in your enterprise. That said, I
would argue that you probably haven't done enough investigation yet to really
know if that's true or not¦it's not personal, why would you? This has likely
never been relevant. Almost no one does this sort of analysis unless they
absolutely have to.
Take some data, please report back to us. I'd love to look at
said data with you if you're unclear as to what would fall in what bucket.
Hope this helps. Please holler back with questions.
~Eric
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of Al Mulnick
Sent: Friday, July 28, 2006 10:34
AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re:
[ActiveDir] Read-Only Domain Controller and Server Core
More
clarity is always welcome.
I suspect
I'm trying to get my mind around the GPO providing that much value that I would
want to put a DC in the local brach as part of the design vs. trying really
hard to use as little of the GPO as possible and making sure that the changes
are as infrequent as possible.
Authentication
and name resolution are my biggest uses for a local DC in a branch.
Outside of Exchange of course. Everything else I try to keep as
compartmentalized as I can because if my WAN is a concern such that I can't use
authentication across the wire (or can't trust it) then I have some big
concerns about the branch environment and how autonomous it is.
Outside
of "GP work" what else comes to mind that is off-loaded to the local
site that you can think of?
Perhaps
I'm looking at this sideways?
On
7/28/06, Eric Fleischman
efleis@xxxxxxxxxxxxxxxxxxxxx> wrote:
To add a bit more¦
> The part that makes me wonder about the
"story" is if it stores no secrets is the server doing anything for
me?
The short answer is yes.
The bulk of the work that a DC does, even in the auth code
path, may not involve the secret. So even if the secret checking work is
"outsourced" to a hub DC, there is a lot more work that the local DC
can perform for the user. For example, if it is an interactive logon, consider
all of the GP work alone that is done that is now local.
At the end of the day, you have a knob¦.you can make real
security trade-offs based upon what attack surface you can accept &
mitigate, what administrative story you want, etc. You get to choose what
secrets end up on the RODC. The product is built such that you can turn these
knobs as you see fit but the default knob setting is "more secure".
I hope between my response and Dmitri's you are clear that
the belief that it stores "nothing locally" is incorrect. If more
clarity is required please just holler.
~Eric
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of Dmitri Gavrilov
Sent: Friday, July 28, 2006 9:48
AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only
Domain Controller and Server Core
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of neil.ruston@xxxxxxxxxxxxx
Sent: Friday, July 28, 2006 8:22
AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only
Domain Controller and Server Core
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On
Behalf Of Al Mulnick
Sent: 28 July 2006 16:08
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] Read-Only
Domain Controller and Server Core
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] wrote:
FYI:
http://blogs.msdn.com/jolson/archive/2006/07/27/679801.aspx
Read-Only Domain Controller
and Server Core
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
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. | | | |
| GuidoG
Posts:114
| | 07/29/2006 6:15 AM |
| Ofcourse OUs don™t fix the underlying challenge of knowing
which user belongs to which site. And once tools exist to automate this knowledge
whether by populating groups or attributes (such as office or address) or leveraging
an OU structure, it really doesn™t matter which mechanism is used to
configure the RODC policies.
However, many companies have organized their AD with a geographic
OU structure, which doesn™t necessarily match 100% to their site
structure, but certainly gets pretty close. And since the delegation
model is often configured such that local admins manage particular aspects of
the users and computers in their site, it is a common practice to move a user account
from one OU to another when the user is relocated to a different location
within the company. As such the OU structure is often a good starting base to
build policies for which credentials to replicate to which RODC¦
I do agree that a lot of the same customers tend to have a security
group that matches the OU a user is located in, simply because an OU is not a
security principal and thus you can™t use it for permissioning (another
long missed feature from Netware). The problem is that without automation tools
(and there are still plenty of customers without these), the OU-specific
users group won™t necessarily be updated as consistently when a
User account is moved from one OU to another.
I am sure that at some point it is a performance thing “ not
sure how this password replication mechanism actually works in the background,
but I think an RODC needs to make decisions at the time of logon of a user:
during the logon process the RODC must determine if it should cache (and then
continue to replicate) the user™s credentials or not. And I guess a
user™s group-membership is analyzed faster than figuring out the OU that
a user belongs to.
Naturally, query based security groups wouldn™t help to
improve performance, but if you could add some nice processes from MIIS to AD that
periodically and dynamically populate AD groups based on LDAP queries (without
the need to support another database), this would certainly help. And the
I would be all for using groups instead of OUs ;-)
/Guido
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Eric Fleischman
Sent: Friday, July 28, 2006 11:02 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core
> And currently this is all based on group memberships. I hope
to see an option coming up to use OU™s instead.
To be clear, OUs are a Guido likes the way this looks
feature, not a this helps the problem feature.
The crux of the problem is figuring out who to cache on a given
RODC. If you know this¦by OU membership or something
else¦constructing a group with said membership is trivial. However, if
you don™t know this, OU based policy is not going to help.
With that, I™ll state in public that my vote is not to build
OU based policy. Why? Because it doesn™t fix the problem. Instead, I want
to spend our engineering dollars building tools to help users find who should
be cached where¦ie, tackling the problem itself head on. Whether you then
organize by OU or just populate groups is the easy part.
~Eric
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On
Behalf Of Grillenmeier, Guido
Sent: Friday, July 28, 2006 1:33 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core
Could be worth to note that an RODC can also be a DNS server for
the respective BO. As it is designed for one-way replication from a writeable
DC, it does not allow direct dynamic updates of DNS records that are requested
to be updated by clients that use the RODC as a DNS server (same is true for
password changes) => these are basically forwarded to the next writeable DC
and then replicated back to the RODC. Sounds complicated, but makes sense as
the RODC should be regarded as an untrusted DC.
I am certainly a friend of combining RODC with Server Core for BO
environments. Combine this with the Admin Separation features of RODC and you
have a great BO story. Admin Separation means that you can make a non-domain
admin a member of the local admin group on an RODC, without granting him/her
admin rights in AD. Server Core will obviously not only be useful for BOs
“ they can also host writeable DCs in a company™s datacenters.
Biggest challenge I see is configuring the policies for storing
credentials on RODCs “ it™s the typical challenge of matching
mobile objects (users and notebooks) to non-mobile devices (an RODC in a site).
And currently this is all based on group memberships. I hope to see an option
coming up to use OU™s instead.
I do agree with Al, that the original blog entry that started this
discussion was a little misleading and didn™t do the features of RODC
justice.
/Guido
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Eric Fleischman
Sent: Friday, July 28, 2006 9:42 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core
Hi Al,
Take your workstation and take a sniff of a logon. All traffic you
throw at the DC will work against the RODC. The only WAN traffic in that
scenario would be the auth itself, a tiny amt of work. (assuming GC and all
that is satisfied locally)
So, the statement that authentication is your biggest use is true,
kinda¦you need to more carefully define the operation. I suspect you
don™t mean auth in the Kerberos sense, you mean user logon
really. Unless your branch has a bunch of apps that do Kerb work and no
clients¦.then you can correct me and we have a totally different
conversation on our hands. :)
Answering some questions of yours, from this and other forks of the
thread¦..
> What conditions would make it so that the password
policy would be configured such that the password replication
> was not allowed?
There is a policy (not group policy, administrative one defined in
AD itself) which defines what can be cached there and what can not. The
statement made (I think first by Dmitri, but I then commented on it further)
was that by default, this policy allows almost nothing to be cached. You could
tweak this in your enterprise and change what is cached, anything from the
near-nothing default to almost every secret in the domain. You can choose.
> Would that just be that the RODC is no longer trusted
(i.e. it was abducted or otherwise compromised?)
Well, we never know if an RODC was compromised. Rather, RODC was
built such that you the admin can assume they are compromised, and fully
understand the scope of compromise in your enterprise should it happen one day,
and respond to said event.
So, I say you should look at this problem the other way¦.
Treat your RODCs as if they were about to get compromised, then make
real decisions around how much work the recovery from said compromise would be
vs. actually having an environment that is useful, reliable, easy to manage,
etc. That™s what I was talking about re: the knobs¦.you can turn
said knobs and make decisions that work for you. And we™ll have
documentation that will help you do this.
> Or is that something that some admin can configure and
hurt themselves? Better yet, if that were true, is there any value left in the
> RODC that can't get a password hash?
I think I answered this but please holler if it is still unclear.
> Outside of "GP work" what else comes to mind
that is off-loaded to the local site that you can think of?
Take a network sniff of your clients talking to your DCs for a day.
Almost all of that stuff. J You could have apps, you have logon itself, etc.
> Perhaps I'm looking at this sideways?
Every environment is different. It is entirely possible that a
secret-less RODC is totally uninteresting in your enterprise. That said, I
would argue that you probably haven™t done enough investigation yet to
really know if that™s true or not¦it™s not personal, why
would you? This has likely never been relevant. Almost no one does this sort of
analysis unless they absolutely have to.
Take some data, please report back to us. I™d love to look at
said data with you if you™re unclear as to what would fall in what
bucket.
Hope this helps. Please holler back with questions.
~Eric
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On
Behalf Of Al Mulnick
Sent: Friday, July 28, 2006 10:34 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] Read-Only Domain Controller and Server Core
More clarity is always welcome.
I suspect I'm trying to get my mind around the GPO providing
that much value that I would want to put a DC in the local brach as part of the
design vs. trying really hard to use as little of the GPO as possible and
making sure that the changes are as infrequent as possible.
Authentication and name resolution are my biggest uses for a
local DC in a branch. Outside of Exchange of course. Everything else I
try to keep as compartmentalized as I can because if my WAN is a concern such
that I can't use authentication across the wire (or can't trust it) then I have
some big concerns about the branch environment and how autonomous it is.
Outside of "GP work" what else comes to mind that
is off-loaded to the local site that you can think of?
Perhaps I'm looking at this sideways?
On 7/28/06, Eric Fleischman
wrote:
To
add a bit more¦
>
The part that makes me wonder about the "story" is if it
stores no secrets is the server doing anything for me?
The
short answer is yes.
The
bulk of the work that a DC does, even in the auth code path, may not involve
the secret. So even if the secret checking work is "outsourced" to a
hub DC, there is a lot more work that the local DC can perform for the user.
For example, if it is an interactive logon, consider all of the GP work alone
that is done that is now local.
At
the end of the day, you have a knob¦.you can make real security
trade-offs based upon what attack surface you can accept & mitigate, what
administrative story you want, etc. You get to choose what secrets end up on
the RODC. The product is built such that you can turn these knobs as you see
fit but the default knob setting is "more secure".
I
hope between my response and Dmitri's you are clear that the belief that it
stores "nothing locally" is incorrect. If more clarity is required
please just holler.
~Eric
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of Dmitri Gavrilov
Sent: Friday, July 28, 2006 9:48 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only Domain Controller and
Server Core
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of neil.ruston@xxxxxxxxxxxxx
Sent: Friday, July 28, 2006 8:22 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Al Mulnick
Sent: 28 July 2006 16:08
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] Read-Only Domain Controller and Server Core
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] sbradcpa@xxxxxxxxxxx>
wrote:
FYI:
http://blogs.msdn.com/jolson/archive/2006/07/27/679801.aspx
Read-Only Domain Controller
and Server Core
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
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. | | | |
| efleis1
Posts:0
| | 07/29/2006 6:35 AM |
| You basically articulated my point for me.
J
> And once tools exist to automate
this knowledge whether by populating groups or attributes (such as office or
address)
> or leveraging an OU structure, it
really doesn™t matter which mechanism is used to configure the RODC
policies.
Yup. My contention is that in many cases,
I think this will be non-trivial for customers. They will have trouble knowing
where security principals are¦.especially computers. So we need to spend
engineering effort here (the Auth2 list should help with this though).
> However, many companies have
organized their AD with a geographic OU structure, which doesn™t
necessarily match
> 100% to their site structure, but
certainly gets pretty close
Yes, and because it is not 100%, they™ll
either need to move users around across their OUs (which has other implications,
like on delegation) or use groups to work around it. ;)
My contention is not that OUs are a bad
idea for this sort of policy. Only that:
-
For many
customers they will not work. Groups will work for all customers, even the ones
that are already organized by OU¦.simply provision a group with the OU
membership and you have it.
-
If I ran
the world and got to choose ever engineering dollar that we spend, I would want
to solve as many problems as I can. Far more customers will have trouble
figuring out what security principals are where than there are customers that
have a 100% site to OU mapping.
My $0.02. Since I don™t make this
call, maybe this is idle chatter. ;)
~Eric
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Grillenmeier, Guido
Sent: Friday, July 28, 2006 11:15
PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only
Domain Controller and Server Core
Ofcourse OUs don™t fix the
underlying challenge of knowing which user belongs to which site. And once
tools exist to automate this knowledge whether by populating groups or attributes
(such as office or address) or leveraging an OU structure, it really
doesn™t matter which mechanism is used to configure the RODC policies.
However, many companies have organized
their AD with a geographic OU structure, which doesn™t necessarily match
100% to their site structure, but certainly gets pretty close. And since
the delegation model is often configured such that local admins manage
particular aspects of the users and computers in their site, it is a common
practice to move a user account from one OU to another when the user is
relocated to a different location within the company. As such the OU structure
is often a good starting base to build policies for which credentials to
replicate to which RODC¦
I do agree that a lot of the same customers
tend to have a security group that matches the OU a user is located in, simply
because an OU is not a security principal and thus you can™t use it for
permissioning (another long missed feature from Netware). The problem is that
without automation tools (and there are still plenty of customers without
these), the OU-specific users group won™t necessarily be
updated as consistently when a User account is moved from one OU to another.
I am sure that at some point it is a
performance thing “ not sure how this password replication mechanism
actually works in the background, but I think an RODC needs to make decisions
at the time of logon of a user: during the logon process the RODC must
determine if it should cache (and then continue to replicate) the user™s
credentials or not. And I guess a user™s group-membership is
analyzed faster than figuring out the OU that a user belongs to.
Naturally, query based security groups
wouldn™t help to improve performance, but if you could add some nice
processes from MIIS to AD that periodically and dynamically populate AD groups
based on LDAP queries (without the need to support another database), this
would certainly help. And the I would be all for using groups instead of
OUs ;-)
/Guido
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Eric Fleischman
Sent: Friday, July 28, 2006 11:02
PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only
Domain Controller and Server Core
> And currently this is all based on group memberships. I hope to see an option
coming up to use OU™s instead.
To be clear, OUs are a Guido likes
the way this looks feature, not a this helps the problem
feature.
The crux of the problem is figuring out
who to cache on a given RODC. If you know this¦by OU membership or
something else¦constructing a group with said membership is trivial.
However, if you don™t know this, OU based policy is not going to help.
With that, I™ll state in public that
my vote is not to build OU based policy. Why? Because it doesn™t fix the
problem. Instead, I want to spend our engineering dollars building tools to
help users find who should be cached where¦ie, tackling the problem
itself head on. Whether you then organize by OU or just populate groups is the
easy part.
~Eric
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Grillenmeier, Guido
Sent: Friday, July 28, 2006 1:33
PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only
Domain Controller and Server Core
Could be worth to note that an RODC can
also be a DNS server for the respective BO. As it is designed for one-way
replication from a writeable DC, it does not allow direct dynamic updates of
DNS records that are requested to be updated by clients that use the RODC as a
DNS server (same is true for password changes) => these are basically
forwarded to the next writeable DC and then replicated back to the RODC. Sounds
complicated, but makes sense as the RODC should be regarded as an
untrusted DC.
I am certainly a friend of combining
RODC with Server Core for BO environments. Combine this with the Admin
Separation features of RODC and you have a great BO story. Admin Separation
means that you can make a non-domain admin a member of the local admin group on
an RODC, without granting him/her admin rights in AD. Server Core will
obviously not only be useful for BOs “ they can also host writeable DCs
in a company™s datacenters.
Biggest challenge I see is configuring
the policies for storing credentials on RODCs “ it™s the typical
challenge of matching mobile objects (users and notebooks) to non-mobile
devices (an RODC in a site). And currently this is all based on group
memberships. I hope to see an option coming up to use OU™s instead.
I do agree with Al, that the original
blog entry that started this discussion was a little misleading and
didn™t do the features of RODC justice.
/Guido
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Eric Fleischman
Sent: Friday, July 28, 2006 9:42
PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only
Domain Controller and Server Core
Hi Al,
Take your workstation and take a sniff of
a logon. All traffic you throw at the DC will work against the RODC. The only
WAN traffic in that scenario would be the auth itself, a tiny amt of work.
(assuming GC and all that is satisfied locally)
So, the statement that authentication is
your biggest use is true, kinda¦you need to more carefully define the
operation. I suspect you don™t mean auth in the Kerberos sense, you mean
user logon really. Unless your branch has a bunch of apps that do
Kerb work and no clients¦.then you can correct me and we have a totally different
conversation on our hands. :)
Answering some questions of yours, from
this and other forks of the thread¦..
> What conditions would
make it so that the password policy would be configured such that the password
replication
> was not allowed?
There is a policy (not group policy,
administrative one defined in AD itself) which defines what can be cached there
and what can not. The statement made (I think first by Dmitri, but I then
commented on it further) was that by default, this policy allows almost nothing
to be cached. You could tweak this in your enterprise and change what is
cached, anything from the near-nothing default to almost every secret in the
domain. You can choose.
> Would that just be that
the RODC is no longer trusted (i.e. it was abducted or otherwise compromised?)
Well, we never know if an RODC was
compromised. Rather, RODC was built such that you the admin can assume they are
compromised, and fully understand the scope of compromise in your enterprise
should it happen one day, and respond to said event.
So, I say you should look at this problem
the other way¦. Treat your RODCs as if
they were about to get compromised, then make real decisions around how much
work the recovery from said compromise would be vs. actually having an
environment that is useful, reliable, easy to manage, etc. That™s what I
was talking about re: the knobs¦.you can turn said knobs and make
decisions that work for you. And we™ll have documentation that will help
you do this.
> Or is that something that some admin can configure and hurt
themselves? Better yet, if that were true, is there any value left in the
> RODC that can't get a password hash?
I think I answered this but please holler
if it is still unclear.
> Outside of "GP
work" what else comes to mind that is off-loaded to the local site that
you can think of?
Take a network sniff of your clients
talking to your DCs for a day. Almost all of that stuff. J You could have apps, you
have logon itself, etc.
> Perhaps I'm looking at
this sideways?
Every environment is different. It is
entirely possible that a secret-less RODC is totally uninteresting in your
enterprise. That said, I would argue that you probably haven™t done
enough investigation yet to really know if that™s true or not¦it™s
not personal, why would you? This has likely never been relevant. Almost no one
does this sort of analysis unless they absolutely have to.
Take some data, please report back to us.
I™d love to look at said data with you if you™re unclear as to what
would fall in what bucket.
Hope this helps. Please holler back with
questions.
~Eric
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Al Mulnick
Sent: Friday, July 28, 2006 10:34
AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] Read-Only
Domain Controller and Server Core
More clarity is always welcome.
I suspect I'm trying to get my mind around the GPO providing that much
value that I would want to put a DC in the local brach as part of the design vs.
trying really hard to use as little of the GPO as possible and making sure that
the changes are as infrequent as possible.
Authentication and name resolution are my biggest uses for a local DC
in a branch. Outside of Exchange of course. Everything else I try to keep
as compartmentalized as I can because if my WAN is a concern such that I can't
use authentication across the wire (or can't trust it) then I have some big
concerns about the branch environment and how autonomous it is.
Outside of "GP work" what else comes to mind that is
off-loaded to the local site that you can think of?
Perhaps I'm looking at this sideways?
On 7/28/06, Eric
Fleischman
wrote:
To add a bit more¦
> The part that makes me wonder about the
"story" is if it stores no secrets is the server doing anything for
me?
The short answer is yes.
The bulk of the work that a DC does, even in the auth code
path, may not involve the secret. So even if the secret checking work is
"outsourced" to a hub DC, there is a lot more work that the local DC
can perform for the user. For example, if it is an interactive logon, consider
all of the GP work alone that is done that is now local.
At the end of the day, you have a knob¦.you can make
real security trade-offs based upon what attack surface you can accept &
mitigate, what administrative story you want, etc. You get to choose what
secrets end up on the RODC. The product is built such that you can turn these
knobs as you see fit but the default knob setting is "more secure".
I hope between my response and Dmitri's you are clear that
the belief that it stores "nothing locally" is incorrect. If more
clarity is required please just holler.
~Eric
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of Dmitri Gavrilov
Sent: Friday, July 28, 2006 9:48
AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE:
[ActiveDir] Read-Only Domain Controller and Server Core
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of neil.ruston@xxxxxxxxxxxxx
Sent: Friday, July 28, 2006 8:22
AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only
Domain Controller and Server Core
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On
Behalf Of Al Mulnick
Sent: 28 July 2006 16:08
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] Read-Only
Domain Controller and Server Core
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] wrote:
FYI:
http://blogs.msdn.com/jolson/archive/2006/07/27/679801.aspx
Read-Only Domain Controller
and Server Core
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
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. | | | |
| CrawfordS
Posts:129
| | 07/29/2006 7:06 AM |
| Well, since you offered....I'll take a large pan pepperoni and mushroom.
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx on behalf of Eric FleischmanSent: Sat 7/29/2006 11:22 AMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: RE: [ActiveDir] Read-Only Domain Controller and Server Core
I want to make one other thing clear¦.the other reason to ship the product in this state is secure by default.
Out of the box, we have no idea what secrets you will want on the RODC. We don™t know your enterprise or your threat model. As such, there™s really no good choice¦.we too would be implicitly turning the knob for better out of the box admin experience vs more secure out of the box. No good choices.
So, even if you assume that this state is good for no one (a contention I™ll disagree with, there are some enterprises that will do this, but that™s not the point), it is still the right state in which to ship the product.
This is like ordering pizza for every admin in every forest on the planet.
~Eric
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Al MulnickSent: Friday, July 28, 2006 3:28 PMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: Re: [ActiveDir] Read-Only Domain Controller and Server Core
That's the ~Eric we've come to know :)
Thanks for that view. I'll take your advice and check for the traffic and rethink the view on the RODC concept. Like you said, it may prove uninteresting, but after that amount of information from you, Dmitri and Guido, I'd hate to leave that stone unturned.
I'll ping back if I get lost watching the traces. I appreciate the offer and you guys taking the time to discuss this.
Al
On 7/28/06, Eric Fleischman wrote:
Hi Al,
Take your workstation and take a sniff of a logon. All traffic you throw at the DC will work against the RODC. The only WAN traffic in that scenario would be the auth itself, a tiny amt of work. (assuming GC and all that is satisfied locally)
So, the statement that authentication is your biggest use is true, kinda¦you need to more carefully define the operation. I suspect you don't mean auth in the Kerberos sense, you mean "user logon" really. Unless your branch has a bunch of apps that do Kerb work and no clients¦.then you can correct me and we have a totally different conversation on our hands. :)
Answering some questions of yours, from this and other forks of the thread¦..
> What conditions would make it so that the password policy would be configured such that the password replication
> was not allowed?
There is a policy (not group policy, administrative one defined in AD itself) which defines what can be cached there and what can not. The statement made (I think first by Dmitri, but I then commented on it further) was that by default, this policy allows almost nothing to be cached. You could tweak this in your enterprise and change what is cached, anything from the near-nothing default to almost every secret in the domain. You can choose.
> Would that just be that the RODC is no longer trusted (i.e. it was abducted or otherwise compromised?)
Well, we never know if an RODC was compromised. Rather, RODC was built such that you the admin can assume they are compromised, and fully understand the scope of compromise in your enterprise should it happen one day, and respond to said event.
So, I say you should look at this problem the other way¦. Treat your RODCs as if they were about to get compromised, then make real decisions around how much work the recovery from said compromise would be vs. actually having an environment that is useful, reliable, easy to manage, etc. That's what I was talking about re: the knobs¦.you can turn said knobs and make decisions that work for you. And we'll have documentation that will help you do this.
> Or is that something that some admin can configure and hurt themselves? Better yet, if that were true, is there any value left in the
> RODC that can't get a password hash?
I think I answered this but please holler if it is still unclear.
> Outside of "GP work" what else comes to mind that is off-loaded to the local site that you can think of?
Take a network sniff of your clients talking to your DCs for a day. Almost all of that stuff. J You could have apps, you have logon itself, etc.
> Perhaps I'm looking at this sideways?
Every environment is different. It is entirely possible that a secret-less RODC is totally uninteresting in your enterprise. That said, I would argue that you probably haven't done enough investigation yet to really know if that's true or not¦it's not personal, why would you? This has likely never been relevant. Almost no one does this sort of analysis unless they absolutely have to.
Take some data, please report back to us. I'd love to look at said data with you if you're unclear as to what would fall in what bucket.
Hope this helps. Please holler back with questions.
~Eric
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Al MulnickSent: Friday, July 28, 2006 10:34 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] Read-Only Domain Controller and Server Core
More clarity is always welcome.
I suspect I'm trying to get my mind around the GPO providing that much value that I would want to put a DC in the local brach as part of the design vs. trying really hard to use as little of the GPO as possible and making sure that the changes are as infrequent as possible.
Authentication and name resolution are my biggest uses for a local DC in a branch. Outside of Exchange of course. Everything else I try to keep as compartmentalized as I can because if my WAN is a concern such that I can't use authentication across the wire (or can't trust it) then I have some big concerns about the branch environment and how autonomous it is.
Outside of "GP work" what else comes to mind that is off-loaded to the local site that you can think of?
Perhaps I'm looking at this sideways?
On 7/28/06, Eric Fleischman wrote:
To add a bit more¦
> The part that makes me wonder about the "story" is if it stores no secrets is the server doing anything for me?
The short answer is yes.
The bulk of the work that a DC does, even in the auth code path, may not involve the secret. So even if the secret checking work is "outsourced" to a hub DC, there is a lot more work that the local DC can perform for the user. For example, if it is an interactive logon, consider all of the GP work alone that is done that is now local.
At the end of the day, you have a knob¦.you can make real security trade-offs based upon what attack surface you can accept & mitigate, what administrative story you want, etc. You get to choose what secrets end up on the RODC. The product is built such that you can turn these knobs as you see fit but the default knob setting is "more secure".
I hope between my response and Dmitri's you are clear that the belief that it stores "nothing locally" is incorrect. If more clarity is required please just holler.
~Eric
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Dmitri GavrilovSent: Friday, July 28, 2006 9:48 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of neil.ruston@xxxxxxxxxxxxxSent: Friday, July 28, 2006 8:22 AMTo: ActiveDir@xxxxxxxxxxxxxxxxxx Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto: ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Al MulnickSent: 28 July 2006 16:08To: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: Re: [ActiveDir] Read-Only Domain Controller and Server Core
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] wrote:
FYI:http://blogs.msdn.com/jolson/archive/2006/07/27/679801.aspx Read-Only Domain Controller and Server CoreList info : http://www.activedir.org/List.aspxList FAQ : http://www.activedir.org/ListFAQ.aspxList archive: http://www.activedir.org/ml/threads.aspx
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. | | | |
| sbradcpa
Posts:496
| | 07/29/2006 7:50 AM |
| Ah see but I don't like mushrooms.
Stupid question alert?
What's the specs on this? We've always joked that in SBSland with our
everything including the kitchen sink on our DCs if there was a way to
make the DC services like on a linksys sized box that attached to the
file/printer/email/kitchen sink box that would remove a lot of
"OHMYGOSHYOUDOWHATTOYOURDC!" that we get from the enterprise crowd.
Are there any embedded OS like plans for this server core RODC?
Crawford, Scott wrote:
Well, since you offered....I'll take a large pan pepperoni and mushroom.
------------------------------------------------------------------------
*From:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx on behalf of Eric Fleischman
*Sent:* Sat 7/29/2006 11:22 AM
*To:* ActiveDir@xxxxxxxxxxxxxxxxxx
*Subject:* RE: [ActiveDir] Read-Only Domain Controller and Server Core
I want to make one other thing clear¦.the other reason to ship the
product in this state is secure by default.
Out of the box, we have no idea what secrets you will want on the
RODC. We don™t know your enterprise or your threat model. As such,
there™s really no good choice¦.we too would be implicitly turning the
knob for better out of the box admin experience vs more secure out
of the box. No good choices.
So, even if you assume that this state is good for no one (a
contention I™ll disagree with, there are some enterprises that will do
this, but that™s not the point), it is still the right state in which
to ship the product.
This is like ordering pizza for every admin in every forest on the planet.
~Eric
------------------------------------------------------------------------
*From:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] *On Behalf Of *Al Mulnick
*Sent:* Friday, July 28, 2006 3:28 PM
*To:* ActiveDir@xxxxxxxxxxxxxxxxxx
*Subject:* Re: [ActiveDir] Read-Only Domain Controller and Server Core
That's the ~Eric we've come to know :)
Thanks for that view. I'll take your advice and check for the traffic
and rethink the view on the RODC concept. Like you said, it may prove
uninteresting, but after that amount of information from you, Dmitri
and Guido, I'd hate to leave that stone unturned.
I'll ping back if I get lost watching the traces. I appreciate the
offer and you guys taking the time to discuss this.
Al
On 7/28/06, *Eric Fleischman* > wrote:
Hi Al,
Take your workstation and take a sniff of a logon. All traffic you
throw at the DC will work against the RODC. The only WAN traffic in
that scenario would be the auth itself, a tiny amt of work. (assuming
GC and all that is satisfied locally)
So, the statement that authentication is your biggest use is true,
kinda¦you need to more carefully define the operation. I suspect you
don't mean auth in the Kerberos sense, you mean "user logon" really.
Unless your branch has a bunch of apps that do Kerb work and no
clients¦.then you can correct me and we have a totally different
conversation on our hands. :)
Answering some questions of yours, from this and other forks of the
thread¦..
> What conditions would make it so that the password policy would be
configured such that the password replication
> was not allowed?
There is a policy (not group policy, administrative one defined in AD
itself) which defines what can be cached there and what can not. The
statement made (I think first by Dmitri, but I then commented on it
further) was that by default, this policy allows almost nothing to be
cached. You could tweak this in your enterprise and change what is
cached, anything from the near-nothing default to almost every secret
in the domain. You can choose.
> Would that just be that the RODC is no longer trusted (i.e. it was
abducted or otherwise compromised?)
Well, we never know if an RODC was compromised. Rather, RODC was built
such that you the admin can assume they are compromised, and fully
understand the scope of compromise in your enterprise should it happen
one day, and respond to said event.
So, I say you should look at this problem the other way¦. Treat your
RODCs /as if /they were about to get compromised, then make real
decisions around how much work the recovery from said compromise would
be vs. actually having an environment that is useful, reliable, easy
to manage, etc. That's what I was talking about re: the knobs¦.you can
turn said knobs and make decisions that work for you. And we'll have
documentation that will help you do this.
> Or is that something that some admin can configure and hurt
themselves? Better yet, if that were true, is there any value left in the
> RODC that can't get a password hash?
I think I answered this but please holler if it is still unclear.
> Outside of "GP work" what else comes to mind that is off-loaded to
the local site that you can think of?
Take a network sniff of your clients talking to your DCs for a day.
Almost all of that stuff. J You could have apps, you have logon
itself, etc.
> Perhaps I'm looking at this sideways?
Every environment is different. It is entirely possible that a
secret-less RODC is totally uninteresting in your enterprise. That
said, I would argue that you probably haven't done enough
investigation yet to really know if that's true or not¦it's not
personal, why would you? This has likely never been relevant. Almost
no one does this sort of analysis unless they absolutely have to.
Take some data, please report back to us. I'd love to look at said
data with you if you're unclear as to what would fall in what bucket.
Hope this helps. Please holler back with questions.
~Eric
------------------------------------------------------------------------
*From:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx
] *On Behalf Of *Al Mulnick
*Sent:* Friday, July 28, 2006 10:34 AM
*To:* ActiveDir@xxxxxxxxxxxxxxxxxx
*Subject:* Re: [ActiveDir] Read-Only Domain Controller and Server Core
More clarity is always welcome.
I suspect I'm trying to get my mind around the GPO providing that much
value that I would want to put a DC in the local brach as part of the
design vs. trying really hard to use as little of the GPO as possible
and making sure that the changes are as infrequent as possible.
Authentication and name resolution are my biggest uses for a local DC
in a branch. Outside of Exchange of course. Everything else I try to
keep as compartmentalized as I can because if my WAN is a concern such
that I can't use authentication across the wire (or can't trust it)
then I have some big concerns about the branch environment and how
autonomous it is.
Outside of "GP work" what else comes to mind that is off-loaded to the
local site that you can think of?
Perhaps I'm looking at this sideways?
On 7/28/06, *Eric Fleischman* > wrote:
To add a bit more¦
> The part that makes me wonder about the "story" is if it stores no
secrets is the server doing anything for me?
The short answer is yes.
The bulk of the work that a DC does, even in the auth code path, may
not involve the secret. So even if the secret checking work is
"outsourced" to a hub DC, there is a lot more work that the local DC
can perform for the user. For example, if it is an interactive logon,
consider all of the GP work alone that is done that is now local.
At the end of the day, you have a knob¦.you can make real security
trade-offs based upon what attack surface you can accept & mitigate,
what administrative story you want, etc. You get to choose what
secrets end up on the RODC. The product is built such that you can
turn these knobs as you see fit but the default knob setting is "more
secure".
I hope between my response and Dmitri's you are clear that the belief
that it stores "nothing locally" is incorrect. If more clarity is
required please just holler.
~Eric
------------------------------------------------------------------------
*From:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx
] *On Behalf Of *Dmitri
Gavrilov
*Sent:* Friday, July 28, 2006 9:48 AM
*To:* ActiveDir@xxxxxxxxxxxxxxxxxx
*Subject:* RE: [ActiveDir] Read-Only Domain Controller and Server Core
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:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx
] *On Behalf Of
*neil.ruston@xxxxxxxxxxxxx
*Sent:* Friday, July 28, 2006 8:22 AM
*To:* ActiveDir@xxxxxxxxxxxxxxxxxx
*Subject:* RE: [ActiveDir] Read-Only Domain Controller and Server Core
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:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx
] *On Behalf Of *Al Mulnick
*Sent:* 28 July 2006 16:08
*To:* ActiveDir@xxxxxxxxxxxxxxxxxx
*Subject:* Re: [ActiveDir] Read-Only Domain Controller and Server Core
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]* > wrote:
FYI:
http://blogs.msdn.com/jolson/archive/2006/07/27/679801.aspx
Read-Only Domain Controller and Server Core
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
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.
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx | | | |
| GuidoG
Posts:114
| | 07/29/2006 8:12 AM |
| Only if your sister™s name is Cindy ;-)
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Crawford, Scott
Sent: Saturday, July 29, 2006 8:42 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx; ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core
Well, since you offered....I'll take a large pan pepperoni and
mushroom.
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx on
behalf of Eric Fleischman
Sent: Sat 7/29/2006 11:22 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core
I want to make one other thing clear¦.the other reason to ship the
product in this state is secure by default.
Out of the box, we have no idea what secrets you will want on the
RODC. We don™t know your enterprise or your threat model. As such, there™s
really no good choice¦.we too would be implicitly turning the knob for better
out of the box admin experience vs more secure out of the box. No good
choices.
So, even if you assume that this state is good for no one (a
contention I™ll disagree with, there are some enterprises that will do this,
but that™s not the point), it is still the right state in which to ship the
product.
This is like ordering pizza for every admin in every forest on the
planet.
~Eric
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On
Behalf Of Al Mulnick
Sent: Friday, July 28, 2006 3:28 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] Read-Only Domain Controller and Server Core
That's the ~Eric we've come to know :)
Thanks for that view. I'll take your advice and check
for the traffic and rethink the view on the RODC concept. Like you said, it may
prove uninteresting, but after that amount of information from you, Dmitri and
Guido, I'd hate to leave that stone unturned.
I'll ping back if I get lost watching the traces. I
appreciate the offer and you guys taking the time to discuss this.
Al
On 7/28/06, Eric Fleischman
wrote:
Hi
Al,
Take
your workstation and take a sniff of a logon. All traffic you throw at the DC
will work against the RODC. The only WAN traffic in that scenario would be the
auth itself, a tiny amt of work. (assuming GC and all that is satisfied
locally)
So,
the statement that authentication is your biggest use is true, kinda¦you need
to more carefully define the operation. I suspect you don't mean auth in the
Kerberos sense, you mean "user logon" really. Unless your branch has
a bunch of apps that do Kerb work and no clients¦.then you can correct me and
we have a totally different conversation on our hands. :)
Answering
some questions of yours, from this and other forks of the thread¦..
>
What conditions would make it so that the password policy would be
configured such that the password replication
> was not allowed?
There
is a policy (not group policy, administrative one defined in AD itself) which
defines what can be cached there and what can not. The statement made (I think
first by Dmitri, but I then commented on it further) was that by default, this
policy allows almost nothing to be cached. You could tweak this in your
enterprise and change what is cached, anything from the near-nothing default to
almost every secret in the domain. You can choose.
>
Would that just be that the RODC is no longer trusted (i.e. it was
abducted or otherwise compromised?)
Well,
we never know if an RODC was compromised. Rather, RODC was built such that you
the admin can assume they are compromised, and fully understand the scope of
compromise in your enterprise should it happen one day, and respond to said
event.
So,
I say you should look at this problem the other way¦. Treat your RODCs as if
they were about to get compromised, then make real decisions around how
much work the recovery from said compromise would be vs. actually having an
environment that is useful, reliable, easy to manage, etc. That's what I was
talking about re: the knobs¦.you can turn said knobs and make decisions that
work for you. And we'll have documentation that will help you do this.
> Or is that something that some admin can configure and hurt themselves?
Better yet, if that were true, is there any value left in the
> RODC that can't get a password hash?
I
think I answered this but please holler if it is still unclear.
>
Outside of "GP work" what else comes to mind that is
off-loaded to the local site that you can think of?
Take
a network sniff of your clients talking to your DCs for a day. Almost all of
that stuff. J You could have apps, you have logon itself, etc.
>
Perhaps I'm looking at this sideways?
Every
environment is different. It is entirely possible that a secret-less RODC is
totally uninteresting in your enterprise. That said, I would argue that you
probably haven't done enough investigation yet to really know if that's true or
not¦it's not personal, why would you? This has likely never been relevant.
Almost no one does this sort of analysis unless they absolutely have to.
Take
some data, please report back to us. I'd love to look at said data with you if
you're unclear as to what would fall in what bucket.
Hope
this helps. Please holler back with questions.
~Eric
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of Al Mulnick
Sent: Friday, July 28, 2006 10:34 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] Read-Only
Domain Controller and Server Core
More clarity is always welcome.
I suspect I'm trying to get my mind around the GPO providing that much value
that I would want to put a DC in the local brach as part of the design vs.
trying really hard to use as little of the GPO as possible and making sure that
the changes are as infrequent as possible.
Authentication and name resolution are my biggest uses for a local DC in a
branch. Outside of Exchange of course. Everything else I try to keep as
compartmentalized as I can because if my WAN is a concern such that I can't use
authentication across the wire (or can't trust it) then I have some big
concerns about the branch environment and how autonomous it is.
Outside of "GP work" what else comes to mind that is off-loaded to
the local site that you can think of?
Perhaps I'm looking at this sideways?
On 7/28/06, Eric Fleischman
efleis@xxxxxxxxxxxxxxxxxxxxx> wrote:
To
add a bit more¦
>
The part that makes me wonder about the "story" is if it stores
no secrets is the server doing anything for me?
The
short answer is yes.
The
bulk of the work that a DC does, even in the auth code path, may not involve
the secret. So even if the secret checking work is "outsourced" to a
hub DC, there is a lot more work that the local DC can perform for the user.
For example, if it is an interactive logon, consider all of the GP work alone
that is done that is now local.
At
the end of the day, you have a knob¦.you can make real security trade-offs
based upon what attack surface you can accept & mitigate, what
administrative story you want, etc. You get to choose what secrets end up on
the RODC. The product is built such that you can turn these knobs as you see
fit but the default knob setting is "more secure".
I
hope between my response and Dmitri's you are clear that the belief that it
stores "nothing locally" is incorrect. If more clarity is required
please just holler.
~Eric
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of Dmitri Gavrilov
Sent: Friday, July 28, 2006 9:48 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of neil.ruston@xxxxxxxxxxxxx
Sent: Friday, July 28, 2006 8:22 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Al Mulnick
Sent: 28 July 2006 16:08
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] Read-Only Domain Controller and Server Core
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] sbradcpa@xxxxxxxxxxx>
wrote:
FYI:
http://blogs.msdn.com/jolson/archive/2006/07/27/679801.aspx
Read-Only Domain Controller
and Server Core
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
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. | | | |
|
|