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?
Although we use Samba (so take my comments with a bucket of NaCl), we have something like this. Our biggest headache is the inability to set domain policies specific for staff or students. Everybody is in the same domain so they all get the same policies. I don't know you you can set domain policies based on group membership in a real AD domain. > 2. ad.nsd.org with child domains sta.ad.nsd.org and stu.ad.nsd.org > This will separate out the staff and students to resolve the concerns of > option #1. We put the shared resources in the top level ad.nsd.org domain. > We just do not like the length of the path (e.g. sta.ad.nsd.org). What's wrong with length? "s.a.nsd.org" or "f.a.nsd.org"; when length is a concern you loose a lot of clarity in your names. > 3. nsd top level domain with child domains sta.nsd and stu.nsd > We like the idea of a short path, but are concerned with how this would > affect DNS as now the AD domains are not subdomains of the main DNS server. > Anyone try something like this? As I understand it, MS Windows domains want to be able to update the domain data themselves; add in the additional separation of responsibilities an you even have a more-secure/better setup this way. Maybe. -- Perfection is just a word I use occasionally with mustard. --Atom Powers-- _______________________________________________ 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/
