Accessing Authentication, Authorization and Enterprise Directory Resources
Authorization and Enterprise Directory Services
Authorization services are handled by our Enterprise Directory (LDAP). Access to the directory is restricted, requiring the use of IP-restricted, application-specific, bind credentials. The attributes that each application may access requires approval from the CEDAR Development Team and a higher controlling body made of representatives from various data providers.
To request access to the directory, or to use it for authorization services, you must complete a project request form. If you lack the ability to submit OIT project requests, please email OIT Production Control, providing your name, telephone number, and department.
In your requst, please state the name of your application (including any applicable version information) , the intended use of the data, who will be consuming the data, from which IP address(es) your application will operate, and a list of attributes that you need to access. Once approved, you will be contacted with appropriate credentials as well as a list of attributes that you may access.
Request Access to the Directory or additional attributes
OIT Project Request
Please refer to the LDAP Schema document for a complete list of attributes and under which branch of the directory they exist.
Authentication Services
Authentication is handled by the MIT Kerberos realm CEDAR.UTA.EDU. This realm is fully supported by UT Arlington's domain name service (DNS) configuration. Most client operating systems will allow you to either specify the Key Distribution Center (KDC) and Kerberos Admin (kadmin) server or have the servers configured dynamically using DNS SVR record identifiers. The use of DNS SRV records is strongly encouraged. If your client requires a manual configuration, please see the krb5.conf example below.
Our LDAP directory servers (ldap.cedar.uta.edu) are set up to authenticate using the CEDAR.UTA.EDU Kerberos realm, your application or operating system may be configured to utilize LDAP for authentication. Note that the CEDAR Development Team does not recommend using LDAP in this manner, as the LDAP protocol was designed specifically for authentication. Also note that in order to authenticate someone to LDAP you must attempt to bind to the server with their credentials -- this usually requires you to first obtain their NetID and password internally before processing. If your web application does collect a NetID, you must use SSL encryption. (see UTS165 - UT System Information Resources Use and Security Policy)
Examples
krb5.conf
# Puppet: modules/kerberos/files/krb5.conf
#
# $Id: krb5.conf 4874 2009-06-17 18:26:14Z davids $
#
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = CEDAR.UTA.EDU
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
forwardable = yes
[realms]
CEDAR.UTA.EDU = {
kdc = kerberos.cedar.uta.edu:88
kdc = terrier.cedar.uta.edu:88
kdc = husky.cedar.uta.edu:88
kdc = labrador.cedar.uta.edu:88
admin_server = labrador.cedar.uta.edu:749
}
[domain_realm]
uta.edu = CEDAR.UTA.EDU
.uta.edu = CEDAR.UTA.EDU
cedar.uta.edu = CEDAR.UTA.EDU
.cedar.uta.edu = CEDAR.UTA.EDU
[kdc]
profile = /var/kerberos/krb5kdc/kdc.conf
[appdefaults]
pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}