Description

Many organizations rely on some sort of accounting in the IT department. When it comes to managing all of the accounts on the different servers, nightmares run rampant. Centralizing the account management can be a complex task, especially when it comes to uniting differing operating systems, such as both NT and Unix. This document discusses the breakdown of setting up systems where accounts are centrally managed, yet refrain from being global in settings. It discusses the principles of setting up server specific accesses, logs, and how to keep your system from becoming un-manageable.

Theory

Here's how the centralization works. We set up one host, our "Account Host" if you will. This device will house the required log in information. We also have additional servers for things such as E-Mail, Web logins, FTP access, shells, Instant Messengers, etc., and these will be required to contact our "Account Host" to verify the users access.

When an individual trys to access a service on a server, the server first requests a username, and then a valid "credential". These credentials are typically passwords, but can be things such as fingerprints, timestamp encoded data, or anything else that can function as a method of securing accounts. Once the username and credential have been obtained, the host then contains the "Account Host", and tries to verify the supplied username and credentials. If the credentials do not verify, our host returns an "access denied".

We would also set up our other services to function the same way, where they would verify the credentials to the main "Account Host". This means that one would only have to alter the credentials on the "Account Host" in order to alter the credentials on the other hosts. In pictorial fashion :

Account Host			Mail Server
			Database Server

Design

There are many methods that allow a Centralized Access Control mechanism to be implemented. Some require third party protocols, where as others rely on databases. The common method of late has been to implement an LDAP server, and include authentication information with the information on the LDAP server. My method is to attach to an actual database server.

To implement a centralized system, an individual would use combinations of different software. For example, in Unix, a combination of PAM (Pluggable Authentication Modules) and NSS (Network Security Services) would allow the account information to be stored completely elsewhere. At the same time, back-up account access can be used in case the main system goes down. In windows, one would typically implement a GINA program that verifies against the specific service (Novell's login and the Microsoft Logon are both widely used implementations of GINA).

Implementation means designing a system that can house the number of users you expect to need access at any given time, while keeping all of the data you are going to need, such as login times, services needed and accessed, login sources, and contact information. It also means using a system that can be secured if someone finds access to your physical network and starts dumping network protocols that contain user information. The design must also entail a failure mechanism to allow access for at least your systems administrator, should the centralized host become incapacitated in handling account information.

Security

There is more to security than obsolving the furious employee or preventing the malicious individual from accessing services. Security also entails a fall-back method of recovering from disasters. For example, if a company has implemented a system that depends on an external account host (or an account host housed by another part of the company over a WAN (Wide Area Network), and the connection fails, that particular division of the company will be unable to access the local services. Security means preventing the propogation of information to people who should not have it, and allowing the information to reside reguardless of the current state of the network.

Still, in centralizing the system, one does not need to implement a purely secured system, where company divisions require their own back up to the main, centralized account host. This becomes redundant and can often cost thousands of dollars in maintainance on the devices that house the back ups. Theoretical implementations are more common. This entails a setup that does not neccesarily involve redundant back-ups of the account host services, just the data stored on the system.

At the same time, people will try to test the security of the system to find breaking points. This can be done maliciously, or in earnest of attempting to find and fix flaws. This means that connecting to services should force the server to access the centralized host in a SECURED fashion. Typically, this means using an SSL layer to encrypt the data prior to sending across the network. When it comes to shells and E-Mail, forcing your users to use an SSL layer (such as SSH in unix or TLS in E-Mail clients) is suggested.

Implementation

I've already discussed the methods of centralizing the system above, in the design section of this document. If you need information on actual implementation of the above protocols, or customizations, do not hesitate to contact one of our consultants, using the E-Mail address consult@sharktooth.org.