Re: different acctuniqueids with common keys?
This is an issue for us as well. It seems in our case, the NAS retransmits the
start packet 60 seconds later and this has an impact on the acctuniqueid as
shown in the example below:
Tue Aug 30 13:32:49 2011
Event-Timestamp = "Aug 30 2011 13:32:48 EDT"
User-Name = "u...@example.com"
NAS-IP-Address = 69.72.31.155
NAS-Identifier = "mtar-apx01.1dial.com"
Ascend-Owner-IP-Addr = 0.0.0.0
NAS-Port = 4652
Ascend-NAS-Port-Format = 4
NAS-Port-Type = Async
Service-Type = Framed-User
Class = 0x4241534943495350
Acct-Status-Type = Start
Acct-Delay-Time = 0
Acct-Session-Id = "592238627"
Acct-Authentic = RADIUS
Ascend-Auth-Delay = 1580
Ascend-Data-Rate = 21600
Ascend-Xmit-Rate = 4
Ascend-Modem-PortNo = 92
Ascend-Modem-SlotNo = 14
Ascend-Modem-ShelfNo = 1
Calling-Station-Id = "..."
Ascend-Calling-Id-Type-Of-Num = Unknown
Ascend-Calling-Id-Number-Plan = Unknown
Ascend-Calling-Id-Presentatn = Allowed
Ascend-Calling-Id-Screening = 40
Called-Station-Id = "..."
Ascend-Data-Svc = Switched-Voice-Bearer
Framed-Protocol = PPP
Framed-IP-Address = 208.103.135.234
Proxy-State = 0x3138
Proxy-State = 0x313435
Proxy-State = 0x323034
Realm = "example.com"
Acct-Unique-Session-Id = "547e6cd62913bca0"
Timestamp = 1314725569
Tue Aug 30 13:33:49 2011
Event-Timestamp = "Aug 30 2011 13:32:48 EDT"
User-Name = "u...@example.com"
NAS-IP-Address = 69.72.31.155
NAS-Identifier = "mtar-apx01.1dial.com"
Ascend-Owner-IP-Addr = 0.0.0.0
NAS-Port = 4652
Ascend-NAS-Port-Format = 4
NAS-Port-Type = Async
Service-Type = Framed-User
Class = 0x4241534943495350
Acct-Status-Type = Start
Acct-Delay-Time = 60
Acct-Session-Id = "592238627"
Acct-Authentic = RADIUS
Ascend-Auth-Delay = 1580
Ascend-Data-Rate = 21600
Ascend-Xmit-Rate = 4
Ascend-Modem-PortNo = 92
Ascend-Modem-SlotNo = 14
Ascend-Modem-ShelfNo = 1
Calling-Station-Id = "..."
Ascend-Calling-Id-Type-Of-Num = Unknown
Ascend-Calling-Id-Number-Plan = Unknown
Ascend-Calling-Id-Presentatn = Allowed
Ascend-Calling-Id-Screening = 40
Called-Station-Id = "..."
Ascend-Data-Svc = Switched-Voice-Bearer
Framed-Protocol = PPP
Framed-IP-Address = 208.103.135.234
Proxy-State = 0x3230
Proxy-State = 0x3832
Proxy-State = 0x3934
Realm = "example.com"
Acct-Unique-Session-Id = "0041ee21d0b1c6b1"
Timestamp = 1314725629
As with many companies using load balancing, it may not be good to use
Client-IP-Address to key on as this changed 60 seconds later.
Default in modules/acct_unique:
acct_unique {
key = "User-Name, Acct-Session-Id, NAS-IP-Address, Client-IP-Address, NAS-Port"
}
The man page for rlm_acct_unique shows:
acct_unique {
key = "User-Name, Acct-Session-Id, NAS-IP-Address, NAS-Port"
}
Anyone know when this was changed?
- Original Message -
From: "Arran Cudbard-Bell"
To: "FreeRadius users mailing list"
Sent: Saturday, June 18, 2011 7:50:49 AM
Subject: Re: different acctuniqueids with common keys?
On Jun 18, 2011, at 1:26 PM, and...@sybaweb.com wrote:
> On Sat, 18 Jun 2011 07:39:53 +0200, Arran Cudbard-Bell wrote:
>> As Alan says it's the NAS not including a consistent set of
>> Attribute and or values.
>
> The key attributes per the config (acct_unique { key = "User-Name,
> Acct-Session-Id, NAS-IP-Address, Client-IP-Address, NAS-Port"
> }) *are* consistent in the radacct table yet the value of acctuniqueid is
> not. I suppose the missing values could have been populated later.
Um yes. Especially if you're using interim updates.
-Arran
Arran Cudbard-Bell
RM-RF Limited - Security consultation and contracting
VoIP: +1 916-436-1352 Cell: +44 7854041841
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Expanding Suffix or Realm attributes
- Original Message -
> From: "Rob Turner"
> To: freeradius-users@lists.freeradius.org
> Sent: Tuesday, June 29, 2010 9:55:57 PM
> Subject: Expanding Suffix or Realm attributes
> Problem: Cannot expand %{Realm} or %{Suffix} control attributes for
> use unless realm is explicitly defined in proxy.conf
>
> I'm using freeradius2-2.1.7-7.el5 with ldap module. I would like to
> perform an ldap dip to get the radiusProxyToRealm attribute for each
> request based on Suffix as configured in modules/ldap:
>
> filter = "(radiusRealm=%{Suffix})"
>
> NOTE: If using in modules/ldap,
> radiusProxyToRealm is returned successfully and things work as
> expected. In this case the Proxy-To-Realm (which is mapped in
> ldap.attrmap) is set in ldap to proxy.com and proxy.com is defined in
> proxy.conf.
>
> Output from radiusd -X:
> ... [suffix] Looking up realm "domain.com" for User-Name =
> "t...@domain.com" [suffix] No such realm "domain.com"
> ++[suffix] returns noop
> ++[files] returns noop
> [ldap] performing user authorization for t...@domain.com
> [ldap] expand: (radiusRealm=%{Suffix}) -> (radiusRealm=)
> ...
>
> After reading man unlang, I have also attempted (without success) to
> expand using the following in ldap filter:
>
> %{control:Realm}
> %{control:Suffix} %{suffix:User-Name}
> %{realm:User-Name}
>
> Finally, after revisiting man rlm_realm, I read the following which is
> of concern as I don't see any other way to utilize the
> radiusProxyToRealm attribute in ldap:
>
> "In either case, a Realm attribute is created and added to the packet
> on a match, which can be used by other modules."
>
> Is there currently anyway to always match (regardless if the realm is
> defined in proxy.conf) in order to create a Stripped-User-Name and
> Realm run-time variable with every request?
>
> Regards,
>
> Rob
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
Also, I've tried to use a regex realm such as
realm "~.*\\.*\\.*$" {
ignore_default = yes
nostrip
}
Output from radiusd -X:
...
[suffix] Looking up realm "domain.com" for User-Name = "t...@domain.com"
[suffix] Found realm "~.*\.*\.*$"
[suffix] Adding Realm = "~.*\.*\.*$"
[suffix] Authentication realm is LOCAL.
++[suffix] returns ok
++[files] returns noop
[ldap] performing user authorization for t...@domain.com
[ldap] expand: (radiusRealm=%{Realm}) -> (radiusRealm=~.\2a\5c.\2a\5c.\2a$)
...
The regex realm would work if I could use the Suffix or Realm attribute from
something like the check or control list rather than "~.\2a\5c.\2a\5c.\2a$"
Thanks,
Rob
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Expanding Suffix or Realm attributes
Problem: Cannot expand %{Realm} or %{Suffix} control attributes for use unless
realm is explicitly defined in proxy.conf
I'm using freeradius2-2.1.7-7.el5 with ldap module. I would like to perform an
ldap dip to get the radiusProxyToRealm attribute for each request based on
Suffix as configured in modules/ldap:
filter = "(radiusRealm=%{Suffix})"
NOTE: If using in modules/ldap,
radiusProxyToRealm is returned successfully and things work as expected. In
this case the Proxy-To-Realm (which is mapped in ldap.attrmap) is set in ldap
to proxy.com and proxy.com is defined in proxy.conf.
Output from radiusd -X:
...
[suffix] Looking up realm "domain.com" for User-Name = "t...@domain.com"
[suffix] No such realm "domain.com"
++[suffix] returns noop
++[files] returns noop
[ldap] performing user authorization for t...@domain.com
[ldap] expand: (radiusRealm=%{Suffix}) -> (radiusRealm=)
...
After reading man unlang, I have also attempted (without success) to expand
using the following in ldap filter:
%{control:Realm}
%{control:Suffix}
%{suffix:User-Name}
%{realm:User-Name}
Finally, after revisiting man rlm_realm, I read the following which is of
concern as I don't see any other way to utilize the radiusProxyToRealm
attribute in ldap:
"In either case, a Realm attribute is created and added to the packet on a
match, which can be used by other modules."
Is there currently anyway to always match (regardless if the realm is defined
in proxy.conf) in order to create a Stripped-User-Name and Realm run-time
variable with every request?
Regards,
Rob
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
