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 offered....I'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. > > > > > Perhaps I'm looking at this sideways? > > > > Every environment is different. It is entirely possible that a > > secret-less RODC is totally uninteresting in your enterprise. That > > said, I would argue that you probably haven't done enough > > investigation yet to really know if that's true or not...it's not > > personal, why would you? This has likely never been relevant. Almost > > no one does this sort of analysis unless they absolutely have to. > > > > Take some data, please report back to us. I'd love to look at said > > data with you if you're unclear as to what would fall in what bucket. > > > > Hope this helps. Please holler back with questions. > > > > ~Eric > > > > --------------------------------------------------------------------- > - > > -- > > > > *From:* [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]> > > [mailto:[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>] *On Behalf Of *Al > Mulnick > > *Sent:* Friday, July 28, 2006 10:34 AM > > > > > > *To:* ActiveDir@mail.activedir.org > > <mailto:ActiveDir@mail.activedir.org> > > > > *Subject:* Re: [ActiveDir] Read-Only Domain Controller and Server > Core > > > > More clarity is always welcome. > > > > I suspect I'm trying to get my mind around the GPO providing that > much > > value that I would want to put a DC in the local brach as part of the > > design vs. trying really hard to use as little of the GPO as possible > > and making sure that the changes are as infrequent as possible. > > > > Authentication and name resolution are my biggest uses for a local DC > > in a branch. Outside of Exchange of course. Everything else I try to > > keep as compartmentalized as I can because if my WAN is a concern > such > > that I can't use authentication across the wire (or can't trust it) > > then I have some big concerns about the branch environment and how > > autonomous it is. > > > > Outside of "GP work" what else comes to mind that is off-loaded to > the > > local site that you can think of? > > > > Perhaps I'm looking at this sideways? > > > > On 7/28/06, *Eric Fleischman* < [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> wrote: > > > > To add a bit more... > > > > > The part that makes me wonder about the "story" is if it stores no > > secrets is the server doing anything for me? > > > > The short answer is yes. > > > > The bulk of the work that a DC does, even in the auth code path, may > > not involve the secret. So even if the secret checking work is > > "outsourced" to a hub DC, there is a lot more work that the local DC > > can perform for the user. For example, if it is an interactive logon, > > consider all of the GP work alone that is done that is now local. > > > > At the end of the day, you have a knob....you can make real security > > trade-offs based upon what attack surface you can accept & mitigate, > > what administrative story you want, etc. You get to choose what > > secrets end up on the RODC. The product is built such that you can > > turn these knobs as you see fit but the default knob setting is "more > > secure". > > > > I hope between my response and Dmitri's you are clear that the belief > > that it stores "nothing locally" is incorrect. If more clarity is > > required please just holler. > > > > ~Eric > > > > --------------------------------------------------------------------- > - > > -- > > > > *From:* [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]> > > [mailto:[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>] *On Behalf Of *Dmitri > > Gavrilov > > *Sent:* Friday, July 28, 2006 9:48 AM > > > > > > *To:* ActiveDir@mail.activedir.org > > <mailto: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 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]> > > [mailto:[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>] *On Behalf Of > > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > *Sent:* Friday, July 28, 2006 8:22 AM > > *To:* ActiveDir@mail.activedir.org > > <mailto: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]> [mailto: > > [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>] *On Behalf Of *Al > Mulnick > > *Sent:* 28 July 2006 16:08 > > *To:* ActiveDir@mail.activedir.org > > <mailto: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 to earn my paycheck!" > > > > I'm sure there's more, but I don't yet know which parts are public > > information and which are NDA. > > > > Can you tell I'm concerned about the story being created? I like > > stories; don't get me wrong. But I'm concerned that the story being > > spun up might be missing the mark and lead a few people astray. > > > > Safe to note that there are some features that differentiate the RODC > > from a NT4 BDC and that make it appealing in some cases. > > > > But if it actually does not store anything locally, ever, then I'm > not > > sure it's worth the time to deploy one now is it? > > > > Al > > > > > > > > On 7/27/06, *Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]* < > > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: > > > > FYI: > > > > http://blogs.msdn.com/jolson/archive/2006/07/27/679801.aspx > > <http://blogs.msdn.com/jolson/archive/2006/07/27/679801.aspx> > > > > > > Read-Only Domain Controller and Server Core > > > > > > > > > > List info : http://www.activedir.org/List.aspx > > List FAQ : http://www.activedir.org/ListFAQ.aspx > > List archive: http://www.activedir.org/ml/threads.aspx > > > > PLEASE READ: The information contained in this email is confidential > > and > > > > intended for the named recipient(s) only. If you are not an intended > > > > recipient of this email please notify the sender immediately and > > delete your > > > > copy from your system. You must not copy, distribute or take any > > further > > > > action in reliance on it. Email is not a secure method of > > communication and > > > > Nomura International plc ('NIplc') will not, to the extent permitted > > by law, > > > > accept responsibility or liability for (a) the accuracy or > > completeness of, > > > > or (b) the presence of any virus, worm or similar malicious or > > disabling > > > > code in, this message or any attachment(s) to it. If verification of > > this > > > > email is sought then please request a hard copy. Unless otherwise > > stated > > > > this email: (1) is not, and should not be treated or relied upon as, > > > > investment research; (2) contains views or opinions that are solely > > those of > > > > the author and do not necessarily represent those of NIplc; (3) is > > intended > > > > for informational purposes only and is not a recommendation, > > solicitation or > > > > offer to buy or sell securities or related financial instruments. > > NIplc > > > > does not provide investment services to private customers. Authorised > > and > > > > regulated by the Financial Services Authority. Registered in England > > > > no. 1550505 VAT No. 447 2492 35. Registered Office: 1 St > > Martin's-le-Grand, > > > > London, EC1A 4NP . A member of the Nomura group of companies. > > > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: http://www.activedir.org/ml/threads.aspx 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
