NIS => Kerberos/LDAP Migration

[Marcus Watts]

> Date:    Tue, 19 May 2009 12:03:59 PDT
> To:      kerberos at mit.edu
> From:    Russ Allbery <rra at stanford.edu>
> Subject: Re: NIS => Kerberos/LDAP Migration
> 
> Marcus Watts <mdw at umich.edu> writes:
> 
> > I'm not sure I understand why
> > 	Authen::Krb5::Admin
> > 	http://search.cpan.org/~korty/Authen-Krb5-Admin-0.11/Admin.pm
> > is a problem.  I've run it with various incarnations of MIT 1.4.3 /
> > 1.6.3 for a while now.  Ok, they weren't stock, but I don't remember doing
> > anything special to export the necessary kadm5 functions.  The only messy
> > bit is that Authen::Krb5::Admin provides its own header files for the MIT
> > functions - that sucks, but that having been said, it basically works.
> > Is there something special about debian's MIT kerberos libraries?
> 
> That works -- you just can't use it in a PAM module.  PAM modules
> generally need to be C.  I suppose you could embed a Perl interpreter in
> a PAM module, but that terrifies me.  You could also write a PAM module
> that talks to something written in Perl via a local socket or something,
> but now you're getting into a fair bit of coding.

Perl would certainly have a startup cost, so yes, not ideal.

There are pam modules that exec programs -- pam_exec, and
pam_unix + unix_chkpwd.  Neither of them is quite right for
this, and exec'ing a program is ugly, but perhaps possible
(depending on which application(s) need to use this.)

Using c/remctl in pam, then invoking a perl script would be
relatively trivial - although running perl like that is still
going to incur the startup cost.  Running perl once and not
on each authentication attempt is going to need some form of ipc,
be it local sockets or whatever.

To do the local socket thing in perl, this perl module
is useful:
	Socket::MsgHdr
http://search.cpan.org/~mjp/Socket-MsgHdr-0.01/MsgHdr.pm

It's quite possible to write servers or clients in perl that
use local (unix domain) sockets.  In some existing code,
I seem to have used about 350 lines of perl (and the above
module) to do most of the socket management and argument
packing/unpacking.

...

For a completely different solution: if you were willing to modify the
kdc/kadmin as well as the client, and really weren't at all afraid of
coding, you could add a "crypt salt" type, and simply import your nis
password database directly into your kerberos database.  I did this
at one point (with an experimental crypto system based on cast-5); it
took me approximately 360 extra lines in just 5 files to handle this.
Of course, the devil is in the details, and this was *not* a stock
kerberos code base.

Personally, if I was going for the simplest least code approach, I'd use
the "steal the headers" approach and just call kadm5 from inside the pam
module.  I might set up a special service principal that is acl'd to
only be able to invoke "ank".

If I was going for "most secure", I'd have a separate daemon that
validated the password matched the crypt string from nis, then
created a kerberos principal that matched.  perl5 might actually
be ok for the separate daemon.

					-Marcus Watts