Re: Re: LDAP auth success / User reject
Hello *, Problem solved thx to Alans help -Find out what part of the configuration is setting "Auth-Type := Reject" -Look in the "files" configuration, and in the data in LDAP. The reject was the last default statement in the users file My problem was, that the patterns for both entries before failed. I resolved the reason, It was a Bug in the LDAP Tree of customer for this site, not noticed by me before. Michael - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
No NAS Port seen ?
Hello * -is the error belwo caused by fault of the NAS -or a stupid mistake of mine within setup ? rlm_radutmp: No NAS-Port seen. Cannot do anything. rlm_radumtp: WARNING: checkrad will probably not work! -other attributes are sent correctly -device is a lancom 315-agn TIA Micha - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: configure output summary
On Fri, Nov 19, 2010 at 09:21:11AM +0200, Johan Meiring wrote: > I agree that a lot of newbies will not read it, but if _one_ person reads > it a month, it will mean less questions on the list! That's actually the wrong solution to that particular problem. Newbies should stop compiling whenever they can use binary packages and avoid the whole issue. -- 2. That which causes joy or happiness. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Case-insensitive regexps in rlm_files
Brian Candler wrote: > The benefit to us in doing this in rlm_files/rlm_fastusers is that when > these files are rsynced out, freeradius re-reads them without needing a > restart. While the modules are reloaded on HUP, so are the virtual servers. So you can put "unlang" into a file, and it will be reloaded on HUP. > rlm_fastusers can also be a lot faster than a linear search in unlang. Yes, but it's not any faster than the "files" module. There's no need for "fastusers" any more. > Furthermore, it also helps that the syntax is limited and line-based, as it > results in less scope for errors. It's just a bit too limited without //i. ... and many other features, which are in "unlang". I'm wary of re-implementing the same thing multiple times. > We currently use our own custom modules which have similar functionality to > rlm_files and rlm_fastusers with case-insensitive regexp matching, but I'm > keen to fold this back into mainline if possible. (*) It's probably simpler just to add case-insensitive regex matching to the core. That way *all* of the modules get the functionality, and not just "users". Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Radmin segmentation fault
Hi list, I'm trying radmin with freeradius 2.1.10, in debian distro with 2.6.26-2-686 kernel. When I put the "show module config sql" I receive a segmentation fault un radiusd. Has anybody have the same bug? Regards, David - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Authenticating MACs and users
Hey List, I was just wondering - I have setup a freeradius server (stock packages on SLES 11, I don't have the exact version athand since I don't have access to the server right now) which is used for mac-based authentication with cisco switches - including vlan assignment. This works as intended. But I would also like to centralize my user accounts for switches and routers - am I able to do this with the same radius setup? Or do I have to setup another radius server? I am currently using flatfiles for the mac authentication. I already checked the list archive and the wiki but couldn't find anything helpful - maybe I looked for the wrong keywords ;) Any help would be appreciated! -- Mit freundlichen Grüßen/With Kind Regards Rudolph Bott - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: want to set up something a little more complex, not sure how to start. (hosts authenticated against openldap server)
Christ Schlacta wrote: > I'm not really sure how to accomplish authorizing a certificate that's > already passed tls authentication, but if it's possible, I know you > folks will be able to point me to a guide or provide some input as to > how to accomplish this. Read raddb/sites-available/default in 2.1.10. Look for "TLS-Cert". Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Changing a Reject into an Accept
Is it possible to turn a reject into an accept inside the post-auth section?
The idea is to tunnel specific groups of failed users to an appropriate help
page.
I have tried:
post-auth {
...
Post-Auth-Type REJECT {
if ( ) {
applyTunnelAttributes
ok
}
}
}
The attributes are added, but the 'ok' doesn't change the packet into an
Access-Accept.
I also tried, unsuccessfully,
update control {
Packet-Type := Access-Accept
Response-Packet-Type := Access-Accept
}
update reply {
Packet-Type := Access-Accept
Response-Packet-Type := Access-Accept
}
(freeradius reports that modifying the value of a virtual attribute is not
supported)
I could mess about with the authenticate section, but this goes against
the stern advice in the default config:
# Please do not put "unlang" configurations into the "authenticate"
# section. Put them in the "post-auth" section instead. That's what
# the post-auth section is for.
Going against that advice, the following appears to work:
authenticate {
Auth-Type PAP {
pap {
ok = return
reject = 1
}
applyTunnelAttributes
}
Auth-Type CHAP {
chap {
ok = return
reject = 1
}
applyTunnelAttributes
}
}
So, any better way of achieving this?
Thanks,
Brian.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Case-insensitive regexps in rlm_files
Alan DeKok wrote: > > The benefit to us in doing this in rlm_files/rlm_fastusers is that when > > these files are rsynced out, freeradius re-reads them without needing a > > restart. > > While the modules are reloaded on HUP, so are the virtual servers. So > you can put "unlang" into a file, and it will be reloaded on HUP. However, rlm_fastusers doesn't even require a HUP: it notices any changed file and reloads it on demand. (rlm_files doesn't though). > It's probably simpler just to add case-insensitive regex matching to > the core. That way *all* of the modules get the functionality, and not > just "users". Absolutely. So the options I see are: (1) lib/valuepair.c, paircmp() * before calling regcomp, look for (?i: ... ) * if found, strip it off and add REG_ICASE to regcomp. Advantages: - tiny change - fully backwards compat, regexps like (?i:...) fail to compile today Disadvantages: - it's a frig, as we're not really implementing non-capturing groups (2) Set case-insensitive flag on the value * Parse /xxx/ and /xxx/i as a PW_STRING containing xxx * Add new flag 'case_insensitive' to attr_flags * Use this flag when calling regcomp Advantages: - changes parser, but otherwise touches relatively little code - gives the expected user syntax for regexps Disadvantages: - technically this is an incompatible change for existing configs with User-Name == /foo/, which would have to change to User-Name == "/foo/" (I think this is very unlikely in practice though) I'd say (2) looks like the most attractive, what do you think? As a separate point, I think it's possible to cache the regcomp when do_xlat is not set. This would require another field in struct value_pair (to avoid changing strvalue into a struct). Worthwhile? Regards, Brian. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: configure output summary
"But newcomers aren't that trained yet." Perhaps you should change your course material? Sent from Verizon Wireless - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Having 2 User-Name when using Session Resumption
Hello all,
I am experiencing the following problem when using EAP-TLS and
session resumption. When my client tries to authenticate for the 2nd time
and FR recognizes that it has a valid session for it, it goes on and adds a
cached attribute to the reply (User-Name) thus ending up with two User-Name
attributes in my packet reply to NAS.
Debug: SSL Connection Established
Debug: SSL Application Data
Info: [tls] eaptls_process returned 3
Info: [tls] Retrieved session data from cached session
Info: [tls] Adding cached attributes to the reply: User-Name =
"anonym...@myisp2.com"
Info: [eap] Freeing handler
Info: ++[eap] returns ok
Auth: Login OK: [anonym...@myisp2.com] (from client
my_proxy_AAAServer1 port 1 cli 00-1B-2F-29-00-99)
Info: # Executing section post-auth from file
/usr/local/etc/raddb/sites-enabled/default
Info: +- entering group post-auth {...}
Info: ++[exec] returns noop
Sending Access-Accept of id 23 to 2001:db95::100 port 1814
User-Name = "anonym...@myisp2.com"
User-Name = "anonym...@myisp2.com"
MS-MPPE-Recv-Key =
0x40a71fc0b17fd5ce0bee1cfc06ebf8c48a6d37aa710c436a1da4aa3459a22007
MS-MPPE-Send-Key =
0x54ef81d0a961dda08062bb5e9f433a289f3b6628622122b0314a758abacacce2
EAP-Message = 0x03c90004
Message-Authenticator = 0x
Proxy-State = 0x34
How could I check if my reply has two User-Name attributes and remove
one? I am guessing that I should add some code in my post-auth..
Thanks a lot in advance,
Panos
PS. in order for session resumption to work on EAP-TLS I am having an update
reply { User-Name = "%{request:User-Name}"} section at the end of my auth
stanza of default which explains why it is not surprising to have the first
instance of User-Name there when FR decides to add cached attributes... (if
I don't have this update reply code SR doesn't work in EAP-TLS)
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: configure output summary
Hi, "But newcomers aren't that trained yet." Perhaps you should change your course material? I wasn't referring to my course in particular. It's just one instance where I can see how "innocent" users perceive things when they come across them first time. I.e. you should read 'newcomers' as "people who compile FreeRADIUS for the first time". Not all these first-timers have previously attended my course, so changing my course material doesn't solve the general problem. Greetings, Stefan -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Having 2 User-Name when using Session Resumption
Well, just to answer my own question really.. I 've been messing about with
it all morning, trying to figure out where exactly should I put my code to
check for duplicate User-Name attributes and how could I implement removing
only one, but in fact after sending the email to the list I realized that I
could go to post-auth and remove all User-Name attributes and add one, with
the following :
update reply {
User-Name !* 0x00
User-Name = "%{request:User-Name}"
}
It's not pretty, but it does the job! Now all I have to do is do more
testing to see if it affects other things...
Cheers,
Panos
> -Original Message-
> From: freeradius-users-
> bounces+panos=comp.lancs.ac...@lists.freeradius.org [mailto:freeradius-
> users-bounces+panos=comp.lancs.ac...@lists.freeradius.org] On Behalf Of
> Panagiotis Georgopoulos
> Sent: 19 November 2010 14:30
> To: freeradius-users@lists.freeradius.org
> Subject: Having 2 User-Name when using Session Resumption
>
> Hello all,
>
> I am experiencing the following problem when using EAP-TLS and
> session resumption. When my client tries to authenticate for the 2nd
> time
> and FR recognizes that it has a valid session for it, it goes on and
> adds a
> cached attribute to the reply (User-Name) thus ending up with two User-
> Name
> attributes in my packet reply to NAS.
>
>Debug: SSL Connection Established
>Debug: SSL Application Data
>Info: [tls] eaptls_process returned 3
>Info: [tls] Retrieved session data from cached session
>Info: [tls] Adding cached attributes to the reply: User-Name =
> "anonym...@myisp2.com"
>Info: [eap] Freeing handler
>Info: ++[eap] returns ok
>Auth: Login OK: [anonym...@myisp2.com] (from client
> my_proxy_AAAServer1 port 1 cli 00-1B-2F-29-00-99)
>Info: # Executing section post-auth from file
> /usr/local/etc/raddb/sites-enabled/default
>Info: +- entering group post-auth {...}
>Info: ++[exec] returns noop
> Sending Access-Accept of id 23 to 2001:db95::100 port 1814
> User-Name = "anonym...@myisp2.com"
> User-Name = "anonym...@myisp2.com"
> MS-MPPE-Recv-Key =
> 0x40a71fc0b17fd5ce0bee1cfc06ebf8c48a6d37aa710c436a1da4aa3459a22007
> MS-MPPE-Send-Key =
> 0x54ef81d0a961dda08062bb5e9f433a289f3b6628622122b0314a758abacacce2
> EAP-Message = 0x03c90004
> Message-Authenticator = 0x
> Proxy-State = 0x34
>
>How could I check if my reply has two User-Name attributes and
> remove
> one? I am guessing that I should add some code in my post-auth..
>
>Thanks a lot in advance,
>Panos
>
>
> PS. in order for session resumption to work on EAP-TLS I am having an
> update
> reply { User-Name = "%{request:User-Name}"} section at the end of my
> auth
> stanza of default which explains why it is not surprising to have the
> first
> instance of User-Name there when FR decides to add cached attributes...
> (if
> I don't have this update reply code SR doesn't work in EAP-TLS)
>
> -
> 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: No NAS Port seen ?
Michael Arndt wrote: > -is the error belwo caused by fault of the NAS > -or a stupid mistake of mine within setup ? > > rlm_radutmp: No NAS-Port seen. Cannot do anything. > rlm_radumtp: WARNING: checkrad will probably not work! The NAS decides what goes into the RADIUS request. > -other attributes are sent correctly If you're not doing Simultaneous-Use checking, this message can be ignored. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Radmin segmentation fault
David Seira wrote: > I'm trying radmin with freeradius 2.1.10, in debian distro with > 2.6.26-2-686 kernel. When I put the "show module config sql" I receive a > segmentation fault un radiusd. > > Has anybody have the same bug? Nope. See doc/bugs for help. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Case-insensitive regexps in rlm_files
Brian Candler wrote: > (2) Set case-insensitive flag on the value > > * Parse /xxx/ and /xxx/i as a PW_STRING containing xxx > * Add new flag 'case_insensitive' to attr_flags > * Use this flag when calling regcomp That's probably better... > Advantages: > - changes parser, but otherwise touches relatively little code > - gives the expected user syntax for regexps > > Disadvantages: > - technically this is an incompatible change for existing configs with > User-Name == /foo/, which would have to change to User-Name == "/foo/" ? /foo/ isn't supported right now. So that won't cause any change. > As a separate point, I think it's possible to cache the regcomp when do_xlat > is not set. This would require another field in struct value_pair (to avoid > changing strvalue into a struct). Worthwhile? No. That structure is already too big. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Changing a Reject into an Accept
Brian Candler wrote: > Is it possible to turn a reject into an accept inside the post-auth section? No. > I could mess about with the authenticate section, but this goes against > the stern advice in the default config: > > # Please do not put "unlang" configurations into the "authenticate" > # section. Put them in the "post-auth" section instead. That's what > # the post-auth section is for. > > Going against that advice, the following appears to work: If it works, use it. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Lost package after use FreeRadius
Dear Freeradius, At first, I use RouterOS(Mikrotik) as pppoe server and radius server. Now I use RouterOS as pppoe server and user FreeRadius as radius server. After changing as above, we find some pppoe users can dial up successfully via freeradius, but their internet transportation will lost package even can’t visit any website. I would like to know, how to explain the situation? What am I supposed to solve this problem? P.S When I change RouterOS to pppoe and radius server again (disable freeradius), it will all be ok. Thank you very much. Robin Lu - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Authenticating MACs and users
Rudolph Bott wrote: > But I would also like to centralize my user accounts for switches and > routers - am I able to do this with the same radius setup? Yes. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Lost package after use FreeRadius
Robin wrote: > At first, I use RouterOS(Mikrotik) as pppoe server and radius server. > Now I use RouterOS as pppoe server and user FreeRadius as radius server. > > After changing as above, we find some pppoe users can dial up > successfully via freeradius, but their internet transportation will lost > package even can’t visit any website. > > I would like to know, how to explain the situation? What am I supposed > to solve this problem? Make FreeRADIUS send back an Access-Accept containing the same attributes as sent by Access-Accept by the Mikrotik server. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Case-insensitive regexps in rlm_files
Alan DeKok wrote: > > - technically this is an incompatible change for existing configs with > > User-Name == /foo/, which would have to change to User-Name == "/foo/" > > ? /foo/ isn't supported right now. So that won't cause any change. Maybe not supported, but it does work: the unquoted string /foo/ is treated as if it were "/foo/" DEFAULT User-Name =~ /foo/, Cleartext-Password := "testing" Service-Type = Framed-User, Framed-Protocol = PPP, ... snip $ bin/radtest /foo/ testing localhost 1 testing123 Sending Access-Request of id 159 to 127.0.0.1 port 1812 User-Name = "/foo/" User-Password = "testing" NAS-IP-Address = 127.0.0.1 NAS-Port = 1 rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=159, length=71 Service-Type = Framed-User Framed-Protocol = PPP ... snip - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Having 2 User-Name when using Session Resumption
Panagiotis Georgopoulos wrote:
>
> Well, just to answer my own question really.. I 've been messing about with
> it all morning, trying to figure out where exactly should I put my code to
> check for duplicate User-Name attributes and how could I implement removing
> only one, but in fact after sending the email to the list I realized that I
> could go to post-auth and remove all User-Name attributes and add one, with
> the following :
>
>update reply {
>User-Name !* 0x00
>User-Name = "%{request:User-Name}"
>}
>
...or 'User-Name := foobar'
Cheers
--
Alexander Clouter
.sigmonster says: There is no royal road to geometry.
-- Euclid
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Lost package after use FreeRadius
Dear Alan, Actually, only about 5-10% users have this problem. If it's access-accept attributes issue, why will not all users lose package or not visit website? Where can I find any documents about this? Thanks. Robin -Original Message- From: freeradius-users-bounces+freeradius=itpm@lists.freeradius.org [mailto:freeradius-users-bounces+freeradius=itpm@lists.freeradius.org] On Behalf Of Alan DeKok Sent: Saturday, November 20, 2010 12:30 AM To: FreeRadius users mailing list Subject: Re: Lost package after use FreeRadius Robin wrote: > At first, I use RouterOS(Mikrotik) as pppoe server and radius server. > Now I use RouterOS as pppoe server and user FreeRadius as radius server. > > After changing as above, we find some pppoe users can dial up > successfully via freeradius, but their internet transportation will lost > package even can’t visit any website. > > I would like to know, how to explain the situation? What am I supposed > to solve this problem? Make FreeRADIUS send back an Access-Accept containing the same attributes as sent by Access-Accept by the Mikrotik server. Alan DeKok. - 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: Lost package after use FreeRadius
Hi Robin, Have FreeRadius mirror the Access-Accept (plus reply-attributes) of your Mikrotik radius server. You should be able to do a tcpdump (or snoop if it's on Solaris) to see the authentication messaging. Perhaps your Mikrotik radius server is setting some network-level parameters in the access-accept. If it is, you'll want FreeRadius to have the same behavior. As long as the access-accept and reply-attributes are the same, it should not matter which radius server you are using. >> Actually, only about 5-10% users have this problem. >From your description of the packet loss, I can't fathom how any radius server could have that impact/result. >> If it's access-accept attributes issue, why will not all users lose package or not visit website? If all your users are configured the same, then they should have the same experience. I'd lean towards network troubleshooting for the problem you describe. Regards, Jason P Hodges -Original Message- From: freeradius-users-bounces+jhodges=pocket@lists.freeradius.org [mailto:freeradius-users-bounces+jhodges=pocket@lists.freeradius.org ] On Behalf Of Robin Sent: Friday, November 19, 2010 11:19 AM To: 'FreeRadius users mailing list' Subject: RE: Lost package after use FreeRadius Dear Alan, Actually, only about 5-10% users have this problem. If it's access-accept attributes issue, why will not all users lose package or not visit website? Where can I find any documents about this? Thanks. Robin - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Authenticating MACs and users
Am 19.11.2010 17:01, schrieb Alan DeKok: Rudolph Bott wrote: But I would also like to centralize my user accounts for switches and routers - am I able to do this with the same radius setup? Yes. Ah yes, thanks - any hints on how to achieve this? Maybe I'm just using the wrong keywords for searching. Alan DeKok. -- Mit freundlichen Grüßen/With kind regards Rudolph Bott - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: [Segmentation Fault while proxing Request to home server]
Hum I don't get it I've got this bug in 2.1.10. This means I should get the latest git ? Thomas Le 19/11/2010 07:43, Alan DeKok a écrit : Thomas Fagart wrote: I've enable develloper mode, now I've got the following output : ... ASSERT FAILED event.c[1181]: "We do not have threads, but the request is marked as queued or running in a child thread" == NULL Ah, that's easy. It's fixed in git commit 5849d7aa69. See the v2.1.x branch. Alan DeKok. - 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: [Segmentation Fault while proxing Request to home server]
Thomas Fagart wrote: > Hum I don't get it I've got this bug in 2.1.10. Yes, I know. I've been reading your messages. > This means I should get the latest git ? Yes, that's what I ws trying to say. If was fixed in an official release, I would have said that. Instead, I pointed you to the git repository. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Authenticating MACs and users
Rudolph Bott wrote: > Ah yes, thanks - any hints on how to achieve this? Maybe I'm just using > the wrong keywords for searching. (a) configure user authentication (b) configure MAC authentication There is no real difference between the two, other than the format of the User-Name attribute. If your question was more specific, my answers could be more detailed. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Chargeable-User-Identity implementation
Hi,
> From my perspective, Chargeable-User-Identity is something that should
be logged with the 'custom' SQL logging rules being used. Slipping it
into a separate table, somehow feels weird; I guess that's what makes me
a packet-pusher and someone else a database guru :)
The question is: where to put it. The CUI information comes with the
Access-Accept, and needs to be stored before the first accounting packet
(if any) arrives at the server. So it can't be an extra column in any
accounting query.
SQL logging in post-auth would be an option. But that usually doesn't
store the necessary bits to retrofit the incoming accounting queries
with the CUI value (Calling-Station-Id being one thing that needs to be
logged alongside, to correlate the auth and acct). So that requires a
new structure for radpostauth - which is certainly a possibility. I just
wonder how much people fancy if radpostauth structure changes between
releases - it hasn't changed in a long while now.
* I thought Client-IP-Address was deprecated and we all should be using
'%{%{Packet-Src-IPv6-Address}:-%{Packet-Src-IP-Address}}'
Humm. That deserves updating the code :-)
* section 2.1 of RFC 4372 lets you be awkward about mis-matching CUI's
and offers you the option to Reject :)
That's the paragraph for re-authentications, right? i.e
"Upon receiving a non-nul CUI value in an Access-Request, the home
RADIUS server MAY verify that the value of CUI matches the CUI from
the previous Access-Accept. If the verification fails, then the
RADIUS server SHOULD respond with an Access-Reject message."
I don't think that is essential or even clever to implement. A home server is
allowed to change its CUIs after a (long) while. Now what happens if a user
authenticated with one value for his CUI, the home server meanwhile rolled over
to a new CUI, and then the client reauthenticates? Rejecting the re-auth is
rather drastic, and out of control of the user in question.
* not too sure about the outer.request bits. It seems cleaner to get
the inner layer to return just the User-Name to the outer layer,
the outer layer can then add the CUI bits (as if it was a
non-EAP request) and trim the User-Name in the reply packet
before it sends out the Access-Accept
The code in that section is the result of a rather long and fruitful
trial-and-error: there are EAP methods which don't have an inner method.
Some other EAP types generate the CUI value not in the last inner-tunnel
packet, but the penultimate one. I'm not the one who implemented it, but
I know that much pain has gone into testing and refining these statements.
But this doesn't preclude from advancing the implementation even more,
of course. But I'd be happy to have *some* implementation in mainline
release eventually, and then take it from there.
* I never thought to add Operator-Name as part of the hash key for CUI,
noted for myself, ta
* not sure about even having cui_require_operator_name as the
user's realm would tell you who you need to pester surely?
No, the user's realm gives the Service Provider an idea who the
responsible Identity Provider is. Operator-Name gives the Identity
Provider an idea which Service Provider to pester.
The "require" part of this is due to privacy considerations: if
Operator-Name is not in the packet, CUI for a user will be the same *at
all Service Provider locations* - enabling tracking mobility profiles.
As an Identity Provider you could say: "I'll only release CUI if I can
do it per Service Provider to prevent tracking" - and the "require"
option allows you to make just that happen.
Greetings,
Stefan Winter
My approach is a bit more softly-softly (although I will admit it has
not had any field testing), most of the brains is here in policy.conf:
cui {
if (Realm == "%{config:local.MY.realm}") {
update control {
# md5(cui_hash_key + u...@realm)
Chargeable-User-Identity :=
"%{md5:%{config:local.MY.cui_hash_key}%{tolower:%{%{reply:User-Name}:-%{request:User-Name"
}
if ((request:Chargeable-User-Identity)) {
update reply {
Chargeable-User-Identity :=
"%{control:Chargeable-User-Identity}"
}
if (request:Chargeable-User-Identity != "\\000") {
if (request:Chargeable-User-Identity !=
reply:Chargeable-User-Identity) {
update reply {
Reply-Message := "CUI Mismatch"
}
reject
}
}
}
else {
update request {
