unified authentication

Wed Sep 24 12:55:59 PDT 2003

On Wednesday 24 September 2003 12:54, Matthew George wrote:
> On Wed, 24 Sep 2003, Jesse Guardiani wrote:
> > 1.) Kerberos
>
> krb is nice, but the problem with it is that all of your applications need
> to be kerberized in order to support ticket validation from the krb
> server.  There is an interesting description (albeit slightly dated) of
> how the system works at:
>
> http://web.mit.edu/kerberos/www/dialogue.html

Yes, I found that after I posted to the list. Very informative.

I understand what you're saying when you say that all applications need
to be kerberized in order to work, but isn't that true of any auth mechanism?

Perhaps kerberization just isn't very widespread as something
like LDAP?

>
> > 2.) PAM (Seems to be more of a library than a complete
> >     solution.)
>
> Indeed.  PAM is a vehicle used to employ various authentication
> mechanisms and not actually an authentication service by itself.  For
> example, you could specify that for login services to a machine, a user
> must first attempt to authenticate via tacacs, but should that fail,
> authentication against the system password file is sufficient.
>
> The following PAM support is available in FreeBSD (I'm running 5.1):
>
> mdg at mdg:/etc/pam.d> ls /usr/lib/pam*so
> /usr/lib/pam_chroot.so          /usr/lib/pam_opieaccess.so
> /usr/lib/pam_deny.so            /usr/lib/pam_passwdqc.so
> /usr/lib/pam_echo.so            /usr/lib/pam_permit.so
> /usr/lib/pam_exec.so            /usr/lib/pam_radius.so
> /usr/lib/pam_ftp.so             /usr/lib/pam_rhosts.so
> /usr/lib/pam_ftpusers.so        /usr/lib/pam_rootok.so
> /usr/lib/pam_group.so           /usr/lib/pam_securetty.so
> /usr/lib/pam_krb5.so            /usr/lib/pam_self.so
> /usr/lib/pam_ksu.so             /usr/lib/pam_ssh.so
> /usr/lib/pam_lastlog.so         /usr/lib/pam_tacplus.so
> /usr/lib/pam_login_access.so    /usr/lib/pam_unix.so
> /usr/lib/pam_nologin.so         /usr/lib/pam_wheel.so
> /usr/lib/pam_opie.so
> mdg at mdg:/etc/pam.d> ls -d /usr/ports/security/pam*
> /usr/ports/security/pam-mysql           /usr/ports/security/pam_ldap
> /usr/ports/security/pam-pgsql           /usr/ports/security/pam_pop3
> /usr/ports/security/pam_alreadyloggedin /usr/ports/security/pam_pwdfile
> /usr/ports/security/pam_krb5            /usr/ports/security/pam_smb
>
> > 3.) LDAP
>
> LDAP is good because of the centralized directory services it provides.
> You can store much more information about users other than their username
> and password (such as addresses, job title, department, phone numbers,
> location, public key, etc).  I've seen documentation online (although the
> specific location escapes me at the moment) about how to integrate UNIX
> and Windows (active directory) authentication via LDAP (I believe the ADS
> controllers become authoritative in this scheme ... not sure if openldap
> can be used instead).  This isn't something I'm familiar with first-hand,
> but it's currently on my list of things to research.
>
> > 4.) RADIUS
>
> RADIUS is designed specifically for centralized user administration and
> authentication.  Support is available for a wide variety of devices (cisco
> is included, but I'm pretty sure Windows isn't).  pam_radius is included
> in the FreeBSD base system and just needs to be enabled via PAM.
>
> > 5.) NIS/NIS+
>
> My personal favorite, NIS can be used to provide many services to UNIX
> hosts.  NIS is at a bit of a disadvantage due to the unencrypted transport
> of information.  Although MD5 hashes in the passwd databases make
> passwords harder to crack, usernames and group memberships may still be
> retrieved with little difficulty if you have access to a network where NIS
> is running.  I definitely would not recommend running it on networks where
> unknown / not-trusted users have access, but it has served me quite well
> for access administration on internal servers / corporate networks.  I'm
> not familiar with a UNIX variant that does not support it, but you may
> have problems with other network devices and Windows integration.
>
>
> If you are running a Windows network with NT domain controllers, you may
> want to look at pam_smb.
>
> Since you have cisco devices, you may want to look at pam_tacplus.
>
> Another alternative is OPIE (an S/Key derivative).  This implements
> one-time passwords, but will require much more support for users if they
> aren't familiar with how it's supposed to work.
>
> I'm sure I'm forgetting something ...

Well, I'm currently trying to decide between these then:

Kerberos
RADIUS
LDAP (OpenLDAP only. I don't have a proprietary LDAP solution.)
TACACS
pam_smb, possibly.

I'm ruling out NIS/NIS+ because:
--------------------------------
1.) I'd like something with decent cyptography built in. That's why I conceptually
    like Kerberos.
2.) AFAIK, no Cisco support.

Now, I suppose the question is this:
------------------------------------
Will any of the above do ALL of the following?
(The below is a prioritized list of the things
I'd like to see in an authentication system:)

1.) Authenticate for ssh
2.) Authenticate for Cisco equipment
3.) Authenticate for Apache htaccess files
4.) Allow some way to easily set root passwords and su
5.) Do the above from a centralized location
6.) Do so with reasonable security/encryption
7.) Authenticate for Windows boxes

And honestly, I could live with ditching the Windows
Auth if a given solution works a lot better on *NIX.

For example, I've heard that OpenLDAP is a real
pain in the rear to install and configure. If that
is true, and something like RADIUS or Kerberos would
provide a better solution, then that's where I'd
likely go.

The other question I find myself asking is this:
------------------------------------------------
Once I get authentication working, how do I handle
the creation of home directories and basic user
files across multiple machines?

Do I need to start running NFS, or is there a more
elegant solution?

Thus far, I've gotten a lot of great feedback from
list members. Thanks!

-- 
Jesse Guardiani, Systems Administrator
WingNET Internet Services,
P.O. Box 2605 // Cleveland, TN 37320-2605
423-559-LINK (v)  423-559-5145 (f)
http://www.wingnet.net