Kerberos (krb5) Module Overrides Other Authentication Types . . .

[Mowgli Assor]

>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 at osu.edu                          | Network Security Engineer
   Web : http://www.infosec.ohio-state.edu         | Office : (Use E-mail)