Re: [PLUG] Centralized Directory

["William H. Magill" <magill@mcgillsociety.org>]

On Saturday, November 9, 2002, at 10:11 AM, dwild wrote:
> > For what it's worth, I was talking with the Redhat guys when they 
> > were at
> > Ursinus, and, they are planning on using openldap for future versions 
> > to do
> > the logon stuff for big networks.  They are going to be writing some 
> > of
> > their own software (graphical, of course) to make it nice and easy, 
> > as well
> > as migration tools.
>
> Kerberos also works very well...the problems are the learning curve for
> lusers and it's a pain to implement.

Kerberos and LDAP are not related, and from the users point of view, 
there is really no learning curve. Getting Kerberos principles issued 
and maintained, however, is a different story.

Microsoft really muddied the waters because they extended their 
implementation of  Kerberos to include "authorization" and now 
"everybody" thinks that is how Kerberos should work.

Kerberos ONLY provides AUTHENTICATION, not AUTHORIZATION or ACCOUNTING 
-- no information on directories, what files you can access, who did 
what or anything else of that sort.

Kerberos authentication can be coupled with LDAP, NIS, Netinfo or local 
/etc/passwd authorization -- it all depends on what the application 
does with the ticket. Login becomes just another kerberized application.

Implementing the Kerberos server (KDC) is mostly an exercise in 
security. It's not rocket science. Getting Kerberized apps deployed is 
a different story. Common ones - telnet, ftp, most mail clients are not 
a significant problem but most everything else is "roll your own." 
Defining what the behavior should be when a Kerberos ticket cannot be 
obtained (ie when the server cannot be accessed for some reason) can be 
a "sticky-wicket." The correct implementation is NOT particularly user 
friendly, and that causes political problems more than technical ones.

For what it's worth, Penn just implemented Kerberos Campus wide. It 
took a while, but the problems were predominantly political, not 
technical. The technical problems had to do with Microsoft and Apple 
desktop applications, most of which involved 3rd party, non-unix 
software.

T.T.F.N.
William H. Magill
magill@mcgillsociety.org
magill@acm.org
magill@mac.com

_________________________________________________________________________
Philadelphia Linux Users Group        --       http://www.phillylinux.org
Announcements - http://lists.netisland.net/mailman/listinfo/plug-announce
General Discussion  --   http://lists.netisland.net/mailman/listinfo/plug