The Solution the single-authentication problem
Single sign-on across a heterogenous network can be done many ways, only one
of which is account synchonization.
If the network comprises of only popular UNIX based operating systems, eg.
a mix of Solaris/Linux/IRIX/AIX/HPUX/OS-X, etc Then you can get away with
a simple configuration of the following protocols...
Most UNIX based operating systems use PAM ( Pluggable Authentication Modules
) to control the basic user account issues.
- Kerberos - Most secure option of the list. Developed at MIT specifically
to solve the single sign-on problem. Token based system allows users
to log in once and use distrubuted services without having to log in again.
Note that this choice still requieres you to run an LDAP server for
complete single sign-on, as Kerberos only stores passwords.
- LDAP - Widely used directory protocol ( more later )
- NIS - Very insecure protocol. Goes way back.
Avoid if at all possible.
- NIS+ - An upgraded version of NIS with security in mind proposed
by Sun. Solaris has good support of this, Linux has some. Very
difficult to use.
Fig1. PAM use ( oversimplified )
PAM is a very capable abstraction layer, and can be used to control all types
of user account behavior such as password strength policies, user resource
limits, time of day restrictions and many others. PAM works by simply
include a PAM "module" for the protocol you wish to use a your authentication
protocol and configuring the PAM parameters for that module. eg. LDAP
would use pam_ldap.so module, which comes with most UNIXes.
Throwing Microsoft windows in the mix creates some complications. Unlike
Just about every UNIX in Apple's OSX can natively talk directly to some or
all of the authentication services, especially LDAP. This means an administrator
can configure a MacOSX computer to search a LDAP server for user accounts
for example. This can not be done of windows hence the diagram below...
Notice that there is the "LDAP Account Synchonization" link in the middle
between Microsoft windows and "everybody else".
So how do you integrate windows into your single sign-on network?
There are other solutions out there as well. Many solutions that have
you authenticate UNIX servers off Windows 2000 servers using LDAP only, do
not allow UNIX users to change passwords using the "passwd" command or a suitable
- SAMBA - Provides all services a windows client would expect from a primary
domain controller of a windows network. Great NT4 "emulation", Win2k
"native mode" support in Samba 3.0. Running Win2k clients in
"mixed-mode" with SAMBA as the PDC works though
- pGINA - Microsoft provides the "GINA" API in their Operating Systems.
This allows administrators to add DLL that replace the native windows
authentication services. A GINA module can be written that allows authentication
off most external databases. pGINA is a project that built a pluggable application
around this. Therefore you can configure pGINA to look to an LDAP server
for user information. This solution requires installing on all client
computers. Other vendors who supply GINA based solutions include Novell.
- AcctSync - Uses another microsoft supplied API call the "password filter"
API. This obscure API allows administrators to install a DLL that catches
all user password changes and synchronize them with an external database,
eg. LDAP. Other vendors who supply Password filter synchronization solutions
include Psynch, Novell and iPlanet.
A good solution is SAMBA, if it works for your environment. Since native
mode is not officially supported yet, and there are some situations where
having a non-windows based PDC complicates things further. GINA based
solutions require you to install software on all windows client machines.
A maintainance headache if you are short on support staff, but very
good for small groups of windows clients. Account synchronization only
requires software to be installed on the windows Domain controllers, allows
windows clients to use their natural password change dialogs. But Windows
to LDAP link must either stay intact or the sychronization script must have
logic to store or deny change request in the circumstance of failure.