> Date: Tue, 19 May 2009 12:03:59 PDT > To: kerberos@mit.edu > From: Russ Allbery <r...@stanford.edu> > Subject: Re: NIS => Kerberos/LDAP Migration > > Marcus Watts <m...@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 ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos