| The Plan |
|
As we now know, the NisGina2000 project has failed. This leads us to seek out
a method in which we will be able to authenticate our users using one and only one
database of users. Regardless of the method which we choose to do this, we must do it in a way that will cause the least amount of disruption to the way things currently are operating, as from the perspective of the user, everything is just perfect the way that it is. After a good amount of hours of reading through various documents, I have come to the conclusion that Kerberos will provide us with our services efficiently, and most importantly, securely. While LDAP is more tailored to the requirements of an organization the size of ours, it was designed to be an efficient method of retrieving any data whether it be sensitive information (such as passwords) or the weather for the past year. This is not to say that LDAP cannot be made secure, because it most definitely can and has been done. However, aside from being very apparantly complex to configure, it was still designed with the principle of being a general purpose directory. Kerberos is specifically tailored to the task of extremely secure authentication and identification. Kerberos has been around for almost 10 years now, and is allegedly relatively easy to deploy. In addition, Kerberos scales well beyond simply figuring out if credentials to log on are truly authentic. It employs a two way trust between the principles of the transaction. This means that not only does the server know if the credentials delivered are authentic or not, the client knows whether the server it is communicating with is authentic, and can be guaranteed that if it is not, then no harm has been done and no security problems have been introduced Additionally, it provides services for delegating who is allowed to do what, in a similar fashion as Active Directory. However, Active Directory provides these services only for Microsoft systems, which is the base of our problem (the fact.. not the company) Kerberos is able to provide us with services we need now, and services relating to authentication that we have not yet dreamed about. The problem of course comes down to how and when. This document will discuss the how, and the Timeframe will discuss the when. After some development systems are thoroughly tested, we can implement the KDC (key distribution center) on soemail. Once deployed on soemail, the KDC will be physically located on the same machine that the current NIS maps (thus the accounts) are stored on. Furthermore, RATS will be modified by simply adding the account creation routines neccesary to create accounts for the KDC to use. This can consist of simply having rats run a "finishing" script to create the Kerberos accounts. The whole idea behind this system is so that NIS will not be retired on our systems. NIS will still exist for the clients that currently depend on it, and the transition will not be felt by any of our current users and machines that are already configured. Using this model, Kerberos can be deployed very quickly, and thus take effect in the EIT lab as quickly. Nisgina will still run on the NT machines, NIS will still operate between the servers, and everyone is happy. This pretty much takes the expected time to FULLY deploy Kerberos and changes it from a year+ to just a month or two. Take me to the timeframe page Take me to the Authorization Home |