Re: [Freeipa-users] 2FA and AllowNTHash

2017-01-05 Thread Brian Candler

On 05/01/2017 10:57, Maciej Drobniuch wrote:

Maybe I'll paraphrase the question.

It would suffice if I could tell IPA to use pass+otp only instead of 
both (Password+ pass+otp) for particular hosts.

So for example users from hosts X can login with OTP only.

Sorry, I don't understand that.  What are the two passwords you refer 
to, when you say "Password + pass+otp"?


Can you give an example of the type of exchange that goes on now, and 
what you would like it to do instead?


-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] 2FA and AllowNTHash

2017-01-05 Thread Maciej Drobniuch
Hi Brian

Thank You for your answer.
It started working, not sure yet why it did not work. I need to do some
extensive testing.

So, I've actually followed the blogposts you've mentioned to setup
ipanthash + freeradius.

Maybe I'll paraphrase the question.

It would suffice if I could tell IPA to use pass+otp only instead of both
(Password+ pass+otp) for particular hosts.
So for example users from hosts X can login with OTP only.

Thanks for help!

On Tue, Jan 3, 2017 at 7:02 PM, Brian Candler  wrote:

> On 03/01/2017 15:28, Maciej Drobniuch wrote:
>
>> We have a topo with 3x IPA servers + freeradius.
>>
>> Freeradius is being used to do mschap with wifi APs. Freeradius connects
>> over ldap to IPA.
>>
>> In order to do the challange-response thing, freeipa has AllowNTHash
>> enabled.
>>
>> So I wanted to enable 2FA/OTP but leave the NTHash as is for wifi auth.
>>
>> In the moment I disallow Password auth for a user and enable OTP the wifi
>> auth stopps working, but the hash clearly stays in ldap.
>>
> How are you actually authenticating the user? Are you just reading the
> ipaNTHash out of the LDAP database and letting FreeRADIUS check it? Then
> AFAICS it shouldn't make any different whether OTP is enabled or not.  Can
> you show more of your RADIUS config, and the debug output from the part
> which authenticates the user?
>
> I don't use OTP myself, but I wouldn't expect the ipaNTHash to change
> depending on whether OTP is enabled or not (and you're saying the hash
> stays put).
>
> I have what sounds like a similar setup to yours, using FreeRADIUS 3.0.12
> talking to FreeIPA 4.4.0, using a service user which has permissions to
> read out the ipaNTHash directly, based on this blog post:
> http://firstyear.id.au/blog/html/2015/07/06/FreeIPA:_Giving_
> permissions_to_service_accounts..html
>
> ldap config:
>
> base_dn = 'cn=users,cn=accounts,dc=ipa,dc=example,dc=com'
>
> sasl {
> mech = 'GSSAPI'
> realm = 'IPA.EXAMPLE.COM'
> }
>
> update {
> control:NT-Password := 'ipaNTHash'
> control:Tmp-String-9:= 'krbPasswordExpiration'
> }
>
> user {
> base_dn = "${..base_dn}"
> filter = "(uid=%{%{Stripped-User-Name}:-%{User-Name}})"
> scope = "one"
> }
>
> group {
> membership_attribute = 'memberOf'
> name_attributes = 'cn'
>
> cacheable_dn = 'yes'
> cacheable_name = 'no'
> }
>
> default and inner-tunnel authentication is then just:
>
> authenticate {
> Auth-Type PAP {
> pap
> }
>
> Auth-Type MS-CHAP {
> mschap
> }
>
> eap
> }
>
> Also you need to put the service user's keytab somewhere, and set a couple
> of environment variables when it starts, if you want to use Kerberos to
> protect the LDAP connection. Using systemd override:
>
> [Unit]
> Requires=dirsrv.target
> After=dirsrv.target
>
> [Service]
> Environment=KRB5_CLIENT_KTNAME=/etc/radiusd.keytab
> Environment=KRB5CCNAME=MEMORY:
> Restart=always
> RestartSec=5
>
> (Otherwise you can bind with a specific dn and password, but then you also
> need to sort out TLS to secure the LDAP traffic)
>
> There is more magic you can do with the krbPasswordExpiration attribute to
> force the user to do a password change over MSCHAP - but that's now
> straying a long way from what's relevant on a FreeIPA mailing list.
>
> HTH,
>
> Brian.
>



-- 
Best regards

Maciej Drobniuch
Network Security Engineer
Collective-Sense,LLC
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] 2FA and AllowNTHash

2017-01-03 Thread Brian Candler

On 03/01/2017 15:28, Maciej Drobniuch wrote:

We have a topo with 3x IPA servers + freeradius.

Freeradius is being used to do mschap with wifi APs. Freeradius 
connects over ldap to IPA.


In order to do the challange-response thing, freeipa has AllowNTHash 
enabled.


So I wanted to enable 2FA/OTP but leave the NTHash as is for wifi auth.

In the moment I disallow Password auth for a user and enable OTP the 
wifi auth stopps working, but the hash clearly stays in ldap.
How are you actually authenticating the user? Are you just reading the 
ipaNTHash out of the LDAP database and letting FreeRADIUS check it? Then 
AFAICS it shouldn't make any different whether OTP is enabled or not.  
Can you show more of your RADIUS config, and the debug output from the 
part which authenticates the user?


I don't use OTP myself, but I wouldn't expect the ipaNTHash to change 
depending on whether OTP is enabled or not (and you're saying the hash 
stays put).


I have what sounds like a similar setup to yours, using FreeRADIUS 
3.0.12 talking to FreeIPA 4.4.0, using a service user which has 
permissions to read out the ipaNTHash directly, based on this blog post:

http://firstyear.id.au/blog/html/2015/07/06/FreeIPA:_Giving_permissions_to_service_accounts..html

ldap config:

base_dn = 'cn=users,cn=accounts,dc=ipa,dc=example,dc=com'

sasl {
mech = 'GSSAPI'
realm = 'IPA.EXAMPLE.COM'
}

update {
control:NT-Password := 'ipaNTHash'
control:Tmp-String-9:= 'krbPasswordExpiration'
}

user {
base_dn = "${..base_dn}"
filter = "(uid=%{%{Stripped-User-Name}:-%{User-Name}})"
scope = "one"
}

group {
membership_attribute = 'memberOf'
name_attributes = 'cn'

cacheable_dn = 'yes'
cacheable_name = 'no'
}

default and inner-tunnel authentication is then just:

authenticate {
Auth-Type PAP {
pap
}

Auth-Type MS-CHAP {
mschap
}

eap
}

Also you need to put the service user's keytab somewhere, and set a 
couple of environment variables when it starts, if you want to use 
Kerberos to protect the LDAP connection. Using systemd override:


[Unit]
Requires=dirsrv.target
After=dirsrv.target

[Service]
Environment=KRB5_CLIENT_KTNAME=/etc/radiusd.keytab
Environment=KRB5CCNAME=MEMORY:
Restart=always
RestartSec=5

(Otherwise you can bind with a specific dn and password, but then you 
also need to sort out TLS to secure the LDAP traffic)


There is more magic you can do with the krbPasswordExpiration attribute 
to force the user to do a password change over MSCHAP - but that's now 
straying a long way from what's relevant on a FreeIPA mailing list.


HTH,

Brian.

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project


[Freeipa-users] 2FA and AllowNTHash

2017-01-03 Thread Maciej Drobniuch
Hi All,

We have a topo with 3x IPA servers + freeradius.

Freeradius is being used to do mschap with wifi APs. Freeradius connects
over ldap to IPA.

In order to do the challange-response thing, freeipa has AllowNTHash
enabled.

So I wanted to enable 2FA/OTP but leave the NTHash as is for wifi auth.

In the moment I disallow Password auth for a user and enable OTP the wifi
auth stopps working, but the hash clearly stays in ldap.

The goal is to stay with password on freeradius but for everything else:
kerberos/sssd related use password+code.

How can I disable password login for user but still make freeradius work
with ldap, so when it asks for users hash it gets one.

Freeradius ldap mod snippet:
"base_dn = "cn=users,cn=accounts,dc=cs,dc=com""

Thank You

-- 
Best regards

Maciej Drobniuch
Network Security Engineer
Collective-Sense,LLC
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project