Directory Services The University of Queensland LDAP Experience

Directory Services The University of Queensland LDAP Experience

Intro - What Is A Directory ? A directory is something which through organisation and categorisation assists people in finding things. TV Guides, Telephone Books and Library Catalogues are all directories. Online Directories are dynamic and flexible directories. Online Directories can also allow personalised access including configuration and security. Active Directory is and example of a Network OS tailored online directory. Lotus Notes and Microsoft Exchange are examples of Application Specific Directories. Internet DNS is an example of a purpose specific directory. LDAP and X 500 are examples of general purpose directory systems, this presentation will be looking at LDAP Implementation at The University of Queensland. An online directory can organise itself hierarchically, starting at the country then the organisation – e. g. ‘o=The University of Queensland, c=AU’. Alternately a directory can organise itself hierarchically using a domain naming convention much like the DNS structure.

Intro - What Is LDAP ? It all started with X. 500 which developed during the 1980 s and was formalised in an 1990 and included 8 recommendations (X 501, X 509, XF 511, X 518, X 519, X 520, X 521 and X 525). LDAP was initially created as a front end for X 500 directory services (at The University of Michigan) as the protocol stack for X 500 was too demanding for the client computing of the day. It was released in 1992 as copyrighted but free software and called U-M LDAP. The client protocol (LDAPv 2) become a de-facto standard and was published in RFC 1823. At then end of 1995 The University of Michigan released an updated U -M LDAP (V 3. 2) which included the first LDAP server (SLAPD). LDAPv 3 in the late 1990 s was extended to include Internationalisation, Referrals, Security (SASL and TLS), Extensibility and Feature and Schema Discovery.

Intro - How Is UQ Using LDAP ? Configurable and secure mass e-mailer for allowing certain staff access to various groups of staff and students (for example allowing certain staff to e-mail all members of a particular superannuation fund, or lecturers to e-mail all students in one of their subjects). University wide access to central authentication and through that enable development of single sign on. University wide access to central authorisation allowing access to facilities (web sites, samba shares and other logins) based on age (over 18), courses (subject material) and many other criteria. Enabling a university wide mail directory for e-mail clients (including Eudora, Netscape Mail and Outlook). Replacement of the printed phone, e-mail and location directory with an online directory – increasing privacy and improving access. Directory enabling the university portal (my. UQ) for configuration information and online directory facilities.

Intro – Presentation University Database Systems Data Consolidation and Import Central Collation Database Export Procedure Directory Servers Directory Applications

UQ - University Databases University Database Systems

Databases - Requirements A single data source which defines the existence of each object type (people, units etc) A single unique identifier representing instances of each object type (people, units etc) Data sources responsible for information about instances of each object type A mechanism for defining single unique login ids for each person, and an optional external authentication system A way of linking people to membership of each of the organisational structures Co-operation with the owners of these data sources A security policy to protect the information contained in the directory from each of these data sources.

Databases – PRISM Prism has an INGRES backend. Prism is an account management system used by Information Technology Services at UQ for management and billing of central computing and dial-in facilities. Prism was chosen as the database responsible for creating directory entries for people because it currently creates and maintains login ids for all categories of persons (including Staff and Students). Prism also creates the entries for the authentication system Kerberos, as the UQ LDAP services pass authentication through to Kerberos – this was an additional reason to choose PRISM for entry creation for persons. Prism also provides a unique identifier for each person, e-mail aliases and also unique identifiers for the person in the staff and student systems.

Databases – AURION has an Oracle backend. AURION is the primary system used by UQ to maintain personal and corporate information about all staff. AURION has a separate feed into PRISM for automatic creation of Staff accounts and Kerberos entries. The information the directory obtains from AURION includes employment information, superannuation information, full name details and a link to the organisational unit employing them.

Databases – STUDENT 2000 Student 2000 has an Oracle backend. Student 2000 is a comprehensive database system (Peoplesoft) which stores information about all students, their personal, enrolment details and course information. As well as all the information about the student, Student 2000 provides the directory with lists of classes and timetables for subjects. Student 2000 has a complete directory of all subjects taught within the university and this information is imported into the LDAP directory in a structured (hierarchical) layout.

Databases – UQORG/UQROLES UQOrg currently has an MS-SQL 6. 5 backend The UQOrg database and associated database UQRoles provide important structural information for the directory. The UQOrg database allows creation of a hierarchy of business units and also a hierarchy of geographic facilities (campus, building, floor and room) The UQRoles database supplies information connecting different roles performed by different persons with the units (from UQOrg) locations and facilities (from UQOrg) and subjects (from Student 2000). Additional ‘free floating’ roles are also defined that are not tied to any specific area.

Databases - Other PABX database gives information about the telephone and fax numbers for staff as well as room numbers. PABX is currently a text file manual feed. Convocation (FUTURE) database will provide information about alumni Research Services (FUTURE) database will provide information about research areas, pointers to research material allowing searching and contact with groups of similar interest. Union (FUTURE) databases allowing access to both staff and students by their respective unions, allowing contact for resources and information to those groups.

UQ - Database Import University Database Systems Data Consolidation and Import

Import – Requirements A structured system that accepts input data from any data source. Regularly reads the data sources for additions, deletions and modifications. Input injection procedures checking for error conditions, duplicates and changes. Assumes a primary key from each data source. Allows multiple value fields for a given primary key.

Import – Structure Units Input Data Sources for People (Configuration Files) PRISM Add AURION Student 2000 Subjects PABX Locations Delete Input Processing Scripts (Perl Code – for flexibility) People Units Subjects Locations Input Injection Procedures (Oracle PL/SQL – for database speed) PRISM AURION S 2000 PABX etc…

UQ - Collation Database University Database Systems Data Consolidation and Import Central Collation Database

Collation – Requirements The collation database is designed to store basic information about each object type (People, Units etc), in such a way that it can represent directory information. The collation database is therefore not suitable as a normal data warehouse. It must be capable of storing large quantities of data and optimised for updating, not for reporting or browsing. Each object type (People, Units etc) needs to be flagged as ‘altered’ to allow the export procedure to only export modified, deleted or added records. The database should preferably reside on the same server as the master directory server.

Collation – Data Structure Attribute People Staff, Student ID People ID Attribute Value Unit ID Subject ID Attribute Value Location ID Attribute Value Category -1 Default Value Category 0 Force Value * -1 Default Value * 0 Force Value Subject ID Location ID Note: The People table has sub categories such as Student, Staff etc) Note: * is a wildcard on category, 0 is a wildcard for a mandatory value on ID and -1 is a wildcard for a default value

UQ - Export Procedure University Database Systems Data Consolidation and Import Central Collation Database Export Procedure

Export – Requirements Procedures capable of regularly (each hour) looking at the collation database and creating, deleting and modifying entries within the directory server. For organisational structures be capable of modifying hierarchical structures, given the limitation of the LDAP directory that moving nonleaf entries is not inherently possible. Logging error conditions and logging entries that failed on updates.

Export – Structure Collation Database People Export Scripts (Perl) Full Entries for People Unit Subjects Location Export Unit Export Subjects Export Location Hierarchical Information Including Member People Master Directory

Export – Hierarchy o=The University of Queensland, c=AU Student Staff Subject ARTS People Vice-Chancellor Location SCIENCE Ipswich Gatton St Lucia Permanent People Casual People Pointers to real entries from groups below each unit, subjects and locations Associate Unit Secretary and Registrar Unit People Information Technology Services Staff Full Read Mail

UQ - Directory Servers University Database Systems Data Consolidation and Import Central Collation Database Export Procedure Directory Servers

Directory – Requirements As the directory was being used for authentication it had to be primarily reliable with little or no downtime. As the directory contained sensitive information it had to be secure from prying eyes yet open to those who were permitted access. Due to the volume of requests to the directory it needed to be responsive, but at the same time allow large scale queries to those who needed them. Due to the nature of some e-mail clients the directory had to be standard both in the protocols used (LDAP) and in the attributes that the clients expected to exist.

Directory – Structure E 10 K A Master Directory Replication Kerberos Authentication Primary Slave Directory 80% load Replication Secondary Slave Directory 20% load Primary LDAP Router 20% load 80% load Secondary LDAP Router E 10 K B E 10 K C DNS Rotary ldap. uq. edu. au

Directory – Security/Privacy Security is implemented using the Netscape Directory Server ACI access control system. Privacy is enabled through additional attributes (prefixed with pub_) which are publicly viewable versions of certain personal information – e. g. pub_displayname corresponds to the standard attribute cn (common name). A person can disable public viewing and searching on these attributes through a web interface built into the university web portal. The ACIs give read and search controls for anonymous users to ‘pub_*’, and deny all other anonymous access. ACIs can control access individually to different parts of the directory based on login details, client IP address, target attributes and most importantly membership of groups. Through membership of control groups within each organisational unit, the directory knows which persons are allowed access to staff within that unit (or students within that subject etc).

Directory – Reliability/Response Redundancy is firstly achieved via the dual slave directory servers, by attempting connection on one then the other. Secondly the LDAP routers both load-share to both directories, if one directory fails then the second takes up the full load. Thirdly the DNS ldap. uq. edu. au is a rotary, so that load is shared between both LDAP router in case of hardware failure. By ensuring that only short searches are done on the slave servers and the longer searches on the master, the response time for most users is normally 1 or 2 seconds with half a million operations per day. In future we want to implement a smart DNS that only serves the addresses of the operational LDAP routers – this would allow for automatic recovery on hardware failure.

Directory – Compatibility The LDAP routers also allow attribute translation – that is a search for one attribute can be mapped onto another search at the two slaves. Returned attributes get mapped the other way. This allows us to map the public attributes (e. g. pub_displayname) to and from the standard attributes (e. g. cn). Pub_displayname, pub_email, pub_phone and pub_ouname are currently mapped to ‘cn’, ‘mail’, ‘telephonenumber’ and ‘ouname’. This is currently working with Eudora, Netscape Mail and Outlook Express – giving them an expanded address book that is University Wide.

UQ - Applications University Database Systems Data Consolidation and Import Central Collation Database Export Procedure Directory Servers Directory Applications

Applications – Admin applications talk via LDAP directly to the master directory server. Mass e-Mailer application authenticates and authorises application users, then searches and returns e-mail addresses. Directory and security management applications written in Borland Kylix (Linux and Win 32) talk to any of the servers.

Applications – Central applications talk to slave 1 and fail over to slave 2. SI-Net Student Information Network, allows students to enrol, select subject etc online – authenticated via LDAP my. UQ web portal including Netscape Mail and Netscape Calendar – authenticated an authorised via LDAP

Applications – Client applications talk to ldap. uq. edu. au Eudora E-Mail Mac and Windows Netscape (not version 6) E-Mail Microsoft Outlook Express Microsoft Outlook

UQ - Summary University Database Systems Data Consolidation and Import Central Collation Database Export Procedure Directory Servers Directory Applications

Summary - Hardware/Software Hardware: Three domains on Enterprise 10000 hardware shared with other applications (1 x 8 processor, 2 x 16 processor) Operating System : Solaris 8 Collation Database : Oracle 8. 1. 6 Directory Server: Netscape Directory Server 4. 12 LDAP Router: i. Planet Directory Access Router 2. 1 Kerberos Plugin for Directory Server: Written in C Custom Server Software: Perl 5 and Oracle PL/SQL Custom Client Software: PHP/Web and Kylix (Win 32 and Linux).

Summary - Issues An additional requirement for inserting changes from the directory back into the collation database was implemented via an audit log which Netscape Directory Server implements. Searching, especially un-index attributes is very time consuming so good design of the schema and indexing is needed. Replication using Netscape Replication services creates a redundant system – however re-initialising replication cause significant problems (if the master is corrupted), this was a several hour process. The directory server requires around 2 GBytes of physical memory, fast disks for updates and a large number of available file handles for socket communications. It performs well on a single processor – but at times was using up to 3 of the Enterprise 10000 processors. Scripts were written to transfer all the access logs for the master and slaves to a central location for processing. The access logs are very complex and at this stage only simple analysis has been done. Netscape and i. Planet recommend that Netscape Directory servers that are required for high traffic should be on stand alone servers – rather than on shared servers. We have had some issues with that and are still resolving these problems.

Summary - Read about LDAP Understanding and Deploying Ldap Directory Services (Mac. Millan Network Architecture and Development Series) by Tim Howes, Mark C. Smith, Gordon S. Good, Timothy A. Howes 1 st edition (January 1999) New Riders Publishing ISBN: 1578700701