How does your patch work, Peter? Is it similar to what I described? --Mike On Sep 20, 2006, at 9:45 AM, Alan DeKok wrote:

Peter Nixon <listuser@peternixon.net> wrote:

...

We have had to locally patch rlm_sql to make it accept NULL usernames. Is there any particular reason why it does this check? rlm_sql_postgresql works fine with NULL usernames as does the rest of FreeRADIUS.

Go for it.

Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/ devel.html

There already is a DEFAULT profile that is checked for every user regardless of what groups they may or not may be in. It would be easiest (and make the most sense, IMO) to just wrap everything before the profile check section (line 1018 in the CVS HEAD rlm_sql.c) in an "if (request->username != NULL)" block... That way none of the radcheck/radreply and group checks for the normal username are done, it just skips straight to checking the default profile (or user profile if the attribute exists). --Mike On Sep 20, 2006, at 5:05 PM, Peter Nixon wrote:

Our patch needs a little work before its ready to be committed. Currently to save auditing the rest of the code we are rewriting null values to "X" which doesn't exist as a user in our database.

We will spend some time tomorrow to write this patch correctly now that I know alan doesn't have anything against it. (It was just a hack to get us operational)

I also think that we should be able to have DEFAULT data in SQL tables, but this will require a whole new class of query to impliment correctly. (Or a second copy of the SQL module with the current code)

Cheers

On Wed 20 Sep 2006 19:26, Michael Griego wrote:

...

How does your patch work, Peter? Is it similar to what I described?

--Mike

On Sep 20, 2006, at 9:45 AM, Alan DeKok wrote:

...

Peter Nixon <listuser@peternixon.net> wrote:

...

We have had to locally patch rlm_sql to make it accept NULL usernames. Is there any particular reason why it does this check? rlm_sql_postgresql works fine with NULL usernames as does the rest of FreeRADIUS.

Go for it.

Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/ devel.html

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html

--

Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/ devel.html

Hey, Peter,

How/Where is this DEFAULT user checked in SQL? I was of the impression that DEFAULT data didnt work in SQL. (It it does I obviously am missing something.)

We do a lot of default processing here. We're using it as a catchall default policy for users (ie unless otherwise specified beforehand, users are, by default, allowed access these resources and denied access to these resources). Anyway, check out rlm_sql.c line 1018. This is where the default profile processing begins based on the default_user_profile configuration item in the sql {} section. These section also processes the User-Profile attribute if its present instead of the default profile.

As you can see a request with NULL username is quite valid for me, and may be proxied or accepted based (from inside the sql procedure) based on information in the request other than username/password and should therefore go through the normal sql queries.

Oh, absolutely. There are many instances where a User-Name attribute may not/need not be present that are completely valid and should be handled by the sql module. --Mike

There is a risk with this patch of running queries where the WHERE clause becomes WHERE UserName = ''... Which, I guess isn't really all that bad... I'm not sure I have any real problem with it, but we'll probably want to make the default sql_user_name configuration item %{User-Name:- DEFAULT} if we make the change this way. --Mike On Sep 21, 2006, at 8:20 AM, Peter Nixon wrote:

...

...

As you can see a request with NULL username is quite valid for me, and may be proxied or accepted based (from inside the sql procedure) based on information in the request other than username/password and should therefore go through the normal sql queries.

Oh, absolutely. There are many instances where a User-Name attribute may not/need not be present that are completely valid and should be handled by the sql module.

Can someone please test the attached patch before I commit it. It works ok for us with Postgresql but its possible that it may cause suprises for other database types.

Cheers

--

Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc <nullsqluser.patch> - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/ devel.html

On Sep 21, 2006, at 11:35 AM, Peter Nixon wrote:

It doesn't really bother me, but this is different behaviour to other modules... Why rewrite it at all?

If we attempt to mimic the users file processing as close as posslble, it uses the DEFAULT entries. This is exactly the reason that my take on this was to, if no User-Name is present, simply skip over the radcheck/radgroupcheck for the User-Name and jump straight to the DEFAULT profile checking. In my mind, that most closely mimics users file processing, reduces confusion of modules behaving differently, keeps the code as close to the same as possible in how it operates, and accomplishes the goal of allowing requests with no username. --Mike

On Sep 22, 2006, at 7:08 AM, Peter Nixon wrote:

It seems to me that while this is "close" to the users file behaviour it is NOT the same. If its not the same then I'm not sure that it matters how different it is. Maybe we should add an extra query for a DEFAULT user which always runs before the standard queries? This would be much closer than what you are suggesting (I think)

Well, I do disagree with which is more close to users file processing, however the way you're doing it does add a bit more flexibility in the request handling, so (like I said in the beginning), I'm not against it, just want to make sure things operate more consistently. In any case, I do have a different idea I came up with this morning. It involves consolidating the radcheck/radgroupcheck and radreply/ radgroupreply tables into just radcheck and radreply. Basically, what would change is, instead of having a "UserName" or "GroupName" column, you'd have one table with a "SectionName" column. This would be roughly equivalent to the groupname as it sits now (or, rather, descriptive names for sections of the users file in SQL). When processing occurs, the entire existing mechanism for radcheck/ radreply is no longer used (skipped). Instead it goes straight to group/section processing, and users are only members of sections. Yes, it means you will have more groups/sections in your database tables, however it has several advantages: 1. All check AVPs are in one table and all reply AVPs are in one table (less places to look to see what attributes will apply to a user, and less unnecessary tables) 2. This *most* closely matches the way the users file is processed, IMO 3. It *greatly* simplifies the code in the sql module 4. Less queries to muck with And, you can even keep things the way you want them now where a zero- length username is a valid entry separate from the DEFAULT sections. I know this is something of a major shift in the way the sql module processes authorizations, but I think it would be a worthwhile change, maybe for 2.0... Thoughts? --Mike

On Fri, 2006-09-22 at 11:57 -0400, Alan DeKok wrote:

Michael Griego <mgriego@utdallas.edu> wrote:

...

In any case, I do have a different idea I came up with this morning.

It sounds interesting... how do people migrate from what they have?

The way I did it was I wrote a perl script to extract the data from the users and password files, then generated data for radcheck usergroup and when required radreply, but all the default settings come from the radgroupcheck and radgroupreply associated with the group they are assigned to in usergroup. NOTE: I did not have any problems using the encrypted passwords from the FreeBSD master.password file, once I figured out how to configure Crypt-Password etc.