Re: (RADIATOR) 2.18.3 & EAP
Hi, Hugh. >> the wireless base station points to the ACS/Windows >> box, which then points to Radiator running on my Unix box, and Radiator >> authenticates based on flat file information. >> >> Plain old flat file authentication works as expected based on tests >> with radpwtst from "localhost". What I need to know is whether Radiator >> will be able to respond correctly to the queries sent by the ACS/Windows >> box on behalf of the wireless base station, and if so, what additional >> configuration items are needed for that client (or the associated realm). > > Radiator should work correctly in the manner you describe, but if you send me > a trace 4 debug from Radiator together with your configuration file (no > secrets), I will be happy to take a look. OK; that would be great. See end of message for that material. > Here is part of the configuration that you will need: > > # define Client clauses > > > Secret somesecret > . > Yup, had that, with a DefaultRealm though. > > Secret mysecret > DupInterval 0 > . > Had that too, as it happens, and also with a (different) DefaultRealm, since that was what I was testing authentication on, but I'm curious as to why that matters for this, i.e., why a localhost client would be needed to do the LEAP authentication with the ACS box. > # define AuthBy clauses > > > Identifier CheckFile > Filename %D/users > . > > > # define Realm(s) or Handler(s) > > > AuthBy CheckFile > .. > Well, instead I have: Filename which should be equivalent, right? So there is no special configuration needed to support the LEAP stuff? I append my config file, with comments removed and secrets X'd out. Then I append the trace output you requested. In both files I have edited the names and IP addresses of hosts, since this list is archived, and there's no reason for the world to know where our network infrastructure hosts are without even bothering to scan. :-) In the trace showing the ACS box's connection, we get "Bad EAP Message-Authenticator". Just for fun, yesterday we tried pointing the access point at Radiator directly, even though I believe that is not supposed to work. Oddly enough, it got further: Radiator sent an Access-Challenge back, though there's no record of a response to that challenge from the access point. Anyway, back to the case we're supposed to be solving, where we authenticate requests from the ACS box: that box is running ACS 2.6. It is configured to consider my "radhost" a type "RADIUS" (as opposed to "TACACS+" or "CiscoSecure ACS for Windows 2000/NT"), with traffic type "inbound/outbound". The access point authenticates with "RADIUS (Cisco Aironet)", as opposed to "TACACS+ (Cisco IOS)", "RADIUS (IETF)", "RADIUS (Cisco IOS/PIX)", "RADIUS (Cisco VPN 5000)", "RADIUS (Cisco VPN 3000)", or "RADIUS (Ascend)". It shares a secret key with the ACS which is different from the secret key shared between the ACS and my "radhost". I wondered if "Bad EAP Message-Authenticator" was the result of a secret mismatch. I tried again with the client entry for the access-point commented out, in case it was somehow interfering with selecting the correct secret to use -- no change, still got "Bad EAP Message-Authenticator". I rechecked the secrets, and they seem to match. Any ideas? Anne. -- Ms. Anne Bennett, Senior Analyst, IITS, Concordia University, Montreal H3G 1M8 [EMAIL PROTECTED]+1 514 848-7606 CONFIG FILE: Foreground LogStdout Trace4 AuthPort 1645 AcctPort 1646 LogDir /tmp/radius/log DbDir /tmp/radius/db LogFile %L/logfile UsernameCharset a-zA-Z0-9\.\-_@ Secret XXX DefaultRealm hse.concordia.ca Secret XXX DefaultRealm wireless.concordia.ca DupInterval 0 Secret XXX DefaultRealm wireless.concordia.ca DupInterval 0 Secret XXX DefaultRealm alcor.concordia.ca Secret XXX DefaultRealm wireless.concordia.ca RejectHasReason RewriteUsername s/\@wireless.concordia.ca$// Filename /path/to/NEG/WIRELESS.users RejectHasReason RewriteUsername s/\@alcor.concordia.ca$// Filename /path/to/SSG/ALCOR.users RejectHasReason Filename /path/to/NEG/HSE.users TRACE 4 OF ACS BOX TRYING TO AUTHENTICATE A USER: # ./radiusd -config_file /tmp/radius/db/radconf Fri Sep 7 11:52:01 2001: DEBUG: Reading users file /path/to/NEG/WIRELESS.users Fri Sep 7 11:52:01 2001: DEBUG: Reading users file /path/to/SSG/ALCOR.users Fri Sep 7 11:52:04 2001: DEBUG: Reading users file /path/to/NEG/HSE.users Thi
Re: (RADIATOR) 2.18.3 & EAP
Hello Anne - On Thursday 06 September 2001 20:51, Anne Bennett wrote: > Hugh, > > > My apologies, but I am still unclear as to what you are trying to do. > > > > From what you describe below, I understand you to mean that you want the > > wireless base station to point to the ACS, which then points to Radiator, > > which then authenticates from a UNIX box. > > > > Is this correct? > > Essentially yes: the wireless base station points to the ACS/Windows > box, which then points to Radiator running on my Unix box, and Radiator > authenticates based on flat file information. > > Plain old flat file authentication works as expected based on tests > with radpwtst from "localhost". What I need to know is whether Radiator > will be able to respond correctly to the queries sent by the ACS/Windows > box on behalf of the wireless base station, and if so, what additional > configuration items are needed for that client (or the associated realm). > Thanks for the clarification. Radiator should work correctly in the manner you describe, but if you send me a trace 4 debug from Radiator together with your configuration file (no secrets), I will be happy to take a look. Here is part of the configuration that you will need: # define Client clauses Secret somesecret . Secret mysecret DupInterval 0 . # define AuthBy clauses Identifier CheckFile Filename %D/users . # define Realm(s) or Handler(s) AuthBy CheckFile .. hth Hugh -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) 2.18.3 & EAP
Hugh, > My apologies, but I am still unclear as to what you are trying to do. > > From what you describe below, I understand you to mean that you want the > wireless base station to point to the ACS, which then points to Radiator, > which then authenticates from a UNIX box. > > Is this correct? Essentially yes: the wireless base station points to the ACS/Windows box, which then points to Radiator running on my Unix box, and Radiator authenticates based on flat file information. Plain old flat file authentication works as expected based on tests with radpwtst from "localhost". What I need to know is whether Radiator will be able to respond correctly to the queries sent by the ACS/Windows box on behalf of the wireless base station, and if so, what additional configuration items are needed for that client (or the associated realm). Anne. -- Ms. Anne Bennett, Senior Analyst, IITS, Concordia University, Montreal H3G 1M8 [EMAIL PROTECTED]+1 514 848-7606 === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) 2.18.3 & EAP
On 6 Sep 2001, at 8:02, Hugh Irvine wrote: > Note that EAP/LEAP support is being added to Radiator in stages, with > EAP/LEAP proxy support being the first. Additional support will be introduced > in future revisions. Can I put in a request for EAP-TLS to be one of the next 'stages' to be added? Thanks! M. -- Mark O'Leary, Manchester Computing, UK PGP Key and Further Details: http://lucy.mcc.ac.uk/mark/mark.html === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) 2.18.3 & EAP
Hello Anne - My apologies, but I am still unclear as to what you are trying to do. >From what you describe below, I understand you to mean that you want the wireless base station to point to the ACS, which then points to Radiator, which then authenticates from a UNIX box. Is this correct? thanks Hugh On Thursday 06 September 2001 08:29, Anne Bennett wrote: > Hi, Hugh. > > >> As per my description when I requested the evaluation copy, I am trying > >> to set up a "wireless network with Cisco Aironet; we need a Unix-based > >> RADIUS server that can speak LEAP to the ACS box, which proxies the > >> requests from the access points". I was told that this is supported, > >> but I can't find anything in the docs. > > > > What you want to do is a simple AuthBy RADIUS proxy set up. > > I'm not quite sure we are understanding each other; perhaps my description > was unclear. I'll try again. The Access Points are pointing at the > ACS box. The ACS box is set up to pass the queries to my Unix box, > where my account database resides. I want my Unix box to perform the > authentication. > > I believe you are suggesting to me the opposite case, where the actual > authentication is performed by the ACS box. However, I am specifically > trying to *avoid* having user account information on the ACS box. > > > Note that EAP/LEAP support is being added to Radiator in stages, with > > EAP/LEAP proxy support being the first. Additional support will be > > introduced in future revisions. > > It sounds like what I am hoping to do is not supported for now. :-( > > > Anne. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) 2.18.3 & EAP
Hi, Hugh. >> As per my description when I requested the evaluation copy, I am trying >> to set up a "wireless network with Cisco Aironet; we need a Unix-based >> RADIUS server that can speak LEAP to the ACS box, which proxies the >> requests from the access points". I was told that this is supported, >> but I can't find anything in the docs. > What you want to do is a simple AuthBy RADIUS proxy set up. I'm not quite sure we are understanding each other; perhaps my description was unclear. I'll try again. The Access Points are pointing at the ACS box. The ACS box is set up to pass the queries to my Unix box, where my account database resides. I want my Unix box to perform the authentication. I believe you are suggesting to me the opposite case, where the actual authentication is performed by the ACS box. However, I am specifically trying to *avoid* having user account information on the ACS box. > Note that EAP/LEAP support is being added to Radiator in stages, with > EAP/LEAP proxy support being the first. Additional support will be > introduced in future revisions. It sounds like what I am hoping to do is not supported for now. :-( Anne. -- Ms. Anne Bennett, Senior Analyst, IITS, Concordia University, Montreal H3G 1M8 [EMAIL PROTECTED]+1 514 848-7606 === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) 2.18.3 & EAP
Hello Anne - What you want to do is a simple AuthBy RADIUS proxy set up. Have a look at section 6.27 in the Radiator 2.18.3 reference manual for a discussion of the AuthBy RADIUS clause. Any EAP or LEAP requset will be automatically handled when the request is proxied. Here is part of a configuration file for what you want to do: # define AuthBy RADIUS clause Identifier ProxyToACS Host the.acs.box Secret .. . # define Realm(s) or Handler(s) AuthBy ProxyToACS . Note that EAP/LEAP support is being added to Radiator in stages, with EAP/LEAP proxy support being the first. Additional support will be introduced in future revisions. Thanks for the note about the omission from the manual - it will be fixed in the next release. regards Hugh On Thursday 06 September 2001 06:36, Anne Bennett wrote: > > If you set the EAPType parameter in the AuthBy clause to something like > > 'notpermitted', it will reject EAP authentication requests. > > > > > > Filename xxx > > # Prevent authentication of any EAP requests > > EAPType notpermitted > > > > I just obtained the demo 2.18.3, and have been reading the HTML docs > that came with it. I can't find a mention of "EAPType" anywhere in my > documentation. > > As per my description when I requested the evaluation copy, I am trying > to set up a "wireless network with Cisco Aironet; we need a Unix-based > RADIUS server that can speak LEAP to the ACS box, which proxies the > requests from the access points". I was told that this is supported, > but I can't find anything in the docs. > > Help? > > > Anne. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) 2.18.3 & EAP
> If you set the EAPType parameter in the AuthBy clause to something like > 'notpermitted', it will reject EAP authentication requests. > > > Filename xxx > # Prevent authentication of any EAP requests > EAPType notpermitted > I just obtained the demo 2.18.3, and have been reading the HTML docs that came with it. I can't find a mention of "EAPType" anywhere in my documentation. As per my description when I requested the evaluation copy, I am trying to set up a "wireless network with Cisco Aironet; we need a Unix-based RADIUS server that can speak LEAP to the ACS box, which proxies the requests from the access points". I was told that this is supported, but I can't find anything in the docs. Help? Anne. -- Ms. Anne Bennett, Senior Analyst, IITS, Concordia University, Montreal H3G 1M8 [EMAIL PROTECTED]+1 514 848-7606 === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) 2.18.3 & EAP
Hello Mark, If you set the EAPType parameter in the AuthBy clause to something like 'notpermitted', it will reject EAP authentication requests. Filename xxx # Prevent authentication of any EAP requests EAPType notpermitted There is no way with configuration to prevent proxying of EAP requests. You would have to do that with a hook. Hope that helps. Cheers. On 1 Sep 2001, at 11:05, Hugh Irvine wrote: > There is nothing to configure. > Radiator will handle the proxying and challenge/response automatically. So, for example, the only way to ensure that Radiator would *not* respond to an EAP challenge is to run a version 2.18.2 or below? I was hoping there'd be a way to set a specific realm as capable of handling EAP authentications and disabling that functionality in other realms via the config file. It'd also be nice to get an idea of what manufacturers implementations of EAP Radiator is now compatible with - i.e. following Mike's 'open letter' about Cisco policy on releasing specs it's for lightweight EAP, do these new features support LEAP challenges? Cheers, M. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) 2.18.3 & EAP
On 1 Sep 2001, at 11:05, Hugh Irvine wrote: > There is nothing to configure. > Radiator will handle the proxying and challenge/response automatically. So, for example, the only way to ensure that Radiator would *not* respond to an EAP challenge is to run a version 2.18.2 or below? I was hoping there'd be a way to set a specific realm as capable of handling EAP authentications and disabling that functionality in other realms via the config file. It'd also be nice to get an idea of what manufacturers implementations of EAP Radiator is now compatible with - i.e. following Mike's 'open letter' about Cisco policy on releasing specs it's for lightweight EAP, do these new features support LEAP challenges? Cheers, M. -- Mark O'Leary, Manchester Computing, UK PGP Key and Further Details: http://lucy.mcc.ac.uk/mark/mark.html === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) 2.18.3 & EAP
Hello Mark - There is nothing to configure. Radiator will handle the proxying and challenge/response automatically. Or have I misunderstood your question? regards Hugh At 15:54 +0100 01/8/31, Mark O'Leary wrote: >Hugh, folks, > >Can anyone give me a pointer as to how to configure use of the new EAP >facilities. "EAP" doesnt appear to be mentioned in the 2.18.3 ref manual on >the Radiator site, nor in the distributed documentation, nor goodies file >etc. Basically all I can find is the three *.pm modules and two test >datafiles in the distribution. even test.pl doesnt seem to use EAP... I don't >feel up to guessing usage from the code. > >Any help much appreciated. > >M. > >-- >Mark O'Leary, Manchester Computing, UK >PGP Key and Further Details: >http://lucy.mcc.ac.uk/mark/mark.html >=== >Archive at http://www.open.com.au/archives/radiator/ >Announcements on [EMAIL PROTECTED] >To unsubscribe, email '[EMAIL PROTECTED]' with >'unsubscribe radiator' in the body of the message. -- NB: I am travelling this week, so there may be delays in our correspondence. Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc. Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) 2.18.3 & EAP
Hugh, folks, Can anyone give me a pointer as to how to configure use of the new EAP facilities. "EAP" doesnt appear to be mentioned in the 2.18.3 ref manual on the Radiator site, nor in the distributed documentation, nor goodies file etc. Basically all I can find is the three *.pm modules and two test datafiles in the distribution. even test.pl doesnt seem to use EAP... I don't feel up to guessing usage from the code. Any help much appreciated. M. -- Mark O'Leary, Manchester Computing, UK PGP Key and Further Details: http://lucy.mcc.ac.uk/mark/mark.html === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
