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
|