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.
Ldap service URIs
- For simple-bind, use ldap://ldap-simple.stanford.edu:636
- For kerberos authentication, use ldap://ldap-prod.stanford.edu:389
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:389
We highly recommend you to use services hosted on GCP for both on-prem and in cloud systems. If your on-prem systems are behind non-routeable shadow net, consider to work with networking to make your system can connect to Internet.
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.
