Main Nav

We are formalizing procedures around use of our enterprise LDAP directory by applications around campus (whether our "partner" is in central IT or in some other department).  We'll be asking partners to sign the equivalent of an SLA with us, in which we lay out rules for appropriate use of the service.  

Here's our draft list of rules for our partners to be aware of and follow.  I wonder if folks think we're missing anything that might be regarded as a "best practice" (or including something that isn't a good idea!).  The theory is to lean toward the "pretty strict" side, btw, and let people ask for exceptions as needed.

Rules:

1) Partner may only use the LDAP Directory for the agreed-upon purposes specified in this agreement.


2) An LDAP account is assigned for use on a specifically designated system or set of systems under the Partner’s management. It may be not be used on additional systems without submission of an updated request.


3) Any information that is retrieved from the Directory is solely for use by the client application, and may not be passed along or otherwise made available by Partner to other systems.


4) A system using LDAP may not itself offer authentication or LDAP-based data services to other systems or applications; i.e. an LDAP client application may not perform proxy authentication for other systems.


5) Client applications using LDAP authentication must use it as the sole authentication source for their end-user community, and not in combination with other local or external authentication means.


6) LDAP clients must run on computer systems directly attached to NYU-NET, managed by NYU employees. By policy, the NYU Enterprise LDAP Directory is not visible to systems outside the NYU network for reasons of security.


7) Partners must make strenuous efforts to preserve the confidentiality of information obtained from the LDAP directory, especially of end-users' NetID/Password information. Client applications prompting end-users for their passwords must only accept those passwords over encrypted network links (typically over SSL). Passwords or password hashes may not be stored on clients beyond the lifetime of a login session on the client system. Whenever possible, a client that relies on LDAP authentication should prominently display a Sign Out option, and should enforce an idle session timeout as short in duration as is practical.


8) All LDAP operations for purposes of authentication must access ldaps://dir.nyu.edu (port 636), use a search base of ou=People,o=nyu.edu,o=nyu, and must only search for a single NetID at a time. The client application should maintain an open LDAP connection if it performs a steady stream of authentications, but should otherwise promptly and cleanly close its connection to the LDAP server.


.












Thanks in advance for any comments!


- Gary Chapman, NYU

 

.

Close
Close


Annual Conference
September 29–October 2
View Proceedings

Events for all Levels and Interests

Whether you're looking for a conference to attend face-to-face to connect with peers, or for an online event for team professional development, see what's upcoming.

Close

Digital Badges
Member recognition effort
Earn yours >

Career Center


Leadership and Management Programs

EDUCAUSE Institute
Project Management

 

 

Jump Start Your Career Growth

Explore EDUCAUSE professional development opportunities that match your career aspirations and desired level of time investment through our interactive online guide.

 

Close
EDUCAUSE organizes its efforts around three IT Focus Areas

 

 

Join These Programs If Your Focus Is

Close

Get on the Higher Ed IT Map

Employees of EDUCAUSE member institutions and organizations are invited to create individual profiles.
 

 

Close

2014 Strategic Priorities

  • Building the Profession
  • IT as a Game Changer
  • Foundations


Learn More >

Uncommon Thinking for the Common Good™

EDUCAUSE is the foremost community of higher education IT leaders and professionals.