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
Client your.acs.box
Secret somesecret
.
/Client
Yup, had that, with a DefaultRealm though.
Client localhost
Secret mysecret
DupInterval 0
.
/Client
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
AuthBy FILE
Identifier CheckFile
Filename %D/users
.
/AuthBy
# define Realm(s) or Handler(s)
Realm
AuthBy CheckFile
..
/Realm
Well, instead I have:
Realm x
AuthBy FILE
Filename
/AuthBy
/Realm
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\.\-_@
Client name_of_router.concordia.ca
Secret XXX
DefaultRealm hse.concordia.ca
/Client
Client radhost.concordia.ca
Secret XXX
DefaultRealm wireless.concordia.ca
DupInterval 0
/Client
Client localhost
Secret XXX
DefaultRealm wireless.concordia.ca
DupInterval 0
/Client
Client name_of_acs.concordia.ca
Secret XXX
DefaultRealm alcor.concordia.ca
/Client
Client name_of_access_point.concordia.ca
Secret XXX
DefaultRealm wireless.concordia.ca
/Client
Realm wireless.concordia.ca
RejectHasReason
RewriteUsername s/\@wireless.concordia.ca$//
AuthBy FILE
Filename /path/to/NEG/WIRELESS.users
/AuthBy
/Realm
Realm alcor.concordia.ca
RejectHasReason
RewriteUsername s/\@alcor.concordia.ca$//
AuthBy FILE
Filename /path/to/SSG/ALCOR.users
/AuthBy
/Realm
Realm hse.concordia.ca
RejectHasReason
AuthBy FILE
Filename /path/to/NEG/HSE.users
/AuthBy
/Realm
Realm
/Realm
Realm DEFAULT
/Realm
TRACE 4 OF ACS BOX
