[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ldap
Subject:    [ldap] Re: LDAP UserID's
From:       Quanah Gibson-Mount <quanah () stanford ! edu>
Date:       2005-10-04 17:57:07
Message-ID: 5D4108ED75746B4F71B06ED3 () [10 ! 0 ! 0 ! 1]
[Download RAW message or body]



--On Tuesday, October 04, 2005 9:27 AM -0400 Lisa Boike 
<LBoike@message.nmc.edu> wrote:

> 
> In implementing LDAP we are changing the userid from a 9 digit number
> beginning with an * to a userid using the last name and first initial of
> the user.  This would be how students and employees login to all of the
> systems on campus (with a password), it would be their email address, and
> it would be the ID they use to identify themselves to records and
> registration etc. We are getting a great deal of negative feedback from
> college employees that think this less secure, a violation of FERPA and
> don't want to change.
> 
> I am wondering if any of you went through a change like this when
> implementing your LDAP.  If so, how did your userid's change and why did
> you decide to change them?

As the directory master for Stanford, which does have a fairly sizeable 
student population, I'll give you my 2c...


1) Using last names + first names is a bad idea.  People get married, 
people get divorced, and people have legal name changes.

2) Using last names + first names is a bad idea.  There are people in this 
world who don't have a "first" or "last" name.  They have a single name 
(yes, we have them @ Stanford).

3) Using last names + first names is a bad idea, and may very well be a 
violation of FERPA.  FERPA clearly defines that students have the ability 
to hide their name from everyone, and we have had a few cases where we've 
had to do that.  Not to mention people like Chelsea Clinton, whose 
electronic identity was hidden her entire time @ Stanford.  We are 
currently undergoing a process to entirely hide people's legal names unless 
the person specifically puts it in a different field as releasable.  In 
addition to helping us work around FERPA, this also helps prevent DATA 
MINERS who frequently target Stanford from getting data they can use for 
identity theft, spam, etc.

4) "People" information and "Account" information are two entirely 
separable and different things.  You may wish to reference:

<http://www.stanford.edu/services/directory/trees/accounts.html>
<http://www.stanford.edu/services/directory/trees/people.html>


So, what does Stanford do?

We allow people to select their own uid's (user ids used for logins to 
unix/windows systems, and web based authentication).  We require that your 
uid be deliverable as an address at Stanford at all times, *but* you do not 
have to list it.  We allow you to pick up to three self-selected delivery 
addresses for email that are based on anything plus a name token from your 
last name.  Like I could have "q.gibson", "q.gibson-mount", "asdf.mount", 
etc.  In the cases of FERPA people, we manually inject another alias for 
them to use as their email delivery address.

Also note that we have any number of other identifiers besides UID's for 
individuals.  Such as:

Their card number
Their Stanford University ID Number
A randomly generated very long hex number (for using as the DN of the 
people container, so that when LDAP returns the user's DN in the people 
tree, their uid, etc isn't exposed)
Their emailable ID's


And on top of that, a large number of attributes that track the visibility 
of those attributes, which means we can tightly control what attributes are 
published to anonymous (world readable) and Stanford-only, in addition to 
the private (unpublished) level.


--Quanah

--
Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

---
You are currently subscribed to ldap@umich.edu as: [ldap@progressive-comp.com]
To unsubscribe send email to ldap-request@umich.edu with the word UNSUBSCRIBE as the \
SUBJECT of the message.


[prev in list] [next in list] [prev in thread] [next in thread]