[Samba] OTP authentication

[Alexander Bokovoy]

On Mon, Jan 26, 2015 at 2:42 PM,  <the2nd at otpme.org> wrote:
> On 2015-01-26 02:20, Alexander Bokovoy wrote:
>>
>> 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.
>>
>
> correct. i dont think that we need any changes to the login screen because
> the otp will not be an additional thing to input on login.
> the otp should _replace_ the static password.
>
> i'm aware of that this might only work if samba is the logon server but
> thats what i want to accomplish. i dont care about windows server
> environments. :)
If you are not replacing Credential Provider, you are not affecting in
any way how Kerberos exchange happens on logon on the client side. The
only difference would be that Credential Provider would use your otp
sequence to encrypt the message sent to the KDC and KDC wouldn't know
how to decrypt it as it wouldn't know it is OTP rather than password.


>> 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.
>>
>
> i agree that its better to implement a feature using (open) standards.
>
> but i also think its not a bad idea to implement something within an open
> source project (e.g. samba or heimdal) that fixes an important gap (missing
> strong two factor auth for windows clients with samba, which is easy to
> implement for the admin).
>
> what i really would like to know is, how much work it would be to implement
> what i've described (preauth data hand over via radius).
>
> i may be wrong but i guess it will not be too complicated? :)
In order to tell KDC that client sent an OTP sequence, you need to
change how client communicates. This means a change of Credential
Provider on the Windows client machine.
You can read more about how this could be done here:
https://msdn.microsoft.com/en-us/magazine/cc163489.aspx

>> 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.
>
>
> i thought samba/winbind does something like this when samba is configured as
> a domain member (security=domain)?
Something like what? Samba is not authenticating off a RADIUS at all.


-- 
/ Alexander Bokovoy