Introduction
In order to make a well-formed request, it is useful to understand a few facts about the directories.
- Currently, we run four completely independent, non-interconnected directory environments: DEV, TEST, UAT, and PROD. Schemas (objectclasses and attributes), access control lists (ACLs), and entries (such as group entries there might be) are not necessarily identical between environments. An attribute type that is available in DEV is not necessarily available in PROD. Access granted for a principal in TEST will not work in UAT unless setup that way, etc.
- The directory information tree (DIT) is organized into branches. Directory access can be restricted by the directory branch as well as individual attribute, so it is important to know which tree you are requesting information from.
- The majority of access is based on Kerberos principals. Examples of Kerberos principals are service/servicename@stanford.edu, sunetid@stanford.edu, or host/host-fqdn@stanford.edu. Specifying the application or service alone is too ambiguous to guarantee a proper understanding of the request. Please make sure your request includes the Kerberos principal that will be used to authenticate (a.k.a. bind )to the directory.
- A growing number of vendor applications support username/password authentication (a.k.a. simple-bind) to the directory service. In this case, you would request a service principal as usual, but request for a password instead of a kerberos keytab for ldap authentication. sunetid and password based simple-bind are not supported with our current OpenLdap directory setup.
Ldap service URIs
- For simple-bind, use ldaps://ldap-simple.stanford.edu
- For kerberos authentication, use ldap://ldap-prod.stanford.edu
These services are running on Google Cloud Platform (GCP) and have been built with regional high availablity.
- For on-prem systems that have no direct Internet access, use ldap://ldap.stanford.edu
Note we no longer have on-prem ldap servers anymore. ldap://ldap.stanford.edu is a proxy that sends all ldap queries to the GCP cloud ldap servers. If your on-prem systems are behind non-routeable shadow net, or there is firewall rule to prevent your system from connecting to the cloud ldap servers, consider to work with networking so that your system can connect to ldap://ldap-prod.stanford.edu and ldaps://ldap-simple.stanford.edu directly. It will reduce dependencies on campus loadbalancer and campus ldap proxy and cut down two extra network hops.
Request Access Check List
- Decide what data is needed
- Decide service principal name with convention like service/<app>. Decide if you need kerberos keytab authentication or password authentication. You need this in request form.
- Obtain permission to access the data.
- Email will be sent to the requestor when access is granted.
- If possible select one of the Attribute Bundles. If an attribute bundle is insufficient then decide what data is needed by examining the Directory Data Definitions. A good format for specifying an access control request is: "In the environment X, directory tree Y, grant principal whatever@stanford.edu [read/write/compare] access to the attributes A,B,C on the [master/replica] server."
- See the Directory Usage Policy and fill out the Data Owner Request form. Requests must be submitted by faculty or staff. The request must include a complete description of the application that will be accessing the directory. A one sentence description is generally not sufficient.
- When all of the Data Owners have approved the request the requester will be notified via email that access has been granted. An email will also be sent to the directory administrators to implement the changes required to grant access. This usually can take a few days and up to a few weeks.
