John Paul wrote:
The issue is that if a machine is authenticated and the server that
did the authentication is down, the switch will contact the other server
and the EAP conversation will fail, causing authentication to fail.
Research indicates that this is because the client and server have
agreed upon session specific symmetric keys that the new server does not
know about.
I don't think it's because of the establishment of symmetric session
keys. Once a user has been authenticated, the *next* authentication
session is completely independent.
I think it's that if fail-over happens in the *middle* of an EAP
authentication, the new server won't have been participating in the TLS
setup. Therefore, it doesn't know about the EAP conversation, and it
rejects the session.
It's not happening in the middle of the conversation. Server 1 will send an
Access-Accept packet and the switch enables the port. Then if server 1 goes
down and you attempt to reauthenticate the port, the switch tries server 2.
That is when it fails.
When I tested this the first time, authentications to server 1 worked and to
server 2 did not. When I couldn't figure it out, I turned the test machines off
and left for the day. The next day I had server 1 turned off - I turned the
test machines on and authentications to server 2 worked fine, but would not
work on server 1 once I powered it on. The common denominator here was that
authentications work against the first server it tries but not any others.
That's why I postulated that there must be some sort of session resumption
going on.
Is there a way to tell FreeRadius to tear down the session
once the user has been authenticated so that the next authentication
will work if using a different server? If not, is anyone working on a
patch or other change to enable this? I'll be happy to write the patch
but am unfamiliar with the code. Can you tell me roughly where to look?
Please check first that the server isn't establishing session keys.
Since FreeRADIUS doesn't do fast session resumption, I have no idea how
session specific symmetric keys could affect anything.
Was a shot in the dark based on some googling I had done awhile back. I assumed
FreeRadius and Windows were agreeing on some sort of fast session resumption
that would include symmetric encryption keys.
i.e. authentication one user via EAP. Stop ALL other authentications.
Turn off one RADIUS server, so it fails over to the other. Try to
re-authenticate that one user.
The user *should* be authenticated.
That's how I've been testing it and it's not working, see above description.
If I run the servers in debug mode (radiusd -X) the output starts to get
different at line 420 of the middle of the conversation. The working server
waits 6 seconds and then continues processing the next Access-Request packet:
(Note that these servers are in a test environment, so there are no additional
access-request packets reaching the servers, just the packets from the testing
machine)
Finished request 0
Going to the next request
--- Walking the entire request list ---
Waking up in 6 seconds...
rad_recv: Access-Request packet from host 172.22.30.170:1812, id=29, length=171
NAS-IP-Address = 172.22.30.170
NAS-Port = 50016
NAS-Port-Type = Ethernet
..
while the non-working server cleans up the request, then receives an
Access-Request packet:
Sending Access-Challenge of id 37 to 172.22.30.170 port 1812
EAP-Message = 0x011300061920
Message-Authenticator = 0x
State = 0x466470a3816b19a56b24e71b7dff8089
Finished request 0
Going to the next request
--- Walking the entire request list ---
Waking up in 6 seconds...
--- Walking the entire request list ---
Cleaning up request 0 ID 37 with timestamp 47556860
Nothing to do. Sleeping until we see a request.
rad_recv: Access-Request packet from host 172.22.30.170:1812, id=38, length=171
NAS-IP-Address = 172.22.30.170
NAS-Port = 50016
NAS-Port-Type = Ethernet
.
I can send the debugs in their entirety if you would like but thought I'd keep
them off the list for now. What else could be going on here?
Thanks for looking at this, if I can send you anything else please let me know.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
