Alan DeKok wrote:

Geoff Silver <geoff+freeradius@uslinux.net> wrote:

...

I have a bunch of users which should have a class attribute returned upon successful authentication. Their entries look something like:

bob NAS-IP-Address == 172.31.33.66, Hint==HasSlash Auth-Type:=Accept Class = "OU=MY_CORP", Filter-Id = "SPCCOLO_O", Split-Tunneling-Policy = 1, Split-Tunnel-List = "SPCCOLO_ST"

What they're actually getting back is:

Packet-Type = Access-Accept User-Name = "bob" Class = 0x3739774831423272375053516a71424143444358434979507544493d

Which is '79...'

*nod*.

It works for me, so my guess is that something else in your configuration is setting Class to that value.

Okay, I'll bite - so what on earth might be causing that? I'm not doing any rewriting, and both the Filter-Id and the Split-Tunnel-List attributes come back as strings. I thought maybe it was getting confused on the Class since it contains an =, but changing that to an _ doesn't help. Is this perhaps coming back from the proxy server, and if so, is there a way to use my local Class attribute instead? My users file has a whole bunch of entries that look like the above, mostly like: bob NAS-IP-Address == 172.31.33.66, Hint==HasSlash, Proxy-To-Realm:=UAS Class = "OU=MY_CORP", Filter-Id = "SPCCOLO_O", Split-Tunneling-Policy = 1, Split-Tunnel-List = "SPCCOLO_ST" My hints file looks like: DEFAULT User-Password =~ ".*/.*" Hint = HasSlash My proxy.conf looks like: proxy server { synchronous = no retry_delay = 5 retry_count = 1 dead_time = 300 default_fallback = yes post_proxy_authorize = yes } realm UAS { type = radius authhost = radius.domain.com:1812 secret = MySecretKey } And my radiusd.conf looks uninterestingly like the following (note that the syslog sections are part of rlm_syslog which I submitted a while back): ## ## radiusd.conf -- FreeRADIUS server configuration file. ## prefix = /opt/radius exec_prefix = ${prefix} sysconfdir = /opt/radius/etc localstatedir = /var sbindir = /opt/radius/sbin logdir = /var/log/radius raddbdir = /opt/radius/etc radacctdir = /var/log/radius confdir = ${raddbdir} run_dir = ${localstatedir}/run/radiusd log_file = ${logdir}/radius.log libdir = ${exec_prefix}/lib pidfile = ${run_dir}/radiusd.pid checkrad = ${sbindir}/checkrad user = radius group = radius max_request_time = 30 delete_blocked_requests = no cleanup_delay = 5 max_requests = 1024 listen { ipaddr = * port = 1645 type = auth } listen { ipaddr = * port = 1646 type = acct } listen { ipaddr = * port = 1812 type = auth } listen { ipaddr = * port = 1813 type = acct } hostname_lookups = no allow_core_dumps = no regular_expressions = yes extended_expressions = yes log_stripped_names = no log_auth = yes log_auth_badpass = no log_auth_goodpass = no usercollide = no lower_user = yes lower_pass = no nospace_user = before nospace_pass = no security { max_attributes = 200 reject_delay = 1 status_server = no } $INCLUDE ${confdir}/clients.conf snmp = no #$INCLUDE ${confdir}/snmp.conf thread pool { start_servers = 5 max_servers = 32 min_spare_servers = 3 max_spare_servers = 10 max_requests_per_server = 0 } modules { preprocess { huntgroups = ${confdir}/huntgroups hints = ${confdir}/hints } files { usersfile = ${confdir}/users compat = no } uas { } syslog acct_log { loglevel = "info" logfacility = "local3" logname = "radiusd-acct" } syslog auth_log { hidepasswd = yes loglevel = "info" logfacility = "local3" logname = "radiusd-auth" } syslog reply_log { hidepasswd = yes # Some of this may be redundant, but it pretty much ensures # we get a unique identifier in every reply log message logextra = "User-Name = %{User-Name},Client-IP-Address = %{Client-IP-Address},NAS-IP-Address = %{NAS-IP-Address},NAS-Port = %{NAS-Port}" loglevel = "info" logfacility = "local3" logname = "radiusd-auth" } acct_unique { key = "User-Name, Acct-Session-Id, NAS-IP-Address, Client-IP-Address, NAS-Port" } always fail { rcode = fail } always reject { rcode = reject } always ok { rcode = ok simulcount = 0 mpp = no } expr { } digest { } exec { wait = yes input_pairs = request output_pairs = none } exec echo { wait = yes program = "/bin/echo %{User-Name}" input_pairs = request output_pairs = reply #packet_type = Access-Accept } } instantiate { exec expr } authorize { preprocess auth_log files } authenticate { Auth-Type UAS { #uas } } preacct { preprocess acct_unique files } accounting { acct_log } session { } post-auth { Post-Auth-Type REJECT { reply_log } reply_log } proxy_requests = yes $INCLUDE ${confdir}/proxy.conf pre-proxy { } post-proxy { }

Stefan Winter wrote:

...

...

It works for me, so my guess is that something else in your configuration is setting Class to that value. Okay, I'll bite - so what on earth might be causing that? I'm not doing any rewriting, and both the Filter-Id and the Split-Tunnel-List attributes come back as strings. I thought maybe it was getting confused on the Class since it contains an =, but changing that to an _ doesn't help. Is this perhaps coming back from the proxy server, and if so, is there a way to use my local Class attribute instead?

Well, you can use := instead of = , this overwrites any Class attribute that a proxy may have sent. See if that helps.

Stefan

Setting Proxy-to-Realm=UAS doesn't seem to work... not sure why. Nevertheless, configuring attr_filter to only use attributes I care about from the proxy seems to work just fine. As a side note, I had to change the Class attribute in dictionary.rfc2865 to be a string, *not* octets. I changed: ATTRIBUTE Class 25 octets to ATTRIBUTE Class 25 string to make it work (and be readable), though I can't tell if that's just an oddity of the Cisco VPN 3000 and the way it was previously implemented here or what. According to the RFC: 5.25. Class Description This Attribute is available to be sent by the server to the client in an Access-Accept and SHOULD be sent unmodified by the client to the accounting server as part of the Accounting-Request packet if accounting is supported. The client MUST NOT interpret the attribute locally. A summary of the Class Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 25 for Class. Length >= 3 String The String field is one or more octets. The actual format of the information is site or application specific, and a robust implementation SHOULD support the field as undistinguished octets. The codification of the range of allowed usage of this field is outside the scope of this specification

Ah ok. So it appears the network guys are doing something non-compliant with the RFCs around here. I hate that, but I'm not going to be able to change it either, so I'll just maintain a small patch for our environment. Thanks for clearing that up. Alan DeKok wrote:

Geoff Silver <geoff+freeradius@uslinux.net> wrote:

...

As a side note, I had to change the Class attribute in dictionary.rfc2865 to be a string, *not* octets. I changed: .... to make it work (and be readable), though I can't tell if that's just an oddity of the Cisco VPN 3000 and the way it was previously implemented here or what. According to the RFC:

The dictionaries are solely for internal server purposes. The reason Class is "octets" in the FreeRADIUS dictionaries is that it can contain binary data.

...

String

The String field is one or more octets. The actual format of the information is site or application specific, and a robust implementation SHOULD support the field as undistinguished octets.

The original RFC's had "string" type for both printable & binary data. FreeRADIUS moved to "string" and "octets", and the RFC's moved to "text" and "string".

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/users.html