How do I not set Auth-Type?
Hello all, I have a configuration where I allow users to get onto the wireless network by authenticating with EAP-TLS or with EAP-GTC inside of EAP-TTLS. If they have a cert, then they authenticate with EAP-TLS, and if they have a password, then they authenticate with EAP-TTLS/EAP-GTC which in turn authenticates against Kerberos. In addition, there are some admins who need to log into the access point's command shell. I would like these to be authenticated against the same Kerberos server, but everyone else should get rejected. As it turns out, I have a configuration that accomplishes all of this *perfectly*. In radiusd.conf, I have: modules { ... krb5 { } ... } ... authenticate { ... Auth-Type Kerberos { krb5 } ... } Then, in the users file, I have: "admin1" NAS-Port-Type == "Virtual", Auth-Type = Kerberos "admin2" NAS-Port-Type == "Virtual", Auth-Type = Kerberos ... DEFAULT NAS-Port-Type == "Virtual", Auth-Type := Reject # This authenticates wireless users DEFAULT NAS-Port-Type == "Wireless-802.11", Auth-Type = Kerberos I should stress, this accomplishes *exactly* what I want. That said, it also involves explicit setting of Auth-Type. I have seen in more than one place that this is a Bad Thing(TM). My first question is how do I accomplish what the above configuration does without this explicit Auth-Type setting? (Or is the above configuration marginally acceptable because it only sets Auth-Type when it isn't already set?) Should I only be defining one authentication module that involves User-PAssword? More generally, suppose that you have two different authentication modules, say unix and krb5, that use User-Password. How does FreeRADIUS tell which users are supposed to use unix and which are supposed to use krb5? (Assuming that you want some to use one, and some to use the other.) That is, how does RADIUS know what the "right thing" is in that case with being told explicitly? Thanks in advance. P.S. Before anyone says anything, I have read the documentation. More than once. It could very easily be that I have missed something totally obvious though. -- John Guthrie guthrie@counterexample.org
John T. Guthrie wrote:
As it turns out, I have a configuration that accomplishes all of this *perfectly*.
If it works...
I should stress, this accomplishes *exactly* what I want. That said, it also involves explicit setting of Auth-Type. I have seen in more than one place that this is a Bad Thing(TM).
It's a bad thing because 90% or more of the times people set Auth-Type, they get it wrong. It's easiest to have a blanket statement saying "Don't do that". And your configuration could be made simpler. You seem to always set Auth-Type = Kerberos, so that only needs to be set once, not for every user. Then, if you have a number of admins, the rules should be *role* based, not *name* based. i.e. use rlm_passwd to create an "admin" group, and then do: DEFAULT NAS-Port-Type == "Virtual", Local-Group != "admin", Auth-Type := Reject
My first question is how do I accomplish what the above configuration does without this explicit Auth-Type setting?
You probably don't.
(Or is the above configuration marginally acceptable because it only sets Auth-Type when it isn't already set?) Should I only be defining one authentication module that involves User-PAssword?
Yes, and no.
More generally, suppose that you have two different authentication modules, say unix and krb5, that use User-Password. How does FreeRADIUS tell which users are supposed to use unix and which are supposed to use krb5?
In the CVS head (which has been fixed), the "unix" module no longer authenticates anyone. Instead, it looks users up in /etc/passwd, and adds "Crypt-Password" to the config items. Then, rlm_pap authenticates them. This is *much* more flexible.
(Assuming that you want some to use one, and some to use the other.) That is, how does RADIUS know what the "right thing" is in that case with being told explicitly?
RADIUS doesn't know how to do the "right thing", FreeRADIUS does, because we've put a lot of work into making it smart. :) In most cases, the choice of authentication protocols is simple: Look in the Access-Request packet... it's requesting a particular authentication protocol. So setting the authentication to any *other* method means that authentication will fail. When finding the authentication *credentials* (i.e. password, etc.), it's also usually pretty easy. Look up the user in /etc/passwd, or LDAP, or whatever. If the user is found, take the credentials from there, and associate them with the request. Then, you have an authentication protocol, and authentication credentials, so knowing what to do for the act of authentication is simple. The confusion comes when people misconstrue back-ends for authentication protocols. i.e. doing EAP to an LDAP server. It gets more complicated when using something like Kerberos, which does not supply authentication credentials. Instead, Kerberos is an "oracle" http://deployingradius.com/documents/protocols/oracles.html i.e. in a certain sense, you're proxying the authentication request to the Kerberos server. So it's a very different manner of setting Auth-Type than forcing LDAP when the Access-Request contains EAP.
P.S. Before anyone says anything, I have read the documentation. More than once. It could very easily be that I have missed something totally obvious though.
I'll try to clarify this in my book. In addition, if anyone can figure out a clear way to configure this in the server, I'd like to know... Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Fri, 2007-03-16 at 09:40 +0100, Alan DeKok wrote:
John T. Guthrie wrote:
As it turns out, I have a configuration that accomplishes all of this *perfectly*.
If it works...
Well, it's been doing what I want it to do for about 7+ months, so I'd say that qualifies as working. ;-) Now granted, its expansion capabilities could very easily limited...
I should stress, this accomplishes *exactly* what I want. That said, it also involves explicit setting of Auth-Type. I have seen in more than one place that this is a Bad Thing(TM).
It's a bad thing because 90% or more of the times people set Auth-Type, they get it wrong. It's easiest to have a blanket statement saying "Don't do that".
And your configuration could be made simpler. You seem to always set
I agree with this completely.
Auth-Type = Kerberos, so that only needs to be set once, not for every user. Then, if you have a number of admins, the rules should be *role* based, not *name* based. i.e. use rlm_passwd to create an "admin" group, and then do:
DEFAULT NAS-Port-Type == "Virtual", Local-Group != "admin", Auth-Type := Reject
Thank you very much! This will go a long ways toward helping me clean up my config.
My first question is how do I accomplish what the above configuration does without this explicit Auth-Type setting?
You probably don't.
(Or is the above configuration marginally acceptable because it only sets Auth-Type when it isn't already set?) Should I only be defining one authentication module that involves User-PAssword?
Yes, and no.
More generally, suppose that you have two different authentication modules, say unix and krb5, that use User-Password. How does FreeRADIUS tell which users are supposed to use unix and which are supposed to use krb5?
In the CVS head (which has been fixed), the "unix" module no longer authenticates anyone. Instead, it looks users up in /etc/passwd, and adds "Crypt-Password" to the config items. Then, rlm_pap authenticates them. This is *much* more flexible.
(Assuming that you want some to use one, and some to use the other.) That is, how does RADIUS know what the "right thing" is in that case with being told explicitly?
RADIUS doesn't know how to do the "right thing", FreeRADIUS does, because we've put a lot of work into making it smart. :)
Fair enough. ;-)
In most cases, the choice of authentication protocols is simple: Look in the Access-Request packet... it's requesting a particular authentication protocol. So setting the authentication to any *other* method means that authentication will fail.
When finding the authentication *credentials* (i.e. password, etc.), it's also usually pretty easy. Look up the user in /etc/passwd, or LDAP, or whatever. If the user is found, take the credentials from there, and associate them with the request.
Then, you have an authentication protocol, and authentication credentials, so knowing what to do for the act of authentication is simple.
The confusion comes when people misconstrue back-ends for authentication protocols. i.e. doing EAP to an LDAP server. It gets more complicated when using something like Kerberos, which does not supply authentication credentials. Instead, Kerberos is an "oracle"
http://deployingradius.com/documents/protocols/oracles.html
i.e. in a certain sense, you're proxying the authentication request to the Kerberos server. So it's a very different manner of setting Auth-Type than forcing LDAP when the Access-Request contains EAP.
P.S. Before anyone says anything, I have read the documentation. More than once. It could very easily be that I have missed something totally obvious though.
I'll try to clarify this in my book.
So are you saying that FreeRADIUS sometimes needs some assistance when dealing with authentication oracles? That is, it needs to be told when to use them? Moreover, is the problem in this case how to tell FreeRADIUS about that without setting an explicit Auth-Type? From what you said above, it seems that is not likely. This would seem to agree with what I've found in experimentation, namely take the configuration in the users file: "user1" If I try to use the command (assuming the password for user1 is "pass_for_user1"): radtest user1 pass_for_user1 radius_server 17 radius_secret Then radiusd -X complains: auth: No authenticate method (Auth-Type) configuration found for the request: Rejecting the user auth: Failed to validate the user. Login incorrect: [user1] (from client net_tester port 17) (I have similar issues with the access point. Namely, it does not set Auth-Type.) However, it works if I use something like: "user1" Auth-Type = Kerberos (Note that I did not use Auth-Type := Kerberos.)
In addition, if anyone can figure out a clear way to configure this in the server, I'd like to know...
I would love to help out with this if at all possible. Thanks again for all of your help. -- John Guthrie guthrie@counterexample.org
John T. Guthrie wrote:
So are you saying that FreeRADIUS sometimes needs some assistance when dealing with authentication oracles? That is, it needs to be told when to use them?
Yes. The oracles are things like Kerberos, Active Directory, or a proxying to another RADIUS server. There is nothing in the RADIUS Access-Request that tells the server to use an oracle. There is nothing in a DB that tells the server how to authenticate the user. So the server has to be explicitly told "use this oracle".
Moreover, is the problem in this case how to tell FreeRADIUS about that without setting an explicit Auth-Type? From what you said above, it seems that is not likely.
Yes. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Alan DeKok wrote:
In addition, if anyone can figure out a clear way to configure this in the server, I'd like to know...
How about a config item like so: username Pap-Auth-DelegateTo := "moduleinstancename" and make rlm_pap the ONLY valid option in authorize/authenticate. rlm_pap, when called in authenticate, checks if the config item is set. If so, it finds the given module instance and passes the authenticate request to it. Many of the "oracles" (nice name) need little or no code to be executed in authorize. LDAP is about the only one I can think of. I could see this having real use in other situations - it would obviate the need for Autz-Type in some "merger" situations.
Phil Mayers wrote:
How about a config item like so:
username Pap-Auth-DelegateTo := "moduleinstancename"
and make rlm_pap the ONLY valid option in authorize/authenticate.
rlm_pap, when called in authenticate, checks if the config item is set. If so, it finds the given module instance and passes the authenticate request to it.
Hmm... I'm not so sure.
Many of the "oracles" (nice name) need little or no code to be executed in authorize. LDAP is about the only one I can think of.
Yes. But even with LDAP, you can configure LDAP bind without doing user lookups in LDAP. I'll think about it some more. A good solution is difficult to come up with.
I could see this having real use in other situations - it would obviate the need for Autz-Type in some "merger" situations.
I'm not sure what you mean by that. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Alan DeKok wrote:
Phil Mayers wrote:
How about a config item like so:
username Pap-Auth-DelegateTo := "moduleinstancename"
and make rlm_pap the ONLY valid option in authorize/authenticate.
rlm_pap, when called in authenticate, checks if the config item is set. If so, it finds the given module instance and passes the authenticate request to it.
Hmm... I'm not so sure.
Well, just a thought.
Many of the "oracles" (nice name) need little or no code to be executed in authorize. LDAP is about the only one I can think of.
Yes. But even with LDAP, you can configure LDAP bind without doing user lookups in LDAP.
I'll think about it some more. A good solution is difficult to come up with.
Indeed
I could see this having real use in other situations - it would obviate the need for Autz-Type in some "merger" situations.
I'm not sure what you mean by that.
Ignore that. I meant "Auth-Type".
participants (3)
-
Alan DeKok -
John T. Guthrie -
Phil Mayers