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...

• 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.

Most UNIX based operating systems use PAM ( Pluggable Authentication Modules ) to control the basic user account issues.

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?

• 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.

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 replacement.

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.