>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 : secur...@osu.edu | Network Security Engineer Web : http://www.infosec.ohio-state.edu | Office : (Use E-mail) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html