NIS => Kerberos/LDAP Migration

[Marcus Watts]

   Russ Allbery <rra at stanford.edu> writes:
...

> 
> > - make my own pam module using perl to send login/passwd with kadmin
> 
> You'll run into the same problem that the existing PAM module has unless
> you run the kadmin command-line client with system(), which is going to
> be tricky from an authentication perspective.
> 
> -- 
> Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos

While I don't greatly recommend using kadmin for this, it
*is* possible.

When you run kadmin, you can give it:
/1/ a keytab against which to authenticate, (-k -t).
/2/ a command to execute.  (-q)
You'll need to make sure users can't run this directly, of course.
You'll also need to think about passwords.  You can just pass them in on
the command line with "ank -pw", but that exposes them briefly via ps.
You could create the principal with "-randkey", then use the kpasswd
protocol right afterward to set it to the desired value.

Another way to hide the password might be to use the perl (or c) remctl
library to call a remote remctl server, then have that machine run kadmin.
The password would be then only be exposed on the command line on the
remote remctl server.  This might simplify development too.

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?

Instead of cloning the headers (like Authen::Krb5::Admin does) it should
also be quite feasible to just get the debian source package for k5,
configure or build as necessary, rip the desired headers out, modify as
necessary, and use them direct.  Admittedly, this is a hack, and a bad
idea, and all that, but for migration purposes (surely you don't plan
on doing this long-term?) this ought to suffice.  Here's a mail message
I posted May 2007 that describes how to do this:
http://mailman.mit.edu/pipermail/krbdev/2007-March/005702.html

The MIT folks have for other problems in the past have advocated a
heavier weight process like the above: clone the MIT code (bsd license!),
remove the bits that don't do the parts of kerberos that you want,
rename as necessary, then package the entire result in your application.
That means basically taking all the source that makes libkadm5clnt.a and
its associated headers.  If you do this, you probably won't need to rename
anything, since there isn't any public api you'd be conflicting with.  ;-)

I also have java code that talks to kadm5.  I wish I could say it's
pure java, but it's not -- I used JNI to talk at the rpc / gssapi layer.
But I did completely eliminate using libkadm5clnt.so - so down to
and including xdr, I have all of the kadm5 protocol captured in java.
>From rpc / gssapi down, MIT does export and support all of the necessary
functions.  So, that approach is feasible, albeit messy.

					-Marcus Watts