Directory

Overview

Stanford's directory services are based around the LDAP (Lightweight Directory Access Protocol) open standards. IT Services runs two directory environments (OpenLDAP and Active Directory, a Microsoft product) to allow the widest variety of applications to leverage directory services. They include centralized identity, email, and authorization applications, as well as applications run by other organizations.

The OpenLDAP environment is a core element of the data flow from Stanford's identity management systems to various consuming applications, including IT Services' authorization and email infrastructures. The ability to automate the maintenance of this technology and effectively allow for better scaling will be key to the operations of IT Services. Furthermore, the work related to tracking, expediting, and automating data owner approvals will directly reduce the high overhead that the current practice has, which takes a significant amount of staff time and slows the provisioning process, a common complaint from clients.

Current State

  • OpenLDAP and Microsoft Active Directory are centralized and synchronized with central identity management and authentication services. Both deployments are enterprise-scaled offerings with high availability by design.
  • The directory information tree has been used as a model at other peer institutions.
  • Stanford's participation and leadership in the OpenLDAP community is waning.
  • More LDAP environments (for the various phases of testing by MAiS, Middleware and Integration Services) are run out of IT Services than at any other peer institution known.
  • Stanford's data owner approval process is cumbersome and poorly tracked.

Vision

IT Services will continue to encourage and broaden the use of the central directory services via standards-based and secure access methods. In particular, the OpenLDAP directory servers will require GSSAPI (Generic Security Services Application Program Interface) binds for all capable applications. IT Services will avoid the use of password binds unless driven by overriding business needs, as password binds over the network can potentially expose user credentials. Furthermore, password binds for applications requires the creation of passwords as opposed to keytabs for service principals in the Kerberos realms.

IT Services will move towards the use of "over-the-wire" configuration of servers and access control lists (ACLs) via newly released mechanisms that allow such changes on the fly using LDIF (LDAP Data Interchange Format). Furthermore, a new tool to automate the creation and maintenance of ACLs will be created, the LDAP Access Control Infrastructure (LACI). LACI will make ACL management scalable, auditable, and less error-prone. Work flow will also be created to track data owner approval and allow for periodic review of systems access to institutional data via the directory services.

Many applications can take advantage of a robust LDAP service to store a variety of user- and service-related data. IT Services will move to give more applications and services update access to the central LDAP service to support the integration of application management with identity management. Where applicable, Active Directory and OpenLDAP will present the same data to clients in the same way.

Goals

  • Automated LDAP management of access control lists, using LACI. LACI will place Stanford way ahead of the curve in terms of OpenLDAP ACL management.
  • A central management console that will allow servers to be monitored, started, stopped, and have configuration adjustments made using LDIF.
  • Data owner approvals for data access that are tracked for future reference and review.
  • An online system to drive the data owner request and approvals, reducing the amount of HelpSU traffic or email exchanges required to receive and track approvals.
  • Password binds will be supported by the OpenLDAP environment only if it is a business requirement. If there is a requirement to support wide-scale password binds, there will be the need to revisit how the OpenLDAP servers are configured and run. The stability of mechanisms that allow password binds must be tested.
  • Expanded use of the directory as an repository for application- and service-specific data.
  • Course and enrollment information in the directory.
  • Reject all insecure LDAP bind attempts to Active Directory. This includes simple binds (user name and password) performed over an unencrypted connection and SASL binds that are done without integrity verification (signing).

Roadmap

For OpenLDAP:

  • Finish the LACI tool and convert ACL management to LACI.
  • Migrate to LDIF-driven configuration and ACL management.
  • Create a short-term protocol for storing and tracking data owner approvals.
  • Create a web-based tool for requesting, approving, tracking, and auditing data owner approvals.
  • Work with Administrative Systems to populate enrollment and course information in the directory.

For Active Directory:

  • Complete Active Directory upgrade to Microsoft Windows Server 2008 R2 AD-DS.
  • Evaluate impact of settings disabling all insecure binding to Active Directory using the data provided by Directory Service event logs and functional testing. In the past, some clients, especially MacOS clients, have been observed using insecure bind methods.
  • Evaluate the web services interfaces presented by Active Directory in Windows Server 2008 R2 AD-DS.

Measures of success

  • All access controls driven by LACI
  • Decrease in client confusion related to obtaining data owner approval.
  • Auditable levels of tracking data owner approvals.