Using existing attribute vs creating new one for student ID number

[Ned]

I am in the planning stages of creating 1500 user accounts for
highschool students.
I have decided to creat a child domain for the students so that both
staff and students can use the same workstations to access either
domain, also for different password policies. Since some students share
the same first and last names I was thinking of creating a student ID
field so account operators can differentiate between student accounts.
I can use an unused field in the user account general properties like
phone number or web page or I can add my own. The second option would
require that changes to the schema be made in the parent domain (child
domain schema editing options were greyed out) and require additional
work. I am thinking of just using an existing attribute. Has anyone
been through this? What did/would you do?

thanks
NH

 

[Ryan Hanisco]

Ned,

I did this very thing back in 2001 when I was managing the technology
for Lansing Public Schools (Lansing, MI) for 16,000+ students. At the
time, the schema extension was the only real option and it worked well.
I was able to store StudentID, Building, and Grade information in the
directory and I set up nightly batch processes that synched this to the
AS/400 to handle moves and adds.

If you are planning to extend the schema, I would suggest that you
consider this very carefully and inherit the user class and make your
extensions there. This way you can test the whole thing without putting
your production environment in jeopardy. The management consoles work
the same for inherited objects, but you will want to be careful on any
tools that specifically interact with the user class.

Generally, though, there isn't a lot that you can't manage through the
proper use of Domains, OUs and groups. The ADSI hooks I needed to keep
accounts in synch with the AS/400 accounts required the extension so I
could store the account primary keys in the directory. If you are just
looking for a better way to manage your directory, split your domains as
you have suggested and keep your students in OUs.

Also, to protect yourself, you will want to redirect newly created
accounts to an OU that has no logon permissions anywhere. Remember that
in a school district, it is you against kids who have creativity, access
to knowledge, and a ton of free time. You can't be too careful.

Ryan Hanisco
FlagShip Integration Services

 

[Ned]

Hello Ryan

Thanks for the detailed response. I'm still trying to figure this all
out with a fast approaching deadline of 1/24/07. I've already
configured a mirror of my envirnment in vmware and I am testing it out
there. I thought the tip about using an OU with no logon permissions
was great. It looks as though I have a lot to learn.


Thanks again, it's good to hear from someone who has done this already
and with many more students.

 

[Richard Mueller]

Also, user objects have the attribute employeeID that you can use. This
attribute is not used by anything I know of, and the value is not displayed
in ADUC, but you are free to assign any string you want to it. There are
other attributes available as well. For a spreadsheet listing all attributes
available for user objects in W2k AD, see the second spreadsheet in this
link:

http://www.rlmueller.net/UserAttributes.htm

The attributes that correspond to fields in ADUC are documented in the first
spreadsheet. Also, remember that the values assigned to cn must be unique in
the container/OU. The values assigned to sAMAccountName must be unique in
the domain. If you have students with duplicate first and last names, you
will need a naming standard that handles this.

In school environments I have found it useful to create groups based on
graduating years, rather than grade. This minimizes the start of year setup
required to manage group membership. You could also have one OU for each
graduating year. This could allow different policies for kindergarten vs
older students.

 

[Joe Richards [MVP]]

I would recommend creating an auxiliary class and dynamically assigning
that to students myself. I would also look carefully at adding a second
domain. Unless you have really good reasons to do it (say like a
different password policy) you probably want to avoid it as it can add
considerably more complexity for some apps.

Go to the library and start reading the book in my signature, there is a
couple of chapters on schema extensions. Oh yeah, I would add attributes
versus trying to repurpose base attributes.

--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm