The point which I believe you're missing, is that of managability of servers within that domain generally means that the group of people managing servers in that domain requires domain level admin right, which obviates the security benefits of the empty root.
The concept behind the empty root is to provide a container for the schema and forest structure - nothing else. By putting anything other than what is required to meet those needs, its no longer an empty root. ------------------------------------------------------ Roger D. Seielstad - MCSE Sr. Systems Administrator Inovis - Formerly Harbinger and Extricity Atlanta, GA > -----Original Message----- > From: Salandra, Justin A. [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, December 11, 2002 12:46 PM > To: '[EMAIL PROTECTED]' > Subject: RE: [ActiveDir] Back to Basics - Design Pros and Cons > > > Not really. You can have a exchange server in a empty root > that only has > accounts on it from child domains. Meaning that all users > account are in > the child domains, so you still only have the Administrator > group in the > forest root. Plus if you create one more account as the > account you use to > do all your admin work and have all services run as in the > forest root then > you only have two accounts, Administrator and the new account. > > A empty root only means that there are no users maintained in > that domain > context. You can have servers in the forest root such as Application > servers or File servers and even Exchange Servers without > running the risk > of having your AD Security compromised. You specifically > grant child domain > user account access to folders or mailboxes. You are not > granting them, nor > would you, access to the AD Contexts or to any administrative > functions in > the root. > > Justin A. Salandra, MCSE > Senior Network Engineer > Catholic Healthcare System > 914.681.8117 office > 646.483.3325 cell > [EMAIL PROTECTED] > > -----Original Message----- > From: Roger Seielstad [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, December 11, 2002 12:44 PM > To: '[EMAIL PROTECTED]' > Subject: RE: [ActiveDir] Back to Basics - Design Pros and Cons > > No it doesn't. Its empty for security reasons, not for > anything else. By > putting any services within the domain, it voids the > protections offered by > the empty root - specifically preventing changes to the > Enterprise Admins > and Schema Admins groups. > > In the last 2 empty root deployment's in which I've been > involved, there > have been a grand total of 5 accounts with ANY access to the > empty root > domains. In fact, the model was that the admin account in the > empty root is > different from the admin account, for the same individual, in > the production > domain. > > Putting non-DC servers in that domain means granting some > level of rights to > accounts in that domain, which threatens the controls over the above > mentioned groups. > > ------------------------------------------------------ > Roger D. Seielstad - MCSE > Sr. Systems Administrator > Inovis - Formerly Harbinger and Extricity > Atlanta, GA > > > > -----Original Message----- > > From: Salandra, Justin A. [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, December 11, 2002 12:36 PM > > To: '[EMAIL PROTECTED]' > > Subject: RE: [ActiveDir] Back to Basics - Design Pros and Cons > > > > > > True, but logically it makes sense to atleast have servers > > there that are > > common. > > > > -----Original Message----- > > From: Roger Seielstad [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, December 11, 2002 12:29 PM > > To: '[EMAIL PROTECTED]' > > Subject: RE: [ActiveDir] Back to Basics - Design Pros and Cons > > > > Actually - the empty root should be just that - empty. The > > transitive trust > > model handles the rest. > > > > ------------------------------------------------------ > > Roger D. Seielstad - MCSE > > Sr. Systems Administrator > > Inovis - Formerly Harbinger and Extricity > > Atlanta, GA > > > > > > > -----Original Message----- > > > From: Salandra, Justin A. [mailto:[EMAIL PROTECTED]] > > > Sent: Wednesday, December 11, 2002 9:24 AM > > > To: '[EMAIL PROTECTED]' > > > Subject: RE: [ActiveDir] Back to Basics - Design Pros and Cons > > > > > > > > > I also agree with those people here that say to have a 3 > > > domain model in a > > > single forest. By creating an empty root and having two > > > child domains, you > > > can ensure security and separation from faculty and students > > > as well has > > > have a very detailed OU Structure in your students domains > > > based on year or > > > majors and your faculty can have an OU structure of department. > > > > > > For the empty root, I would put in the root those services > > > and servers that > > > both students and faculty members need, such as a e-mail > > > server and web > > > server. File servers and application servers I would put > > in the child > > > domains that are relative to each domains. (ie FACULTYFP01 > > > and FACULTYAPP01 > > > in the Faculty domains and STUDENTFP01 and STUDENTAPP01 in > > the student > > > domain. > > > > > > Just the path I would head down. > > > > > > Justin A. Salandra, MCSE > > > Senior Network Engineer > > > Catholic Healthcare System > > > 914.681.8117 office > > > 646.483.3325 cell > > > [EMAIL PROTECTED] > > > > > > > > > -----Original Message----- > > > From: Craig Cerino [mailto:[EMAIL PROTECTED]] > > > Sent: Wednesday, December 11, 2002 9:10 AM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [ActiveDir] Back to Basics - Design Pros and Cons > > > > > > Max, > > > > > > While I think there are a LOT of issues that should be addressed > > > (probably too many for you top get enough quality feedback > > through an > > > email forum) there are a few basic things I would recommend > > > considering. > > > > > > 1. Who needs to do what or get where (appliance wise) > > > 2. What needs to be accessible to these people (as a whole) > > > 3. Who needs to be able to access what? > > > > > > Again, these are just "tip of the Iceberg things" but that is > > > where I'd > > > start. I'm guessing by what you said and the mere fact > that it is a > > > multi campus university, that you have a healthy reliable > > backbone in > > > place already. > > > > > > While multiple FORRESTS are doable (some people may even > > lead you down > > > that path - your decision) I always consider them to have > a TON over > > > administrative and maintenance related overhead. (Not > sure how large > > > your team is that will support this architecture) > > > > > > If it were me (because I never tell someone "THIS IS WHAT > YOU SHOULD > > > DO") I would forget about the domain for each campus etc. I > > > would stick > > > with two domains FACULTY and STUDENTS (naming convention to > > be decided > > > later) and move on from there. > > > > > > Just my 2 cents Max. > > > > > > Good luck with this project - sounds exciting to me. > > > > > > Craig > > > > > > > > > Craig P. Cerino > > > MCSE, MCP+I > > > Systems Administrator > > > TIE SOLUTIONS, Inc > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Wohlgehagen, Max W > > > > [mailto:[EMAIL PROTECTED]] > > > > Sent: Tuesday, December 10, 2002 8:20 PM > > > > To: '[EMAIL PROTECTED]' > > > > Subject: [ActiveDir] Back to Basics - Design Pros and Cons > > > > > > > > > > > > There is so much material out there on AD now it is almost > > > > scary [in many ways it is not too dissimilar to NDS 'cepting > > > > the DNS component] My problem is design for a new network, > > > > being in a school we have the luxury of starting from scratch > > > > without business fallout problems. We are multi-campus and > > > > have a fairly substantial network with an 11MB "Spread > > > > Spectrum" Microwave link between campuses. I am a big fan of > > > > the KISS principle but am stuck in deciding between multiple > > > > trees or a single tree with many sites, both concepts have > > > > advantages. We do not need to implement a Forrest structure > > > > as our DNS is set in concrete. We have the following > > > > elements: Campus1, Campus2, Students1, Students2, Staff1, > > > > Staff2 ... or OrganisationAll, StaffAll, StudentsAll. > > > > Obviously there are sub components of these elements as well. > > > > The main concern is to have the most useful GPO structure > > > > without too much complexity. Does anyone have any experience > > > > in setting up this type of AD. Any ideas on multiple domains > > > > versus single domain many sites?? Help, opinions, comments, > > > > ideas all welcome. Thanks. > > > > > > > > Max Wohlgehagen > > > > TSI - Rowville > > > > "Of all the things I've lost, it's my mind I miss the most." > > > > <<Wohlgehagen, Max (E-mail).vcf>> > > > > > > > > > > > > > > > > ************************************************************** > > > > ***************** > > > > Important - This email and any attachments may be > > > > confidential. If received in error, please contact us and > > > > delete all copies. Before opening or using attachments check > > > > them for viruses and defects. Regardless of any loss, damage > > > > or consequence, whether caused by the negligence of the > > > > sender or not, resulting directly or indirectly from the use > > > > of any attached files our liability is limited to resupplying > > > > any affected attachments. Any representations or opinions > > > > expressed are those of the individual sender, and not > > > > necessarily those of the Department of Education & Training. > > > > > > > > > > > List info : http://www.activedir.org/mail_list.htm > > > List FAQ : http://www.activedir.org/list_faq.htm > > > List archive: > > > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > > List info : http://www.activedir.org/mail_list.htm > > > List FAQ : http://www.activedir.org/list_faq.htm > > > List archive: > > > http://www.mail-archive.com/activedir%> 40mail.activedir.org/ > > > > > > List info : > > > http://www.activedir.org/mail_list.htm > > > List FAQ : http://www.activedir.org/list_faq.htm > > > List archive: > > > http://www.mail-archive.com/activedir%> 40mail.activedir.org/ > > > > > List info : http://www.activedir.org/mail_list.htm > > List FAQ : http://www.activedir.org/list_faq.htm > > List archive: > > http://www.mail-archive.com/activedir%> 40mail.activedir.org/ > > > > List info : > > http://www.activedir.org/mail_list.htm > > List FAQ : http://www.activedir.org/list_faq.htm > > List archive: > > http://www.mail-archive.com/activedir%> 40mail.activedir.org/ > > > List info : http://www.activedir.org/mail_list.htm > List FAQ : http://www.activedir.org/list_faq.htm > List archive: > http://www.mail-archive.com/activedir%> 40mail.activedir.org/ > > List info : > http://www.activedir.org/mail_list.htm > List FAQ : http://www.activedir.org/list_faq.htm > List archive: > http://www.mail-archive.com/activedir%> 40mail.activedir.org/ > List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
