LOL.
-- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley Sent: Tuesday, August 01, 2006 2:18 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] 80/20 ..... Was: Read-Only Domain Controller and Server Core I've always followed a DSI[1] access model, it definately supercedes in every way what RBS[resource], RBS[role], ABS, CBS, NBC, ABC can provide ... [1] DSI = Defending Security Infrastructures -B On Tue, 1 Aug 2006, Matt Hargraves wrote: > Without going with an Access-Based Security (ABS) model, there are few ways > to make sure that all of the people who need access to an object are the > only ones who are getting access. Local server security groups (which are > difficult to manage), a smallish environment, user-based ACLs on rights and > objects, or a very strange environment, there is no other way to have a 100% > accurate security environment for resources. > > Access based security is nice because it is very granular, but the problem > with it is that it has a very high level of maintenance and has a lot of > room for error and a lot of inherent cost in hardware. The larger the > environment, the larger the number of points of failure in the security > model. You have 100,000 shares in an environment (or more) and the number > of people required to manage that resource start getting restrictively high. > > Does John the Crankshaft mechanic need access to share > "\\servername\share80385"? Probably not 95% of the time, but that one or > two times a year that he does need access, do you really want to make him > wait between 2 hours and potentially as high as 2 days to gain that access > just so that you an have 100 people controlling 1,000 shares and the ACLs > each? > > I can't argue that RBS is the only way to go, but there's nothing wrong with > going with a hybrid. RBS base with an ABS overlap ends up with a security > model where you've got the potential for granularity, but a system where a > resource has a team that may need access to an object, they can be granted > that access and if there are individuals who need access above and beyond > what the RBS model would grant, the access can be granted. Users who change > roles are automatically removed from the groups they are no longer members > of (via the HR software, SAP or whatever) and when someone moves into a role > where they now require access to a resource (or set of resources), they are > automatically granted that access via the same mechanism. > > The alternative is a forest root with disjoined domain that holds users, > then a resource subdomain and an Exchange subdomain. 2-3 times as many DCs, > added cost that goes with that (power, a/c, NOC space), added overhead of > maintaining that somewhat complex environment... the alternative for larger > environments is to buy 2-3 times as many Exchange servers due to large token > sizes. Not to mention the bloating of your DIT database causing reduced > performance on your DCs. > > An exclusive RBS is a best-case scenario that almost never exists. But it > should be the basis of a security model. The alternative is a bloated > environment and a bloated management structure for that environment. > > An exclusive ABS is another best-case scenario that rarely exists outside of > smaller environments, where management of resources is easier to control > because the people who are controlling the resource know everyone who needs > access to their resource. > > Considering how large the companies you commonly work with are, it's > suprising to see you recommending a difficult to manage model. With > hundreds of thousands of users and possibly a nearly identical number of > shares (or worse... more) and a large number of applications, it's hard to > see where an ABS is practical. > > > > On 7/31/06, joe <[EMAIL PROTECTED]> wrote: > > > > If I am fixing security bugs in my program is it ok to get 80% of them > > and leave the remaining known 20%? > > > > Do you have a lot of faith in a firewall that stops 80% of the bad > > traffic? Or an AV scanner that finds 80%? > > > > If I set up a shared folder to get files shared out to multiple folks, is > > it ok if only 80% of the people I give access to really need the access? > > What if in that shared folder are personal files about you or your wife or > > your kids or maybe some compromising photos of you and your mistress[1]? :) > > > > How about the flip side, if I set up a shared folder and only 80% of the > > folks who need the access get it, is that good? > > > > Would you have a list of people in the DA group where only 80% really > > needed the access? Or again on the flip side, only 80% of the people who > > required it got it? > > > > > > Security should be very tightly controlled. Especially for access. > > > > Role based security fits squarely in this hole, IMO. It is probably more a > > problem with the implementation and the definition of the roles than > > anything because if you really got into defining really granular roles that > > you should, you are almost at the point of doing resource based security > > anyway which again, IMO, is by far the more secure way of handling resource > > security. It is rare that the data access requirements of everyone listed as > > a CrankShaft Engineer, for example, are identical in a company. Sure, a good > > portion of the folks will all access the same things but it isn't good to > > say well then, the Role Crankshaft engineers gets all of these accesses. > > Those of you don't really need the access but are in the role... don't look > > at that data... Pshaw. I just said this the other day on another list but > > good fences make good neighbors. You don't trust people not to do bad > > things, you do everything you can to prevent them from having the > > opportunity to do the bad thing in the first place. With resource based > > access, you give the people who need the access to the resource the access. > > It is much easier overall to figure out who has the access and remove folks > > who don't need it. > > > > joe > > > > > > > > [1] Not sure why anyone would need to those photos but if they were being > > shared, certainly the fewer the better and most certainly only the folks who > > are absolutely required. > > > > > > -- > > O'Reilly Active Directory Third Edition - > > http://www.joeware.net/win/ad3e.htm > > > > > > > > ------------------------------ > > *From:* [EMAIL PROTECTED] [mailto: > > [EMAIL PROTECTED] *On Behalf Of *Alex Alborzfard > > *Sent:* Monday, July 31, 2006 4:32 PM > > *To:* ActiveDir@mail.activedir.org > > *Subject:* RE: [ActiveDir] Read-Only Domain Controller and Server Core > > > > 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]> 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] > > *On Behalf Of *Al Mulnick > > > > *Sent:* Saturday, July 29, 2006 10:06 AM > > > > > > *To:* 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] > wrote: > > > > But very useful idle chatter nonetheless ;-) > > > > > > > > /Guido > > > > > > > > *From:* [EMAIL PROTECTED] [mailto: > > [EMAIL PROTECTED] *On Behalf Of *Eric Fleischman > > *Sent: *Saturday, July 29, 2006 8:35 AM > > > > > > *To:* 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] *On Behalf Of *Grillenmeier, Guido > > *Sent:* Friday, July 28, 2006 11:15 PM > > *To:* 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] *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 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] *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 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] *On Behalf Of *Eric Fleischman > > *Sent: *Friday, July 28, 2006 9:42 PM > > *To:* 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] *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 > > > > > > > > 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]> 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] *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 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 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 to earn my paycheck!" > > > > > > > > I'm sure there's more, but I don't yet know which parts are public > > information and which are NDA. > > > > > > > > Can you tell I'm concerned about the story being created? I like stories; > > don't get me wrong. But I'm concerned that the story being spun up might be > > missing the mark and lead a few people astray. > > > > > > > > Safe to note that there are some features that differentiate the RODC from > > a NT4 BDC and that make it appealing in some cases. > > > > But if it actually does not store anything locally, ever, then I'm not > > sure it's worth the time to deploy one now is it? > > > > > > > > Al > > > > > > > > > > > > > > > > On 7/27/06, *Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]* <[EMAIL PROTECTED]> > > wrote: > > > > FYI: > > > > 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
