Russ Allbery <r...@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 (r...@stanford.edu) <http://www.eyrie.org/~eagle/> > ________________________________________________ > Kerberos mailing list Kerberos@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 ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos