subject:"\[ActiveDir\] Read\-Only Domain Controller and Server Core"




Hey Brian, good to see your name on the 
list...

I got pinged offline on the basis behind this 
functionality. I admit to being a little shocked that someone was tossing 
password type info into other attributes especially with AD being so generally 
open to viewing, especially whenusing thePre-W2K Compat group with 
auth'ed usersallowed to see all attributes by default which most domains 
still seem to be in due to fears in what will break if it is turned off. If this 
is purely based on security concerns, I would be more apt to tell people to 
install ADAM on the DCs and put the data there. At least you know that is 
severely locked down by default and not having to be worried what side direction 
someone might come in and pop you from. 

From the standpoint of less crap being sent down to WAN DCs 
I like the idea. I realize I can't have branch level replication but at least 
being able to weed out all of the non-essential attributes would be a nice start 
for tiny branches with 10 users in domains with tens of thousands of users. I 
actually recently had to say it didn't make any sense to move from Novell to AD 
for a customer because of that very issue. You can't imagine how much that 
pained me to say. In cases like that if there is no real strategic reason to 
move to AD, it is better to stay on Novell because of the replication 
model.



--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm




From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Brian 
PuhlSent: Monday, July 31, 2006 4:05 AMTo: 
ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Read-Only Domain 
Controller and Server Core


Youre right Joe  that 
the RODC PAS would complicate things for the developers. The easy 
solution would be for developers to use the writeable flag when connecting to a 
DC, then theyd be guaranteed to not get an RODCbut even that isnt a great 
solution, and if we get the RODC GC it only becomes more 
complex.

For general background 
though, the justification for the RODC PAS DCR is actually that there are 
numerous attributes which contain password hash, or password-like data. 
Because these attributes arent part of the pre-defined list of secrets, they 
are replicated normally rather than on-demand via the PRP. It wouldnt 
do me much good to prevent replication of 5 password attributes, when a 
6th one which also includes a hash gets pushed down through normal 
replication. There needs to be a way for an administrator to define where 
these secrets live and protect them accordingly. 


Ive broached the topic 
of using this method to protect PII data a couple of times in relation to some 
RODC work were doing internally, and the response is always that its firmly in 
the realm of unsupported followed with a thatd be a bad idea and some 
serious head shaking  simply because of the way applications 
behave.

Brian





From: 
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
On Behalf Of joeSent: Sunday, July 30, 2006 5:08 
PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Read-Only Domain 
Controller and Server Core

I am not sure if I 
understand where you are going but let me explain where I am coming 
from.

First, the passwords 
being there or not being there is not important for this talk, that is already 
built in and will be there, now the discussion is around everything versus an 
RODC PAS. 

Everything is already 
there as well but is an important option because it will be the most used 
option. Actually I expect to see a ton of RODCs deployed that are configured as 
replicate everything including passwords so that people get the RO part of the 
benefit and they don't have to worry about replicating bad stuff back into the 
"real directory" and not have to worry about password caching management, if 
someone logs on somewhere, the password is cached there, bob's your uncle have a 
nice day.

So now we get down to 
replicating a portion of the normal attribute set. Why would you want to do 
this? Because you want to minimize the traffic to WAN sites and/or reduced info 
in some locations in case of compromise. For instance, if the email addresses of 
everyone in the company isn't on a DC in a WAN site and someone steals that DC 
hoping to get those email addresses, they are SOL; they missed. However, now 
think about this from a application developer standpoint and it is the same 
issue that exists with GCs only worse because it is DCs. If an app developer 
wants to find something, they need to understand what they can actually find in 
the GC in terms of what attributes are populated. Maybe they (a) put in a 
requirement and hope people follow it, maybe they (b) actually try to verify it, 
maybe they (c) say screw that and query a DC instead because they know all of 
the data is there for a full query. From what I have seen the likely cases for 
an app that can handle any query is C, A, and in the absolute blue moon case B. 
Usually the app

RE: [ActiveDir] Read-Only Domain Controller and Server Core




For Exchange, there has been a lot around Exchange. At no 
point though have I heard that they were even going to start consider supporting 
Exchange with RODCs. I have hear a lot of absolutely we will not support 
Exchange that way. If Exchange were supported, not to be a pain, but I can't 
imagine what a horrible mess that would turn into to support. It isn't my 
opinion that the Exchange team has been wonderfully good at writing code to 
utilize AD as it is already and it is currently relatively 
simple.

I agree on the naming with Guido. Though straw poll now for 
the folks who plan on using RODCs, who plans to just tell them to cache all 
passwords as necessary (excluding admin accounts of course)? Or to put it 
another way, who plans to use RODCs and then actively try to manage where 
passwords can be cached? I would not be surprised to hear that RODCs are going 
out the door with the dial all the way to the right (or left if you prefer) and 
everything but admin passwords are being cached. It still gives a ton of 
benefit, i.e. someone screws with it and that can't (allegedly) get back to the 
"real" directory and not all password hashes would be on all RODCs, it would be 
based on who actually auth'ed at the local DC.

If I could do it dynamically, I would like to do something 
like, if the user/computer has attempted to log into RODC(x) more than y times 
in the last z days, then cache the password locally. If the user/computer hasn't 
authed there inv times in the last w days, then remove them from the 
policy for that RODC again.

My theory is that unless this management is extremely 
simple and mostly automated, most folks won't use it because the security 
concerns probably aren't all that high since most users won't be authenticating 
(and therefore caching) their passwords on most RODCs. 


--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm




From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, 
GuidoSent: Monday, July 31, 2006 4:06 AMTo: 
ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Read-Only Domain 
Controller and Server Core


RODCs 
do NOT replicate a subset of objects = right now they basically replicate 
everything a normal DC has (i.e. the full domain NC, config and schema), less 
the password hashes of any users. 

The OU 
vs. group discussion was solely around configuring the so called Password 
Replication Policy (bad name) for an RODC  and after discussing this here and 
offline, doing various tests and elaborating about possible usage scenarios, I 
agree that configuring this policy by OU doesnt really give you enough 
flexibility. I would actually love to configure it by an LDAP query 
leveraging any appropriate attributes  but this is simply to resource intensive 
during the authentication. Leveraging groups gives us the option to 
automatically provision the memberships appropriately though. Dont forget, 
youll have to do this for users and computers.

Why is 
Password Replication Policy a bad name? Because thats not what it does  
calling it Password Caching Policy would be more appropriate, as an RODC would 
never store a users pwd-hash unless he has logged onto that RODC. Once the 
pwd is changed, an RODC will NOT update the hash  it will only be updated the 
next time a user uses that same RODC. I dont mind this mechanism  it 
provides an automatic cleanup mechanism and thus lowers the attack surface if 
a policy allowed many RODCs to cache a users PWD. But the name Replication 
Policy suggests that an RODC would actually replicate the new password when it 
is changed on a WDC (writeable DC), which is confusing.


Replicating 
only parts of a tree (i.e. only specific OUs) would be a totally different 
story, which I also hope to see in the future (but wont be part of this version 
of RODC). However, RODCs will also be able to replicate the GC partitions 
(making them an ROGC)  but from what I understand this will only be sufficient 
for authenticating, but not to be used as a GC for Exchange (I guess since 
Exchange simply needs that writeable domain partition). So placing an ROGC in a 
remote site will not be sufficient if you also have an Exchange server in that 
site.

Exchange 
2007 edge servers is yet another different story  not sure if they can benefit 
from RODCs.

/Guido



From: 
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
On Behalf Of Paul MayesSent: Monday, July 31, 2006 1:39 
AMTo: activedir@mail.activedir.orgSubject: RE: [ActiveDir] 
Read-Only Domain Controller and Server Core

Apologies 
as Im reading in digest. But I just wanted to chip something into this 
surrounding OUs versus groups as it was something that Ive been thinking about 
on my mind-numbing commute. 
I 
understood that RODCs could be configured to be a read only subset of objects 
(users) from the writeable AD, or that you could set them to cache which would 
also be useful to catch user population at a

RE: [ActiveDir] Read-Only Domain Controller and Server Core




Whoa... Nathan too. This list is 
hopping...

For those folks who don't know Nathan... Read his signature 
carefully and realize the level of people this list is seen by. And don't email 
him directly unless you found a world ending issue with Longhorn DCs, he is a 
busy guy about right now. :) I could easily bother Nathan with about 40 
emails a day but try to leave him completely alone. 

All I say is if this stuff is implemented, please please 
please please have the details in the Platform SDK ASAP. Actualy flag values and 
meanings and caveates and everything else. 

 joe


--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm




From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Nathan 
MuggliSent: Monday, July 31, 2006 12:18 PMTo: 
ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Read-Only Domain 
Controller and Server Core


We thought about using 
the confidential flag as the denotation for the RO-PAS, but that would break too 
many applications. 

The RO-PAS would only 
be for applications that wanted to protect their secrets from replicating to a 
RODC. DIMS (aka cred roaming) is a prime example. Most likely if RO-PAS happens 
it will be a negative PAS in that the marking in the schema would mean that 
the attr is NOT replicated. That way new vanilla attributes are replicated to a 
RODC which would minimize app compat. 

-Nathan 
Muggli
RODC Program 
Manager





From: 
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
On Behalf Of Grillenmeier, 
GuidoSent: Monday, July 31, 
2006 1:35 AMTo: 
ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Read-Only Domain 
Controller and Server Core

Not sure if it makes 
sense, but this could potentially be combined with the confidential flag  RODCs 
wouldnt cache any confidential attributes, unless a Confidential Data Caching 
Policy would allow them to do so 

The confidential flag 
is already used by the Digital Identity Management Service (DIMS) for the 
Credential Roaming feature. And instead of adding yet another flag to 
differentiate attributes which contain secrets or sensitive data, this may just 
be the right flag.

Granted, none of this 
will make life easier for app developers.

/Guido



From: 
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
On Behalf Of Brian 
PuhlSent: Monday, July 31, 
2006 10:05 AMTo: 
ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Read-Only Domain 
Controller and Server Core

Youre right Joe  that 
the RODC PAS would complicate things for the developers. The easy 
solution would be for developers to use the writeable flag when connecting to a 
DC, then theyd be guaranteed to not get an RODCbut even that isnt a great 
solution, and if we get the RODC GC it only becomes more 
complex.

For general background 
though, the justification for the RODC PAS DCR is actually that there are 
numerous attributes which contain password hash, or password-like data. 
Because these attributes arent part of the pre-defined list of secrets, they 
are replicated normally rather than on-demand via the PRP. It wouldnt 
do me much good to prevent replication of 5 password attributes, when a 
6th one which also includes a hash gets pushed down through normal 
replication. There needs to be a way for an administrator to define where 
these secrets live and protect them accordingly. 


Ive broached the topic 
of using this method to protect PII data a couple of times in relation to some 
RODC work were doing internally, and the response is always that its firmly in 
the realm of unsupported followed with a thatd be a bad idea and some 
serious head shaking  simply because of the way applications 
behave.

Brian





From: 
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
On Behalf Of joeSent: Sunday, July 30, 2006 5:08 
PMTo: 
ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Read-Only Domain 
Controller and Server Core

I am not sure if I 
understand where you are going but let me explain where I am coming 
from.

First, the passwords 
being there or not being there is not important for this talk, that is already 
built in and will be there, now the discussion is around everything versus an 
RODC PAS. 

Everything is already 
there as well but is an important option because it will be the most used 
option. Actually I expect to see a ton of RODCs deployed that are configured as 
replicate everything including passwords so that people get the RO part of the 
benefit and they don't have to worry about replicating bad stuff back into the 
"real directory" and not have to worry about password caching management, if 
someone logs on somewhere, the password is cached there, bob's your uncle have a 
nice day.

So now we get down to 
replicating a portion of the normal attribute set. Why would you want to do 
this? Because you want to minimize the traffic to WAN sites and/or reduced info 
in some locations in case of compromise. For instance, if the email addresses of 
everyone in the company isn

RE: [ActiveDir] Read-Only Domain Controller and Server Core

2006-07-31 Thread Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]




This is why I expect most people won't be managing the 
policy that closely. I see RODCs going out with a policy to cache all passwords 
but admin passwords. You get the benefits and don't deal with additional 
management overhead. 

Some places will care enough to do the extra work and some 
more will as well if the toolsets make it trivially easy to manage. If it gets 
down to anything resembling real work load and resource dedication, not going to 
happen in most places.




--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm




From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Al 
MulnickSent: Monday, July 31, 2006 12:50 PMTo: 
ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Read-Only Domain 
Controller and Server Core

See, that's the limitation that for me would make me wonder whether or not 
in *my* environments I would want to deploy such an animal or go full bore and 
deploy a full GC. 

The second biggest problem for me would be to accurately guess where a user 
might be when they logon to the network. They could be ANYWHERE as far as 
I'm concerned and still need to be able to logon. Whether it's in city X 
or branch Y or both in the same day, they may not get what they need if I try to 
restrict them even by group let alone by OU. It's a much more flat 
authentication scenario from my perspective and I cannot see impeding business 
by having them get somewhere and not be able to logon. 
Might still save some performance in the sense that they can logon and 
pull GPO etc. And I still need a chance to see the rest of the traffic to test 
~Eric's information. (not really test, but rather come up to speed with it). 


That's why I'm curious how you envision figuring who logs on where and how 
you'd map that in a way that makes sense. By "you" I'm referring to anyone 
who'd like to comment. 

Al
On 7/31/06, Grillenmeier, 
Guido [EMAIL PROTECTED] 
wrote: 

  
  
  
  RODCs do NOT replicate a subset 
  of objects = right now they basically replicate everything a normal DC has 
  (i.e. the full domain NC, config and schema), less the password hashes of any 
  users. 
  
  The OU vs. group discussion was 
  solely around configuring the so called "Password Replication Policy" (bad 
  name) for an RODC  and after discussing this here and offline, doing various 
  tests and elaborating about possible usage scenarios, I agree that configuring 
  this policy by OU doesn't really give you enough flexibility. I would 
  actually love to configure it by an LDAP query leveraging any appropriate 
  attributes  but this is simply to resource intensive during the 
  authentication. Leveraging groups gives us the option to automatically 
  provision the memberships appropriately though. Don't forget, you'll have to 
  do this for users and computers. 
  
  Why is "Password Replication 
  Policy" a bad name? Because that's not what it does  calling it "Password 
  Caching Policy" would be more appropriate, as an RODC would never store a 
  users pwd-hash unless he has logged onto that RODC. Once the pwd is 
  changed, an RODC will NOT update the hash  it will only be updated the next 
  time a user uses that same RODC. I don't mind this mechanism  it 
  provides an automatic "cleanup" mechanism and thus lowers the attack surface 
  if a policy allowed many RODCs to cache a users PWD. But the name "Replication 
  Policy" suggests that an RODC would actually replicate the new password when 
  it is changed on a WDC (writeable DC), which is confusing. 
  
  
  Replicating only parts of a tree 
  (i.e. only specific OUs) would be a totally different story, which I also hope 
  to see in the future (but won't be part of this version of RODC). However, 
  RODCs will also be able to replicate the GC partitions (making them an ROGC)  
  but from what I understand this will only be sufficient for authenticating, 
  but not to be used as a GC for Exchange (I guess since Exchange simply needs 
  that writeable domain partition). So placing an ROGC in a remote site will not 
  be sufficient if you also have an Exchange server in that site. 
  
  Exchange 2007 edge servers is 
  yet another different story  not sure if they can benefit from 
  RODCs.
  
  /Guido
  
  
  
  From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Paul 
  MayesSent: Monday, July 31, 2006 1:39 AMTo: activedir@mail.activedir.orgSubject: RE: 
  [ActiveDir] Read-Only Domain Controller and Server Core 
  
  
  
  Apologies as I'm 
  reading in digest. But I just wanted to chip something into this surrounding 
  OU's versus groups as it was something that I've been thinking about on my 
  mind-numbing commute. 
  I understood 
  that RODC's could be configured to be a read only subset of objects (users) 
  from the writeable AD, or that you could set them to cache which would also be 
  useful to catch user population at a give

RE: [ActiveDir] Read-Only Domain Controller and Server Core

2006-07-31 Thread Laura A. Robinson




Joe, 
isn't the below kind of like yelling, "OMG! Elvis!" in a McDonald's restaurant 
in Kalamazoo and following it up with, "nobody ask for his 
autograph"?

;-)
Laura

  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of 
  joeSent: Monday, July 31, 2006 3:13 PMTo: 
  ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Read-Only 
  Domain Controller and Server Core
  
  Whoa... Nathan too. This list is 
  hopping...
  
  For those folks who don't know Nathan... Read his 
  signature carefully and realize the level of people this list is seen by. And 
  don't email him directly unless you found a world ending issue with Longhorn 
  DCs, he is a busy guy about right now. :) I could easily bother Nathan 
  with about 40 emails a day but try to leave him completely alone. 
  
  
  All I say is if this stuff is implemented, please please 
  please please have the details in the Platform SDK ASAP. Actualy flag values 
  and meanings and caveates and everything else. 
  
   joe
  
  
  --
  O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
  
  
  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Nathan 
  MuggliSent: Monday, July 31, 2006 12:18 PMTo: 
  ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Read-Only 
  Domain Controller and Server Core
  
  
  We thought about 
  using the confidential flag as the denotation for the RO-PAS, but that would 
  break too many applications. 
  
  The RO-PAS would only 
  be for applications that wanted to protect their secrets from replicating to a 
  RODC. DIMS (aka cred roaming) is a prime example. Most likely if RO-PAS 
  happens it will be a negative PAS in that the marking in the schema would 
  mean that the attr is NOT replicated. That way new vanilla attributes are 
  replicated to a RODC which would minimize app compat. 
  
  
  -Nathan 
  Muggli
  RODC Program 
  Manager
  
  
  
  
  
  From: 
  [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
  On Behalf Of Grillenmeier, 
  GuidoSent: Monday, July 31, 
  2006 1:35 AMTo: 
  ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Read-Only Domain 
  Controller and Server Core
  
  Not sure if it 
  makes sense, but this could potentially be combined with the confidential flag 
   RODCs wouldnt cache any confidential attributes, unless a Confidential 
  Data Caching Policy would allow them to do so 
  
  
  The confidential 
  flag is already used by the Digital Identity Management Service (DIMS) for the 
  Credential Roaming feature. And instead of adding yet another flag to 
  differentiate attributes which contain secrets or sensitive data, this may 
  just be the right flag.
  
  Granted, none of 
  this will make life easier for app developers.
  
  /Guido
  
  
  
  From: 
  [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
  On Behalf Of Brian 
  PuhlSent: Monday, July 31, 
  2006 10:05 AMTo: 
  ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Read-Only Domain 
  Controller and Server Core
  
  Youre right Joe  
  that the RODC PAS would complicate things for the developers. The easy 
  solution would be for developers to use the writeable flag when connecting to 
  a DC, then theyd be guaranteed to not get an RODCbut even that isnt a great 
  solution, and if we get the RODC GC it only becomes more 
  complex.
  
  For general 
  background though, the justification for the RODC PAS DCR is actually that 
  there are numerous attributes which contain password hash, or password-like 
  data. Because these attributes arent part of the pre-defined list of 
  secrets, they are replicated normally rather than on-demand via the 
  PRP. It wouldnt do me much good to prevent replication of 5 password 
  attributes, when a 6th one which also includes a hash gets pushed 
  down through normal replication. There needs to be a way for an 
  administrator to define where these secrets live and protect them 
  accordingly. 
  
  Ive broached the 
  topic of using this method to protect PII data a couple of times in relation 
  to some RODC work were doing internally, and the response is always that its 
  firmly in the realm of unsupported followed with a thatd be a bad idea 
  and some serious head shaking  simply because of the way applications 
  behave.
  
  Brian
  
  
  
  
  
  From: 
  [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
  On Behalf Of joeSent: Sunday, July 30, 2006 5:08 
  PMTo: 
  ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Read-Only Domain 
  Controller and Server Core
  
  I am not sure if I 
  understand where you are going but let me explain where I am coming 
  from.
  
  First, the passwords 
  being there or not being there is not important for this talk, that is already 
  built in and will be there, now the discussion is around everything versus an 
  RODC PAS. 
  
  Everything is already 
  there as well but is an important option because it will be the most used 
  option. Actually I

RE: [ActiveDir] Read-Only Domain Controller and Server Core

2006-07-31 Thread David Adner




The Netware partial-replica model immediately jumped to 
mind when the RODC-PAS idea was broached. I can see a lot of customers 
trying to use this feature to create partial-replicas way beyond concerns of 
preventing replication of sensitive data. I suppose one big difference 
(making an assumption here) is the RODC-PAS will be global and not specific to 
each RODC. Still, I can see customers wanting to "strip out" all sorts of 
data they don't feel needs to be in the branches in order to reduce WAN 
utilization, database sizes, memory consumption, etc. Based on personal 
experience this would probably be a more common reason to deploy an RODC than 
concerns about physical security (not that I agree with them, of 
course).

  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of 
  joeSent: Monday, July 31, 2006 1:53 PMTo: 
  ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Read-Only 
  Domain Controller and Server Core
  
  Hey Brian, good to see your name on the 
  list...
  
  I got pinged offline on the basis behind this 
  functionality. I admit to being a little shocked that someone was tossing 
  password type info into other attributes especially with AD being so generally 
  open to viewing, especially whenusing thePre-W2K Compat group with 
  auth'ed usersallowed to see all attributes by default which most domains 
  still seem to be in due to fears in what will break if it is turned off. If 
  this is purely based on security concerns, I would be more apt to tell people 
  to install ADAM on the DCs and put the data there. At least you know that is 
  severely locked down by default and not having to be worried what side 
  direction someone might come in and pop you from. 
  
  From the standpoint of less crap being sent down to WAN 
  DCs I like the idea. I realize I can't have branch level replication but at 
  least being able to weed out all of the non-essential attributes would be a 
  nice start for tiny branches with 10 users in domains with tens of thousands 
  of users. I actually recently had to say it didn't make any sense to move from 
  Novell to AD for a customer because of that very issue. You can't imagine how 
  much that pained me to say. In cases like that if there is no real strategic 
  reason to move to AD, it is better to stay on Novell because of the 
  replication model.
  
  
  
  --
  O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
  
  
  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Brian 
  PuhlSent: Monday, July 31, 2006 4:05 AMTo: 
  ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Read-Only 
  Domain Controller and Server Core
  
  
  Youre right Joe  
  that the RODC PAS would complicate things for the developers. The easy 
  solution would be for developers to use the writeable flag when connecting to 
  a DC, then theyd be guaranteed to not get an RODCbut even that isnt a great 
  solution, and if we get the RODC GC it only becomes more 
  complex.
  
  For general 
  background though, the justification for the RODC PAS DCR is actually that 
  there are numerous attributes which contain password hash, or password-like 
  data. Because these attributes arent part of the pre-defined list of 
  secrets, they are replicated normally rather than on-demand via the 
  PRP. It wouldnt do me much good to prevent replication of 5 password 
  attributes, when a 6th one which also includes a hash gets pushed 
  down through normal replication. There needs to be a way for an 
  administrator to define where these secrets live and protect them 
  accordingly. 
  
  Ive broached the 
  topic of using this method to protect PII data a couple of times in relation 
  to some RODC work were doing internally, and the response is always that its 
  firmly in the realm of unsupported followed with a thatd be a bad idea 
  and some serious head shaking  simply because of the way applications 
  behave.
  
  Brian
  
  
  
  
  
  From: 
  [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
  On Behalf Of joeSent: Sunday, July 30, 2006 5:08 
  PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Read-Only Domain 
  Controller and Server Core
  
  I am not sure if I 
  understand where you are going but let me explain where I am coming 
  from.
  
  First, the passwords 
  being there or not being there is not important for this talk, that is already 
  built in and will be there, now the discussion is around everything versus an 
  RODC PAS. 
  
  Everything is already 
  there as well but is an important option because it will be the most used 
  option. Actually I expect to see a ton of RODCs deployed that are configured 
  as replicate everything including passwords so that people get the RO part of 
  the benefit and they don't have to worry about replicating bad stuff back into 
  the "real directory" and not have to worry about password caching management, 
  if someo

Re: [ActiveDir] Read-Only Domain Controller and Server Core


The way I read that was as follows:

20% means that 20% of your assets are unprotected 1/5 of sensitive 
data is not managed like it should be, controlled, audited, protected etc.


20% of laptops with mobile data isn't encrypted.
20% of desktops unpatched
20% of servers unpatched.

You get the idea...

I seriously doubt that the guys that do the IT in MSland could have a 
20% failure rate and not be taking remedial action to change a process 
or fix something.


My guess is you'd like more like a 95 to 99% on that?

A 20% failure rate on patching for example is not acceptable and I'd be 
calling MS and letting them know we got dead bodies that need cleaned up.


Which begs the question.. I have seen on the PatchManagement.org 
listserve a 95% to 97% patch rate being striven for what's the 
normal % success factor of managed machines do you achieve?


Alex Alborzfard wrote:


Can you elaborate on why you think 80/20 concept in security is sloppy 
joe (no pun intended!)?


Alex



*From:* [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] *On Behalf Of *joe

*Sent:* Monday, July 31, 2006 3:14 PM
*To:* ActiveDir@mail.activedir.org
*Subject:* RE: [ActiveDir] Read-Only Domain Controller and Server Core

It is a sensitive spot with me, I think 80/20 is a great concept, but 
in security it is a bit sloppy.


--

O'Reilly Active Directory Third Edition - 
http://www.joeware.net/win/ad3e.htm




*From:* [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] *On Behalf Of *Al Mulnick

*Sent:* Monday, July 31, 2006 12:29 PM
*To:* ActiveDir@mail.activedir.org
*Subject:* Re: [ActiveDir] Read-Only Domain Controller and Server Core

Darned if you weren't the only one to pick up on it. :)



On 7/30/06, *joe* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 
wrote:


Argh there it is 80/20 in a security discussion. Oi!

:)

--

O'Reilly Active Directory Third Edition - 
http://www.joeware.net/win/ad3e.htm




*From:* [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED] [mailto: 
[EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED]] *On Behalf Of *Al Mulnick


*Sent:* Saturday, July 29, 2006 10:06 AM


*To:* ActiveDir@mail.activedir.org mailto:ActiveDir@mail.activedir.org
*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* [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED] wrote:


But very useful idle chatter nonetheless ;-)

/Guido

*From:* [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED

RE: [ActiveDir] Read-Only Domain Controller and Server Core




Certainly I know of a couple of customers who could 
immediately make use of it in exactly that way right now. The first thing I 
would be doing once that feature hit is finding out how much I could strip out 
and then find ways to strip out even more because honestly, most of that Cat-1 
base schema stuff really isn't necessary everywhere. :)



--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm




From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of David 
AdnerSent: Monday, July 31, 2006 5:56 PMTo: 
ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Read-Only Domain 
Controller and Server Core

The Netware partial-replica model immediately jumped to 
mind when the RODC-PAS idea was broached. I can see a lot of customers 
trying to use this feature to create partial-replicas way beyond concerns of 
preventing replication of sensitive data. I suppose one big difference 
(making an assumption here) is the RODC-PAS will be global and not specific to 
each RODC. Still, I can see customers wanting to "strip out" all sorts of 
data they don't feel needs to be in the branches in order to reduce WAN 
utilization, database sizes, memory consumption, etc. Based on personal 
experience this would probably be a more common reason to deploy an RODC than 
concerns about physical security (not that I agree with them, of 
course).

  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of 
  joeSent: Monday, July 31, 2006 1:53 PMTo: 
  ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Read-Only 
  Domain Controller and Server Core
  
  Hey Brian, good to see your name on the 
  list...
  
  I got pinged offline on the basis behind this 
  functionality. I admit to being a little shocked that someone was tossing 
  password type info into other attributes especially with AD being so generally 
  open to viewing, especially whenusing thePre-W2K Compat group with 
  auth'ed usersallowed to see all attributes by default which most domains 
  still seem to be in due to fears in what will break if it is turned off. If 
  this is purely based on security concerns, I would be more apt to tell people 
  to install ADAM on the DCs and put the data there. At least you know that is 
  severely locked down by default and not having to be worried what side 
  direction someone might come in and pop you from. 
  
  From the standpoint of less crap being sent down to WAN 
  DCs I like the idea. I realize I can't have branch level replication but at 
  least being able to weed out all of the non-essential attributes would be a 
  nice start for tiny branches with 10 users in domains with tens of thousands 
  of users. I actually recently had to say it didn't make any sense to move from 
  Novell to AD for a customer because of that very issue. You can't imagine how 
  much that pained me to say. In cases like that if there is no real strategic 
  reason to move to AD, it is better to stay on Novell because of the 
  replication model.
  
  
  
  --
  O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
  
  
  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Brian 
  PuhlSent: Monday, July 31, 2006 4:05 AMTo: 
  ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Read-Only 
  Domain Controller and Server Core
  
  
  Youre right Joe  
  that the RODC PAS would complicate things for the developers. The easy 
  solution would be for developers to use the writeable flag when connecting to 
  a DC, then theyd be guaranteed to not get an RODCbut even that isnt a great 
  solution, and if we get the RODC GC it only becomes more 
  complex.
  
  For general 
  background though, the justification for the RODC PAS DCR is actually that 
  there are numerous attributes which contain password hash, or password-like 
  data. Because these attributes arent part of the pre-defined list of 
  secrets, they are replicated normally rather than on-demand via the 
  PRP. It wouldnt do me much good to prevent replication of 5 password 
  attributes, when a 6th one which also includes a hash gets pushed 
  down through normal replication. There needs to be a way for an 
  administrator to define where these secrets live and protect them 
  accordingly. 
  
  Ive broached the 
  topic of using this method to protect PII data a couple of times in relation 
  to some RODC work were doing internally, and the response is always that its 
  firmly in the realm of unsupported followed with a thatd be a bad idea 
  and some serious head shaking  simply because of the way applications 
  behave.
  
  Brian
  
  
  
  
  
  From: 
  [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
  On Behalf Of joeSent: Sunday, July 30, 2006 5:08 
  PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Read-Only Domain 
  Controller and Server Core
  
  I am not sure if I 
  understand where you are going but let me explain where I am coming 
  from.

RE: [ActiveDir] Read-Only Domain Controller and Server Core




RE: RODC PAS

Oi, that will add some nice complexity to all of 
this... :)

If I was looking to implement that I think I would look 
at doing it in four levels so people don't shoot themselves... Everything, 
everything but password info, core NOS info required for auth/authz 
withpasswords, core NOS w/o passwords. 


--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm




From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Dmitri 
GavrilovSent: Friday, July 28, 2006 12:48 PMTo: 
ActiveDir@mail.activedir.orgSubject: 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 RODCs 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 
admins responsibility to populate this list. We might have some UI that helps 
with this process.

Once 
the hash is sent down, theres 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. Theres 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. Theres 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 
dont know if you are seeing the whole object or only a subset of it. We do not 
normally issue referrals due to partial reads.



From: 
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
On Behalf Of [EMAIL PROTECTED]Sent: Friday, July 28, 
2006 8:22 AMTo: ActiveDir@mail.activedir.orgSubject: 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: 
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
On Behalf Of Al MulnickSent: 28 July 2006 16:08To: 
ActiveDir@mail.activedir.orgSubject: 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 toearn my paycheck!" 




I'm sure there's more, but I don't yet know which parts are 
public information and which are NDA. 



Can you tell I'm concerned about the story being created? I 
like stories; don't get me wrong. But I'm concerned that the story being 
spun up might be missing the mark and lead a few people astray. 




Safe to note that there are some features that differentiate 
the RODC from a NT4 BDC and that make it appealing in some 
cases.

But if it actually does not store anything locally, ever, 
then I'm not sure it's worth the time to deploy one now is it? 




Al





On 7/27/06, Susan Bradley, CPA aka 
Ebitz - SBS Rocks [MVP] [EMAIL PROTECTED] wrote: 

FYI: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

Re: [ActiveDir] Read-Only Domain Controller and Server Core

2006-07-30 Thread Al Mulnick

Um, why? What value at this point? 

Last I checked it supports limited applications that might want that information. And if you follow ~Eric's logic, they want to be secure out of the box. That would indicate that they want it to be as minimal as possible until and unless told otherwise. 


To put that information in there by default might be counter to that. 

Now, if you had some templates or something so that we didn't have to work on the carpal tunnel, that would be something:)
On 7/30/06, joe [EMAIL PROTECTED] wrote:



RE: RODC PAS

Oi, that will add some nice complexity to all of this... :)

If I was looking to implement that I think I would look at doing it in four levels so people don't shoot themselves... Everything, everything but password info, core NOS info required for auth/authz withpasswords, core NOS w/o passwords. 



--
O'Reilly Active Directory Third Edition - 
http://www.joeware.net/win/ad3e.htm




From: [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED]] On Behalf Of Dmitri GavrilovSent: Friday, July 28, 2006 12:48 PM
To: ActiveDir@mail.activedir.orgSubject:
 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: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]] On Behalf Of 
[EMAIL PROTECTED]Sent: Friday, July 28, 2006 8:22 AMTo: ActiveDir@mail.activedir.org
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: 
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of 
Al MulnickSent: 28 July 2006 16:08To: ActiveDir@mail.activedir.orgSubject:
 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 toearn my paycheck! 




I'm sure there's more, but I don't yet know which parts are public information and which are NDA. 



Can you tell I'm concerned about the story being created? I like stories; don't get me wrong. But I'm concerned that the story being spun up might be missing the mark and lead a few people astray. 



Safe to note that there are some features that differentiate the RODC from a NT4 BDC and that make it appealing in some cases.

But if it actually does not store anything locally, ever, then I'm not sure it's worth the time to deploy one now is it? 



Al





On 7/27/06, Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] [EMAIL PROTECTED] wrote:
 
FYI: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 recipie

RE: [ActiveDir] Read-Only Domain Controller and Server Core




I agree 100%, secure by default, make the admins learn how 
to make it less secure. This has been one of the core security issues Microsoft 
has had forever. It is good that this has turned around and while it pisses off 
the lesser quality admins, it is good for Windows and the computing 
communityas a whole. If your admins need their hands held, you need new 
admins. Get your checkbook out and stop being stingy. :)

I'll take ham,pepperoni,capsicum, black olives, 
onions, mushrooms, extra sauce, and garlic butter crust please. 
:)


--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm




From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Eric 
FleischmanSent: Saturday, July 29, 2006 12:23 PMTo: 
ActiveDir@mail.activedir.orgSubject: 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 dont know your enterprise or 
your threat model. As such, theres 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 Ill disagree with, there are 
some enterprises that will do this, but thats 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: 
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
On Behalf Of Al 
MulnickSent: Friday, July 28, 
2006 3:28 PMTo: 
ActiveDir@mail.activedir.orgSubject: 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 [EMAIL PROTECTED] 
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, kindayou 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?

RE: [ActiveDir] Read-Only Domain Controller and Server Core

2006-07-30 Thread Paul Mayes









Apologies as Im
reading in digest. But I just wanted to chip something into this surrounding OUs
versus groups as it was something that Ive been thinking about on my
mind-numbing commute. 

I understood that RODCs
could be configured to be a read only subset of objects (users) from the writeable
AD, or that you could set them to cache which would also be useful to catch
user population at a given site if this was unknown. I remember there being a
long discussion at the back of DEC about people wanting the subset replication
to be based around OUs rather than groups, and lots of people being
quite passionate about it. The thing that struck me was how would you then deal
with group membership where the group was sat in a totally different part of
the tree? Somehow youve got to get that closed set to work with, which
is very loosely linked to migration strategies. (Blimey I must have paid
attention on that migration course all of those years ago.). And then youve
got constraints on OU structures for if they are now partitions for replication
in some capacity.

How wrong is this
understanding?

If its kind of right,
then at some point in the future are we going to see multiple domain partitions
hosted on DCs? Cos that would be nice as well as the ability to replicate
subsets as read only. Where a GC could hold writeable copies of domain
partitions that werent from its particular domain in the forest..
etc mmm DC consolidation, the possibilities!



Then going more OT. There
were also rumblings about ROGCs so that didnt contain sensitive
info and could be used purely for email purposes without the baggage of a full
fat DC. Is this correct and how does this relate to Exchange 2007 and its
Edge servers, which from what I can gather are looking to suck bits of the AD
into an ADAM for kind of the same purpose as an ROGC would perform? I may be
totally babbling now.



RE:
[ActiveDir] Read-Only Domain Controller and Server Core


 From:
 Grillenmeier, Guido [EMAIL PROTECTED]
 Date: Sat, 29 Jul 2006 17:14:51 +0100











 
  
  Al,
  thats 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 doesnt 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

RE: [ActiveDir] Read-Only Domain Controller and Server Core




I am not sure if I understand where you are going but let 
me explain where I am coming from.

First, the passwords being there or not being there is not 
important for this talk, that is already built in and will be there, now the 
discussion is around everything versus an RODC PAS. 

Everything is already there as well but is an important 
option because it will be the most used option. Actually I expect to see a ton 
of RODCs deployed that are configured as replicate everything including 
passwords so that people get the RO part of the benefit and they don't have to 
worry about replicating bad stuff back into the "real directory" and not have to 
worry about password caching management, if someone logs on somewhere, the 
password is cached there, bob's your uncle have a nice day.

So now we get down to replicating a portion of the normal 
attribute set. Why would you want to do this? Because you want to minimize the 
traffic to WAN sites and/or reduced info in some locations in case of 
compromise. For instance, if the email addresses of everyone in the company 
isn't on a DC in a WAN site and someone steals that DC hoping to get those email 
addresses, they are SOL; they missed. However, now think about this from a 
application developer standpoint and it is the same issue that exists with GCs 
only worse because it is DCs. If an app developer wants to find something, they 
need to understand what they can actually find in the GC in terms of what 
attributes are populated. Maybe they (a) put in a requirement and hope people 
follow it, maybe they (b) actually try to verify it, maybe they (c) say screw 
that and query a DC instead because they know all of the data is there for a 
full query. From what I have seen the likely cases for an app that can handle 
any query is C, A, and in the absolute blue moon case B. Usually the app will 
just fail to find what it needs if you specify an attribute that isn't in the 
GC. How does Exchange do it??? So there are hybrids like where certain things 
that people KNOW will always be in GC PAS and they will set it up so that 
queries using those things will use a GC and everything else will go to a DC. We 
already know that the same override that exists for the GC PAS would have to 
exist for an RODC PAS so why not just make that the other option and be done 
with it? I don't really see the majority of developers doing this any better 
with RODCs than they do with GCs and so it seems like a lot of make work to 
allow for the flexible handling of that if you just say these are the options. 


Again also the password thing isn't even worried about at 
the app level since apps can play with those anyway.

 joe


--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm




From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Al 
MulnickSent: Sunday, July 30, 2006 6:57 PMTo: 
ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Read-Only Domain 
Controller and Server Core

Um, why? What value at this point? 

Last I checked it supports limited applications that might want that 
information. And if you follow ~Eric's logic, they want to be secure out of the 
box. That would indicate that they want it to be as minimal as possible 
until and unless told otherwise. 

To put that information in there by default might be counter to that. 


Now, if you had some templates or something so that we didn't have to work 
on the carpal tunnel, that would be something:)
On 7/30/06, joe 
[EMAIL PROTECTED] 
wrote: 

  
  
  RE: RODC 
  PAS
  
  Oi, that 
  will add some nice complexity to all of this... :)
  
  If I was 
  looking to implement that I think I would look at doing it in four levels so 
  people don't shoot themselves... Everything, everything but password info, 
  core NOS info required for auth/authz withpasswords, core NOS w/o 
  passwords. 
  
  
  --
  O'Reilly 
  Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
  
  
  
  
  From: [EMAIL PROTECTED] [mailto: 
  [EMAIL PROTECTED]] On Behalf Of Dmitri 
  GavrilovSent: Friday, July 28, 2006 12:48 PM
  To: ActiveDir@mail.activedir.orgSubject: 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

RE: [ActiveDir] RE: [ActiveDir] Read-Only Domain Controller and Server Core

2006-07-29 Thread Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]




I think the story is the fault of the blog post writer. 
That wasn't someone who actually knows what is going on, that was someone who 
say an internal pres that was put on by a PM, probably Nathan, of what they are 
thinking right now and the writer tried to get across the points as he/she 
understood them because he/she thought it was (and it really is) cool. I 
wouldn't take that blog entry to be authoritative for anything on the topic. 


Heck it was even stated that "These features in-turn reduce the attack surface of a 
Windows Server." and it absolutely does nothing to reduce the attack 
surface of a Windows Server, it helps reduce the attack surface on AD as a 
service. 

 joe


--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm




From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Al 
MulnickSent: Friday, July 28, 2006 1:23 PMTo: 
ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] RE: [ActiveDir] 
Read-Only Domain Controller and Server Core


To be completely fair, I'mNOTthe one that said that it doesn't 
store anything. I questioned that from the bloglink that was posted, 
because I know that itcan/does store some information which would make it 
useful.Not that you can get anything from that information, 
but then again, it's early in the adoption cycle (just before it really) so 
there hasn't been a large enough crowd to hammer away at it. 

Being highly familiar with BO environments, I agree it opens plenty of 
opportunity to deploy more DC's where before we could not. In some industries, 
that is far more important than others, but useful nonetheless. 

Note that my original concern was the way that the blog post mentioned the 
product and that it might be a deviation from the original story when the RODC 
concept was created and brought to life. I have seen the RODC before, but I am 
far more limited with what I can talk about and can't. Since I don't know 
what those limits are, I'm erring on the side of not even coming close to 
mentioning what I do and don't know nor some of the other questions that come to 
mind regarding that concept and it's boundaries. This is not the forum for that. 



On 7/28/06, Tim Vander 
Kooi [EMAIL PROTECTED] 
wrote: 

  
  
  
  I'm not sure why you say it 
  doesn't store anything??? It stores EVERYTHING, it simply doesn't get the 
  rights to write anything new back to your core DCs. This is a HUGE 
  breakthrough for those of us with smaller branch offices that today can't cost 
  justify putting an entire server in a BO just to handle authentication, but at 
  the same time we are not willing to open the security hole that is created if 
  you put the DC services on a file server in those offices.. With a RODC I can 
  deploy authentication, as well as hopefully sites, etc. to those file servers 
  without concern that a user might hack in and take over my AD. The 
  number of doors this opens to a spread server architecture is really big. 
  Granted, if you have no branch offices it won't a thing to you. 
  
  
  From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Al 
  MulnickSent: Friday, July 28, 2006 10:08 AM
  To: ActiveDir@mail.activedir.org
  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 toearn my paycheck!" 
  
  
  
  I'm sure there's more, but I don't yet know which parts are public 
  information and which are NDA. 
  
  
  
  Can you tell I'm concerned about the story being created? I like stories; 
  don't get me wrong. But I'm concerned that the story being spun up might 
  be missing the mark and lead a few people astray. 
  
  
  
  Safe to note that there are some features that differentiate the RODC from 
  a NT4 BDC and that make it appealing in some cases.
  
  But if it actually does not store anything locally, ever, then I'm not sure 
  it's worth the time to deploy one now is it? 
  
  
  
  Al
  
  
  
  
  
  On 7/27/06, Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] 
  [EMAIL PROTECTED] 
  wrote: 
  FYI: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

RE: [ActiveDir] Read-Only Domain Controller and Server Core

2006-07-29 Thread Grillenmeier, Guido









Ofcourse OUs dont 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 doesnt matter which mechanism is used to
configure the RODC policies.



However, many companies have organized their AD with a geographic
OU structure, which doesnt 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 cant 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 wont 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 users credentials or not. And I guess a
users group-membership is analyzed faster than figuring out the OU that
a user belongs to.



Naturally, query based security groups wouldnt 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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman
Sent: Friday, July 28, 2006 11:02 PM
To: ActiveDir@mail.activedir.org
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 OUs 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 thisby OU membership or something
elseconstructing a group with said membership is trivial. However, if
you dont know this, OU based policy is not going to help.



With that, Ill state in public that my vote is not to build
OU based policy. Why? Because it doesnt fix the problem. Instead, I want
to spend our engineering dollars building tools to help users find who should
be cached whereie, tackling the problem itself head on. Whether you then
organize by OU or just populate groups is the easy part.



~Eric













From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Grillenmeier, Guido
Sent: Friday, July 28, 2006 1:33 PM
To: ActiveDir@mail.activedir.org
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 companys datacenters.



Biggest challenge I see is configuring the policies for storing
credentials on RODCs  its 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 OUs instead.



I do agree with Al, that the original blog entry that started this
discussion was a little misleading and didnt do the features of RODC
justice. 



/Guido







From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman
Sent: Friday

RE: [ActiveDir] Read-Only Domain Controller and Server Core

2006-07-29 Thread Eric Fleischman









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 dont know your enterprise or your threat
model. As such, theres 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 Ill disagree with, there are some enterprises
that will do this, but thats 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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Al Mulnick
Sent: Friday, July 28, 2006 3:28
PM
To: ActiveDir@mail.activedir.org
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 [EMAIL PROTECTED]
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, kindayou 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 notit'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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
On Behalf Of Al Mulnick
Sent: Friday, July 28, 2006 10:34
AM






To: ActiveDir@mail.activedir.org






Subject: Re:
[ActiveDir] Read-Only Domain Controller and Server Core

RE: [ActiveDir] Read-Only Domain Controller and Server Core

2006-07-29 Thread Crawford, Scott




Well, since you offeredI'll take a large pan pepperoni and mushroom.


From: [EMAIL PROTECTED] on behalf of Eric FleischmanSent: Sat 7/29/2006 11:22 AMTo: ActiveDir@mail.activedir.orgSubject: 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 dont know your enterprise or your threat model. As such, theres 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 Ill disagree with, there are some enterprises that will do this, but thats 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al MulnickSent: Friday, July 28, 2006 3:28 PMTo: ActiveDir@mail.activedir.orgSubject: 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 [EMAIL PROTECTED] 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, kindayou 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 notit'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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Al MulnickS

Re: [ActiveDir] Read-Only Domain Controller and Server Core


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 offeredI'll take a large pan pepperoni and mushroom.


*From:* [EMAIL PROTECTED] on behalf of Eric Fleischman
*Sent:* Sat 7/29/2006 11:22 AM
*To:* ActiveDir@mail.activedir.org
*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:* [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] *On Behalf Of *Al Mulnick

*Sent:* Friday, July 28, 2006 3:28 PM
*To:* ActiveDir@mail.activedir.org
*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* [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED] 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

RE: [ActiveDir] Read-Only Domain Controller and Server Core

2006-07-29 Thread Grillenmeier, Guido









Only if your sisters name is Cindy ;-)







From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Crawford, Scott
Sent: Saturday, July 29, 2006 8:42 PM
To: ActiveDir@mail.activedir.org; ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core











Well, since you offeredI'll take a large pan pepperoni and
mushroom.















From: [EMAIL PROTECTED] on
behalf of Eric Fleischman
Sent: Sat 7/29/2006 11:22 AM
To: ActiveDir@mail.activedir.org
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 dont know your enterprise or your threat model. As such, theres
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 Ill disagree with, there are some enterprises that will do this,
but thats 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:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Al Mulnick
Sent: Friday, July 28, 2006 3:28 PM
To: ActiveDir@mail.activedir.org
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
[EMAIL PROTECTED]
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, kindayou 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
notit's

RE: [ActiveDir] Read-Only Domain Controller and Server Core

2006-07-29 Thread Brian Desmond

IMHO it would be hard to ship an appliance for an application which
requires designing the hardware around the scenario...

Thanks,
Brian Desmond
[EMAIL PROTECTED]

c - 312.731.3132

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:ActiveDir-
 [EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA aka Ebitz -
 SBS Rocks [MVP]
 Sent: Saturday, July 29, 2006 2:50 PM
 To: ActiveDir@mail.activedir.org
 Subject: Re: [ActiveDir] Read-Only Domain Controller and Server Core
 
 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 offeredI'll take a large pan pepperoni and
 mushroom.
 
 
-
 -
  --
  *From:* [EMAIL PROTECTED] on behalf of Eric
  Fleischman
  *Sent:* Sat 7/29/2006 11:22 AM
  *To:* ActiveDir@mail.activedir.org
  *Subject:* RE: [ActiveDir] Read-Only Domain Controller and Server
 Core
 
  I want to make one other thing clearthe 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 choicewe 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:* [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED] *On Behalf Of *Al
Mulnick
  *Sent:* Friday, July 28, 2006 3:28 PM
  *To:* ActiveDir@mail.activedir.org
  *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* [EMAIL PROTECTED]
  mailto:[EMAIL PROTECTED] 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
  clientsthen 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

Re: [ActiveDir] Read-Only Domain Controller and Server Core

2006-07-29 Thread Al Mulnick

I have to admit, when I first read that my initial thought was, why? My second thought was, well, why not? But in the end my first instinct won out and I again ask, why? I mean, SBS comes on an appliance (or am I confusing that with open source version?) But to dedicate a DC to an appliance AND have an SBS box seems to defeat the purpose to me.

Virtualization would be a better bet to me.

RODC on Server Core would be the type of thing that could easily end up in appliance format. Heck, that's half the time spent - figuring out hardware to meet the demands. One shortcoming is that an appliance is harder to support in this scenario because the settings, performance, etc are all tied to the greater fabric. Could be a bit of a support nightmare I'm sure.

To create an appliance with SBS on it would be of interest. To create one for a DC doesn't hold a lot of appeal over virtualization to me.

Am I just missing something Susan?
On 7/29/06, Brian Desmond [EMAIL PROTECTED] wrote:
IMHO it would be hard to ship an appliance for an application whichrequires designing the hardware around the scenario...
Thanks,Brian Desmond[EMAIL PROTECTED]c - 312.731.3132 -Original Message- From:
[EMAIL PROTECTED] [mailto:ActiveDir- [EMAIL PROTECTED]] On Behalf Of Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]
Sent: Saturday, July 29, 2006 2:50 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Read-Only Domain Controller and Server Core
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 offeredI'll take a large pan pepperoni and mushroom.
- - -- *From:* [EMAIL PROTECTED]
on behalf of Eric Fleischman *Sent:* Sat 7/29/2006 11:22 AM *To:* ActiveDir@mail.activedir.org *Subject:* RE: [ActiveDir] Read-Only Domain Controller and Server
Core I want to make one other thing clearthe 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 choicewe too would be implicitly turningthe 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 inwhich to ship the product. This is like ordering pizza for every admin in every forest on the
planet. ~Eric - - -- *From:*
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] *On Behalf Of *AlMulnick *Sent:* Friday, July 28, 2006 3:28 PM
*To:* ActiveDir@mail.activedir.org *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 thetraffic and rethink the view on the RODC concept. Like you said, it mayprove 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* [EMAIL PROTECTED] mailto:
[EMAIL PROTECTED] 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 suspectyou 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
clientsthen 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 replicationwas not allowed?
There is a policy (not group policy, administrative one defined inAD 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 tobe

Re: [ActiveDir] Read-Only Domain Controller and Server Core

2006-07-29 Thread Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]


SBS doesn't come on an appliance

remember SBS is now

Windows
Exchange
Sharepoint
ISA (yes we have our firewall on it)
Also running DHCP/DNS/AD
Kitchen Sink
And in the R2 era WSUS
SQL server 2k5 workgroup

But it's not on an appliance... sucky hardware at times yes, but not 
appliance.


But virtualization is prob the better way to go... I'm just thinking 
also the Centro OS that will be splitting off roles but keeping the 
wizardish stuff.


I think you are thinking of Nitix which has an appliance version.

Al Mulnick wrote:
I have to admit, when I first read that my initial thought was, why? 
My second thought was, well, why not?  But in the end my first 
instinct won out and I again ask, why?  I mean, SBS comes on an 
appliance (or am I confusing that with open source version?)  But to 
dedicate a DC to an appliance AND have an SBS box seems to defeat the 
purpose to me.
 
Virtualization would be a better bet to me.
 
RODC on Server Core would be the type of thing that could easily end 
up in appliance format. Heck, that's half the time spent - figuring 
out hardware to meet the demands.  One shortcoming is that an 
appliance is harder to support in this scenario because the settings, 
performance, etc are all tied to the greater fabric.  Could be a bit 
of a support nightmare I'm sure.
 
To create an appliance with SBS on it would be of interest.  To create 
one for a DC doesn't hold a lot of appeal over virtualization to me.
 
Am I just missing something Susan?


 
On 7/29/06, *Brian Desmond* [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED] wrote:


IMHO it would be hard to ship an appliance for an application which
requires designing the hardware around the scenario...

Thanks,
Brian Desmond
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]

c - 312.731.3132

 -Original Message-
 From: [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] [mailto:ActiveDir-
mailto:ActiveDir-
 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]] On
Behalf Of Susan Bradley, CPA aka Ebitz -
 SBS Rocks [MVP]
 Sent: Saturday, July 29, 2006 2:50 PM
 To: ActiveDir@mail.activedir.org
mailto:ActiveDir@mail.activedir.org
 Subject: Re: [ActiveDir] Read-Only Domain Controller and Server Core

 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 offeredI'll take a large pan pepperoni and
 mushroom.
 
 
-
 -
  --
  *From:* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] on behalf of Eric
  Fleischman
  *Sent:* Sat 7/29/2006 11:22 AM
  *To:* ActiveDir@mail.activedir.org
mailto:ActiveDir@mail.activedir.org
  *Subject:* RE: [ActiveDir] Read-Only Domain Controller and Server
 Core
 
  I want to make one other thing clearthe 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 choicewe 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:* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]] *On Behalf Of *Al
Mulnick
  *Sent:* Friday, July 28, 2006 3:28 PM
  *To:* ActiveDir@mail.activedir.org
mailto:ActiveDir@mail.activedir.org
  *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

RE: [ActiveDir] Read-Only Domain Controller and Server Core

2006-07-29 Thread Crawford, Scott

Now, that would be just a little to frustrating for me :)

From: [EMAIL PROTECTED] on behalf of Grillenmeier, Guido
Sent: Sat 7/29/2006 3:11 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core

Only if your sister's name is Cindy ;-)

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Crawford, Scott
Sent: Saturday, July 29, 2006 8:42 PM
To: ActiveDir@mail.activedir.org; ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core

Well, since you offeredI'll take a large pan pepperoni and mushroom.

From: [EMAIL PROTECTED] on behalf of Eric Fleischman
Sent: Sat 7/29/2006 11:22 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core

I want to make one other thing clearthe 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 choicewe 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick
Sent: Friday, July 28, 2006 3:28 PM
To: ActiveDir@mail.activedir.org
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 [EMAIL PROTECTED] 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 clientsthen 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 knobsyou 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

Re: [ActiveDir] Read-Only Domain Controller and Server Core

2006-07-29 Thread Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]


I was.

(but typically I'm thinking SBSized)

Brian Desmond wrote:


*I wasn’t thinking of SBS. SBS could totally be an appliance. I 
thought she meant AD in general. *


* *

*Thanks,*

*Brian Desmond*

[EMAIL PROTECTED]

* *

*c - 312.731.3132*

* *

*From:* [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] *On Behalf Of *Al Mulnick

*Sent:* Saturday, July 29, 2006 9:48 PM
*To:* ActiveDir@mail.activedir.org
*Subject:* Re: [ActiveDir] Read-Only Domain Controller and Server Core

 

I have to admit, when I first read that my initial thought was, why? 
My second thought was, well, why not?  But in the end my first 
instinct won out and I again ask, why?  I mean, SBS comes on an 
appliance (or am I confusing that with open source version?)  But to 
dedicate a DC to an appliance AND have an SBS box seems to defeat the 
purpose to me.


 


Virtualization would be a better bet to me.

 

RODC on Server Core would be the type of thing that could easily end 
up in appliance format. Heck, that's half the time spent - figuring 
out hardware to meet the demands.  One shortcoming is that an 
appliance is harder to support in this scenario because the settings, 
performance, etc are all tied to the greater fabric.  Could be a bit 
of a support nightmare I'm sure.


 

To create an appliance with SBS on it would be of interest.  To create 
one for a DC doesn't hold a lot of appeal over virtualization to me.


 


Am I just missing something Susan?

 

On 7/29/06, *Brian Desmond* [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED] wrote:


IMHO it would be hard to ship an appliance for an application which
requires designing the hardware around the scenario...

Thanks,
Brian Desmond
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]

c - 312.731.3132

 -Original Message-
 From: [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED] [mailto:ActiveDir- 
mailto:ActiveDir-
 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]] On 
Behalf Of Susan Bradley, CPA aka Ebitz -

 SBS Rocks [MVP]
 Sent: Saturday, July 29, 2006 2:50 PM
 To: ActiveDir@mail.activedir.org mailto:ActiveDir@mail.activedir.org
 Subject: Re: [ActiveDir] Read-Only Domain Controller and Server Core

 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 offeredI'll take a large pan pepperoni and
 mushroom.
 
 
-
 -
  --
  *From:* [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED] on behalf of Eric

  Fleischman
  *Sent:* Sat 7/29/2006 11:22 AM
  *To:* ActiveDir@mail.activedir.org 
mailto:ActiveDir@mail.activedir.org

  *Subject:* RE: [ActiveDir] Read-Only Domain Controller and Server
 Core
 
  I want to make one other thing clearthe 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 choicewe 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:* [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED]] *On Behalf Of *Al

Mulnick
  *Sent:* Friday, July 28, 2006 3:28 PM
  *To:* ActiveDir@mail.activedir.org 
mailto:ActiveDir@mail.activedir.org

  *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* [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED]
  mailto: [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED] 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

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 toearn my paycheck!


I'm sure there's more, but I don't yet know which parts are public information and which are NDA. 

Can you tell I'm concerned about the story being created? I like stories; don't get me wrong. But I'm concerned that the story being spun up might be missing the mark and lead a few people astray. 

Safe to note that there are some features that differentiate the RODC from a NT4 BDC and that make it appealing in some cases.
But if it actually does not store anything locally, ever, then I'm not sure it's worth the time to deploy one now is it? 

Al


On 7/27/06, Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] [EMAIL PROTECTED] wrote:
FYI: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

RE: [ActiveDir] Read-Only Domain Controller and Server Core

2006-07-28 Thread neil.ruston




RODC stores password hashes only for a pre defined list of 
users and they are not stored on a permanent basis. [I'm unclear how the latter 
is achieved.]

The goal is such that if the RODC were removed from the 
office then no password secrets could be extracted from that 
machine.


neil


From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Al 
MulnickSent: 28 July 2006 16:08To: 
ActiveDir@mail.activedir.orgSubject: 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 toearn my paycheck!" 

I'm sure there's more, but I don't yet know which parts are public 
information and which are NDA. 

Can you tell I'm concerned about the story being created? I like stories; 
don't get me wrong. But I'm concerned that the story being spun up might 
be missing the mark and lead a few people astray. 

Safe to note that there are some features that differentiate the RODC from 
a NT4 BDC and that make it appealing in some cases.
But if it actually does not store anything locally, ever, then I'm not sure 
it's worth the time to deploy one now is it? 

Al


On 7/27/06, Susan 
Bradley, CPA aka Ebitz - SBS Rocks [MVP] [EMAIL PROTECTED] wrote: 
FYI: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.

[ActiveDir] RE: [ActiveDir] Read-Only Domain Controller and Server Core

2006-07-28 Thread Tim Vander Kooi









I’m not sure why you say it doesn’t store anything??? It stores
EVERYTHING, it simply doesn’t get the rights to write anything new back to your
core DCs. This is a HUGE breakthrough for those of us with smaller branch
offices that today can’t cost justify putting an entire server in a BO just to
handle authentication, but at the same time we are not willing to open the
security hole that is created if you put the DC services on a file server in
those offices. With a RODC I can deploy authentication, as well as hopefully
sites, etc. to those file servers without concern that a user might hack in and
take over my AD.  The number of doors this opens to a spread server
architecture is really big. Granted, if you have no branch offices it won’t a
thing to you.





From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick
Sent: Friday, July 28, 2006 10:08 AM
To: ActiveDir@mail.activedir.org
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 toearn my
paycheck! 











I'm sure there's more, but I don't yet know which parts are
public information and which are NDA. 











Can you tell I'm concerned about the story being created? I
like stories; don't get me wrong. But I'm concerned that the story being
spun up might be missing the mark and lead a few people astray. 











Safe to note that there are some features that differentiate
the RODC from a NT4 BDC and that make it appealing in some cases.





But if it actually does not store anything locally, ever,
then I'm not sure it's worth the time to deploy one now is it? 











Al



















On 7/27/06, Susan Bradley, CPA aka
Ebitz - SBS Rocks [MVP] [EMAIL PROTECTED]
wrote: 

FYI:

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

RE: [ActiveDir] Read-Only Domain Controller and Server Core

2006-07-28 Thread Dmitri Gavrilov









The set of passwords that *can* be sent down to the RODC
is controlled by password replication policy. The passwords are sent down by RODCs
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 admins responsibility to populate this
list. We might have some UI that helps with this process.



Once the hash is sent down, theres 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. Theres
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. Theres 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 dont know if
you are seeing the whole object or only a subset of it. We do not normally
issue referrals due to partial reads.







From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of [EMAIL PROTECTED]
Sent: Friday, July 28, 2006 8:22 AM
To: ActiveDir@mail.activedir.org
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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick
Sent: 28 July 2006 16:08
To: ActiveDir@mail.activedir.org
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 toearn my
paycheck! 











I'm sure there's more, but I don't yet know which parts are
public information and which are NDA. 











Can you tell I'm concerned about the story being created? I
like stories; don't get me wrong. But I'm concerned that the story being
spun up might be missing the mark and lead a few people astray. 











Safe to note that there are some features that differentiate
the RODC from a NT4 BDC and that make it appealing in some cases.





But if it actually does not store anything locally, ever,
then I'm not sure it's worth the time to deploy one now is it? 











Al



















On 7/27/06, Susan Bradley, CPA aka
Ebitz - SBS Rocks [MVP] [EMAIL PROTECTED]
wrote: 

FYI:

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

RE: [ActiveDir] Read-Only Domain Controller and Server Core

2006-07-28 Thread Eric Fleischman









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 Dmitris
you are clear that the belief that it stores nothing locally is
incorrect. If more clarity is required please just holler.



~Eric













From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Dmitri Gavrilov
Sent: Friday, July 28, 2006 9:48
AM
To: ActiveDir@mail.activedir.org
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 RODCs 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 admins
responsibility to populate this list. We might have some UI that helps with
this process.



Once the hash is
sent down, theres 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. Theres 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. Theres 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
dont know if you are seeing the whole object or only a subset of it. We
do not normally issue referrals due to partial reads.







From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of [EMAIL PROTECTED]
Sent: Friday, July 28, 2006 8:22
AM
To: ActiveDir@mail.activedir.org
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:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick
Sent: 28 July 2006 16:08
To: ActiveDir@mail.activedir.org
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 toearn my
paycheck! 











I'm sure there's more, but I don't yet know which parts are public
information and which are NDA. 











Can you tell I'm concerned about the story being created? I like
stories; don't get me wrong. But I'm concerned that the story being spun
up might be missing the mark and lead a few people astray. 











Safe to note that there are some features that differentiate the RODC
from a NT4 BDC and that make it appealing in some cases.





But if it actually does not store anything locally, ever, then I'm not
sure it's worth the time to deploy one now is it? 











Al



















On 7/27/06, Susan
Bradley, CPA aka Ebitz - SBS Rocks [MVP] [EMAIL PROTECTED] wrote:


FYI:

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

Re: [ActiveDir] Read-Only Domain Controller and Server Core

What conditions would make it so that the password policy would be configured such that the password replication was not allowed? Would that just be that the RODC is no longer trusted (i.e. it was abducted or otherwise compromised?)

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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]] On Behalf Of 
[EMAIL PROTECTED]Sent: Friday, July 28, 2006 8:22 AM
To: ActiveDir@mail.activedir.org
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: 
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of 
Al MulnickSent: 28 July 2006 16:08To: ActiveDir@mail.activedir.orgSubject:
 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 toearn my paycheck! 




I'm sure there's more, but I don't yet know which parts are public information and which are NDA. 



Can you tell I'm concerned about the story being created? I like stories; don't get me wrong. But I'm concerned that the story being spun up might be missing the mark and lead a few people astray. 



Safe to note that there are some features that differentiate the RODC from a NT4 BDC and that make it appealing in some cases.

But if it actually does not store anything locally, ever, then I'm not sure it's worth the time to deploy one now is it? 



Al





On 7/27/06, Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] [EMAIL PROTECTED] wrote:
 
FYI: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 r

Re: [ActiveDir] RE: [ActiveDir] Read-Only Domain Controller and Server Core


To be completely fair, I'mNOTthe one that said that it doesn't store anything. I questioned that from the bloglink that was posted, because I know that itcan/does store some information which would make it useful.Not that you can get anything from that information, but then again, it's early in the adoption cycle (just before it really) so there hasn't been a large enough crowd to hammer away at it.


Being highly familiar with BO environments, I agree it opens plenty of opportunity to deploy more DC's where before we could not. In some industries, that is far more important than others, but useful nonetheless. 


Note that my original concern was the way that the blog post mentioned the product and that it might be a deviation from the original story when the RODC concept was created and brought to life. I have seen the RODC before, but I am far more limited with what I can talk about and can't. Since I don't know what those limits are, I'm erring on the side of not even coming close to mentioning what I do and don't know nor some of the other questions that come to mind regarding that concept and it's boundaries. This is not the forum for that.



On 7/28/06, Tim Vander Kooi [EMAIL PROTECTED] wrote:




I'm not sure why you say it doesn't store anything??? It stores EVERYTHING, it simply doesn't get the rights to write anything new back to your core DCs. This is a HUGE breakthrough for those of us with smaller branch offices that today can't cost justify putting an entire server in a BO just to handle authentication, but at the same time we are not willing to open the security hole that is created if you put the DC services on a file server in those offices.. With a RODC I can deploy authentication, as well as hopefully sites, etc. to those file servers without concern that a user might hack in and take over my AD. The number of doors this opens to a spread server architecture is really big. Granted, if you have no branch offices it won't a thing to you.



From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]] On Behalf Of Al MulnickSent:
 Friday, July 28, 2006 10:08 AM
To: ActiveDir@mail.activedir.org
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 toearn my paycheck! 




I'm sure there's more, but I don't yet know which parts are public information and which are NDA. 



Can you tell I'm concerned about the story being created? I like stories; don't get me wrong. But I'm concerned that the story being spun up might be missing the mark and lead a few people astray. 



Safe to note that there are some features that differentiate the RODC from a NT4 BDC and that make it appealing in some cases.

But if it actually does not store anything locally, ever, then I'm not sure it's worth the time to deploy one now is it? 



Al





On 7/27/06, Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] [EMAIL PROTECTED] wrote:
 
FYI: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

Re: [ActiveDir] Read-Only Domain Controller and Server Core