On Sat, Oct 18, 2008 at 04:07:27PM +0100, Arran Cudbard-Bell wrote:
Alan DeKok wrote:
Danny Paul wrote:
My management would like a way to force authorization to
succeed even if EAP has actually failed.
This is impossible. It is *designed* to be impossible. If it was
possible,
Hi,
If this is a wired port then just force an Access-Accept, yes it breaks
the RFC but if your NAS doesn't inspect the contents of the EAP-Message
then it'll work.
Well... a sane supplicant, be it on a wireless or wired port, will
maintain its EAP state machine, and will alert the user
Eating humble pie for a day would reset the admins expectations on how
to handle customer expectations to a reasonable level I'd think...
Sent from my iPhone
On 19 Oct 2008, at 18:49, Danny Paul [EMAIL PROTECTED] wrote:
This is impossible. It is *designed* to be impossible. If it was
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
For wired... maybe it works. But it's an accident, and may change
from switch revision to revision.
Just re-read RFC 3579, it should always work (I was surprised too).
RFC 3579:
2.6.3. Conflicting Messages
The NAS MUST make its access
Are you sure? Won't the supplicant barf because mutual authentication
doesn't succeed?
The supplicant will barf, and yet, the machine will not ignore the wide open
network port.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi,
The supplicant will barf, and yet, the machine will not ignore the wide open
network port.
That would be supplicant-dependent, right? For example the Intel
supplicant which I tried some time ago had a very solid opinion about
what was going on and I couldn't use the net just like
That would be supplicant-dependent, right? For example the Intel
supplicant which I tried some time ago had a very solid opinion about
what was going on and I couldn't use the net just like that. OTOH,
there is this peculiarity in the IEEE 802.1X standard itself that
basically says the
Yes, the switch would be wide open for the day - but that's better than
completely shut down in management's opinion.
Or, you could put procedures in place to warn you about expiring
certificates.
Already in place. The example of expired certificates is just one possibility.
guest
update control {
Response-Packet-Type := Access-Accept
}
Where this goes depends on your local configuration.
It's undocumented because it's a horrible thing to do. And almost
everyone using it will get it wrong.
Perhaps I'll try it anyway. Again, we're
Well... a sane supplicant, be it on a wireless or wired port, will
maintain its EAP state machine, and will alert the user if the state
machine was violated, right? So if the NAS gets and sends on a
EAPoL-Success out of order, client gear will yell. Or did I get you wrong?
My experience was
Hi,
And without getting into too many details, there would be no easy way to
change the access of the guest vlan or whatever terminology you want to use
so that more network resources could be accessed.
you cant change the guest VLAN access list or policy? pity.
alan
-
List
It'd be a bit more complicated than simply changing an access list,
unfortunately. No reason to get into details, but that's not really an option.
Thanks anyway.
On 10/20/2008 at 11:32 AM, in message [EMAIL PROTECTED],
[EMAIL PROTECTED] wrote:
Hi,
And without getting into too many details,
Hi,
That would be supplicant-dependent, right? For example the Intel
supplicant which I tried some time ago had a very solid opinion abou
Well that is true, I guess I'm only familiar with Windows supplicants.
The Intel supplciant *is* for Windows. It comes coupled with Centrino
chipsets
Hi,
Cisco 2950 switch has an auth fail vlan option. If port authentication
fails, the port is marked authorized and put in the configured auth-fail vlan
as opposed to the default vlan or remaining in an unauthorized state. For
Windows XP SP2, if authentication fails, the user is notified -
This is impossible. It is *designed* to be impossible. If it was
possible, malicious networks could tell users that authentication
succeeded, and then attack the users.
I'm not sure you grasped what I was after - imagine a 802.1x wired switch,
supplicants and RADIUS server configured for
Hi,
I would think that would work, I just don't know how to do that! It's really
easy to create a module that returns ok or handled but, despite hours of
pouring through the unlange manpages and documentation on rlm_example,
rlm_perl, and rlm_exec, I cannot seem to create a module that
Danny Paul wrote:
I'm not sure you grasped what I was after
Yes, I understood. This kind of request has come up before on this list.
For *wireless*, it's impossible, because the supplicant NAS use
encryption keys derived from the EAP-TLS exchange. No exchange means no
keys.
For
Danny Paul wrote:
I would think that would work, I just don't know how to do that! It's
really easy to create a module that returns ok or handled but,
despite hours of pouring through the unlange manpages and documentation
on rlm_example, rlm_perl, and rlm_exec, I cannot seem to create a
Alan DeKok wrote:
Danny Paul wrote:
My management would like a way to force authorization to
succeed even if EAP has actually failed.
This is impossible. It is *designed* to be impossible. If it was
possible, malicious networks could tell users that authentication
succeeded,
I'm getting ready to implement EAP-TLS for 802.1x port authentication.
Everything works great in my testing environment and I'm very happy with it.
However, before we roll it out into production, I must write a set of recovery
procedures. In these procedures I need to include a section on the
Danny Paul wrote:
My management would like a way to force authorization to
succeed even if EAP has actually failed.
This is impossible. It is *designed* to be impossible. If it was
possible, malicious networks could tell users that authentication
succeeded, and then attack the users.
You
21 matches
Mail list logo
