School Design for AD

[phil2627]

We are in a schol district that is going to AD. We are undecided on
which way to go with our domain model. We have 2 schools with a total
of 4000 students. The schools are connected with a 45 MB line. We
thought about using the "Empty root domain" with child domains - 1 for
students and the other for non students. We realize the following:

For Empty Root Domain
--------------------------
Isolation of Built In Admin accounts
Different password policy for Admin accounts

Against Empty Root Domain
------------------------------
More hardware needed
hacker gets child domain password they can access root domain
eventually

We would like security of not having our students access (or have a
difficult time doing) resources in the non-student domain. We have
looked at the single domain with OUs and multiple domain models, but
would like some input as to why we should do one over the other.
Thanks.

 

[Herb Martin]

We are in a schol district that is going to AD. We are undecided on
which way to go with our domain model. We have 2 schools with a total
of 4000 students. The schools are connected with a 45 MB line. We
thought about using the "Empty root domain" with child domains - 1 for
students and the other for non students. We realize the following:

For Empty Root Domain

Against Empty Root Domain

Yes, the (automatic) empty root domain model was a temporary recommendation
by people who had not really thought through the actual security rules
of domains within a forest.

Most single organizations should have ONE domain.

If security is truly important, e.g., financials or privacy laws for your
students,
then perhaps TWO Forests are best with NO sharing of resources between
the two domains/forests.

 

[phil2627]

Yes, the (automatic) empty root domain model was a temporary recommendation
by people who had not really thought through the actual security rules
of domains within a forest.

Most single organizations should have ONE domain.

If security is truly important, e.g., financials or privacy laws for your
students,
then perhaps TWO Forests are best with NO sharing of resources between
the two domains/forests.




- Show quoted text -

Thanks for the quick reply. We are just worried about:

- locking down the admin accounts
- students being able to browse DCs (guessing we can "deny" the
student OU on "admin" DCs)
- have students login to student computers only (we'd also like to
prevent the "log on to" box on the login screen)
- different password policies for students vs staff (more strict for
staff)

 

[Herb Martin]

Thanks for the quick reply. We are just worried about:

- locking down the admin accounts

What does this mean (to you) precisely? You are always going to
have SOME admin account in every domain and these will be subject
to the same attacks no matter where they are located IF the network
is accessible.

- students being able to browse DCs (guessing we can "deny" the
student OU on "admin" DCs)

"Browse" means to see in Network Neighborhood and can be turned
off even though it offers very low security exposure (merely know the
share points or servers are there.)

ACCESS to those resources is controlled by PERMISSIONS.

You control permission by GROUPS not OUs though.

- have students login to student computers only (we'd also like to

Generally you WANT them to logon to the domain when they logon
to the computers -- you get easier CONTROL of them this way.

prevent the "log on to" box on the login screen)

You cannot but there are only limited choices for a machine:

1) The machine
2) The Domain of the machine
3) The Domains trusted by the machines domain

And since every domain in a forest effectively trusts every other domain
in that forest this means that multiple domains don't provide full security
boundaries -- if they are in the same forest.

- different password policies for students vs staff (more strict for
staff)

You cannot do this with the built in features in a single DOMAIN.

Password polices are PER domain for domain accounts.

My advice is to make the password policies strict for everyone and
just teach students to deal with it. They will likely have less trouble
than the teachers who must be TRAINED to use good password
security -- if you make passwords strong and don't train them they
will just write them on the side of the monitor or some such place.

 

[Richard Mueller [MVP]]

I concur with the advice so far. In my experience, having more than one
domain adds complications. You need good reasons to have more than one.

I have supported several schools and the poster brings up excellent points.
The requirements for kindergarten students learning keyboarding skills is
different from 8th graders and teachers. However, I think Microsoft is
starting to realize this. One option is "Shared Computer Toolkit for Windows
XP". Info linked here:

http://www.microsoft.com/windowsxp/sharedaccess/overview.mspx

Password policies are one concern. I have found that even pre-schoolers can
easily logon with simple username/password combinations. I know this makes
it difficult to enforce more secure passwords elsewhere, but I would advise
against creating more domains simply to enforce stricter password policies.
You can makes passwords not expire for some users, and even passwords not
required (if necessary). These settings won't affect the other users.

 

[Kurt]

I concur with the advice so far. In my experience, having more than one
domain adds complications. You need good reasons to have more than one.

I have supported several schools and the poster brings up excellent points.
The requirements for kindergarten students learning keyboarding skills is
different from 8th graders and teachers. However, I think Microsoft is
starting to realize this. One option is "Shared Computer Toolkit for Windows
XP". Info linked here:

http://www.microsoft.com/windowsxp/sharedaccess/overview.mspx

Password policies are one concern. I have found that even pre-schoolers can
easily logon with simple username/password combinations. I know this makes
it difficult to enforce more secure passwords elsewhere, but I would advise
against creating more domains simply to enforce stricter password policies.
You can makes passwords not expire for some users, and even passwords not
required (if necessary). These settings won't affect the other users.

Just to throw in my 2 cents:

Having a "Student" domain and an "Admin-Staff" domain in separate
forests does add additional administrative overhead. But it also allows
for complete separation, including policies at ANY level. Creating a
one-way trust with the student domain as trusting and and admin domain
as trusted will make sure admins can get where they need to on the
student domain, and also keep students out of admin. Even with a 2-way
trust, as long as you create a strong security group model and don't
duplicate accounts in both domains, you can quite easily keep up a wall.
A 45M Link (T3?) is likely to be plenty of bandwidth for replication
(with a DC for each domain at each site) without having to configure
much in the way of bandwidth conservation. I agree that in most cases a
single domain is best for lots of reasons, cost and time to
setup/maintain are definitely at the top. A School situation where there
is a clear-cut line between the two tiers of users, and a known,
constant threat by one of them, is one place where separate domains may
make sense. If you decide to go this route, you'll want to plan
everything out in detail before you commit anything to stone.

Kurt

 

[Richard Mueller [MVP]]

Just to throw in my 2 cents:

Having a "Student" domain and an "Admin-Staff" domain in separate forests
does add additional administrative overhead. But it also allows for
complete separation, including policies at ANY level. Creating a one-way
trust with the student domain as trusting and and admin domain as trusted
will make sure admins can get where they need to on the student domain,
and also keep students out of admin. Even with a 2-way trust, as long as
you create a strong security group model and don't duplicate accounts in
both domains, you can quite easily keep up a wall. A 45M Link (T3?) is
likely to be plenty of bandwidth for replication (with a DC for each
domain at each site) without having to configure much in the way of
bandwidth conservation. I agree that in most cases a single domain is best
for lots of reasons, cost and time to setup/maintain are definitely at the
top. A School situation where there is a clear-cut line between the two
tiers of users, and a known, constant threat by one of them, is one place
where separate domains may make sense. If you decide to go this route,
you'll want to plan everything out in detail before you commit anything to
stone.

Kurt

Ulf B. Simon-Weidner recently got permission to discuss some new password
policy features expected in Longhorn. See these links:

http://msmvps.com/blogs/ulfbsimonwe...longhorn-quot-granular-password-settings.aspx

http://blog.joeware.net/2007/03/18/828/

In the future, instead of applying password policies only for the entire
domain, you will be able to apply them to groups and even users. If you can
wait until Longhorn is in production, this might influence your planning.

 

[Richard Mueller [MVP]]

Just to throw in my 2 cents:

Having a "Student" domain and an "Admin-Staff" domain in separate forests
does add additional administrative overhead. But it also allows for
complete separation, including policies at ANY level. Creating a one-way
trust with the student domain as trusting and and admin domain as trusted
will make sure admins can get where they need to on the student domain,
and also keep students out of admin. Even with a 2-way trust, as long as
you create a strong security group model and don't duplicate accounts in
both domains, you can quite easily keep up a wall. A 45M Link (T3?) is
likely to be plenty of bandwidth for replication (with a DC for each
domain at each site) without having to configure much in the way of
bandwidth conservation. I agree that in most cases a single domain is best
for lots of reasons, cost and time to setup/maintain are definitely at the
top. A School situation where there is a clear-cut line between the two
tiers of users, and a known, constant threat by one of them, is one place
where separate domains may make sense. If you decide to go this route,
you'll want to plan everything out in detail before you commit anything to
stone.

Kurt

Ulf B. Simon-Weidner recently got permission to discuss some new password
policy features expected in Longhorn. See this link:

http://msmvps.com/blogs/ulfbsimonwe...longhorn-quot-granular-password-settings.aspx

In the future, instead of applying password policies only for the entire
domain, you will be able to apply them to groups and even users. If you can
wait until Longhorn is in production, this might influence your planning.

 

[Richard Mueller [MVP]]

Just to throw in my 2 cents:

Having a "Student" domain and an "Admin-Staff" domain in separate forests
does add additional administrative overhead. But it also allows for
complete separation, including policies at ANY level. Creating a one-way
trust with the student domain as trusting and and admin domain as trusted
will make sure admins can get where they need to on the student domain,
and also keep students out of admin. Even with a 2-way trust, as long as
you create a strong security group model and don't duplicate accounts in
both domains, you can quite easily keep up a wall. A 45M Link (T3?) is
likely to be plenty of bandwidth for replication (with a DC for each
domain at each site) without having to configure much in the way of
bandwidth conservation. I agree that in most cases a single domain is best
for lots of reasons, cost and time to setup/maintain are definitely at the
top. A School situation where there is a clear-cut line between the two
tiers of users, and a known, constant threat by one of them, is one place
where separate domains may make sense. If you decide to go this route,
you'll want to plan everything out in detail before you commit anything to
stone.

Kurt

Ulf B. Simon-Weidner recently got permission to discuss some new password
policy features expected in Longhorn. See this link:

http://msmvps.com/blogs/ulfbsimonwe...longhorn-quot-granular-password-settings.aspx

In the future, instead of applying password policies only for the entire
domain, you will be able to apply them to groups and even users. If you can
wait until Longhorn is in production, this might influence your planning.

 

[Richard Mueller [MVP]]

Just to throw in my 2 cents:

Having a "Student" domain and an "Admin-Staff" domain in separate forests
does add additional administrative overhead. But it also allows for
complete separation, including policies at ANY level. Creating a one-way
trust with the student domain as trusting and and admin domain as trusted
will make sure admins can get where they need to on the student domain,
and also keep students out of admin. Even with a 2-way trust, as long as
you create a strong security group model and don't duplicate accounts in
both domains, you can quite easily keep up a wall. A 45M Link (T3?) is
likely to be plenty of bandwidth for replication (with a DC for each
domain at each site) without having to configure much in the way of
bandwidth conservation. I agree that in most cases a single domain is best
for lots of reasons, cost and time to setup/maintain are definitely at the
top. A School situation where there is a clear-cut line between the two
tiers of users, and a known, constant threat by one of them, is one place
where separate domains may make sense. If you decide to go this route,
you'll want to plan everything out in detail before you commit anything to
stone.

Kurt

Ulf B. Simon-Weidner recently got permission to discuss some new password
policy features expected in Longhorn. See this link:

http://msmvps.com/blogs/ulfbsimonwe...longhorn-quot-granular-password-settings.aspx

In the future, instead of applying password policies only for the entire
domain, you will be able to apply them to groups and even users. If you can
wait until Longhorn is in production, this might influence your planning.

 

[Trust No One®]

Yes, the (automatic) empty root domain model was a temporary
recommendation
by people who had not really thought through the actual security rules
of domains within a forest.

Didn't a certain very large company we are all familiar with initially
start out with this model Herb?

 

[Herb Martin]

Didn't a certain very large company we are all familiar with initially
start out with this model Herb?

Not to my knowledge, but I had this argument with some of the
relatively less experienced consultants of one such company
and feld my position was stronger then; eventually they moved
to my (default) position which confirmed that assessment <GRIN>

Vague enough for you?

Seriously, sometimes the case can be made -- I in fact make that
case on occasion. As a default it is just foolishness.

 

[Brandon McCombs]

Thanks for the quick reply. We are just worried about:

- locking down the admin accounts
- students being able to browse DCs (guessing we can "deny" the
student OU on "admin" DCs)
- have students login to student computers only (we'd also like to
prevent the "log on to" box on the login screen)
- different password policies for students vs staff (more strict for
staff)

Why do you want to lock down admin accounts? You need at least 1 admin
account in order to, well, administrate, the non-admin accounts. If you
don't need more than that (each admin should have their own admin
account for accountability and tracking) then don't create them.

FYI, there are other LDAP implementations that allow password policy at
the user level so each user is able to have their own. Unfortunately ADS
does not allow this.

ADS does however allow you to prevent students from logging into
machines they shouldn't log into. As long as the machines you don't want
them to log into would be within the same OU anyway in your tree
structure, you can set security permissions in a Group Policy to only
allow admins to log onto those machines. There is no reason to prevent
the Log On To combo box on the login screen because if they don't have a
local account on the machine they can't log on to it anyway and you want
them to have a domain account because that enforces your domain policies
and security model for everyone who authenticates to it.

 

[phil2627]

First, thanks to everyone who responded.

Currently our password policy for staff is a minimum 10 character
password and students passwords are pulled from a field in the student
information program. Their password is set to be anywhere from 3 to 8
characters, but is easy for the student's to remember. The password
does not change, unlike the administrative passwords that change every
40 days.

I obviously misphrased "lock down" admin account. I just meant that
the enterprise admin accounts would be in another domain if they were
isolated in another domain. As I stated before we realize with a
little work a user could guess the domain admin password and
eventually work their way to the enterprise admin account, but the
isolation of the enterprise admin group (which holds the administrator
account) with give us a little bit more security.

We have figured out a way to not allow users (students in this case)
to log on to non student workstations by group policy, but thought not
having the "log on to" boxon the login screen would help.

We are coming from the world of Netware where we have different
password policies and, by server, we can prevent students from
accessing admin servers by subnet. Students are on their own vlan and
we can have the admin servers deny traffic coming from those
locations. We can also set the login context. We realize security
procedures are different with Windows and know how to do basic
security to some degree, but want to make sure our security is as
tight as can be from the implementation of AD. As also stated before,
we have 4000 students, 500 of which think they are reprising the role
of Mathew Broderick in War Games everyday. Again, thanks for the
replies and welcome more input.

 

[Brandon McCombs]

First, thanks to everyone who responded.

Currently our password policy for staff is a minimum 10 character
password and students passwords are pulled from a field in the student
information program. Their password is set to be anywhere from 3 to 8
characters, but is easy for the student's to remember. The password
does not change, unlike the administrative passwords that change every
40 days.

If anything, I'd force passwords to be no older than 90 days for
students especially since their passwords can be as short as 3 characters.