I would disagree with the point that you need to be Domain Admin in order to administer servers in a domain. This is not true - I would strongly recommend against granting Domain Admin to a server administrator in a domain solely for that purpose. The user only needs to be an Administrator of that server - this is not the same as, nor does it require, Domain Admin priviledge. This can be done with a gpo which adds a particular server admin group to the local admin group on the relevant server.
I would however still agree with the point that an empty root should be as empty as possible. As above, to keep rights at a minimum requires a significant admin overhead which could easily be overlooked compromising the security of the root domain. my 2p worth... ----- Original Message ----- From: "Roger Seielstad" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, December 11, 2002 6:23 PM Subject: RE: [ActiveDir] Back to Basics - Design Pros and Cons > 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/ > 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/
