Removal of plaintext krb5 support.

[Luke Howard]

>I maintain that it is a really silly idea.  After the benefit of not
>having to recompile applications when changing authentication
>mechanisms, the second greatest benefit of PAM is that of code reuse.
>But hiding Samba's NTLMSSP support behind the PAM API doesn't help
>anyone reuse code, because there are no other PAM modules that it would
>be useful to plug into Samba where NTLMSSP sits today.  It would be
>adding unnecessary complexity to the Samba code for no gain at all.

It depends. Having support for different authentication mechanisms
makes sense at the network authentication layer, but this is really
what GSS-API is for: it could be done, but I don't see much point
in trying to shoe-horn GSS-API into PAM. PAM is more appropriately
used, say, to get a Kerberos ticket that can be used _later_ for
network authentication.

You are correct though, in the case of netlogond, I don't see how
using PAM binary prompts (or GSS-API) would be of much use -- the
RPC interface is based on the NTLM authentication model. (There
are some new RPCs for Windows 2000 PAC validation, which can
use the secure channel, but....) What would more likely be useful
is support for pluggable secret stores; the SAM API provides one
possible abstraction for this.

-- Luke

--
Luke Howard | lukehoward.com
PADL Software | www.padl.com