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.