I am a Windows administrator (among other roles) and I agree with what Chris states here.
The way AD works (now anyways, since Windows 2000 Server) is that you establish a domain rooted on a DNS namespace (such as the oft-used example in MSFT documentation, "contoso.com".) The first such domain created also serves as the root of a domain tree (in the DNS sense, like contoso.com -- east.contoso.com -- hq.east.contoso.com, etc.), and also of a "forest" which is a collection of multiple domain trees. (Of course, you can have a forest with only one "tree" consisting of only one domain.) So the "forest" is actually the main security boundary; all domains within the forest have an automatic two-way transitive trust relationship. The individual domains within the forest define a replication boundary; all domain controllers in a given domain replicate their objects between themselves so that each is a full "master" in a DNS sense (excepting for 5 roles named "FSMO" [Flexible Single Master of Operations] for cases where you need one and only one DC to be a role holder.) Within a new domain, there is a default "folder" structure (actually, "Containers" and "OU"s - Containers can't have Group Policy applied to them, whereas OUs can) that have certain default objects contained within them. You can then go on to create your own OUs depending on your need for policy application and structure, and create/modify/delete objects within them. OU's are the main way of enforcing security policy *within* a domain. So you can create an OU (or nested OUs) for students, for example, and have policy applied to the topmost student OU that will be inherited by all of the child OUs (if any.) Policy can be per-computer (applied to Computer objects within the OU) or per-user (applied to User objects within the OU.) As you can imagine, it's a pretty deep subject, and Microsoft keeps adding to it as each version of Windows Server comes out. A good book on the subject which I find very helpful is: Title: Active Directory, Fourth Edition By: Brian Desmond, Joe Richards, Robbie Allen, Alistair G. Lowe-Norris Publisher: O'Reilly Media Formats: Print, Ebook, Safari Books Online Print: November 2008 Ebook: November 2008 Pages: 864 Print ISBN: 978-0-596-52059-5 | ISBN 10: 0-596-52059-X HTH, Will -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Chris Francy Sent: Tuesday, July 19, 2011 3:56 PM To: Ski Kacoroski Cc: [email protected] Subject: Re: [lopsa-tech] Questions on AD domains and Bind DNS On Mon, Jul 18, 2011 at 3:09 PM, Ski Kacoroski <[email protected]> wrote: > 1. ad.nsd.org > Single top level domain for staff and students. We are concerned > because this will allow students to log into staff computers and see > resources in the entire domain. If you have a setup like this, have > you seen problems with students getting into machines/resources they should > not? My $0.02 is that you should avoid creating additional domains as much as possible. It sounds like you want a multi-domain setup mostly for security, and I personally don't think that you get a big enough security gain in a multi-domain setup to offset the additional administrative costs in a K-12 environment. Controlling who has access to what in a single domain is relatively easy with policies and setting appropriate permissions. Yes, if a tech is careless, they can leave something more open, and a student could access it, but that can happen even in a multiple domain setup. Also consider, that while it may break policy, it is likely students have access to the teachers station anyway, no matter how you setup your domains. In my experience it is very difficult to get teachers to be really concerned about security. Teachers often share their credentials with their student TA, and the technically inclined students who help them fix problems that cannot be handled by the typically understaffed K12 IT departments. I am going to guess that you will have a maximum of about 22,000 accounts and somewhere between 2000-2500 computers since Northshore has ~20,000 students. This should be able to be handled easily by a single domain. With a single domain you have less work to duplicate by creating policies in multiple locations. You have less domain controllers to maintain. You will have to put it some more effort into making sure you setup the policies and permissions correctly. Even Microsoft doesn't seem to say that a separate domain creates a security boundary. ] http://technet.microsoft.com/en-us/library/cc756901(WS.10).aspx ] By contrast a domain is not a security boundary because within a forest ] it is not possible for administrators from one domain to prevent a malicious ] administrator from another domain from accessing data in their domain. On Tue, Jul 19, 2011 at 9:29 AM, Dennis <[email protected]> wrote: > I'm not super familiar with the school district, but looking at their > site they would seem to have tens of thousands of ldap objects so it > may be beneficial to segregate these out into separate domains. For K-12 schools, I don't think this really does much. Since 90-95% of the accounts will usually be student accounts, and the rest will be staff. Even If there is slow browsing because of the large number of objects it isn't likely to be improved on the student side by breaking out the small percentage of staff accounts into a separate domain. Chris Francy _______________________________________________ Tech mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/ _______________________________________________ Tech mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
