Ok I understand how it works now. Why is there an option for special
characters at all in the addquery if it uses the value passed to accounting
reardless? And is there a way to remove the realm or rewrite the username
*after* the insert into accounting?
Reason I need this is that my billing system needs to know which users log on
with realms for our roaming users (via megapop which forwards radius requests
based on realm supplied from it's pops). This way we can track usage of our
national dailups. However, if the customers login name is x and he logs in as
[EMAIL PROTECTED], then [EMAIL PROTECTED] is put in the session table. The problem with this is the
customer can then login again from another location as [EMAIL PROTECTED] and successfully
login, bypassing simultaneous use limits because the compare is done based on
the user@realm contained in the session table, and of course, [EMAIL PROTECTED] does not
match [EMAIL PROTECTED] and thus they are allowed in.
Steve
Hugh Irvine wrote:
> Hello Steve -
>
> >
> > I'm having a few problems with the sql session database. Below is my
> > config. What I wish to do is have it use '%U' for the username, and as
> > such I put in AddQuery and CountQuery as needed. The username still
> > shows as '%n' in the table however. In order to track the usernames
> > correctly I changed it (temporarily) to '${Class}' which you can see
> > below. This change does work correctly, however what I ultimately need
> > is all authenticated usernames after all rewrites without realms for the
> > session database (I have Class defined for accounting where I do want to
> > track realms for my roaming customers who use Megapop for national
> > access).
> >
> > So it appears that the standard run time special characters are not
> > recognized by AddQuery? Can someone else duplicate and verify this or is
> > it just something with my current configuration? Below is my config
> > file.
> >
>
> As your queries use special characters elsewhere and all of them work, the
> problem cannot be with the special character handling.
>
> However, you have to keep in mind what is happening here. You are doing your
> rewrites *only* for authentication, and as the session database is updated
> *only* by accounting packets, the usernames are not being rewritten for it.
> The reason the Class attribute works is because you are saving the rewritten
> username in that attribute (sent to the NAS), which is being returned
> subsequently by the NAS in the accounting packets.
>
> In general that is exactly how the Class attribute should be used, so I
> suggest you consider using it for all usernames.
>
> hth
>
> Hugh
>
> --
> Radiator: the most portable, flexible and configurable RADIUS server
> anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
> -
> Nets: internetwork inventory and management - graphical, extensible,
> flexible with hardware, software, platform and database independence
S/MIME Cryptographic Signature
