[Samba] OTP authentication

[Alexander Bokovoy]

On Thu, Jan 22, 2015 at 5:20 PM,  <the2nd at otpme.org> wrote:
> On 2015-01-21 08:21, Alexander Bokovoy wrote:
>> Getting back to Samba -- domain environment means machines are joined to
>> the
>> domain and thus all have host/<fqdn> keys which can and in my opinion
>> should be used.
>
>
>
> but this is not supported by windows, i guess?
No, it is not, at least yet.

>> You need to find out if Heimdal supports this communication. In case
>> of MIT Kerberos both server and client sides have ability to plug into
>> preauth processing. In addition, MIT Kerberos client side since 1.11
>> has special API for preauth conversation as different preauth
>> algorithms require different data, some of which might require
>> interactivity with the user.
>>
>> As far as I can see, existing Heimdal has old otp implementation which
>> uses internal database to store secrets. This code is not in the
>> Heimdal version integrated in Samba. Client side of Heimdal doesn't
>> support RFC6560 yet (nor server side) so there is a possiblity only to
>> go with something similar to what Microsoft did, i.e. overriding how a
>> credentials provider works. Or complete OTP code in Heimdal.
>
>
> talking about samba 4 with kerberos and windows clients, do you know what
> preauth type is used when using standard auth with static passwords?
Timestamp preauth is always there nowadays.
You can easily check yourself with Wireshark.

> i personally would prefer a solution where no changes are needed on the
> client side. if it would be possible to hand over the preauth data to a
> third party tool for verification, like i described previously,there where
> no need to transmit the otp from the client to samba/kdc. the third party
> tool just needs to return the valid otp to the kdc. there would also be no
> reason to implement all otp types and features in the kdc. there are already
> working otp solutions, commercial and open source.
On Windows side there is a possibility in the same way as Microsoft
did. However, that would exclude otpme as you need changes to
Credentials Provider. So that means a replacement to Credentials
Provider and as result changes to the client. I don't think you want
to replace Credentials Provider, though.

>
> yesterday i asked on the freeradius mailing list if it would be possible to
> use a radius request/response for otp verification (via preauth data) and
> returning of the valid otp.
>
> http://freeradius.1045715.n5.nabble.com/encrypted-response-parameter-td5731415.html
>
> it looks like this would be possible as there is an response attribute
> "Tunnel-Password" which is encrypted.
Well, that's correct. Your problem is that of a client side auth which
is controlled by a separate piece that otpme isn't controlling
(Credentials Provider in Windows).

> however, implementing most of this is out of my scope as i dont have the
> (coding) skills to do it. ;)
>
> so it depens on, if there is someone else who is willing to implement it.
> but i think many admins would be happy if it would be possible to use OTPs
> without the need for any client changes.
> and i also think that at least other open source projects like privacyidea
> would be happy to add support for this.
If somebody would get interested in it on Heimdal side, it would most
likely be something that is going to be on RFC6560 tune and compatible
with MIT implementation. I'm not seeing this coming soon though.


> my perfect setup would look like this:
> - setup freeradius with an tool like otpme that knows how to verify preauth
> data
> - configure samba/kdc to send preauth data via a radius request to this
> server and get back the clear text otp over an secure channel
>
> using radius would also be nice because i guess it could also be used in
> samba3 environments where no kerberos is envolved. i'm not sure about this
> but i guess it should be possible that samba3 sends an mschap/ntlm request
> via radius when a user logs in?
Samba does not do it. NTLM is performed by Samba itself so it needs NT
hash to complete it. FreeRADIUS integration is usually the other way
around -- things are stored in LDAP and used by both Samba and
FreeRADIUS, not that they delegated by Samba to a RADIUS server.

-- 
/ Alexander Bokovoy