Re: different eap/tls config for different interfaces
Makes sense. I'm doing EAP-TTLS with LDAP. I probably wouldn't need to define 2 diff ldap instances, since they'd both point to the same ldap server. However, I wonder if the ":=" operator would cause freeradius to ignore any other auth methods (such as ldap)? Doesn't that act as an "override" of sorts, or am I way off? thanks! - Original Message - From: Michael Griego <[EMAIL PROTECTED]> Date: Monday, August 8, 2005 5:53 pm Subject: Re: different eap/tls config for different interfaces > By its Client-IP-Address attribute or NAS-IP-Address attribute. > > Also, you can use the Packet-Dst-IP-Address attribute if you're > certain > that the clients are split up by interface. You can match up > based on > incoming interface like you were thinking about doing with two > different > servers. So, if your server is listening on 10.0.0.1 and > 10.0.1.1, and > your EAP modules are named EAPauth1 and EAPauth2, you could do: > > DEFAULT Packet-Dst-IP-Address == 10.0.0.1, EAP-Message =* "", Auth- > Type > := EAPauth1 > > DEFAULT Packet-Dst-IP-Address == 10.0.1.1, EAP-Message =* "", Auth- > Type > := EAPauth2 > > This functionality may only be CVS snapshots, though. I'm not > sure as I > haven't looked to see if it exists in the production releases. > > --Mike > > [EMAIL PROTECTED] wrote: > > >Mike, > > > >Sounds good, thanks for the info. Just curious: In the dual eap- > tls > >configuration that you mentioned in the second paragraph, how > would > >the radius server know which one to use for a given client? > > > >thanks! > > > >- Original Message - > >From: Michael Griego <[EMAIL PROTECTED]> > >Date: Friday, August 5, 2005 11:34 pm > >Subject: Re: different eap/tls config for different interfaces > > > > > > > >>After I'm done with the rlm_eap_tls rewrites and rlm_eap > updates, > >>there > >>will be functionality to have multiple EAP submodules of the > same > >>type > >>with different configurations. With this, you'll be able to > force > >>the > >>use of a specific EAP type instance by its instance name. > >> > >>In the meantime, if you want to avoid bringing up two servers, > you > >>*can* > >>configure two EAP module instances, each with a different tls > >>submodule > >>configuration. Force the Auth-Type to the EAP module with the > >>correct > >>tls configuration based on your criteria. I've used this > scenario > >>in > >>the past. > >> > >>--Mike > >> > >> > >>[EMAIL PROTECTED] wrote: > >> > >> > >> > >>>Oh...duh...that makes sense. Should have considered that. I > >>> > >>> > >>have since > >> > >> > >>>tested the behavior of the scenario I described, and Alan's on > >>> > >>> > >>target. > >> > >> > >>>Doesn't really seem to matter which interface I enter on, or which > >>>common-name I use. Seems to work either way. > >>> > >>>thanks for the help! > >>> > >>>- Original Message - > >>>From: Kris Benson <[EMAIL PROTECTED]> > >>>Date: Friday, August 5, 2005 5:28 pm > >>>Subject: Re: different eap/tls config for different interfaces > >>> > >>> > >>> > >>> > >>> > >[EMAIL PROTECTED] wrote: > > > > > > > > > >>If so, is it possible to have 2 different tls sections that > >> > >> > >>servicethe 2 different interfaces? > >> > >> > >> > >> > >> > >> > >No. FreeRADIUS supports only 1 TLS module at a time. > > > > > > > > > What Alan forgot to mention is a solution. > > If you run two copies of the Radius server, with one bound to > either a > different set of ports, or one to each IP, you could have > > > >>separate > >> > >> > configs. > -kb > -- > Kris Benson, CCP, I.S.P. > Technical Analyst, District Projects > School District #57 (Prince George) > > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html > > > > > >>>- > >>>List info/subscribe/unsubscribe? See > >>> > >>> > >>http://www.freeradius.org/list/users.html> > >> > >> > >>- > >>List info/subscribe/unsubscribe? See > >>http://www.freeradius.org/list/users.html > >> > >> > >- > >List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html> > > > - > 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: different eap/tls config for different interfaces
Mike, Sounds good, thanks for the info. Just curious: In the dual eap-tls configuration that you mentioned in the second paragraph, how would the radius server know which one to use for a given client? thanks! - Original Message - From: Michael Griego <[EMAIL PROTECTED]> Date: Friday, August 5, 2005 11:34 pm Subject: Re: different eap/tls config for different interfaces > After I'm done with the rlm_eap_tls rewrites and rlm_eap updates, > there > will be functionality to have multiple EAP submodules of the same > type > with different configurations. With this, you'll be able to force > the > use of a specific EAP type instance by its instance name. > > In the meantime, if you want to avoid bringing up two servers, you > *can* > configure two EAP module instances, each with a different tls > submodule > configuration. Force the Auth-Type to the EAP module with the > correct > tls configuration based on your criteria. I've used this scenario > in > the past. > > --Mike > > > [EMAIL PROTECTED] wrote: > > >Oh...duh...that makes sense. Should have considered that. I > have since > >tested the behavior of the scenario I described, and Alan's on > target. > >Doesn't really seem to matter which interface I enter on, or which > >common-name I use. Seems to work either way. > > > >thanks for the help! > > > >- Original Message - > >From: Kris Benson <[EMAIL PROTECTED]> > >Date: Friday, August 5, 2005 5:28 pm > >Subject: Re: different eap/tls config for different interfaces > > > > > > > >>>[EMAIL PROTECTED] wrote: > >>> > >>> > If so, is it possible to have 2 different tls sections that > servicethe 2 different interfaces? > > > >>> No. FreeRADIUS supports only 1 TLS module at a time. > >>> > >>> > >>What Alan forgot to mention is a solution. > >> > >>If you run two copies of the Radius server, with one bound to > >>either a > >>different set of ports, or one to each IP, you could have > separate > >>configs. > >>-kb > >>-- > >>Kris Benson, CCP, I.S.P. > >>Technical Analyst, District Projects > >>School District #57 (Prince George) > >> > >>- > >>List info/subscribe/unsubscribe? See > >>http://www.freeradius.org/list/users.html > >> > >> > >- > >List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html> > > > - > 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: different eap/tls config for different interfaces
Oh...duh...that makes sense. Should have considered that. I have since tested the behavior of the scenario I described, and Alan's on target. Doesn't really seem to matter which interface I enter on, or which common-name I use. Seems to work either way. thanks for the help! - Original Message - From: Kris Benson <[EMAIL PROTECTED]> Date: Friday, August 5, 2005 5:28 pm Subject: Re: different eap/tls config for different interfaces > >[EMAIL PROTECTED] wrote: > >> If so, is it possible to have 2 different tls sections that service > >> the 2 different interfaces? > > > > No. FreeRADIUS supports only 1 TLS module at a time. > > What Alan forgot to mention is a solution. > > If you run two copies of the Radius server, with one bound to > either a > different set of ports, or one to each IP, you could have separate > configs. > -kb > -- > Kris Benson, CCP, I.S.P. > Technical Analyst, District Projects > School District #57 (Prince George) > > - > 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: Multiple Password Prompts
- Original Message - From: Alan DeKok <[EMAIL PROTECTED]> Date: Friday, August 5, 2005 5:30 pm Subject: Re: Multiple Password Prompts > [EMAIL PROTECTED] wrote: > > If the server get's an incomplete reply to it's challenge, or no > reply,> will it resend it's challenge? > > No. RADIUS is entirely driven by the clients. > Gotcha > > Or, will the client sense that the server didn't respond to it's > > challenge response and start a new session. > > The client *does* see the Access-Challenge, but it decides for some > reason to stop talking to the server. > Yep...that's sort of weird. > > Of course, because each vendor has their own radius server and > > 802.1x client solution, they want to blame freeradius so that I'll > > buy their product. > > FreeRADIUs is interoperable with pretty much everything out there. > Novell is dumping their proprietary server for FreeRADIUS. Zyxel is > selling a $500 FreeRADIUS box (with some question of possible GPL > violations), and I know of 2 other companies using FreeRADIUs as part > of their RADIUS server solutions. > I agree. In their argument, they even pointed me to a security web site that supposedly listed 42 freeradius vulnerabilities, most of which had still not been addressed (according to them). I visited the site, read the material, followed the links, and apparently they just typed "freeradius" and clicked "search", and didn't actually read the results, because half of the results were totally unrelated and the rest were describing things that were fixed in version 0.4 or something. > > I'm trying my hardest to fight this, because I'm a big freeradius > > fan. > > Thanks. > No prob. Just keep it up. > > The debug on the Odyssey Client shows that it believes it sent the > > response to the challenge. The debug on the WLAN switch shows > that it > > forwards both the challenge from freeradius and the challenge > response> from the client. Freeradius debug appears to get the > response from the > > client, sees the outer credentials (anonymous, etc.), but doesn't > > process the tunneled information for some reason. > > Hmm... I do know that the odyssey client does some very weird > things. In some cases, it's interoperable *only* with Funk's server, > which is a nice way for them to say "other servers are broken", rather > than "our client is broken". > Yep, I'm beginning to suspect as much. > > So, does this mean that I should interpret the above enum to have > > elements 0-13, or 1-14, and match the numbers 7 and 13 with it's > > position in the enum? > > 0-13 > thanks > > I'm curious why we can see the TLS stuff during the first try > (13), but > > not the second try (7). What is the difference? > > The client is behaving differently the second time around. > > FreeRADIUS treats the two TLS sessions as being 100% unique. It > responds in the same way to the same input every time. So if one > session fails and the other succeeds, it's because the client is doing > something different. > Gotcha. > > I performed a packet capture using ethereal, listening on the > interface> that freeradius is running on. Did this on the box, not > inline. I > > would rather not post it to the list, but I'd be glad to send it > to you > > if you'd be willing to look at it. Let me know. > > Put it on a web page and mail me the link. > Will do. I'll shoot for tomorrow (08/06). > On a plus, the latest version of Ethereal appears to have stolen the > FreeRADIUS dictionary files, so the radius packets it decodes should > make a lot more sense. > Yeh...I noticed that. Very nice. > 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
different eap/tls config for different interfaces
I'm running freeradius on a linux box with 2 nics, eth0 and eth1. Let's say eth0 has an ip of 192.168.5.5, and eth1 has an ip of 192.168.6.6. And, eth0 is a member of vlan 5 and eth1 is a member of vlan 6. I bind freeradius to "*", so it's listening on both interfaces/ip's. I generated freeradius' tls certificate with a common name matching the ip of eth0 (192.168.5.5). Will this cause problems when a client tries to connect to freeradius via eth1 (192.168.6.6)? If so, is it possible to have 2 different tls sections that service the 2 different interfaces? Seems like I read somewhere that you can represent more than one IP in the common name of a certificate, but can't remember for sure as it's been a while. Anyone have any suggestions? thanks! - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Multiple Password Prompts
Thanks for the response. See below:
- Original Message -
From: Alan DeKok <[EMAIL PROTECTED]>
Date: Friday, August 5, 2005 11:03 am
Subject: Re: Multiple Password Prompts
> [EMAIL PROTECTED] wrote:
> > As I'm troubleshooting this, I generated another question in my
> head.
> > This time I'll give some freeradius debug (see blocks
> > between "*"):
> >
> > Here's an exerpt from first try (failure):
> ...
> > Sending Access-Challenge of id 186 to 192.168.3.2:1024
>
> That doesn't look like a failure to me. The supplicant may stop
> talking to the server, and start a new session, but the server thinks
> everything's OK.
>
Sorry...maybe I used the wrong word. By "failure", I meant that from
the end user's perspective, the first attempt was a failure.
If the server get's an incomplete reply to it's challenge, or no reply,
will it resend it's challenge? Or, will the client sense that the
server didn't respond to it's challenge response and start a new
session. I ask because, in talking to the vendors, there is a question
of which side is giving up, or which side isn't sending complete
requests/responses. Of course, because each vendor has their own radius
server and 802.1x client solution, they want to blame freeradius so that
I'll buy their product. I'm trying my hardest to fight this, because
I'm a big freeradius fan.
The debug on the Odyssey Client shows that it believes it sent the
response to the challenge. The debug on the WLAN switch shows that it
forwards both the challenge from freeradius and the challenge response
from the client. Freeradius debug appears to get the response from the
client, sees the outer credentials (anonymous, etc.), but doesn't
process the tunneled information for some reason.
> > I looked back through some of the output, and it seems that each
> time
> > it fails I get "eaptls_process returned 13", but when it is
> succeeds I
> > get "eaptls_process returned 7". Anyone know what 7 and 13
> represent
> > (please don't say 'sucess' or 'failure'...i'm hoping it more
> > meaningful than that).
>
> From src/modules/rlm_eap/types/rlm_eap_tls.h:
>
> typedef enum {
>EAPTLS_INVALID = 0,/* invalid, don't reply */
>EAPTLS_REQUEST,/* request, ok to send,
> invalid to receive */
>EAPTLS_RESPONSE, /* response, ok to receive,
> invalid to send */
>EAPTLS_SUCCESS,/* success, send success */
>EAPTLS_FAIL, /* fail, send fail */
>EAPTLS_NOOP, /* noop, continue */
>EAPTLS_START, /* start, ok to send, invalid
> to receive */
>EAPTLS_OK, /* ok, continue */
>EAPTLS_ACK,/* acknowledge, continue */
>EAPTLS_FIRST_FRAGMENT, /* first fragment */
>EAPTLS_MORE_FRAGMENTS, /* more fragments, to
> send/receive */
>EAPTLS_LENGTH_INCLUDED,/* length included */
>EAPTLS_MORE_FRAGMENTS_WITH_LENGTH, /* more fragments with
> length */
>EAPTLS_HANDLED /* tls code has handled it */
> } eaptls_status_t;
>
> So I don't see any particular reason why one session would succeed
> and the other would fail.
>
So, does this mean that I should interpret the above enum to have
elements 0-13, or 1-14, and match the numbers 7 and 13 with it's
position in the enum?
> > Also, anyone know what the rlm_eap_tls messages mean that accompany
> > the 'returned 13' block?
>
> Information about internal TLS stuff. There are a *lot* of TLS
> packets that go back and forth.
>
I'm curious why we can see the TLS stuff during the first try (13), but
not the second try (7). What is the difference? I agree...it seems
like there should nothing different between what the client sends in the
first try and the second.
> At this point, the only thing I can suggest is to put a packet
> capture on the net somewhere. That might give more information.
>
I performed a packet capture using ethereal, listening on the interface
that freeradius is running on. Did this on the box, not inline. I
would rather not post it to the list, but I'd be glad to send it to you
if you'd be willing to look at it. Let me know.
> 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: Multiple Password Prompts
As I'm troubleshooting this, I generated another question in my head. This time I'll give some freeradius debug (see blocks between "*"): Here's an exerpt from first try (failure): rlm_ldap: - authorize rlm_ldap: performing user authorization for anonymous radius_xlat: '(cn=anonymous)' radius_xlat: 'o=sometree' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in o=sometree, with filter (cn=anonymous) rlm_ldap: looking for check items in directory... rlm_ldap: looking for reply items in directory... rlm_ldap: user anonymous authorized to use remote access rlm_ldap: ldap_release_conn: Release Id: 0 modcall[authorize]: module "ldap" returns ok for request 4 modcall: group authorize returns updated for request 4 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 4 rlm_eap: Request found, released from the list rlm_eap: EAP/ttls rlm_eap: processing type ttls rlm_eap_ttls: Authenticate rlm_eap_tls: processing TLS rlm_eap_tls: Length Included * eaptls_verify returned 11 rlm_eap_tls: <<< TLS 1.0 Handshake [length 0086], ClientKeyExchange TLS_accept: SSLv3 read client key exchange A rlm_eap_tls: <<< TLS 1.0 ChangeCipherSpec [length 0001] rlm_eap_tls: <<< TLS 1.0 Handshake [length 0010], Finished TLS_accept: SSLv3 read finished A rlm_eap_tls: >>> TLS 1.0 ChangeCipherSpec [length 0001] TLS_accept: SSLv3 write change cipher spec A rlm_eap_tls: >>> TLS 1.0 Handshake [length 0010], Finished TLS_accept: SSLv3 write finished A TLS_accept: SSLv3 flush data (other): SSL negotiation finished successfully SSL Connection Established eaptls_process returned 13 ** modcall[authenticate]: module "eap" returns handled for request 4 modcall: group authenticate returns handled for request 4 Sending Access-Challenge of id 186 to 192.168.3.2:1024 Here's an exerpt from the second attempt (success): rlm_ldap: - authorize rlm_ldap: performing user authorization for anonymous radius_xlat: '(cn=anonymous)' radius_xlat: 'o=sometree' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in o=sometree, with filter (cn=anonymous) rlm_ldap: looking for check items in directory... rlm_ldap: looking for reply items in directory... rlm_ldap: user anonymous authorized to use remote access rlm_ldap: ldap_release_conn: Release Id: 0 modcall[authorize]: module "ldap" returns ok for request 5 modcall: group authorize returns updated for request 5 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 5 rlm_eap: Request found, released from the list rlm_eap: EAP/ttls rlm_eap: processing type ttls rlm_eap_ttls: Authenticate rlm_eap_tls: processing TLS rlm_eap_tls: Length Included *** eaptls_verify returned 11 eaptls_process returned 7 *** rlm_eap_ttls: Session established. Proceeding to decode tunneled attributes. Processing the authorize section of radiusd.conf modcall: entering group authorize for request 5 modcall[authorize]: module "preprocess" returns ok for request 5 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 5 rlm_ldap: - authorize rlm_ldap: performing user authorization for doe_john I looked back through some of the output, and it seems that each time it fails I get "eaptls_process returned 13", but when it is succeeds I get "eaptls_process returned 7". Anyone know what 7 and 13 represent (please don't say 'sucess' or 'failure'...i'm hoping it more meaningful than that). Also, anyone know what the rlm_eap_tls messages mean that accompany the 'returned 13' block? Thanks for any help! - Original Message - From: [EMAIL PROTECTED] Date: Thursday, August 4, 2005 6:40 pm Subject: Multiple Password Prompts > Hi, > > The Odyssey Client prompts at least twice for the password. Once > connected, clients can roam across different AP's within the same > WLAN > with no problems. Has anyone else experienced this problem with a > similar configuration? > > Running Environment: > > -- Freeradius Server = Gentoo Linux running FreeRADIUS v1.0.2 > -- User DB = Novell NetWare 6.5 SP3 w/ eDirectory 8.7.3.5 (LDAP) > -- Wireless Switch = Cisco Airespace 4100 WLAN Switch with WLAN > configured for WPA-TKIP using dynamic key exchange > -- Wireless AP = Cisco 1000 Series AP's (was Airespace) > -- Wireless Client = Funk Odyssey Client v4.0.1 on Windows XP > configured for WPA-TKIP and EAP-TTLS > > > We have captured debug output on the Odyssey Client, on the > Airespace > WLAN switch, and on FreeRADIUS, as well as an ethereal sniff on > the > freeradius interface on the radius server. I can provide these as > well as freeradius
Multiple Password Prompts
Hi, The Odyssey Client prompts at least twice for the password. Once connected, clients can roam across different AP's within the same WLAN with no problems. Has anyone else experienced this problem with a similar configuration? Running Environment: -- Freeradius Server = Gentoo Linux running FreeRADIUS v1.0.2 -- User DB = Novell NetWare 6.5 SP3 w/ eDirectory 8.7.3.5 (LDAP) -- Wireless Switch = Cisco Airespace 4100 WLAN Switch with WLAN configured for WPA-TKIP using dynamic key exchange -- Wireless AP = Cisco 1000 Series AP's (was Airespace) -- Wireless Client = Funk Odyssey Client v4.0.1 on Windows XP configured for WPA-TKIP and EAP-TTLS We have captured debug output on the Odyssey Client, on the Airespace WLAN switch, and on FreeRADIUS, as well as an ethereal sniff on the freeradius interface on the radius server. I can provide these as well as freeradius configs if needed. Thanks! - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: use_tunneled_reply
Ahh, I see. Based on the syntax you used it looks like I'd do this
using local users file. However, I'm using edirectory for the user
db. I have seen in the debug output where radius is checking for any
reply items in the directory. Maybe I could use radiusReplyItem as an
attribute in edir with a value "User-Name = ${User-Name}"?
thanks,
mack
- Original Message -
From: Alan DeKok <[EMAIL PROTECTED]>
Date: Saturday, June 18, 2005 4:21 pm
Subject: Re: use_tunneled_reply
> [EMAIL PROTECTED] wrote:
> > > Did you set "User-Name = novelluser" in the *reply* for the
> tunneled> > session?
> >
> > H...I did not explicitly do this. How to?
>
> Set it as a reply attribute?
>
> user blah-blah = blah
> User-Name = `%{User-Name}`
>
> > > You can verify that, independent of EAP, but using "radtest"
with
> > > the name & password of the tunneled user.
> >
> > I'm testing this now, but don't see the same "Access-Accept"
> message in
> > the debug output. Guess I'm still missing something.
>
> You will see the INNER TUNNEL Access-Accept. The reply attributes
> in that Access accept are the ones which will be copied to the outer
> tunnel, when TTLS is used.
>
> 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: use_tunneled_reply
- Original Message - From: Alan DeKok <[EMAIL PROTECTED]> Date: Saturday, June 18, 2005 11:46 am Subject: Re: use_tunneled_reply > [EMAIL PROTECTED] wrote: > > This leads a dunce like me to believe that radius will send a > reply > > back to AP/NAS that has User-Name equaling "novelluser", rather > > than "anonymous". > > Did you set "User-Name = novelluser" in the *reply* for the tunneled > session? H...I did not explicitly do this. How to? > > You can verify that, independent of EAP, but using "radtest" with > the name & password of the tunneled user. I'm testing this now, but don't see the same "Access-Accept" message in the debug output. Guess I'm still missing something. > > > I looked in the debug output (radiusd -A -X, right?). I think > this is > > what I am supposed to look for: > > Look at the REST of the debug output. It tells you what the reply > is in the tunnel, and what it's copying back to the outer session. > > Please, when you're reading the debug log, do MORE than just look at > the last few lines. Will do. > > 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: use_tunneled_reply
Thanks for the reply. The supplicant indeed sends "anonymous" as outer, but also sends "novelluser" as inner. So, I think I understand that the AP/NAS can't see the inner as the request is on it's way to the radiusso at that point, all it knows is "anonymous". However, according to the comment in eap.conf (v1.0.2): "The reply attributes sent to the NAS are usually based on the name of the user 'outside' of the tunnel (usually 'anonymous'). If you want to send the reply attributes based on the user name inside of the tunnel, then set this configuration entry to 'yes', and the reply to the NAS will be taken from the reply to the tunneled request." This leads a dunce like me to believe that radius will send a reply back to AP/NAS that has User-Name equaling "novelluser", rather than "anonymous". I looked in the debug output (radiusd -A -X, right?). I think this is what I am supposed to look for: Sending Access-Accept of id 247 to 192.168.3.2:1024 MS-MPPE-Recv-Key = 0x17c9701998d6ad7ee94b37819449c3cb0ebd9804c5de36c141a1509816dc6d71 MS-MPPE-Send-Key = 0xff1226efbfd249e76d3a502c43cc2ca5a95a5a38e9bd0829ca6ba34fe089696a EAP-Message = 0x03040004 Message-Authenticator = 0x User-Name = "anonymous" Before seeing this, my suspicion was that the NAS might somehow be ignoring the new value for User-Name, but it seems it's receiving exactly what radius is sending it. I thought the magical "use_tunneled_reply" setting was supposed to fix this? Am I understanding what "use_tunneled_reply" is actually supposed to do? Thanks for the patience and the advice. later, mack - Original Message - From: Alan DeKok <[EMAIL PROTECTED]> Date: Friday, June 17, 2005 1:23 pm Subject: Re: use_tunneled_reply > [EMAIL PROTECTED] wrote: > > Using FreeRADIUS 1.0.2, Cisco/Airespace 4100 WLAN switch as NAS, > and > > Odyssey Client v4.01 as supplicant. Kept seeing the user > > as "anonymous" in the WCS management software for the client. > > Because that's what the supplicant sends. > > > So, in eap.conf I changed use_tunneled_reply to equal yes. Still, > > replies to NAS show User-Name = "anonymous". Have I missed > > something? > > Run the server in debugging mode to see what's going on. > > 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
use_tunneled_reply
Hi, Using FreeRADIUS 1.0.2, Cisco/Airespace 4100 WLAN switch as NAS, and Odyssey Client v4.01 as supplicant. Kept seeing the user as "anonymous" in the WCS management software for the client. Wanted to see the *real* username, meaning the username that was actually authenticated to the backend db (in this case eDirectory). So, in eap.conf I changed use_tunneled_reply to equal yes. Still, replies to NAS show User-Name = "anonymous". Have I missed something? Thanks for the help, mack - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Novell eDirectory and FreeRADIUS docs
FYI -- I've seen alot of posts related to FreeRADIUS and Novell. I just found some documentation on the Novell web site for integrating Novell eDirectory with FreeRADIUS: http://www.novell.com/documentation/edir_radius/index.html Hope this helps someone! later, mack - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
