Architecture and Middleware Components
- OpenLDAP
- MIT Kerberos
- JA-SIG CAS (Central Authentication Service)
- CEDAR::AMS (Account Management Service)
- CEDAR::EDIS (Enterprise Data Integration Suite)
- CEDAR::PRS (Password Replication Service)
- Shibboleth
- Grouper
The Case for Middleware
Middleware has emerged as a critical second level of the enterprise IT infrastructure. The need for middleware stems from growth in the number of applications, in the customizations within those applications and in the number of locations in our environments. These and other factors now require that a set of core data and services be moved from their multiple instances into a centralized institutional offering. This central provision of service eases application development, increases robustness, assists data management, and provides overall operating efficiencies.
Core middleware services are those that all other middleware services depend on. The challenges in providing these services are as much political as they are technical. Many of the hardest issues involve the ownership and management of data in the complex world of higher education.
CEDAR undertakes core middleware services at UT Arlington, including identifiers, authentication, authorization, and directory services. Each core middleware service is handled by a separate CEDAR sub-project, detailed below.
Account Management Service
Enterprise Data Integration Suite
Password Replication Service
PRS Introduction
While pursuing the creation of a brand new middleware layer, our clear objective was to minimize the impact to end users. Transitioning to a purely MIT Kerberos Realm would have orphaned some Windows services that were not Kerberized. Alternately, the popular "central password change website" approach (where a central website is used for all password changes and native methods such as using CTRL-ALT-DEL in Windows are disabled) would have had too great of a detrimental impact on our user base, who are used to the convenience of changing domain passwords straight from their workstation. Nevertheless, it was evident that transitioning towards an application-neutral, standards-based Kerberos Realm would prove to be more cross-compatible and flexible. As such, the Password Replication Service (PRS) sub-project was born, under the umbrella of the much larger CEDAR project.
Password Replication Service is a bit of a misnomer, as passwords are not actually replicated between two repositories. Rather, it is the password changes themselves that are captured, which in turn is used to bring the password for a particular user in sync between two independent password stores. In the PRS model, the MIT Kerberos store is used as the authoritative password service in which complexity, password histories, etc, are enforced, and Active Directory is used as a complementary authenticating service.
The architecture of PRS is quite simple and is discussed in detail in other sections. In summary, it can be broken down as two hooking mechanisms that "trap" password changes occurring in the Kerberos Realm and Windows Domain, and a middleware service that acts as an interface between the two. While the two hooks are actually fairly simple, the middleware service handles the bulk of the work by serving as a liaison between the two password stores.
The way password changes are handled depends on the point of origination. Password changes originating on the Windows Domain are first handed to the middleware service, which then contacts the Kerberos Realm to see if the password change is allowed (has the password been used before? Is it too short? Is it complex enough?). Once the Kerberos Realm has accepted the password change, a confirmation is returned to the Windows Domain. If there is a problem, however, a rejection notice is returned informing the Domain Controller not to accept the password in its local store.
Password changes originating on the Kerberos Realm, on the other hand, are first handled internally by the Kadmin server itself. Only passwords that are allowed (based on the same restrictions as in the above paragraph) are reported to the middleware service. In this case, the middleware service contacts the Windows Domain to change the password in that store as well.
Thusly, PRS is able to "replicate" or "synchronize" passwords in two independent repositories.
PRS Architecture
PRS was designed to take advantage of existing technologies and to minimize the impact on the existing infrastructure. In this section, we will briefly discuss the three parts of the PRS package: Kerberos hook, Windows DC hook, and the middleware service.
Kerberos Hook
To capture password changes in MIT Kerberos v 1.3.5, a patch was created for the source file /src/lib/kadm5/srv/svr_principal.c. This patch enables the functions listed below to report the successful completion of the respective event they handle.
- kadm5_create_principal_3
- kadm5_delete_principal
- kadm5_rename_principal
- kadm5_chpass_principal_3
These functions call logEvent and give it three parameters: the principal, the event (such as "ADD" or "CHANGE") and the password, if available. The logEvent function in turn makes a system call to /opt/oit/sbin/cedar_prs_event.pl and gives it the same three parameters with the password URL encoded first.
The Perl script /opt/oit/sbin/cedar_prs_event.pl then takes the information and passes it on to the middleware service using HTTP POST.
It should be noted that while it would have been possible to perform an HTTP call from within Kerberos itself, the decision was made to minimize changes within the MIT Kerberos source code. Therefore, only the minimal amount of work is done within Kerberos, and as much as possible is deferred outside the kadmin server.
Windows DC Hook
To capture password changes in the Windows Domain, we rely upon another open source project: passwdHk. PasswdHk was part of a larger (and now seemingly defunct) project, but by itself, proves to be a rather useful tool for extending password requirements for Windows. In our project, the requirement is that all passwords are first accepted by the authoritative Kerberos Realm.
PasswdHk has been installed on each of the Windows DCs, and configured to run a pre-change vbscript. In other words, before the DLL accepts a password, a vbscript is called, which does an HTTP POST to the middleware service and waits for a response. If the response is ACCEPT, the passwdHk gives a thumbs up to the password; if the response is REJECT or ERROR, passwdHk gives the password a thumbs down.
PRS Middleware Service
The PRS middleware service is built around some simple protocols and tried and true open source technology such as HTTP, LDAP, Apache, Perl, and MySQL. Using Perl modules with Apache, a web-based service is instantiated that listens to incoming events reported by the hooks described earlier. A MySQL database holds records of these events to prevent infinite loopback problems (e.g. password change in A triggers password change in B triggers password change in A, etc).
PRS works in three modes: handling password changes from Kerberos, handling password changes from Windows, and resetting passwords for PUID (UTA's account management system).
Password changes from Kerberos
When handling a password change from Kerberos, the middleware service makes the assumption that the password has already been stored in the Kerberos store. All that is left to do is synchronize Windows Active Directory. The username and a hash of the password are stored in the database, and then LDAP calls are made to Active Directory. The service randomly picks a Windows DC from a list of available DCs and binds using credentials that have Domain Administrator privileges. Finally, the service simply replaces the userPassword attribute with the new password.
As would be expected, the Windows DC calls the middleware service before storing the password. However, when the middleware service looks in the events cache (the username and password hashes stored in the database), it will know this is just an "echo" of a previous event. Therefore, it will simply return an "ACCEPT" message back to the Windows DC so it can store the password.
Password changes from Windows
When handling a password change event from the Windows DC that does not already exist in the event cache, the service assumes that the Windows DC has not yet stored the password and is asking for permission. The service logs the event in the database and then uses a couple of Perl modules (Authen::Krb5 and Authen::Krb5::Admin) to connect to the Kadmin server and submit a password change. If Kadmin accepts the password, the service returns a thumbs up ("ACCEPT"); if the password is rejected, the service returns a thumbs down ("REJECT") along with an explanation.
Again, the Kadmin server will call the middleware service after storing the password. When the middleware service looks in the event cache, it will know that this is an echo of a previous event and will return an "ACCEPT" message. Of course, the returned message is just for consistency, as the Kadmin server actually does not wait for any kind of response from the middleware service because its the authoritative source.
Password resets from PUID
Lastly, the PRS service aids PUID (our account management system) by handling password resets. PUID contacts the service with the username and temporary password and identifies the event type as "RESET." PRS enters the information into the event cache and then changes the password in Kerberos.
To do this, PRS must first overcome the password history mechanism. Currently, we employ "default passwords" - fixed passwords picked by the employee or based on the students biographical information. If a student or employee forgets his or her password and requests a "password reset," the respective password is set to this unique default password. This way, the individual can regain access to the system and change his or her password. There are, admittedly, several flaws in this system and the concept of the default password is soon to be phased out completely. But until then, if this default password is still in the password history Kerberos will reject the password reset attempt. By doing so we have worked around the password history mechanism by creating a Kerberos policy that has a password history one item long. The service first changes the policy of the principal in question to this special policy, sets the password to a known temporary password that the middleware service ignores, changes the principal back to the policy named "default", and finally sets the password to the default password as specified by PUID in the form of a string. Thus, the service overcomes the password history mechanism.
Once the password has been changed in Kerberos, PRS next modifies the principal in Kerberos, setting the password expiration timestamp to the current time. This concludes phase one of handling password resets. The next phase begins when Kerberos echoes back the default password.
When Kerberos stores the default password, its hook will report the event to PRS. When PRS looks in the event cache, it will find this event is an echo of an event initiated by PUID when doing a "RESET." Therefore, it assumes that it must now handle phase two: changing and expiring the password in Windows. Using the same privileged credentials it used in the first phase, the service binds to Active Directory using LDAP, changes the password, and then expires the password by setting pwdLastSet attribute to zero. This concludes the service's response to password reset requests.