"The local DC is an auth point either for redundancy in case of WAN break or for perf to prevent the auth traffic from traversing the WAN."
I don't buy that. At best, I would have the local DC work some of the time (not predictable) if I used a caching only DC or a RODC becaue my WAN link would not be considered reliable in this scenario (which would be one reason why I would put one there right?) Unfortunately, it would not be predictable which is far worse for the user experience and help desk scenarios. I'd be more apt to put a full-fledged DC on that site vs. a caching version. I assume you want the security benefits more than the performance, of putting a RODC or caching DC in a remote site while you still want to retain the performance. But because the performance would not be predictable, it would be a support nightmare to me, and if it had the information available, it would be a risk no matter what. Unless you had something else in mind? Here's my thoughts: AD provides IAA services. As such, it must be a trusted entity. Even if I change the name, at some point I need a trusted entity to hold identities. AD does that today, and a RODC or CDC isn't going to change the need for IAA services. The question is where to geographically deploy those and how many trusted realms they can handle per instance. More precisely, how they can provide IAA services for as many realms as possible. It's a trusted entity and must be protected accordingly. Should it fall into the wrong hands, it could compromise my ability to trust it for IAA services. If it shares all of the information available in the other sites, then I have problem with a much larger global scope. If it only holds information for the local site, then I have a much narrower (geographically and likely in terms of number of clients) breach so it follows that I should have less effort to expend repairing the breach and getting back to goodness. Whenever I deploy a branch solution, I expect the following to be the criteria (at a minimum): 1) must satisfy the operational requirements 2) must be secure and secureable 3) needs to be cheap [1] The implication of the operational requirements is availability. It's expected that they are highly available. If I had a CDC or RODC, (hey, wouldn't it be nice if this was a button to press like making an Exchange server a FE server or not?) I have four options to choose from: 1) I could deploy a RODC, 2) I could deploy a CDC or 3) I could deploy a full fledged DC. 4)I could not deploy any DC (IAA entity) and rely on the WAN for IAA traffic. Each has strengths and weaknesses right? Traditionally, I only had two choices DC or no DC in the local site. I see the RODC and CDC options as being pretty close to the fourth option except that for a period of time I could save some WAN bits. I don't see this as a reliability question because if the WAN is down, I can't get all of my users in there UNLESS they have been authenticated before by that machine AND have not waited past the TTL or... A RODC doesn't have a cache like that, so I can't lump that in there. But it still only works if the user has logged on before and the authentication has been replicated to the RODC meaning the WAN link was operational. The plus is that I have less risk if the dc goes missing. On the other hand, if I deploy a DC to that environment, I have a better and more predictable chance that the site will continue to function even if three fiber-seeking backhoes get hold of my WAN in three countries. The site can be more self-sufficient. The drawback is that I have a bigger security concern if something happens to that IAA entity. Potentially, my loss is greater if that server sprouts legs because my entire AD must be considered compromised if that happens. Why virtualize here? Because I may have multiple security boundaries, A.K.A. forests that I have deployed for various service functions or business security boundaries. What to do? I think a more federated ability might be useful here. I think being able to handle multiple security realms would be awesome if done without having to unnaturally have a client configured or use TS type apparatus. But the real reason I want mutliple forests hosted on the same hardware is so that I don't have to buy environmentals for these small-ish sites. I don't want to have to host 4 machines in a wiring closet just for IAA services. I want one even if it runs four instances. I understand that it must be protected in that remote site. Just give me the ability to allow local opposable thumbs the ability to logon and back it up without having the keys to the kingdom. A RODC doesn't solve all three problems. None of the solutions really does, and in fact if I can run multiple IAA entities on the same machine, I've effectively increased my risk and penalty. Dangerous thinking that is. But I have also maintained my first priority which is to provide a service in a reliable fashion. It's the second requirement I'm still having trouble with and it's what federation concepts might help with. [1] I threw that in there as a tip of the hat to managers that always want it fast, cheap, and secure but forget that they can only have two of those. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Tuesday, October 11, 2005 5:09 PM To: [email protected] Subject: RE: [ActiveDir] Active Directory wish list > How's that better than having a live, writeable version handy? > The limitations of a RODC seem to be unwieldy and otherwise clumsy on it's own. In most every branch DC I have seen, there was no serious need to be able to handle full LDAP searchs or allow local writes. The local DC is an auth point either for redundancy in case of WAN break or for perf to prevent the auth traffic from traversing the WAN. Exceptions were LARGE branch DCs that had local web servers or Exchange. The idea of the caching DC is not the same as the RODC. Think of a caching DC as a DNS server that has an non-authoritative copy of a name that will disappear when the TTL goes away. The RODC is a complete copy of the domain, config, and schema that only replicates changes in. Way back at DEC a few years ago when Stuart (of the Ottawa Kwans) queried the audience on the idea of a caching DC or RODC I was very much behind the caching DC idea with the idea it was like DNS and wasn't actually a DC for any Domain but could cache creds for all domains as long as the domain said it was ok. I obviously lost that one. But I still see it as something that would be valuable. Another possible option is that each WAN site is its own Federation and everyone else just trusts the creds that comes out from it. Of course, we are a long ways out from MS having fat client Federation. It is all web based until probably Blackcomb. > For that matter, why does it have to be a native LH thing vs. keeping > some of the legacy intact? Huh? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick Sent: Tuesday, October 11, 2005 11:19 AM To: [email protected] Subject: RE: [ActiveDir] Active Directory wish list Expand? "Even better in my opinion would be a DC that could auth someone from any domain, basically a caching DC, once someone auth's there, their credentials come down and sit there until some TTL and then they are purged. " How's that better than having a live, writeable version handy? The limitations of a RODC seem to be unwieldy and otherwise clumsy on it's own. I can see multiple NC's being a good thing as long as the apps follow. I also think Aric is right to question the thoughts behind security boundaries. That needs a serious rethink without legacy interaction. Bolt on the legacy stuff as an option later or something, but the concepts that were the foundation are gone now. Departmental level servers are not the norm as they were in the last major design phase of NOS products. Multiple domains don't make a lot of sense any longer either. I don't see that as beneficial, but rather as greens fee to be in the game. Multiple security realms can be useful in some cases, but should we have to have to deploy multiple instances of the OS to achieve that? That's what this seems to boil down to in my mind. For that matter, why does it have to be a native LH thing vs. keeping some of the legacy intact? I don't know that it does because of the way the clients find resources, now that it gets mentioned in that light. ;) It should be far easier to deploy multiple security realms without unnatural acts of deployment. It should also be far easier to share my resources with your resources without having to rewrite the wheel or jump through fiery hoops. And there shouldn't be the same limitations of a security realm that I have today. If I want to put down a group of settings that should apply to 10 of the 50 NC's, I should be able to do that across all boundaries and for all settings. Passwords included. Should we work back from the functionality needed and decide what stays from there? Or is it better to continue to debate the legacy cost vs. dropping it in favor of doing things differently? I don't think they are exclusive of each other FWIW. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Monday, October 10, 2005 9:07 PM To: [email protected] Subject: RE: [ActiveDir] Active Directory wish list :o) Don't even need to worry about multiple ports. It is all hierarchical. I can, for instance run 50 NCs on a single ADAM instance on a single server. I could also run 50 different instances of ADAM on 50 different ports. Which makes more sense? But otherwise yes, the SRV records coupled with the builtin hierarchical structure just helps in many ways. As for the iusr accounts and actually any accounts for the system provided services and cluster accounts, etc. I don't like them. I like connection agreements for chatting between machines. This service on this machine can talk to that service on that machine. Look at DNS/WINS replication. Look at Exchange now. Etc. There are lots of cases that spinning up two whole domain controllers for two different domains is extreme overkill versus simply allowing the one DC handle principals from the two domains. Even better in my opinion would be a DC that could auth someone from any domain, basically a caching DC, once someone auth's there, their credentials come down and sit there until some TTL and then they are purged. Out of curiosity, does anyone know if anyone has tried integrating MIT or Heimdahl kerb packages into a server running ADAM using ADAM for the backend principal store? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bernard, Aric Sent: Monday, October 10, 2005 6:59 PM To: [email protected] Subject: RE: [ActiveDir] Active Directory wish list Agreed - the legacy APIs pose a serious problem in many cases. After noodling over the LDAP issue a little more, and recalling that ports are specified in the SRV records :), any AD aware of SRV aware system/application should be able to handle multiple instances of LDAP on a single server (assuming they are each using a different port or IP). The SYSVOL issue is also negligible as, like you said, the file system hierarchy was clearly designed with the domain name embedded. The only issue here that remains (in its current incarnation) is that of data replication. Given the advancements shown in DFSR this should be easily overcome with the only problem being replicating data to places it should not be (i.e. a legacy DC running some antiquated OS like W2K or W2K3 pre-R2 ;-). There are of course other unhandled issues such as which domain should the IUSR_Machine user object be created in if IIS is installed/running on a multi-domain capable DC? (Or better yet, should the IUSR account exist at all?) Regardless, there is a substantial trail of legacy issues that have to be handled before multi-domain DCs can come to fruition. Of course we should more properly be talking about multi-forest DCs as opposed to multi-domain DCs - or does that just blur the entire security boundary issue a bit too much? Needless to say, given the current technology, using virtual guest operating systems atop your favorite virtualization product is a viable way to generally satisfy the need for running multiple domains on a single piece of hardware as opposed to the desire of running them all on a single OS instance albeit at a higher theoretical cost for system management and other pay for software that is installed in each instance. Aric -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Monday, October 10, 2005 2:09 PM To: [email protected] Subject: RE: [ActiveDir] Active Directory wish list I don't think the issue is there. When you make an LDAP call, you specify where you want to go, the hierarchy is all there and required in the call. Also I don't believe the issue is in SYSVOL, if you look at the sysvol structure, it has the domain component in there. In fact when I first saw that in say Oct 1999 in the gold product I was thinking... Hmmmm is MS thinking about supporting multiple domains from a single DC? One of the big issues is at the level of all of the old NET style calls. You specify a server, not a domain, then it assumes there is one auth point on that one server (i.e. one SAM in the old days) and it works it. If a call came in for user bob on server123 and there were three domains or partitions or x hosted all of which have bob, which one gets sent back? If the old NET functionality got dumped, I would be rewriting quite a bit of code. The only reason I am not already doing it is that there is no impetus to, it works, I don't have to worry about it. At the same time, that holds back from doing newer and cooler things if MS did offer the option to move on. If that option were there though... I would start rewriting to get to it. At the present time, there is no sign of the death of the NET API so there is no reason to rewrite something that works fine using it unless there is some other reason (like you need something that isn't accessible through the API). Even on this list which has a lot of the more eager techofolks, we discuss the WinNT provider and other NET API based methods quite a bit for accessing AD. How come everyone isn't only using the LDAP methods? Answer, because the NET API methods still work for many things. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bernard, Aric Sent: Monday, October 10, 2005 4:03 PM To: [email protected] Subject: RE: [ActiveDir] Active Directory wish list Sounds like we need an LDAP.SYS that is similar to HTTP.SYS in that it can act as a routing, queuing, and parsing mechanism to determine which LDAP namespace/partition or domain an inbound request is destined for. With such a mechanism in place registration/advertisement (DNS) of the various LDAP namespaces supported should be compatible with today's implementation and existing client capabilities. However, some of the other facets of the NOS implementation (i.e. SYSVOL) would still be unaccounted for but I suppose similar proxy methods could be developed to support these subsystems as well... Aric -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charlie Kaiser Sent: Monday, October 10, 2005 12:42 PM To: [email protected] Subject: RE: [ActiveDir] Active Directory wish list The limitations of the VMs are the underlying hardware, in our case. I have 9 VMs running on one server. It's choking for more RAM, but management won't foot the bill for the additional riser card and ram. Otherwise, no limitations in functionality. If I had adequate hdw to run the VMs I could use VMs more gracefully. I've used/use desktop hdw to run testlab machines, but scalability and user experience testing is indeed a factor for some things. The underlying "wish" here was to be able to put multiple AD DCs on one piece of hdw/OS. Instead of having to build 3 VMs or physical machines, be able to run 3 domains on one, with AD running as a service, kinda like the way IIS can run multiple websites, or SQL can run multiple DBs (although it's at a lower level than either of those apps). If I could run 3 domains on 2 servers instead of 6, I would imagine that I'd save on licensing costs as well as hdw, since running an AD service would likely be less hdw intensive than running an OS... We can dream, can't we? :-) ********************** Charlie Kaiser W2K3 MCSA/MCSE/Security, CCNA Systems Engineer Essex Credit / Brickwalk 510 595 5083 ********************** > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick > Sent: Monday, October 10, 2005 10:28 AM > To: [email protected] > Subject: Re: [ActiveDir] Active Directory wish list > > I agree. SMB business can be very complex. > > Can you expand on the idea that VM's aren't working well for you? I'm > trying to understand the difference between that and a multiple domain > DC for that scenario. > > I'd have to say that smaller, cheaper dc's (desktop class?) have > always worked well for me in the past when doing functionality > testing. > Scalability requires full-blown hardware. But I'm not seeing where VM > environments aren't working as well as you'd like a physical > environment to work? What's the difference in this situation? > > For availability, I could see some value in a DC configured to host > mulitple domains because I could designate one to be the failover for > several domains. Otherwise, I'm not sure I get it. Is this like a > LPAR concept you're talking about? That would be more helpful to you > in these situations? > If so, how is that different than VM's? > > Test environments are notoriously able to take down servers without > warning. > I would often prefer to use a VM to decrease that risk of consuming > all resources to destruction. That provides some isolation while not > requiring extra hardware. > > VM's require licenses (the OS and apps do) FWIW. You're only saving on > the hardware and environmentals that I can see, but I'm trying to > understand what I'm missing. > > > ----- Original Message ----- > From: "Charlie Kaiser" <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Monday, October 10, 2005 11:05 AM > Subject: RE: [ActiveDir] Active Directory wish list > > > For us, it's the ability to run parallel domains for test/development > purposes. We have our production domain, my IT test domain, and our > LOB application test domain. I'd have another IT test domain if I had > the available hardware right now. > We are required to test and document all changes to the LOB app and a > significant number of people work in that test domain. > Running it on VMs > or old hardware doesn't cut it gracefully, although that's what I do. > Since management won't write the check for additional > hardware/licenses, we do what we can. > But if we had one beefy server to replace 3, and one server license to > replace 3, it would be much more cost effective to do, and would > increase performance for the user community. > In my last gig, we had multiple domains that were used for development > and customer support departments. The support kids especially needed > multiple domains to recreate customer environments and various > software versions. > I can think of a lot of reasons to need multiple domains/forests in an > SMB environment. Regulatory compliance, 24x7 availability that > mandates full testing prior to implementation in production, customer > support domains, etc. Just because a business is small doesn't mean it > can't have complex requirements... > > ********************** > Charlie Kaiser > W2K3 MCSA/MCSE/Security, CCNA > Systems Engineer > Essex Credit / Brickwalk > 510 595 5083 > ********************** > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick > > Sent: Monday, October 10, 2005 7:10 AM > > To: [email protected] > > Subject: RE: [ActiveDir] Active Directory wish list I'm curious, > > Charlie and Neil. What services do these SMB's offer that they need > > multiple instances of DC's? I realize that a best practice is to > > have multiple servers that can provide some failure tolerant > > behaviors, but I'm wondering what type of work a SMB does that > > requires multiple full blown AD domain instances and therefore > > multiple servers etc. Can you expand that? > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
