NIS => Kerberos/LDAP Migration

[Hubert Chomette]

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 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
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>