Kerberos (krb5) Module Overrides Other Authentication Types . . .
I've had the rlm_krb5 module running for a while now, with the line in the users file : ----- DEFAULT Auth-Type = Kerberos ----- I found that was the only way to get the rlm_krb5 module to actually fire, otherwise the krb5 module would never try to authenticate anyone. I'm now trying to add authentication from an SQL database. So, I have an appropriate tested setup for SQL, and the following in the radreply table : mysql> select * from radreply; +----+----------+--------------+----+------------+ | id | username | attribute | op | value | +----+----------+--------------+----+------------+ | 1 | mowglidb | Service-Type | := | Login-User | | 2 | mowglidb | Fall-Through | = | No | | 3 | mowglidb | Auth-Type | := | Accept | | 4 | mowglidb | Hint | := | SQL | +----+----------+--------------+----+------------+ 4 rows in set (0.00 sec) I've verified that both authentication types work properly, but what happens is that the Kerberos result is the only one ever used, despite the fact that the SQL result appears valid. So when you lookup an ID in the SQL table which is valid, the Kerberos lookup executes, doesn't find the ID, and sends a REJECT. Here's partial radiusd -X output showing the results of a query . . . ----- Ready to process requests. rad_recv: Access-Request packet from host 128.146.XXX.XXX port 1166, id=12, length=48 User-Name = "mowglidb" User-Password = "1234abcd" +- entering group authorize {...} ++[preprocess] returns ok [auth_log] expand: /var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d -> /var/log/radius/radacct/128.146.XXX.XXX/auth-detail-20100401 [auth_log] /var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /var/log/radius/radacct/128.146.XXX.XXX/auth-detail-20100401 [auth_log] expand: %t -> Thu Apr 1 00:38:53 2010 ++[auth_log] returns ok ++[chap] returns noop ++[mschap] returns noop [IPASS] No '/' in User-Name = "mowglidb", looking up realm NULL [IPASS] No such realm "NULL" ++[IPASS] returns noop [suffix] No '@' in User-Name = "mowglidb", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] No EAP-Message, not doing EAP ++[eap] returns noop ++[unix] returns notfound [files] users: Matched entry DEFAULT at line 210 ++[files] returns ok [sql] expand: %{User-Name} -> mowglidb [sql] sql_set_user escaped user --> 'mowglidb' rlm_sql (sql): Reserving sql socket id: 3 [sql] expand: SELECT id, username, attribute, value, op FROM radcheck WHERE username = '%{SQL-User-Name}' ORDER BY id -> SELECT id, username, attribute, value, op FRO M radcheck WHERE username = 'mowglidb' ORDER BY id rlm_sql_mysql: query: SELECT id, username, attribute, value, op FROM radcheck WHERE username = 'mowglidb' ORDER BY id [sql] User found in radcheck table [sql] expand: SELECT id, username, attribute, value, op FROM radreply WHERE username = '%{SQL-User-Name}' ORDER BY id -> SELECT id, username, attribute, value, op FRO M radreply WHERE username = 'mowglidb' ORDER BY id rlm_sql_mysql: query: SELECT id, username, attribute, value, op FROM radreply WHERE username = 'mowglidb' ORDER BY id [sql] expand: SELECT groupname FROM radusergroup WHERE username = '%{SQL-User-Name}' ORDER BY priority -> SELECT groupname FROM radusergroup WHERE username = 'mowglidb' ORDER BY priority rlm_sql_mysql: query: SELECT groupname FROM radusergroup WHERE username = 'mowglidb' ORDER BY priority rlm_sql (sql): Released sql socket id: 3 ++[sql] returns ok ++[expiration] returns noop ++[logintime] returns noop [pap] Found existing Auth-Type, not changing it. ++[pap] returns noop Found Auth-Type = Kerberos +- entering group Kerberos {...} rlm_krb5: [mowglidb] krb5_g_i_t_w_p failed: Client not found in Kerberos database ++[krb5] returns reject Failed to authenticate the user. Login incorrect: [mowglidb] (from client test port 0) Using Post-Auth-Type Reject +- entering group REJECT {...} [attr_filter.access_reject] expand: %{User-Name} -> mowglidb attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] returns updated Sending Access-Reject of id 12 to 128.146.XXX.XXX port 1166 Finished request 1. Going to the next request ----- I've tried varying what is in the users file, but so far my only results are either the SQL result is squashed by the Kerberos result, or the Kerberos section never attempts a lookup. In reading the attributes description, it implies that if I put the "Auth-Type = Kerberos" in the check section for the DEFAULT entry, it should only add this if there is no Auth-Type, but I'm not clear on when the items from the radreply table are added to the reply. Explicitly setting the Auth-Type in the SQL reply doesn't appear to affect anything - the Kerberos DEFAULT entry seems to simply override it. I've tried swapping the order of the sql & files attributes in the authenticate section, but that didn't work either : ----- ++[sql] returns ok [files] users: Matched entry DEFAULT at line 210 ++[files] returns ok ++[expiration] returns noop ++[logintime] returns noop [pap] Found existing Auth-Type, not changing it. ++[pap] returns noop Found Auth-Type = Kerberos +- entering group Kerberos {...} rlm_krb5: [mowglidb] krb5_g_i_t_w_p failed: Client not found in Kerberos database ++[krb5] returns reject Failed to authenticate the user. Login incorrect: [mowglidb] (from client test port 0) Using Post-Auth-Type Reject +- entering group REJECT {...} ----- And modifying the users file so that the entry reads : ----- DEFAULT Auth-Type = Kerberos ----- resulted in the krb5 module failing to fire at all, even though the files result did match the DEFAULT rule : ----- ++[chap] returns noop ++[mschap] returns noop [IPASS] No '/' in User-Name = "assor.3", looking up realm NULL [IPASS] No such realm "NULL" ++[IPASS] returns noop [suffix] No '@' in User-Name = "assor.3", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] No EAP-Message, not doing EAP ++[eap] returns noop ++[unix] returns notfound [files] users: Matched entry DEFAULT at line 210 ++[files] returns ok [sql] expand: %{User-Name} -> assor.3 [sql] sql_set_user escaped user --> 'assor.3' rlm_sql (sql): Reserving sql socket id: 3 [sql] expand: SELECT id, username, attribute, value, op FROM radcheck WHERE username = '%{SQL-User-Name}' ORDER BY id -> SELECT id, username, attribute, value, op FRO M radcheck WHERE username = 'assor.3' ORDER BY id rlm_sql_mysql: query: SELECT id, username, attribute, value, op FROM radcheck WHERE username = 'assor.3' ORDER BY id [sql] expand: SELECT groupname FROM radusergroup WHERE username = '%{SQL-User-Name}' ORDER BY priority -> SELECT groupname FROM radusergroup WHERE username = 'assor.3' ORDER BY priority rlm_sql_mysql: query: SELECT groupname FROM radusergroup WHERE username = 'assor.3' ORDER BY priority rlm_sql (sql): Released sql socket id: 3 [sql] User assor.3 not found ++[sql] returns notfound ++[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 No authenticate method (Auth-Type) configuration found for the request: Rejecting the user ----- The users file really only has the single DEFAULT rule in it, but let me know if seeing any of the other configuration files would help. Otherwise, I'd appreciate any help on getting the krb5 module to work with other authentication types. One other thing, it might be useful to add an "extended debugging" flag to the -X option, which shows you the reply table entries after each module, to allow tracking what sets what values. I haven't seen that mentioned in any documentation, but in my case that would at least allow me to answer the question of what reply entries get set where when. Thanks, <Mowgli> -- The Ohio State University Network Security Group | Mowgli Assor ---------------------------------------------------+-------------------------- E-mail : security@osu.edu | Network Security Engineer Web : http://www.infosec.ohio-state.edu | Office : (Use E-mail)
Mowgli Assor wrote:
I've had the rlm_krb5 module running for a while now, with the line in the users file : ... I found that was the only way to get the rlm_krb5 module to actually fire, otherwise the krb5 module would never try to authenticate anyone.
Yes. You have to tell the server when to use Kerberos authentication.
I'm now trying to add authentication from an SQL database. So, I have an appropriate tested setup for SQL, and the following in the radreply table :
mysql> select * from radreply; +----+----------+--------------+----+------------+ | id | username | attribute | op | value | +----+----------+--------------+----+------------+ | 1 | mowglidb | Service-Type | := | Login-User | | 2 | mowglidb | Fall-Through | = | No | | 3 | mowglidb | Auth-Type | := | Accept |
Why is that last line there?
| 4 | mowglidb | Hint | := | SQL | +----+----------+--------------+----+------------+ 4 rows in set (0.00 sec)
I've verified that both authentication types work properly, but what happens is that the Kerberos result is the only one ever used, despite the fact that the SQL result appears valid. So when you lookup an ID in the SQL table which is valid, the Kerberos lookup executes, doesn't find the ID, and sends a REJECT.
I don't see why... Kerberos has nothing to do with SQL. Adding entries in SQL *cannot* change how Kerberos works.
rlm_krb5: [mowglidb] krb5_g_i_t_w_p failed: Client not found in Kerberos database
Does this work when you delete the entries from SQL?
In reading the attributes description, it implies that if I put the "Auth-Type = Kerberos" in the check section for the DEFAULT entry, it should only add this if there is no Auth-Type, but I'm not clear on when the items from the radreply table are added to the reply.
They're added when the SQL module gets executed. It shows this in the debug output.
Explicitly setting the Auth-Type in the SQL reply doesn't appear to affect anything - the Kerberos DEFAULT entry seems to simply override it.
Because the Auth-Type belongs in the *check* items in SQL, not in the *reply* items. Alan DeKok.
From the fingers of Alan DeKok :
Mowgli Assor wrote:
I've had the rlm_krb5 module running for a while now, with the line in the users file : ... I found that was the only way to get the rlm_krb5 module to actually fire, otherwise the krb5 module would never try to authenticate anyone.
Yes. You have to tell the server when to use Kerberos authentication.
OK, but is there any way to do that without setting a DEFAULT entry? I really want Kerberos to be just another in the long list of things it tries for authentication, and when one of them succeeds, it stops and returns ACCEPT (unless of course Fall-Through is set, but in what I'm setting up it would not be). Yet just adding Kerberos to the "authenticate" section doesn't do anything. I've followed all the instructions on the Wiki for Kerberos, and had to add the DEFAULT entry to get it to do anything, so something seems to be missing there.
I'm now trying to add authentication from an SQL database. So, I have an appropriate tested setup for SQL, and the following in the radreply table :
mysql> select * from radreply; +----+----------+--------------+----+------------+ | id | username | attribute | op | value | +----+----------+--------------+----+------------+ | 1 | mowglidb | Service-Type | := | Login-User | | 2 | mowglidb | Fall-Through | = | No | | 3 | mowglidb | Auth-Type | := | Accept |
Why is that last line there?
Because I'm trying to get it to *not* run the Kerberos (DEFAULT) authentication when the user has authenticated via SQL. So it was my attempt to force the Auth-Type to something, and then I tried having the DEFAULT entry simply run Kerberos if the Auth-Type wasn't set, using "Auth-Type = Kerberos" as the check string. But of course, that didn't work.
| 4 | mowglidb | Hint | := | SQL | +----+----------+--------------+----+------------+ 4 rows in set (0.00 sec)
I've verified that both authentication types work properly, but what happens is that the Kerberos result is the only one ever used, despite the fact that the SQL result appears valid. So when you lookup an ID in the SQL table which is valid, the Kerberos lookup executes, doesn't find the ID, and sends a REJECT.
I don't see why... Kerberos has nothing to do with SQL. Adding entries in SQL *cannot* change how Kerberos works.
rlm_krb5: [mowglidb] krb5_g_i_t_w_p failed: Client not found in Kerberos database
Does this work when you delete the entries from SQL?
It works for any valid Kerberos set. The only entry in the SQL table right now is the mowglidb entry, mainly for testing. But basically I can't seem to get it to choose Kerberos *or* SQL - if Kerberos is in the loop, it'll always use the Kerberos return value, so even though SQL authentication succeeds, the reply is REJECT.
In reading the attributes description, it implies that if I put the "Auth-Type = Kerberos" in the check section for the DEFAULT entry, it should only add this if there is no Auth-Type, but I'm not clear on when the items from the radreply table are added to the reply.
They're added when the SQL module gets executed. It shows this in the debug output.
You mean because of the statements : ----- [sql] expand: SELECT id, username, attribute, value, op FROM radreply WHERE username = '%{SQL-User-Name}' ORDER BY id -> SELECT id, username, attribute, value, op FROM radreply WHERE username = 'mowglidb' ORDER BY id rlm_sql_mysql: query: SELECT id, username, attribute, value, op FROM radreply WHERE username = 'mowglidb' ORDER BY id ----- This doesn't actually show me anything about what the reply looks like. I can infer it searched the table, and presume it added entries, but I'd prefer to see what those entries (and any others that are there) are, so that I can figure out if among other things I've used the correct operator, and haven't mistyped something. That extra level of detail I don't see anywhere in the debug output.
Explicitly setting the Auth-Type in the SQL reply doesn't appear to affect anything - the Kerberos DEFAULT entry seems to simply override it.
Because the Auth-Type belongs in the *check* items in SQL, not in the *reply* items.
So, the desired behavior is : I have Kerberos, SQL, & (for fun let's say) specifically hardcoded users in the /etc/raddb/users file, and I wish to have the radius server return ACCEPT anytime any *one* of those sources authenticates properly. How would I accomplish this? My thinking was, that I'd have the SQL module run first, and include a set Auth-Type in the reply. Then, the check statement "Auth-Type = Kerberos" should NOT do Kerberos if Auth-Type is already set. That's clearly not working. Yet, if I put anything other than "Auth-Type = Kerberos" in the check line for the DEFAULT entry, the Kerberos module never attempts authentication. My other idea, and the whole reason for the "Hint = SQL" in radreply idea was that I could then put a check line in the DEFAULT entry : DEFAULT "Hint != SQL" Auth-Type = Kerberos But with that the Kerberos authentication is never attempted, regardless of whether the SQL module succeeds or not. Presumably this is because as you mentioned above, the Auth-Type belongs only in the check section? So the question I guess is how does one integrate the Kerberos module in so that, like the SQL, PAP, CHAP, and other modules it's simply one of several authentication methods, and have the server return ACCEPT when any one of them succeeds? Thanks, <Mowgli> -- The Ohio State University Network Security Group | Mowgli Assor ---------------------------------------------------+-------------------------- E-mail : security@osu.edu | Network Security Engineer Web : http://www.infosec.ohio-state.edu | Office : (Use E-mail)
Mowgli Assor wrote:
OK, but is there any way to do that without setting a DEFAULT entry? I really want Kerberos to be just another in the long list of things it tries for authentication, and when one of them succeeds, it stops and returns ACCEPT (unless of course Fall-Through is set, but in what I'm setting up it would not be).
That's not really how authentication works. You need to decide which users get what kind of authentication. Then, configure it. Trying multiple kinds of authentication won't work.
It works for any valid Kerberos set. The only entry in the SQL table right now is the mowglidb entry, mainly for testing. But basically I can't seem to get it to choose Kerberos *or* SQL - if Kerberos is in the loop, it'll always use the Kerberos return value, so even though SQL authentication succeeds, the reply is REJECT.
There is no "SQL authentication"
----- [sql] expand: SELECT id, username, attribute, value, op FROM radreply WHERE username = '%{SQL-User-Name}' ORDER BY id -> SELECT id, username, attribute, value, op FROM radreply WHERE username = 'mowglidb' ORDER BY id rlm_sql_mysql: query: SELECT id, username, attribute, value, op FROM radreply WHERE username = 'mowglidb' ORDER BY id -----
This doesn't actually show me anything about what the reply looks like.
Yes. You can run the query manually (as you did) to see the reply. There's no need to print it in debug mode.
I can infer it searched the table, and presume it added entries, but I'd prefer to see what those entries (and any others that are there) are, so that I can figure out if among other things I've used the correct operator, and haven't mistyped something.
Then edit the source code to add that functionality.
I have Kerberos, SQL, & (for fun let's say) specifically hardcoded users in the /etc/raddb/users file, and I wish to have the radius server return ACCEPT anytime any *one* of those sources authenticates properly.
How would I accomplish this?
With great difficulty. The phrasing of the problem statement is wrong.
My thinking was, that I'd have the SQL module run first, and include a set Auth-Type in the reply.
As you were told, the Auth-Type does NOT go in the reply.
Then, the check statement "Auth-Type = Kerberos" should NOT do Kerberos if Auth-Type is already set. That's clearly not working.
Because you're not following the documentation and the messages on this list. That's a big part of the problem... you need to understand how it works before trying to configure it. Instead, you keep trying things you were told are wrong.
Yet, if I put anything other than "Auth-Type = Kerberos" in the check line for the DEFAULT entry, the Kerberos module never attempts authentication.
My other idea, and the whole reason for the "Hint = SQL" in radreply idea was that I could then put a check line in the DEFAULT entry :
DEFAULT "Hint != SQL" Auth-Type = Kerberos
But with that the Kerberos authentication is never attempted, regardless of whether the SQL module succeeds or not.
Exactly. You were told Auth-Type does not go in the reply. Yet here you do it again. Why? Do you think I was joking? Or maybe you didn't understand my reply?
Presumably this is because as you mentioned above, the Auth-Type belongs only in the check section?
Perhaps reading my messages would answer that question.
So the question I guess is how does one integrate the Kerberos module in so that, like the SQL, PAP, CHAP, and other modules it's simply one of several authentication methods, and have the server return ACCEPT when any one of them succeeds?
You don't. You decide which users get Kerberos, and you configure that. Alan DeKok.
On 04/03/2010 08:30 AM, Alan DeKok wrote:
Mowgli Assor wrote:
OK, but is there any way to do that without setting a DEFAULT entry? I really want Kerberos to be just another in the long list of things it tries for authentication, and when one of them succeeds, it stops and returns ACCEPT (unless of course Fall-Through is set, but in what I'm setting up it would not be).
That's not really how authentication works. You need to decide which users get what kind of authentication. Then, configure it.
rlm_krb5 does not have an authorize callback therefore it's can't say "I'm available for authentication if there is a cleartext password" like any other pap style method. Why does rlm_krb5 have behavior seemingly at odds with the other types of modules in it's family (e.g. those which can authenticate given a cleartext password). -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
John Dennis wrote:
Why does rlm_krb5 have behavior seemingly at odds with the other types of modules in it's family (e.g. those which can authenticate given a cleartext password).
*some* authentication modules can be listed in "authorize": * chap * mschap * eap This is because the *type* of authentication shows up in the packet: * CHAP-Password * MSCHAP-Challenge / Response * EAP-Message There is no corresponding attribute for Kerberos. There is no corresponding attribute for LDAP. On top of that, Kerberos, LDAP, etc. usually work *only* for User-Password. And there many, many such modules. "Automatically" choosing one is hard. If you can edit *anything* to require a particular authentication back-end, you might as well do it by setting Auth-Type. Alan DeKok.
participants (3)
-
Alan DeKok -
John Dennis -
Mowgli Assor