Thanks for the quick response. I'll try to be more descriptive, the configuration does look a little peculiar unless you know the order of events. On Nov 13, 2007 1:54 AM, Alan DeKok <aland@deployingradius.com> wrote:
Rachel Primrose wrote:
Version: FreeRADIUS Version 1.1.3
Please upgrade to 1.1.7.
I'll talk to the sys admins about this!
Problem: The LNS that will be sending requests to this server first sends an access request with just the realm with Service-Type=Outbound-User/Dialout-Framed-User (5). We either accept the request and give the LNS some interesting reply items that tell it to authenticate the user at another radius server, OR we reject the access request and the LNS will then send us through an access request for user@realm with Service-Type=Framed-User.
It also sounds like you want to do more, but you haven't described what that "more" really is.
So, here is the order of operations: 1. User is trying to log in with user@realm.com 2. The LNS first tries to authenticate the realm. It sends through an access request packet to our radius server with User-Name=realm.com, Service-Type=Dialout-Framed-User and Password = cisco. For certain realms only, we want to accept the request, and pass back some cisco specific attributes. For the rest of the realms, we want to just reject the request. 3a. If the LNS gets an accept packet back with cisco attributes, it forwards an access request with user@realm.com to a third party LNS. 3b. If the LNS gets a reject packet back, it will then send an access request packet to our radius server with User-Name = user@realm.com, Service-Type=Framed-User and Password = user-provided password. 4. We then authenticate/authorize against an ldap server, hence the term ldap_user. This setup enables us to have an l2tp setup with some specific clients.
When the first realm access request comes through, we do not want to use the sql module to log it, regardless of what our reply will be. The problem is, that Post-Auth-Type is overwritten no matter what I set it to in the users file!
That's confusing. Say what you want to happen. Don't say what's going wrong.
Please see the last paragraph for what I want to happen.
Configuration (just the important bits):
users
realm1.com Password=="blah", Service-Type=="Dialout-Framed-User", Auth-Type=Accept
That is wrong. This does NOT check the password!
This is just accepting the first access request from the lns for a particular realm. And then passing back the cisco attributes seen below. 192.168.0.0 is the IP of the third party LNS (I have replaced all the values with dummys of course, I would be a little concerned if that was the actual IP). realm1.com Password=="cisco", Service-Type=="Dialout-Framed-User", Auth-Type=Accept Cisco-AVpair = "vpdn:ip-addresses=192.168.0.0", Cisco-AVpair += "vpdn:tunnel-type=l2tp", Cisco-AVpair += "vpdn:l2tp-tunnel-password=blah", Cisco-AVpair += "vpdn:tunnel-id=blah"
DEFAULT Auth-Type = LDAP, Autz-Type = ldap_user, Post-Auth-Type = ldap_user
And you don't have a post-auth-type of "ldap_user".
post-auth { Post-Auth-Type ldap{ sql
Configuration error, fixed to: DEFAULT Auth-Type = LDAP, Autz-Type = ldap_user, Post-Auth-Type := ldap_user post-auth{ Post-Auth-Type ldap_user { sql
Why? The names aren't magic. There's no need to call it "ldap" if it's not doing ldap.
I called it ldap_user in line with the autz-type to keep it simple for people not that familiar with radius (there will be a number of people maintaining this system, some of which have never worked with radius before).
In the post-auth section Post-Auth-Type REJECT I want to conditionally run the sql module, based on the Service-Type attribute.
To do... what?
By conditionally run, I mean when the first access request packet with just the realm arrives and is rejected, we do not want to log it in the Post-Auth-Type REJECT section. However, when the second access request arrives, if it is genuinely rejected i.e. if the user does not exist, or the password is wrong, we want to log it in the Post-Auth-Type REJECT section. - Rachel Primrose