Ok Thank's all for your help
I 'll try this.
ps: I try debian experimental package version of libkrb53,
pam_migrate and same issue. When added to the common-auth, It just
hung the console when someone try to login.
Le 20 mai 09 à 01:01, Marcus Watts a écrit :
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
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
