And...I generalized the root domain comment, that was certainly a mistake. It was a common recommendation that it be done for security and even Microsoft mistakenly recommended an empty root for a while for that reason. I know that I had that mindset for a while when AD first came out until I started learning more about AD. Security wasn't (and isn't) the only reason for an empty root. I think that a good explaination of some good reasons for implementing an empty forest root might be a good idea as it is an area that doesn't have a lot of information about it. I wouldn't mind getting your (and others) opinion on when to use an empty root; the GPO example was good and was an aspect I hadn't thought of before.
I think the problem is that by showing the multi-domain forest example it is a tacit recommendation of its use to some people. I don't necessarily agree that people should read it that way but I can see where people would. Plus many people don't want to start from scratch, they will take what someone has, mark it down for their own, and then try to decide what to change.> Even big companies generally start out by trying to have a single forest single domain and only move from that if it makes sense.I agree they do this if they are coming from another OS or have a VERY decentralized NT infrastructure. From what I have seen, the companies that organized under NT4 to have account domains tend to follow those same account domain designs when moving to AD. The resource domains they tend to fold in. I think the reason here being to avoid the whole customer training piece. Personally though, I think companies really need to start training people to use UPNs and then the underlying domain structure isn't so very important.> The empty root domain was a common recommendation a number of years ago, but that> position has been revised as the reasons it was recommended were based on the empty> root giving you more security but it doesn't offer more security. There has been extensive> coverage of this on the list as well and I think a recent post by joe touched on it again.The empty root domain discussions always kind of irk me. SOME people said it should be done for security. Those same people were the ones thinking a domain was a security boundary. Those who knew it wasn't a security boundary still would recommend empty roots and still do if there appear to be reasons for it. In other words, not everyone that has an empty root did it because they thought it was for securing the enterprise admin group, in fact in the company that I personally moved from NT4 to AD securing the Enterprise Admin group was never a consideration behind the reasoning of the empty root.The one thing that I think could sort of be considered security related is the fact that you can dictate via administrative policy that no one dorks with the policy on the forest root so you know you always have a haven away from dorked up GPOs. This is especially true if you let someone other than domain admins create/modify/link GPOs rather high in the AD structure of a domain. I have seen first hand domains that have been locked down for all users on all machines to kiosk mode. It isn't funny when it is happening but is a riot months later when you can laugh about it. Personally I am against anyone but DAs modifying policy in the domains but then I HATE GPOs anyway and consider them to be extremely dangerous.joe
From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Phil Renouf
Sent: Thursday, October 13, 2005 2:51 PM
To: [email protected]
Subject: Re: [ActiveDir] Design Question
Just to re-iterate this: the BO Guide does not specifically recommend a multi domain forest even for larger organisations. It uses the multi domain forest as an example and specifically states that configuration is just an example and not a recommendation. There is a section in the document on design, but I don't think it recommends a multi domain forest there either.Even big companies generally start out by trying to have a single forest single domain and only move from that if it makes sense.The empty root domain was a common recommendation a number of years ago, but that position has been revised as the reasons it was recommended were based on the empty root giving you more security but it doesn't offer more security. There has been extensive coverage of this on the list as well and I think a recent post by joe touched on it again.
PhilOn 10/12/05, Noah Eiger <[EMAIL PROTECTED] > wrote:Thanks again. Yep, I figured the guide was aimed at larger groups. I just wanted to check out the "Caddilac" version and see what parts applied to us, if any. Frankly one of the other things that made me sort of doubt the single-domain model was the number of posts on this list that say something like: "I have four domains and an empty root...."Thanks again. I will KISS.-- nme
From: Arthur Freyman [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 12, 2005 1:49 PM
To: [email protected]
Subject: RE: [ActiveDir] Design Question
You're absolutely right. Although there is a fairly compelling argument which states that it is best security practice to turn off cached logons. Additionally, it somewhat limits the value of the ability to logon to the workstation, if the user cannot perform their normal business functions, depending of what those may be. Of course its better then nothing..
Arthur Freyman
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Thommes, Michael M.
Sent: Wednesday, October 12, 2005 1:21 PM
To: [email protected]
Subject: RE: [ActiveDir] Design Question
Unless specifically turned off, your "disconnected" branch office user should still be able to logon using cached credentials. Of course, other network resources may not be available.
Mike Thommes
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Arthur Freyman
Sent: Wednesday, October 12, 2005 2:58 PM
To: [email protected]
Subject: RE: [ActiveDir] Design Question
I've had to grapple with this issue a number of times when I designed AD implementations. It is basically an argument of a centralized vs distributed model. There are obvious pros and cons to each approach, but ultimately it comes down to reliability and speed of links to your branch offices. You could improve your management and security by not having DCs in the branch offices, but you have to realize that if the link is down, your branch office people won't be able to login. This could be particularly a significant factor if you implemented single sign on and you depend on AD for access to other applications. You should perhaps look at statistics of downtime for your WAN links and see if you can put up with branch offices being down for that period of time.
Arthur Freyman
From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of [EMAIL PROTECTED]
Sent: Wednesday, October 12, 2005 12:41 PM
To: [email protected]
Subject: Re: [ActiveDir] Design Question
That's a good question on the number of domains in the Branch Office Guide -- it seems to be overkill unless they all have separate and independent IT departments or if there a requirement for a separate password policy or something else bizzarre. I suppose you could deploy a DC to each branch, and especially if you have a slow, unreliable WAN link such as a fractional T-1 to each location and with 10 branches you should be OK using 10 extra DCs.
Regards,
Chuck Gafford
Systems Architect
Unisys
Imagine It. Done.
-----Original Message-----
From: Noah Eiger < [EMAIL PROTECTED]>
To: [email protected]
Sent: Wed, 12 Oct 2005 11:49:43 -0700
Subject: RE: [ActiveDir] Design QuestionThanks, all. Good to see confirmation of the few-domains-as-possible concept.
Yes, I was planning to deploy a DC to each branch. Some are not as physically secure as I would like, though I realize that security is somewhat a function both of access and intent. I don't see a lot of latter -- but maybe that is what we all thought on September 10. Does that change the model?
-- nme
P.S. Why does MS still recommend so many domains in the Branch Office Guide? Is it for replication load?
From: Al Mulnick [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 12, 2005 11:27 AM
To: [email protected]
Subject: RE: [ActiveDir] Design QuestionThe same reasons apply to this situation as those of a much larger organization: deploy multiple domains if you need x, y, and z functionality. Otherwise try to keep it to fewer domains.
Are there are any compelling reasons to deploy multiple domains? Are you going to deploy a DC to each branch office?
-----Original Message-----
From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Noah Eiger
Sent: Wednesday, October 12, 2005 1:47 PM
To: [email protected]
Subject: [ActiveDir] Design QuestionHi -
I am designing a new domain structure what will have a HQ and then roughly 10 branch offices, less than 200 users total. The Microsoft Branch Office Deployment guide shows a single forest with three domains: root, hq, and branches (and oodles of domain controllers). Allen, Minasi, etc etc etc all say to try to limit yourself to a single domain if possible.
My inclination is to go with the latter (single domain) model. With this size organization is there a need for multiple domains? An empty root?
Thanks.
-- nme
