[19400] in Kerberos_V5_Development

home help back first fref pref prev next nref lref last post

Re: Implementing a KDB plugin

daemon@ATHENA.MIT.EDU (Greg Hudson)
Thu May 5 15:42:00 2016

To: harsh savla <harsh.savla@gmail.com>, krbdev@mit.edu
From: Greg Hudson <ghudson@mit.edu>
Message-ID: <572BA1FF.7070004@mit.edu>
Date: Thu, 5 May 2016 15:41:51 -0400
MIME-Version: 1.0
In-Reply-To: <CACbP_Kb0qdbxUcD4BF0braRUqEbMaU7-kaAUYApgsQE539YuEw@mail.gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu

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.
_______________________________________________
krbdev mailing list             krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

home help back first fref pref prev next nref lref last post