Re: [Freeipa-users] freeipa radius cisco

2013-01-18 Thread John Dennis 

On 01/18/2013 10:13 AM, John Dennis wrote:

On 01/18/2013 09:31 AM, Han Boetes wrote:

In the users file
DEFAULT Auth-Type = Kerberos
  Service-Type = NAS-Prompt-User, cisco-avpair = "shell:priv-lvl=15"


Be careful!

It's almost never a good idea to set the Auth-Type in the user config.
Why? Because normally the server figures out the best Auth-Type to use
for a given Auth-Request based on the contents of the Auth-Request
packet. The contents of the Auth-Request packet depends exclusively on
the configuration of the user's device, something you typically do not
have control over (think of random user trying to connect with unknown
device).

The FR server figures out which Auth-Type to use based on it's
configuration and set of policy rules, all of which you can write.

The problem comes when a user sends an Auth-Request whose contents does
not math the Auth-Type you've forced on them, then things will
completely *fail*.

Using DEFAULT for the Auth-Type is even a more pernicious problem
because you're saying apply this to everyone that lands in the default
category.

There are a few Auth-Type's the server can't figure out on it's own,
kerberos is one of them (because fundamentally it's no different than
pap in terms of what the client sends). There are a number of approaches
one can take to address this issue via policy configuration in the
server, but I'm sorry to say I don't have time to document and test all
those at the moment.

All I'm trying to say is what you've done above will work only in a very
constrained scenario, it is not a general solution. The FreeRADIUS list
is filled with folks attempts to force an Auth-Type in the users file
only to discover their woes.



Here are a couple of threads I found on the freeradius-users list which 
might be of help to you:


You should use a TLS tunnel with Kerberos auth because the user's 
password is sent in the request packet, this explains some of the issues 
with doing krb inside the inner tunnel of the server:


http://lists.freeradius.org/pipermail/freeradius-users/2011-February/051625.html

This is a how-to someone wrote up on using kerberos with FreeRADIUS, 
sorry I haven't read it to check for accuracy, but it might be helpful.


http://lists.freeradius.org/pipermail/freeradius-users/2012-December/064375.html

--
John Dennis 

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] freeipa radius cisco

2013-01-18 Thread John Dennis 

On 01/18/2013 09:31 AM, Han Boetes wrote:

In the users file
DEFAULT Auth-Type = Kerberos
 Service-Type = NAS-Prompt-User, cisco-avpair = "shell:priv-lvl=15"


Be careful!

It's almost never a good idea to set the Auth-Type in the user config. 
Why? Because normally the server figures out the best Auth-Type to use 
for a given Auth-Request based on the contents of the Auth-Request 
packet. The contents of the Auth-Request packet depends exclusively on 
the configuration of the user's device, something you typically do not 
have control over (think of random user trying to connect with unknown 
device).


The FR server figures out which Auth-Type to use based on it's 
configuration and set of policy rules, all of which you can write.


The problem comes when a user sends an Auth-Request whose contents does 
not math the Auth-Type you've forced on them, then things will 
completely *fail*.


Using DEFAULT for the Auth-Type is even a more pernicious problem 
because you're saying apply this to everyone that lands in the default 
category.


There are a few Auth-Type's the server can't figure out on it's own, 
kerberos is one of them (because fundamentally it's no different than 
pap in terms of what the client sends). There are a number of approaches 
one can take to address this issue via policy configuration in the 
server, but I'm sorry to say I don't have time to document and test all 
those at the moment.


All I'm trying to say is what you've done above will work only in a very 
constrained scenario, it is not a general solution. The FreeRADIUS list 
is filled with folks attempts to force an Auth-Type in the users file 
only to discover their woes.


--
John Dennis 

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] freeipa radius cisco

2013-01-18 Thread Han Boetes 
I've got it running. Of course you shouldn't expect passwordless logins to
work but it's much better than having everyone knowing the passwords.

The document that helped me setting up the cisco part was this one:

http://wiki.freeradius.org/vendor/Cisco

And the magic to add to the configfiles:

In client.conf; somerandompass is also used in the cisco config.

client 192.168.2.0/16 {
secret= somerandompass
shortname = someshortname
nastype  = cisco
}

And in the file users; the last line throws users directly to the "root"
shell:

DEFAULT Auth-Type = Kerberos
Service-Type = NAS-Prompt-User, cisco-avpair = "shell:priv-lvl=15"



Now all I have to figure out is how to set up using eap-tls. The relevant
log-message is:

[eap] No EAP-Message, not doing EAP
++[eap] returns noop
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] freeipa radius cisco

2013-01-16 Thread Dmitri Pal 
On 01/16/2013 11:44 AM, Han Boetes wrote:
> This might be somewhat off-topic but I'll ask anyway.
>
> First my questions:
>
> How do I get the cisco device -- a 3750 with the latest software image
> -- to use EAP-TTLS and what am I missing for the rest.

My memory about all this is a bit rusty. I was hoping that latest cisco
switches support EAP-TTLS but it does not seem to be the case.
It seems that it supports EAP-TLS that might be as good.
You effectively need to fins a tunneling protocol that both ends i.e
switch and radius server support.
You would have to match  docs on the two.
The protocols you are looking for are EAP-TTLS, PEAP.
As far as I remember EAP-TLS and LEAP might work to but I do not
remember the details so you need to do a bit of reading on those.

>
> I've set up radius to use kerberos: kerberos seems to like it when I
> log on with ssh on the cisco:
>
> Jan 16 17:33:34 auth-ipa.domain.at 
> krb5kdc[9251](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.2.74
> : NEEDED_PREAUTH: h...@domain.at for
> krbtgt/domain...@domain.at, Additional pre-authentication required
> Jan 16 17:33:34 auth-ipa.domain.at 
> krb5kdc[9251](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.2.74
> : ISSUE: authtime 1358354014, etypes {rep=18
> tkt=18 ses=18}, h...@domain.at for krbtgt/domain...@domain.at
>
> Allas radius does not.
>
> rad_recv: Access-Request packet from host 192.168.2.99 port 1645,
> id=14, length=91
> User-Name = "h...@realm.at "
> User-Password = "hidden"
> NAS-Port = 1
> NAS-Port-Id = "tty1"
> NAS-Port-Type = Virtual
> Calling-Station-Id = "192.168.2.73"
> NAS-IP-Address = 192.168.2.99
> # Executing section authorize from file /etc/raddb//sites-enabled/default
> +- entering group authorize {...}
> ++[preprocess] returns ok
> ++[chap] returns noop
> ++[mschap] returns noop
> ++[digest] returns noop
> [suffix] Looking up realm "REALM.AT " for User-Name =
> "h...@realm.at "
> [suffix] Found realm "REALM.AT "
> [suffix] Adding Stripped-User-Name = "hb"
> [suffix] Adding Realm = "REALM.AT "
> [suffix] Proxying request from user hb to realm REALM.AT 
> [suffix] Preparing to proxy authentication request to realm "REALM.AT
> " 
> ++[suffix] returns updated
> [eap] No EAP-Message, not doing EAP
> ++[eap] returns noop
> [files] users: Matched entry DEFAULT at line 206
> ++[files] returns ok
> ++[expiration] returns noop
> ++[logintime] returns noop
> ++[pap] returns noop
>   WARNING: Empty pre-proxy section.  Using default return values.
> Sending Access-Request of id 149 to 127.0.0.1 port 1812
> User-Name = "hb"
> User-Password = "hidden"
> NAS-Port = 1
> NAS-Port-Id = "tty1"
> NAS-Port-Type = Virtual
> Calling-Station-Id = "192.168.2.73"
> NAS-IP-Address = 192.168.2.99
> Message-Authenticator := 0x
> Proxy-State = 0x3134
> Proxying request 9 to home server 127.0.0.1 port 1812
> Sending Access-Request of id 149 to 127.0.0.1 port 1812
> User-Name = "hb"
> User-Password = "hidden"
> NAS-Port = 1
> NAS-Port-Id = "tty1"
> NAS-Port-Type = Virtual
> Calling-Station-Id = "192.168.2.73"
> NAS-IP-Address = 192.168.2.99
> Message-Authenticator := 0x
> Proxy-State = 0x3134
> Going to the next request
> Waking up in 0.9 seconds.
> rad_recv: Access-Request packet from host 127.0.0.1 port 1814, id=149,
> length=102
> User-Name = "hb"
> User-Password = "hidden"
> NAS-Port = 1
> NAS-Port-Id = "tty1"
> NAS-Port-Type = Virtual
> Calling-Station-Id = "192.168.2.73"
> NAS-IP-Address = 192.168.2.99
> Message-Authenticator = 0xf42c5bcf8d1c09945833967ce22f9690
> Proxy-State = 0x3134
> # Executing section authorize from file /etc/raddb//sites-enabled/default
> +- entering group authorize {...}
> ++[preprocess] returns ok
> ++[chap] returns noop
> ++[mschap] returns noop
> ++[digest] returns noop
> [suffix] No '@' in User-Name = "hb", looking up realm NULL
> [suffix] No such realm "NULL"
> ++[suffix] returns noop
> [eap] No EAP-Message, not doing EAP
> ++[eap] returns noop
> [files] users: Matched entry DEFAULT at line 206
> ++[files] returns ok
> ++[expiration] returns noop
> ++[logintime] returns noop
> [pap] WARNING! No "known good" password found for the user.
>  Authentication may fail because of this.
> ++[pap] returns noop
> Found Auth-Type = Kerberos
> # Executing group from file /etc/raddb//sites-enabled/default
> +- entering group Kerberos {...}
> rlm_krb5: [hb] krb5_sname_to_principal failed: Hostname cannot be
> canonicalized
> ++[krb5] returns reject
> Failed to authenticate the user.
> Using Post-Auth-Type Reject
> # Executing group from file /etc/raddb//sites-enabled/default
> +- entering group REJECT {...}
> [attr_filter.access_reject] expand: %{User-Name} -> hb
> attr_filter: Matched entry DEFAULT at line 11
> ++[attr_filter.acc

Re: [Freeipa-users] freeipa radius cisco

2013-01-16 Thread John Dennis 

On 01/16/2013 11:44 AM, Han Boetes wrote:

This might be somewhat off-topic but I'll ask anyway.

First my questions:

How do I get the cisco device -- a 3750 with the latest software image
-- to use EAP-TTLS and what am I missing for the rest.


Sorry, I can't help you with cisco configuration, maybe others can. But 
I can help with FreeRADIUS.



# Executing group from file /etc/raddb//sites-enabled/default
+- entering group Kerberos {...}
rlm_krb5: [hb] krb5_sname_to_principal failed: Hostname cannot be


It's failing because it's finding a bogus value for the service 
principal. This is configured in /etc/raddb/modules/krb5, by default it's


krb5 {
keytab = /path/to/keytab
service_principal = name_of_principle
}

How did you configure these?


--
John Dennis 

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] freeipa radius cisco

2013-01-16 Thread Simo Sorce 
On Wed, 2013-01-16 at 17:44 +0100, Han Boetes wrote:
> +- entering group Kerberos {...}
> rlm_krb5: [hb] krb5_sname_to_principal failed: Hostname cannot be
> canonicalized 

Something's wrong in your configuration

Probably the host name is not a fqdn or similar

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] freeipa radius cisco

2013-01-16 Thread Han Boetes 
This might be somewhat off-topic but I'll ask anyway.

First my questions:

How do I get the cisco device -- a 3750 with the latest software image --
to use EAP-TTLS and what am I missing for the rest.

I've set up radius to use kerberos: kerberos seems to like it when I log on
with ssh on the cisco:

Jan 16 17:33:34 auth-ipa.domain.at krb5kdc[9251](info): AS_REQ (4 etypes
{18 17 16 23}) 192.168.2.74: NEEDED_PREAUTH: h...@domain.at for
krbtgt/domain...@domain.at, Additional pre-authentication required
Jan 16 17:33:34 auth-ipa.domain.at krb5kdc[9251](info): AS_REQ (4 etypes
{18 17 16 23}) 192.168.2.74: ISSUE: authtime 1358354014, etypes {rep=18
tkt=18 ses=18}, h...@domain.at for krbtgt/domain...@domain.at

Allas radius does not.

rad_recv: Access-Request packet from host 192.168.2.99 port 1645, id=14,
length=91
User-Name = "h...@realm.at"
User-Password = "hidden"
NAS-Port = 1
NAS-Port-Id = "tty1"
NAS-Port-Type = Virtual
Calling-Station-Id = "192.168.2.73"
NAS-IP-Address = 192.168.2.99
# Executing section authorize from file /etc/raddb//sites-enabled/default
+- entering group authorize {...}
++[preprocess] returns ok
++[chap] returns noop
++[mschap] returns noop
++[digest] returns noop
[suffix] Looking up realm "REALM.AT" for User-Name = "h...@realm.at"
[suffix] Found realm "REALM.AT"
[suffix] Adding Stripped-User-Name = "hb"
[suffix] Adding Realm = "REALM.AT"
[suffix] Proxying request from user hb to realm REALM.AT
[suffix] Preparing to proxy authentication request to realm "REALM.AT"
++[suffix] returns updated
[eap] No EAP-Message, not doing EAP
++[eap] returns noop
[files] users: Matched entry DEFAULT at line 206
++[files] returns ok
++[expiration] returns noop
++[logintime] returns noop
++[pap] returns noop
  WARNING: Empty pre-proxy section.  Using default return values.
Sending Access-Request of id 149 to 127.0.0.1 port 1812
User-Name = "hb"
User-Password = "hidden"
NAS-Port = 1
NAS-Port-Id = "tty1"
NAS-Port-Type = Virtual
Calling-Station-Id = "192.168.2.73"
NAS-IP-Address = 192.168.2.99
Message-Authenticator := 0x
Proxy-State = 0x3134
Proxying request 9 to home server 127.0.0.1 port 1812
Sending Access-Request of id 149 to 127.0.0.1 port 1812
User-Name = "hb"
User-Password = "hidden"
NAS-Port = 1
NAS-Port-Id = "tty1"
NAS-Port-Type = Virtual
Calling-Station-Id = "192.168.2.73"
NAS-IP-Address = 192.168.2.99
Message-Authenticator := 0x
Proxy-State = 0x3134
Going to the next request
Waking up in 0.9 seconds.
rad_recv: Access-Request packet from host 127.0.0.1 port 1814, id=149,
length=102
User-Name = "hb"
User-Password = "hidden"
NAS-Port = 1
NAS-Port-Id = "tty1"
NAS-Port-Type = Virtual
Calling-Station-Id = "192.168.2.73"
NAS-IP-Address = 192.168.2.99
Message-Authenticator = 0xf42c5bcf8d1c09945833967ce22f9690
Proxy-State = 0x3134
# Executing section authorize from file /etc/raddb//sites-enabled/default
+- entering group authorize {...}
++[preprocess] returns ok
++[chap] returns noop
++[mschap] returns noop
++[digest] returns noop
[suffix] No '@' in User-Name = "hb", looking up realm NULL
[suffix] No such realm "NULL"
++[suffix] returns noop
[eap] No EAP-Message, not doing EAP
++[eap] returns noop
[files] users: Matched entry DEFAULT at line 206
++[files] returns ok
++[expiration] returns noop
++[logintime] returns noop
[pap] WARNING! No "known good" password found for the user.  Authentication
may fail because of this.
++[pap] returns noop
Found Auth-Type = Kerberos
# Executing group from file /etc/raddb//sites-enabled/default
+- entering group Kerberos {...}
rlm_krb5: [hb] krb5_sname_to_principal failed: Hostname cannot be
canonicalized
++[krb5] returns reject
Failed to authenticate the user.
Using Post-Auth-Type Reject
# Executing group from file /etc/raddb//sites-enabled/default
+- entering group REJECT {...}
[attr_filter.access_reject] expand: %{User-Name} -> hb
attr_filter: Matched entry DEFAULT at line 11
++[attr_filter.access_reject] returns updated
Delaying reject of request 10 for 1 seconds
Going to the next request
Waking up in 0.9 seconds.
Sending delayed reject for request 10
Sending Access-Reject of id 149 to 127.0.0.1 port 1814
Proxy-State = 0x3134
Waking up in 4.9 seconds.
rad_recv: Access-Reject packet from host 127.0.0.1 port 1812, id=149,
length=24
Proxy-State = 0x3134
# Executing section post-proxy from file /etc/raddb//sites-enabled/default
+- entering group post-proxy {...}
[eap] No pre-existing handler found
++[eap] returns noop
Using Post-Auth-Type Reject
# Executing group from file /etc/raddb//sites-enabled/default
+- entering group REJECT {...}
[attr_filter.access_reject] expand: %{User-Name} -> h...@realm.at
attr_filter: Matched entry DEFAULT at line 11
++[attr_filter.access_reject] returns updated
Sending Access-Reject of id 14 to 192.168.2.99 port 1645
Finished request 9.
Going to the next request
Waking up in 4.9 seconds.
Cleaning up request 10 ID 149 with timestamp +2998
Cleaning up request 9 ID 14 with timestamp

Re: [Freeipa-users] freeipa radius cisco

2013-01-15 Thread Dmitri Pal 
On 01/15/2013 11:09 AM, Simo Sorce wrote:
> On Tue, 2013-01-15 at 16:39 +0100, Han Boetes wrote:
>> Hi,
>>
>>
>> Since most of our cisco images do not support encryption the apparent
>> way to go is using radius which is supported by most  cisco devices.
>>
>>
>> What is the current status for making this wonderful idea work in the
>> real world.
>>
> We haven;t resumed work to integrate radius as a full feature component
> of FreeIPA yet, sorry.
>
> Simo.
>
But this does not mean that you can't use freeradius with LDAP, Kerberos
or PAM plugin.
You do not need to have integrated radius to get auth from IPA.
http://wiki.freeradius.org/modules/Rlm_ldap
http://wiki.freeradius.org/modules/Rlm_krb5
http://wiki.freeradius.org/modules/Rlm_pam

Just configure freeradius to use one of those authentication methods and
you can use it with freeIPA.
http://deployingradius.com/documents/protocols/oracles.html
We recommend to configure EAP-TTLS if your infrustucture supports it and
use PAP as an inner method.
If this is not possible you would have to use PAP so you need to use
pretty long secrets (i would say 20 bytes at least).
Keep in mind that not tunneled PAP is based on MD5 which would be a
problem if your environment needs to comply with different compliance
acts; tunneling would be a must.





-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] freeipa radius cisco

2013-01-15 Thread Simo Sorce 
On Tue, 2013-01-15 at 16:39 +0100, Han Boetes wrote:
> Hi,
> 
> 
> Since most of our cisco images do not support encryption the apparent
> way to go is using radius which is supported by most  cisco devices.
> 
> 
> What is the current status for making this wonderful idea work in the
> real world.
> 

We haven;t resumed work to integrate radius as a full feature component
of FreeIPA yet, sorry.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

[Freeipa-users] freeipa radius cisco

2013-01-15 Thread Han Boetes 
Hi,

Since most of our cisco images do not support encryption the apparent way
to go is using radius which is supported by most  cisco devices.

What is the current status for making this wonderful idea work in the real
world.

Thanks in advance.


# Han
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users