Implementing a KDB plugin

[harsh savla]

Thanks for the reply. I am aware of the fact that the user's password won't
be transferred plain-text or even encrypted over the wire.

I was thinking along the lines that the security blob (encrypted using the
user's password as a key) received by the krb5kdc service on user login
will be passed to the cloud service via the kdb plugin. The cloud service
then passes this blob to the AD (Windows Active Directory) service. AD, as
it supports Kerberos, will have the long term keys stored for all the
users. So it should be able to authenticate the blob.

On Thu, May 5, 2016 at 12:41 PM, Greg Hudson <ghudson at mit.edu> wrote:

> On 05/05/2016 02:57 PM, harsh savla wrote:
> > The idea is that end users map Samba share using map drive and enter
> their
> > Kerberos credentials. This hits our VM (specifically the krb5kdc service)
> > and we just pass these credentials to the cloud service which then
> > authenticates against the AD.
>
> Kerberos KDCs do not generally receive the user's password from the
> client.  Instead, the client and KDC leverage their shared knowledge of
> the password (more specifically, a long-term key derived from the
> password) to authenticate and create a ticket-granting ticket for the
> client.  Therefore, it is not possible to create a KDB module which
> causes the KDC to act as a pass-through password authentication service.
>
> With some caveats, it is possible to do this using the FAST OTP preauth
> protocol (RFC 6560).  In our implementation, you would do this by
> creating a local RADIUS server which authenticates the client's
> otp-value (which could just be a password) against a third-party
> service.  The two caveats are (1) you must deploy FAST on the client to
> protect the communication between the client and KDC, and (2) this
> preauth mechanism is only implemented by MIT krb5 clients, not Microsoft
> or Heimdal.
>