[Samba] OTP authentication

the2nd at otpme.org the2nd at otpme.org
Mon Jan 26 05:42:57 MST 2015

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. :)

>> 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.

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? :)

>> 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.

i thought samba/winbind does something like this when samba is 
configured as a domain member (security=domain)?


More information about the samba-technical mailing list