Directory
Request Directory Access
In order to make a well-formed request, it is useful to understand a few quick 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 (including whatever webauth or other group entries there might be) are never 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 several trees. These trees are generally used as the first detail in specifying an ACL entry so it is important to know which tree you are requesting information in.
Attributes and object classes (and their values) make up the data in the directory. Attributes alone cannot be used: they must be either a required or optional member of an objectclass. The type of values an attribute will hold should be known when creating the attribute. Generally, they will be a number or a string but other values are possible. In order for attributes to be searchable, they must be properly defined and indexed, and it is helpful to know if they need to be searchable before they are added to the directory. Generally, we index for equality searches (uid=blah) or substring searches (suWhatever=stanford:*).
Finally, a word about principals. The majority of access it based on kerberos principals. The kerberos principal is the service/whatever@stanford.edu, or sunetid@stanford.edu, or webauth/something@stanford.edu. Specifying the application or service alone is too ambiguous to guarantee a proper understanding of the request.
Request Check List
Access controls are very tricky and complex in OpenLDAP. To specify them correctly, they must be described in as much detail as possible. Generally, the way an access control is stated is similar to: "In the environment X, tree Y, grant access to principal whatever@stanford.edu to [read/write/compare] access the attributes A,B,C on the master and/or replica server." This is a generalization and more intricacies are possible but that is what most general access controls look like. As such, here are some tips that will make your request more thorough and minimize processing delay:
Have you obtained sufficient permission for access the data? (see Access Policy) If permission was required and obtained, be sure to include a copy of the approval message. If permission was not required, ignore this bullet point.
What environment (dev,test,uat,prod)?
What servers do you need access to (master and/or replica)?
What tree of the directory do you need access to?
What kind of access do you need? (read? write? compare?)
What attributes are you interested in?
If you are asking for a present bundle of privileges, like WebAuth General or WebAuth Privileged, specify that clearly.
If this is an attribute creation request, what kind of attribute is this supposed to be? (string, number, "similar to attribute xyz") What object class is the attribute allowed or required in? What kind of indexing, if any, does it need?
Create HelpSU ticket to request access
