Bug in CUI generation? Is this a known issue?
I'm playing around with CUI generation with FreeRADIUS 2.2.0 and discovered
something odd.
In policy.conf I've set cui_require_operator_name = 1 and cui_hash_key =
4c2982f2f3b1dc4804994cf386db8c0a34d4ab2a. As you can see it's a 32-character
string and it looks like a hash.
In radiusd -X output I get this:
Ready to process requests.
rad_recv: Access-Request packet from host 192.168.126.155 port 1814, id=17,
length=113
User-Name = st...@diamond.ac.uk
User-Password = testing
NAS-IP-Address = 127.0.0.1
NAS-Port = 0
Message-Authenticator = 0x80a453196d15a8e68ba13642ba725b24
Proxy-State = 0x30
Operator-Name = 1camford.ac.uk
Chargeable-User-Identity =
Proxy-State = 0x313630
# Executing section authorize from file /etc/raddb/sites-enabled/default
+- entering group authorize {...}
++? if (!(User-Name =~ /@/))
?? Evaluating (User-Name =~ /@/) - TRUE
? Converting !TRUE - FALSE
++? if (!(User-Name =~ /@/)) - FALSE
++? if (User-Name =~ /@$/)
? Evaluating (User-Name =~ /@$/) - FALSE
++? if (User-Name =~ /@$/) - FALSE
++? if (User-Name =~ /@.+?@/)
? Evaluating (User-Name =~ /@.+?@/) - FALSE
++? if (User-Name =~ /@.+?@/) - FALSE
++? if (User-Name =~ /@.+?[^[:alnum:]\\.-]/)
? Evaluating (User-Name =~ /@.+?[^[:alnum:]\\.-]/) - FALSE
++? if (User-Name =~ /@.+?[^[:alnum:]\\.-]/) - FALSE
++? if (User-Name =~ /@[\\.-]/)
? Evaluating (User-Name =~ /@[\\.-]/) - FALSE
++? if (User-Name =~ /@[\\.-]/) - FALSE
++? if (User-Name =~ /@.+?[\\.-]$/)
? Evaluating (User-Name =~ /@.+?[\\.-]$/) - FALSE
++? if (User-Name =~ /@.+?[\\.-]$/) - FALSE
++? if (User-Name =~ /@[^\\.]+$/)
? Evaluating (User-Name =~ /@[^\\.]+$/) - FALSE
++? if (User-Name =~ /@[^\\.]+$/) - FALSE
++? if (User-Name =~ /@.+?\\.\\./)
? Evaluating (User-Name =~ /@.+?\\.\\./) - FALSE
++? if (User-Name =~ /@.+?\\.\\./) - FALSE
++? if (User-Name =~ /@myabc\\.com$/i)
? Evaluating (User-Name =~ /@myabc\\.com$/i) - FALSE
++? if (User-Name =~ /@myabc\\.com$/i) - FALSE
++? if (User-Name =~
/@wlan\\.[[:alnum:]]+\\.[[:alnum:]]+\\.3gppnetwork\\.org$/i)
? Evaluating (User-Name =~
/@wlan\\.[[:alnum:]]+\\.[[:alnum:]]+\\.3gppnetwork\\.org$/i) - FALSE
++? if (User-Name =~
/@wlan\\.[[:alnum:]]+\\.[[:alnum:]]+\\.3gppnetwork\\.org$/i) - FALSE
++? if (User-Name =~ /@gmail\\.co(m|\\.[[:alnum:]][[:alnum:]])$/i)
? Evaluating (User-Name =~ /@gmail\\.co(m|\\.[[:alnum:]][[:alnum:]])$/i) -
FALSE
++? if (User-Name =~ /@gmail\\.co(m|\\.[[:alnum:]][[:alnum:]])$/i) - FALSE
++? if (User-Name =~ /@yahoo\\.co(m|\\.[[:alnum:]][[:alnum:]])$/i)
? Evaluating (User-Name =~ /@yahoo\\.co(m|\\.[[:alnum:]][[:alnum:]])$/i) -
FALSE
++? if (User-Name =~ /@yahoo\\.co(m|\\.[[:alnum:]][[:alnum:]])$/i) - FALSE
++? if (User-Name =~ /@hotmail\\.co(m|\\.[[:alnum:]][[:alnum:]])$/i)
? Evaluating (User-Name =~ /@hotmail\\.co(m|\\.[[:alnum:]][[:alnum:]])$/i) -
FALSE
++? if (User-Name =~ /@hotmail\\.co(m|\\.[[:alnum:]][[:alnum:]])$/i) - FALSE
++? if (User-Name =~ /@\\.?ac\\.uk$/i)
? Evaluating (User-Name =~ /@\\.?ac\\.uk$/i) - FALSE
++? if (User-Name =~ /@\\.?ac\\.uk$/i) - FALSE
++? if (User-Name =~ /@.+?\\.ax\\.uk$/i)
? Evaluating (User-Name =~ /@.+?\\.ax\\.uk$/i) - FALSE
++? if (User-Name =~ /@.+?\\.ax\\.uk$/i) - FALSE
++[preprocess] returns ok
++[chap] returns noop
++[mschap] returns noop
++[digest] returns noop
[suffix] Looking up realm diamond.ac.uk for User-Name = st...@diamond.ac.uk
[suffix] Found realm diamond.ac.uk
[suffix] Adding Stripped-User-Name = steve
[suffix] Adding Realm = diamond.ac.uk
[suffix] Authentication realm is LOCAL.
++[suffix] returns ok
[eap] No EAP-Message, not doing EAP
++[eap] returns noop
[files] users: Matched entry steve at line 76
++[files] returns ok
++[expiration] returns noop
++[logintime] returns noop
++[pap] returns updated
Found Auth-Type = PAP
# Executing group from file /etc/raddb/sites-enabled/default
+- entering group PAP {...}
[pap] login attempt with password testing
[pap] Using clear text password testing
[pap] User authenticated successfully
++[pap] returns ok
# Executing section post-auth from file /etc/raddb/sites-enabled/default
+- entering group post-auth {...}
++- entering policy cui_postauth {...}
+++? if (FreeRadius-Proxied-To == 127.0.0.1)
(Attribute FreeRadius-Proxied-To was not found)
? Evaluating (FreeRadius-Proxied-To == 127.0.0.1) - FALSE
+++? if (FreeRadius-Proxied-To == 127.0.0.1) - FALSE
+++- entering else else {...}
? if (!(%{control:Proxy-To-Realm}) Chargeable-User-Identity
!(reply:Chargeable-User-Identity) (Operator-Name ||
!(${policy.cui_require_operator_name})) )
expand: %{control:Proxy-To-Realm} -
?? Evaluating (%{control:Proxy-To-Realm}) - FALSE
? Converting !FALSE - TRUE
? Evaluating (Chargeable-User-Identity ) - TRUE
?? Evaluating (reply:Chargeable-User-Identity) - FALSE
? Converting !FALSE - TRUE
?? Evaluating (Operator-Name ) - TRUE
??? Skipping
Re: Bug in CUI generation? Is this a known issue?
Hi, rad_recv: Access-Request packet from host 192.168.126.155 port 1814, id=17, length=113 User-Name = st...@diamond.ac.uk User-Password = testing NAS-IP-Address = 127.0.0.1 NAS-Port = 0 Message-Authenticator = 0x80a453196d15a8e68ba13642ba725b24 Proxy-State = 0x30 Operator-Name = 1camford.ac.uk this is wrong. please update your config so that you are setting the correct Operator-Name - you seem to have copied some example document verbatim CUI policy has been updated quite a bit - the 3.x has more updates...check the latest 2.2.1 code to see what policy looks like. alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Bug in CUI generation? Is this a known issue?
Hi Alan, No, the operator name was 'correct' for our purposes. This is not a live system, we were using 'camford.ac.uk' as the 'visited site' on our test network. In the real world, it would be the correct operator name. :-) So, if I were to download v2.2.1, would a 32-character hex-string in cui_hash_key work or would it still cause the expand: portion to give me an empty value? Regards Stefan -Original Message- From: freeradius-users-bounces+stefan.paetow=diamond.ac...@lists.freeradius.org [mailto:freeradius-users-bounces+stefan.paetow=diamond.ac...@lists.freeradius.org] On Behalf Of a.l.m.bu...@lboro.ac.uk Sent: 10 May 2013 11:00 To: FreeRadius users mailing list Subject: Re: Bug in CUI generation? Is this a known issue? Hi, rad_recv: Access-Request packet from host 192.168.126.155 port 1814, id=17, length=113 User-Name = st...@diamond.ac.uk User-Password = testing NAS-IP-Address = 127.0.0.1 NAS-Port = 0 Message-Authenticator = 0x80a453196d15a8e68ba13642ba725b24 Proxy-State = 0x30 Operator-Name = 1camford.ac.uk this is wrong. please update your config so that you are setting the correct Operator-Name - you seem to have copied some example document verbatim CUI policy has been updated quite a bit - the 3.x has more updates...check the latest 2.2.1 code to see what policy looks like. alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Bug in CUI generation? Is this a known issue?
Hi, On Fri, May 10, 2013 at 09:49:14AM +, stefan.pae...@diamond.ac.uk wrote: As you can see, the expand: bit shows an empty value. Then I changed my cui_hash_key to 01234567890abcdef01234567890abcdef and it did the same. However, when I set cui_hash_key to a hex string that was not 32 characters in length (abcdef as an example), or a non-hex string of any length, it works ok. So I'm guessing here that if the cui_hash_key happens to be a string that is a potentially valid MD5 hash, the md5 operator in the CUI generation statement does nothing or barfs. Bug. src/main/xlat.c:1077 has: if (isdigit(l[1])) break; which stops looking for a module_name (e.g. md5 if the first character after the : is a digit. Fixed in 3.0 (see 4fd62ce9 22 August 2012). Matthew -- Matthew Newton, Ph.D. m...@le.ac.uk Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, ith...@le.ac.uk - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Bug in CUI generation? Is this a known issue?
On 10/05/13 12:12, Matthew Newton wrote: Hi, On Fri, May 10, 2013 at 09:49:14AM +, stefan.pae...@diamond.ac.uk wrote: As you can see, the expand: bit shows an empty value. Then I changed my cui_hash_key to 01234567890abcdef01234567890abcdef and it did the same. However, when I set cui_hash_key to a hex string that was not 32 characters in length (abcdef as an example), or a non-hex string of any length, it works ok. So I'm guessing here that if the cui_hash_key happens to be a string that is a potentially valid MD5 hash, the md5 operator in the CUI generation statement does nothing or barfs. Bug. src/main/xlat.c:1077 has: if (isdigit(l[1])) break; which stops looking for a module_name (e.g. md5 if the first character after the : is a digit. Fixed in 3.0 (see 4fd62ce9 22 August 2012). I think it's fixed in 2.2 head as well? IIRC leaving a after the : works fine. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Bug in CUI generation? Is this a known issue?
Thank you :-) Regards Stefan -Original Message- From: freeradius-users-bounces+stefan.paetow=diamond.ac...@lists.freeradius.org [mailto:freeradius-users-bounces+stefan.paetow=diamond.ac...@lists.freeradius.org] On Behalf Of Matthew Newton Sent: 10 May 2013 12:13 To: FreeRadius users mailing list Subject: Re: Bug in CUI generation? Is this a known issue? Hi, On Fri, May 10, 2013 at 09:49:14AM +, stefan.pae...@diamond.ac.uk wrote: As you can see, the expand: bit shows an empty value. Then I changed my cui_hash_key to 01234567890abcdef01234567890abcdef and it did the same. However, when I set cui_hash_key to a hex string that was not 32 characters in length (abcdef as an example), or a non-hex string of any length, it works ok. So I'm guessing here that if the cui_hash_key happens to be a string that is a potentially valid MD5 hash, the md5 operator in the CUI generation statement does nothing or barfs. Bug. src/main/xlat.c:1077 has: if (isdigit(l[1])) break; which stops looking for a module_name (e.g. md5 if the first character after the : is a digit. Fixed in 3.0 (see 4fd62ce9 22 August 2012). Matthew -- Matthew Newton, Ph.D. m...@le.ac.uk Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, ith...@le.ac.uk - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Inner tunnel post auth question
Hi,
This may have come up before but I can't find any solutions :
I'm using a NAS which always performs EAP/MSCHAP2 authentication, so
I've stripped the sites-enabled/default right down to pretty much just
include the eap stuff for authorisation/authentication, and am doing all
the rest inside the inner tunnel - fine.
When the radius returns an access-accept, it runs the stuff in the
inner-tunnel post_auth section ok, and I can record the attributes I
want to a mysql db, including a custom ldap attribute inserted into a
control variable.
However it seems that following a reject, the post_auth reject section
of inner-tunnel isn't actually used, so it doesn't record any info about
the attributes in the sql database if I use an sql call.
Ok .. so do it in the default post_auth reject bit - ok but I can't
figure how to pass back control variables to the outer tunnel. I'd
imagine it should be similar to the description in the post auth reject
section of the inner tunnel :
update outer.reply {
User-Name = %{request:User-Name}
}
But the section never gets called, so I tried putting it after the ldap
authorization bit, as I can't do it in the authentication part, or so I
gather (no unlang support in there?).
In the below update, ldap-UserDescription is my custom attribute, which
I can see from the logs is being populated :
[ldap] description - Ldap-UserDescription == test ip phone
Authorize {
..
..
ldap
update outer.control {
Ldap-UserDescription := %{control:Ldap-UserDescription}
}
}
But again it doesn't make it through (or am I doing it wrong?)
+- entering group REJECT {...}
expand: %{control:Ldap-UserDescription} - :
++[reply] returns noop
Am I being stupid? The best thing would be for the post_auth reject
section in inner tunnel to run, but failing that I need to work out the
control item passback to the outer tunnel.
Thanks for any help in advance!
Andy
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Inner tunnel post auth question
Andy,
What version of FreeRadius are you using?
I *think* that unless you are using the git source for 2.2.1, post-auth reject
is broken. There was some stuff I was doing a few months ago that got fixed in
2.2.1 … but I'm getting old and can't remember all the details :-(
On 10 May 2013, at 13:53, Franks Andy (RLZ) IT Systems Engineer
andy.fra...@sath.nhs.uk wrote:
Hi,
This may have come up before but I can’t find any solutions :
I’m using a NAS which always performs EAP/MSCHAP2 authentication, so I’ve
stripped the sites-enabled/default right down to pretty much just include the
eap stuff for authorisation/authentication, and am doing all the rest inside
the inner tunnel – fine.
When the radius returns an access-accept, it runs the stuff in the
inner-tunnel post_auth section ok, and I can record the attributes I want to
a mysql db, including a custom ldap attribute inserted into a control
variable.
However it seems that following a reject, the post_auth reject section of
inner-tunnel isn’t actually used, so it doesn’t record any info about the
attributes in the sql database if I use an sql call.
Ok .. so do it in the default post_auth reject bit – ok but I can’t figure
how to pass back control variables to the outer tunnel. I’d imagine it should
be similar to the description in the post auth reject section of the inner
tunnel :
update outer.reply {
User-Name = %{request:User-Name}
}
have u got
use_tunneled_reply = yes
set up in eap.conf?
Rgds
Alex
But the section never gets called, so I tried putting it after the ldap
authorization bit, as I can’t do it in the authentication part, or so I
gather (no unlang support in there?).
In the below update, ldap-UserDescription is my custom attribute, which I can
see from the logs is being populated :
[ldap] description - Ldap-UserDescription == test ip phone
Authorize {
..
..
ldap
update outer.control {
Ldap-UserDescription := %{control:Ldap-UserDescription}
}
}
But again it doesn’t make it through (or am I doing it wrong?)
+- entering group REJECT {...}
expand: %{control:Ldap-UserDescription} - :
++[reply] returns noop
Am I being stupid? The best thing would be for the post_auth reject section
in inner tunnel to run, but failing that I need to work out the control item
passback to the outer tunnel.
Thanks for any help in advance!
Andy
-
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: Inner tunnel post auth question
On 10/05/13 13:53, Franks Andy (RLZ) IT Systems Engineer wrote: Hi, This may have come up before but I can’t find any solutions : I’m using a NAS which alwaysperformsEAP/MSCHAP2authentication, so I’ve stripped the sites-enabled/default right down to pretty much just include the eap stuff for authorisation/authentication, and am doing all the rest inside the inner tunnel–fine. When the radius returns an access-accept, it runs the stuff in theinner-tunnelpost_auth section ok, and I can record the attributes I want to a mysql db, including a custom ldap attribute inserted into a control variable. However it seems that following a reject, the post_auth reject section of inner-tunnel isn’t actually used, so it doesn’t record any info about the attributes in the sql databaseif I use an sql call. Correct. This is fixed in 2.x.x head and 3.x See here: https://github.com/FreeRADIUS/freeradius-server/commit/860dd99c9d6390686b12f622a87f2f82d84bc867#src/main/auth.c - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Need help with making RPM from v2.x.x branch
It appears that the created RPM doesn't include the TLV update that were
made to the 2.x.x branch last week. Why wouldn't this be inlcuded in the
RPM even though I am building the RPM with the current 2.x.x. source?
Thanks.
On Wed, May 8, 2013 at 5:42 PM, Divyesh Raithatha
divyesh.raitha...@gmail.com wrote:
Thanks everyone. Finally got the RPM build to work by doing the following:
Version: 2.2.0 in the top of the freeradius.spec file to 2.2.1, and
renaming source
bz2 file to freeradius-server-2.2.1.tar.**bz2
Along with commenting out patches 2 and 5
#Patch2: freeradius-radtest.patch
#Patch5: freeradius-radeapclient-ipv6.patch
Changing the README line to README.rst
# install doc files omitted by standard install
for f in COPYRIGHT CREDITS INSTALL README.rst; do
cp $f $RPM_BUILD_ROOT/%{docdir}
diff freeradius.spec ~/freeradius-server-2.2.1/redhat/freeradius.spec
3c3
Version: 2.2.0
---
Version: 2.2.1
15c15
Patch2: freeradius-radtest.patch
---
#Patch2: freeradius-radtest.patch
18c18
Patch5: freeradius-radeapclient-ipv6.patch
---
#Patch5: freeradius-radeapclient-ipv6.patch
152c152
%patch2 -p1 -b .radtest
---
#%patch2 -p1 -b .radtest
155c155
%patch5 -p1 -b .radeapclient-ipv6
---
#%patch5 -p1 -b .radeapclient-ipv6
239c239
for f in COPYRIGHT CREDITS INSTALL README; do
---
for f in COPYRIGHT CREDITS INSTALL README.rst; do
By commenting out patch 2 and patch 5 what am I missing, if anything?
On Wed, May 8, 2013 at 8:20 AM, John Dennis jden...@redhat.com wrote:
On 05/08/2013 03:19 AM, Fajar A. Nugraha wrote:
On Wed, May 8, 2013 at 1:50 PM, Raithatha, Divyesh
divyesh.raitha...@gmail.com wrote:
Thanks, I got past the README but now I am getting the following file
not found errors. They do exist, however, it looks like the build is
looking for version 2.2.0 of the library files yet they are listed as
2.2.1.
error: File not found: /home/test/rpmbuild/BUILDROOT/**
freeradius-2.2.0-1.el6.x86_64/**etc/raddb/certs/README.rst
That's kinda tricky. Look at %files section in the spec file.
The cleanest solution right now would probably be changing Version:
2.2.0 in the top of the make file to 2.2.1, AND rename your source
bz2 file to freeradius-server-2.2.1.tar.**bz2.
The version macro in the spec file, the version embedded in tar file
name, and the contents of tar file all *MUST* match. You have to be precise
with what version you're building.
I assumed that was obvious as opposed to being tricky ;-)
Another way would be changing the files section, from (e.g.)
%{_libdir}/freeradius/rlm_**acct_unique-%{version}.so
to
%{_libdir}/freeradius/rlm_**acct_unique-*.so
... or even try deleting all rlm_* lines and replace them with a
one-liner
%{_libdir}/freeradius/rlm_*.**so*
--
John Dennis jden...@redhat.com
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/**
list/users.html http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Need help with making RPM from v2.x.x branch
On 05/10/2013 12:05 PM, Divyesh Raithatha wrote: It appears that the created RPM doesn't include the TLV update that were made to the 2.x.x branch last week. Why wouldn't this be inlcuded in the RPM even though I am building the RPM with the current 2.x.x. source? Use the source Luke :-) I assume you built from git, therefore you've got every piece of information you need to figure this out. git log will give you exact information. -- John Dennis jden...@redhat.com Looking to carve out IT costs? www.redhat.com/carveoutcosts/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Inner tunnel post auth question
My FR version is 2.1.10+dfsg-3build2_amd64. Unless there's a nice
package for Ubuntu 12.04 server then I'll be compiling from source then
I think.
This is the peap bit of eap.conf :
peap {
default_eap_type = mschapv2
copy_request_to_tunnel = yes
use_tunneled_reply = yes
# proxy_tunneled_request_as_eap = yes
virtual_server = inner-tunnel
so yes, the use_tunneled reply bit is there. Is that what's causing
the copying of attributes from within the tunnel to fail, or is that
setting what it's supposed to be? I'm still getting my head around the
eap thing - like for example why I need authorization and authentication
settings in the inner-tunnel virtual server for eap again - my intuition
would tell me that the inner eap just needs mschap in there if that's
the protocol inside the tunnel, but then perhaps it's something to do
with the protection bit of peap that means it's a tunnel within a
tunnel or something. Like I said still getting my head around it all.
I'd still like to get the attributes copying from the inner to outer
tunnels regardless of the fix in 2.2. It's gnawing at me a bit.
Thanks
Andy
From:
freeradius-users-bounces+andy.franks=sath.nhs...@lists.freeradius.org
[mailto:freeradius-users-bounces+andy.franks=sath.nhs.uk@lists.freeradiu
s.org] On Behalf Of Alex Sharaz
Sent: 10 May 2013 14:09
To: FreeRadius users mailing list
Subject: Re: Inner tunnel post auth question
Andy,
What version of FreeRadius are you using?
I *think* that unless you are using the git source for 2.2.1, post-auth
reject is broken. There was some stuff I was doing a few months ago that
got fixed in 2.2.1 ... but I'm getting old and can't remember all the
details :-(
On 10 May 2013, at 13:53, Franks Andy (RLZ) IT Systems Engineer
andy.fra...@sath.nhs.uk wrote:
Hi,
This may have come up before but I can't find any solutions :
I'm using a NAS which always performs EAP/MSCHAP2 authentication, so
I've stripped the sites-enabled/default right down to pretty much just
include the eap stuff for authorisation/authentication, and am doing all
the rest inside the inner tunnel - fine.
When the radius returns an access-accept, it runs the stuff in the
inner-tunnel post_auth section ok, and I can record the attributes I
want to a mysql db, including a custom ldap attribute inserted into a
control variable.
However it seems that following a reject, the post_auth reject section
of inner-tunnel isn't actually used, so it doesn't record any info about
the attributes in the sql database if I use an sql call.
Ok .. so do it in the default post_auth reject bit - ok but I can't
figure how to pass back control variables to the outer tunnel. I'd
imagine it should be similar to the description in the post auth reject
section of the inner tunnel :
update outer.reply {
User-Name = %{request:User-Name}
}
have u got
use_tunneled_reply = yes
set up in eap.conf?
Rgds
Alex
But the section never gets called, so I tried putting it after the ldap
authorization bit, as I can't do it in the authentication part, or so I
gather (no unlang support in there?).
In the below update, ldap-UserDescription is my custom attribute, which
I can see from the logs is being populated :
[ldap] description - Ldap-UserDescription == test ip phone
Authorize {
..
..
ldap
update outer.control {
Ldap-UserDescription := %{control:Ldap-UserDescription}
}
}
But again it doesn't make it through (or am I doing it wrong?)
+- entering group REJECT {...}
expand: %{control:Ldap-UserDescription} - :
++[reply] returns noop
Am I being stupid? The best thing would be for the post_auth reject
section in inner tunnel to run, but failing that I need to work out the
control item passback to the outer tunnel.
Thanks for any help in advance!
Andy
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
