My production patching has been very lucky. I tend to find the bugs in testing and if I get through my testing ok then I haven't had an issue in prod that I can recall, at least nothing in the last 6 or so years. Certainly when I managed an Enterprise (DCs/Wins/And utility servers for domain support) I was at a 100% patch rate for applied patches across the ~390 or so machines and I can't think of any patch that I wanted to apply but it wouldn't go on or would cause a failure if I did so. Once I felt a patch was good and my manager felt it was good (over and above or completely to the side of whether security or the integration group thought it was good) I would usually have a patch out to all of the machines globally in a couple of hours. The process involved pushing the patch package to all of the machines at the same time, then slowly, at first, pulling the triggers on machines that wouldn't have major impact if they all went unavailable together. After about a 1/3 were done then the speed got ramped up and larger numbers would be done at once. At the end the one off utility machines would be touched and I would wrap the new patch into the build wrapup process so it was automatically applied on every new machine built.
-- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] Sent: Monday, July 31, 2006 6:15 PM To: ActiveDir@mail.activedir.org Subject: 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]>[mailto:[EMAIL PROTECTED] vedir.org > <mailto:[EMAIL PROTECTED]>] *On Behalf Of *Eric > Fleischman > *Sent: *Saturday, July 29, 2006 8:35 AM > > > *To:* ActiveDir@mail.activedir.org <mailto:ActiveDir@mail.activedir.org> > *Subject: *RE: [ActiveDir] Read-Only Domain Controller and Server Core > > You basically articulated my point for me. J > > > And once tools exist to automate this knowledge whether by populating > groups or attributes (such as office or address) > > > or leveraging an OU structure, it really doesn't matter which > mechanism is used to configure the RODC policies. > > Yup. My contention is that in many cases, I think this will be > non-trivial for customers. They will have trouble knowing where > security principals are..especially computers. So we need to spend > engineering effort here (the Auth2 list should help with this though). > > > However, many companies have organized their AD with a geographic OU > structure, which doesn't necessarily match > > > 100% to their site structure, but certainly gets pretty close > > Yes, and because it is not 100%, they'll either need to move users > around across their OUs (which has other implications, like on > delegation) or use groups to work around it. ;) > > My contention is not that OUs are a bad idea for this sort of policy. > Only that: > > - For many customers they will not work. Groups will work for all > customers, even the ones that are already organized by OU..simply > provision a group with the OU membership and you have it. > > - If I ran the world and got to choose ever engineering dollar that we > spend, I would want to solve as many problems as I can. Far more > customers will have trouble figuring out what security principals are > where than there are customers that have a 100% site to OU mapping. > > My $0.02. Since I don't make this call, maybe this is idle chatter. ;) > > ~Eric > > ------------------------------------------------------------------------ > > *From:* [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>[mailto:[EMAIL PROTECTED] vedir.org > <mailto:[EMAIL PROTECTED]>] *On Behalf Of > *Grillenmeier, Guido > *Sent:* Friday, July 28, 2006 11:15 PM > *To:* ActiveDir@mail.activedir.org <mailto:ActiveDir@mail.activedir.org> > *Subject:* RE: [ActiveDir] Read-Only Domain Controller and Server Core > > Ofcourse OUs don't fix the underlying challenge of knowing which user > belongs to which site. And once tools exist to automate this knowledge > whether by populating groups or attributes (such as office or address) > or leveraging an OU structure, it really doesn't matter which > mechanism is used to configure the RODC policies. > > However, many companies have organized their AD with a geographic OU > structure, which doesn't necessarily match 100% to their site > structure, but certainly gets pretty close. And since the delegation > model is often configured such that local admins manage particular > aspects of the users and computers in their site, it is a common > practice to move a user account from one OU to another when the user > is relocated to a different location within the company. As such the > OU structure is often a good starting base to build policies for which > credentials to replicate to which RODC. > > I do agree that a lot of the same customers tend to have a security > group that matches the OU a user is located in, simply because an OU > is not a security principal and thus you can't use it for > permissioning (another long missed feature from Netware). The problem > is that without automation tools (and there are still plenty of > customers without these), the "OU-specific users group" won't > necessarily be updated as consistently when a User account is moved > from one OU to another. > > I am sure that at some point it is a performance thing - not sure how > this password replication mechanism actually works in the background, > but I think an RODC needs to make decisions at the time of logon of a > user: during the logon process the RODC must determine if it should > cache (and then continue to replicate) the user's credentials or not. > And I guess a user's group-membership is analyzed faster than figuring > out the OU that a user belongs to. > > Naturally, query based security groups wouldn't help to improve > performance, but if you could add some nice processes from MIIS to AD > that periodically and dynamically populate AD groups based on LDAP > queries (without the need to support another database), this would > certainly help. And the I would be all for using groups instead of OUs > ;-) > > /Guido > > *From:* [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>[mailto:[EMAIL PROTECTED] vedir.org > <mailto:[EMAIL PROTECTED]>] *On Behalf Of *Eric > Fleischman > *Sent: *Friday, July 28, 2006 11:02 PM > *To:* ActiveDir@mail.activedir.org <mailto: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 OU's instead. > > To be clear, OUs are a "Guido likes the way this looks" feature, not a > "this helps the problem" feature. > > The crux of the problem is figuring out who to cache on a given RODC. > If you know this.by OU membership or something else.constructing a > group with said membership is trivial. However, if you don't know > this, OU based policy is not going to help. > > With that, I'll state in public that my vote is not to build OU based > policy. Why? Because it doesn't fix the problem. Instead, I want to > spend our engineering dollars building tools to help users find who > should be cached where.ie, tackling the problem itself head on. > Whether you then organize by OU or just populate groups is the easy part. > > ~Eric > > ------------------------------------------------------------------------ > > *From:* [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>[mailto:[EMAIL PROTECTED] vedir.org > <mailto:[EMAIL PROTECTED]>] *On Behalf Of > *Grillenmeier, Guido > *Sent:* Friday, July 28, 2006 1:33 PM > *To:* ActiveDir@mail.activedir.org <mailto: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 company's datacenters. > > Biggest challenge I see is configuring the policies for storing > credentials on RODCs - it's the typical challenge of matching mobile > objects (users and notebooks) to non-mobile devices (an RODC in a > site). And currently this is all based on group memberships. I hope to > see an option coming up to use OU's instead. > > I do agree with Al, that the original blog entry that started this > discussion was a little misleading and didn't do the features of RODC > justice. > > /Guido > > *From:* [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>[mailto:[EMAIL PROTECTED] vedir.org > <mailto:[EMAIL PROTECTED]>] *On Behalf Of *Eric > Fleischman > *Sent: *Friday, July 28, 2006 9:42 PM > *To:* ActiveDir@mail.activedir.org <mailto:ActiveDir@mail.activedir.org> > *Subject:* RE: [ActiveDir] Read-Only Domain Controller and Server Core > > Hi Al, > > Take your workstation and take a sniff of a logon. All traffic you > throw at the DC will work against the RODC. The only WAN traffic in > that scenario would be the auth itself, a tiny amt of work. (assuming > GC and all that is satisfied locally) > > So, the statement that authentication is your biggest use is true, > kinda.you need to more carefully define the operation. I suspect you > don't mean auth in the Kerberos sense, you mean "user logon" really. > Unless your branch has a bunch of apps that do Kerb work and no > clients..then you can correct me and we have a totally different > conversation on our hands. :) > > Answering some questions of yours, from this and other forks of the > thread... > > > What conditions would make it so that the password policy would be > configured such that the password replication > > > was not allowed? > > There is a policy (not group policy, administrative one defined in AD > itself) which defines what can be cached there and what can not. The > statement made (I think first by Dmitri, but I then commented on it > further) was that by default, this policy allows almost nothing to be > cached. You could tweak this in your enterprise and change what is > cached, anything from the near-nothing default to almost every secret > in the domain. You can choose. > > > Would that just be that the RODC is no longer trusted (i.e. it was > abducted or otherwise compromised?) > > Well, we never know if an RODC was compromised. Rather, RODC was built > such that you the admin can assume they are compromised, and fully > understand the scope of compromise in your enterprise should it happen > one day, and respond to said event. > > So, I say you should look at this problem the other way.. Treat your > RODCs /as if/ they were about to get compromised, then make real > decisions around how much work the recovery from said compromise would > be vs. actually having an environment that is useful, reliable, easy > to manage, etc. That's what I was talking about re: the knobs..you can > turn said knobs and make decisions that work for you. And we'll have > documentation that will help you do this. > > > Or is that something that some admin can configure and hurt > themselves? Better yet, if that were true, is there any value left in the > > > RODC that can't get a password hash? > > I think I answered this but please holler if it is still unclear. > > > Outside of "GP work" what else comes to mind that is off-loaded to > the local site that you can think of? > > Take a network sniff of your clients talking to your DCs for a day. > Almost all of that stuff. J You could have apps, you have logon > itself, etc. > > > Perhaps I'm looking at this sideways? > > Every environment is different. It is entirely possible that a > secret-less RODC is totally uninteresting in your enterprise. That > said, I would argue that you probably haven't done enough > investigation yet to really know if that's true or not.it's not > personal, why would you? This has likely never been relevant. Almost > no one does this sort of analysis unless they absolutely have to. > > Take some data, please report back to us. I'd love to look at said > data with you if you're unclear as to what would fall in what bucket. > > Hope this helps. Please holler back with questions. > > ~Eric > > ------------------------------------------------------------------------ > > *From:* [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>[mailto:[EMAIL PROTECTED] vedir.org > <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] vedir.org > <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] vedir.org > <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 > <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. > > > -- Letting your vendors set your risk analysis these days? http://www.threatcode.com If you are a SBSer and you don't subscribe to the SBS Blog... man ... I will hunt you down... http://blogs.technet.com/sbs 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
