[Samba] OTP authentication
the2nd at otpme.org
the2nd at otpme.org
Tue Jan 20 09:55:15 MST 2015
On 2015-01-20 12:29, Alexander Bokovoy wrote:
> On Tue, Jan 20, 2015 at 1:03 PM, <the2nd at otpme.org> wrote:
>> On 2015-01-20 02:18, Andrew Bartlett wrote:
>>> On Wed, 2015-01-14 at 17:53 +0100, the2nd at otpme.org wrote:
>>>> it's not a certain project that i need this for. its a general
>>>> if this would be possible. i think OTPs are a good idea, also for
>>>> windows logins.
>>>> maybe some of the samba devs can shed some light on this?
>>> I'm seeing some work in upstream Heimdal, mirroring work being done
>>> the Kerberos standards community for this kind of thing.
>>> If your two-factor is a smart-card, then this is all OK - you can
>>> already use a smart card to log into Samba. Likewise, if you can
>>> a device that appears to be a smart card to windows (perhaps using a
>>> backchannel to get short-term certificates), but unlocks with a OTP,
>>> then you could use that.
>>> However, I've not seen anything that lets you use this at the
>>> login screen. If you can on the server-side, predict what the
>>> OTP will be, then we have a better chance (we can just generate the
>>> 'keys' on a just-in-time basis in our KDC plugin), but otherwise we
>>> to do whatever the Microsoft GUI allows.
>>> If your clients are not Windows, then things get more flexible, as we
>>> could hook into the standard OTP support being added.
>>> I'm very interested in this area, and would love for Samba to be the
>>> very best it can be in supporting improved security like this.
>>> Andrew Bartlett
>> Thanks for the explanation. OTPme (the tool i'm currently writing:
>> http://www.otpme.org) supports motp (http://motp.sf.net) as
>> One-Time-Password tokens.
>> The design of motp allows the server side to generate a list of OTPs
>> (for a
>> given time range) that could be used to verify the authentication
>> E.g. for ntlm requests OTPme just generates a "response" for each OTP
>> the list and checks it against the response from the request.
>> Some time ago i read something about using OTPs with kerberos
>> preauthentication data. If i remember correctly preauthentication data
>> was a
>> string (e.g. timestamp) encrypted with the users key/OTP.
> Timestamp preauth is a norm in Kerberos environments now.
> With MIT Kerberos 1.11 we have now client-side support for OTP
> Preauth, as described in RFC 6560. In MIT Kerberos 1.12 a server-side
> support to have FAST OTP preauth that does OTP validation via RADIUS
> protocol was added, we use it in FreeIPA with a local helper that
> redirects validation requests from KDC to LDAP server bind requests
> and LDAP server handles OTP auth method. Works very well.
> You can read more at
> http://k5wiki.kerberos.org/wiki/Projects/OTPOverRADIUS and
> It would be nice if Heimdal would support RFC 6560 as it was supposed
> in the original case of the work done Linus Nordberg which became OTP
> support in MIT Kerberos. People asked this several times but I guess
> the key part, as usual, is how to carve out required time for doing
thanks for the infos. i must admit that my knowledge of kerberos is not
very deep but i'll try to read AND understand the RFCs :)
maybe you can give me some hints.
as far as i know in non-otp setups, kerberos works without transmitting
the clear-text password.
- client send preauth info (timestamp encrypted with the user password)
to the server.
- server verifies preauth info and sends tgt (encrypted with the user
password) to user/client.
- tgt can be used to get service tickets without re-auth with
- service tickets consist of two copies of the "session key". one
encrypted with the password/key of the requested service (e.g. ldap) and
one encrypted with the users password/key
- user/client decrypts service key and creates a new "packet" that is
crypted with the service key and contains a timestamp
- service (e.g. ldap) receives both "packets" from the client/user and
decrypts the packet that contains the "session key" (which is encrypted
with its own service key)
- service decrypts the second "packet" that contains a timestamp (which
is encrypted with the session key)
that's what i've learned some time ago reading some howtos. not the
right terminology and not in the very detail but i guess in general
thats how it works?
please correct me if i'm wrong. :)
maybe you can describe shorthand how otp preauth works with kerberos? i
guess the otp needs to be transmitted to the kerberos server as you talk
about validation via radius?
More information about the samba-technical