migrating client from 2.0 to 3.0
Greetings FR-users, I am attempting to fold the functionality of a 2.0 FR system into an existing 3.0 system. I've configured the 2.0 system to proxy to the 3.0 system and this works - call this scenario A: UPS (client) | v FR 2.0 | v FR 3.0 works!! However if I attempt to auth directly from the UPS to the 3.0 system, it does not work - call this scenario B: UPS (client) | v FR 3.0 no works. :( Here are the debug logs for scenario A (working): 2.0 system: rad_recv: Access-Request packet from host 100.73.8.85 port 44482, id=41, length=113 User-Name = "foo" User-Password = "__REDACTED_BUT_VERIFIED_CORRECT_CLEARTEXT__" NAS-IP-Address = 100.73.8.85 NAS-Identifier = "apcE89163.d.umn.edu" NAS-Port = 0 # Executing section authorize from file /etc/freeradius/sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop ++[digest] returns noop [suffix] No '@' in User-Name = "foo", looking up realm NULL [suffix] Found realm "NULL" [suffix] Adding Stripped-User-Name = "foo" [suffix] Adding Realm = "NULL" [suffix] Proxying request from user foo to realm NULL [suffix] Preparing to proxy authentication request to realm "NULL" ++[suffix] returns updated [eap] No EAP-Message, not doing EAP ++[eap] returns noop ++[expiration] returns noop ++[logintime] returns noop ++[pap] returns noop WARNING: Empty pre-proxy section. Using default return values. Sending Access-Request of id 230 to 10.212.109.12 port 1812 User-Name = "foo" User-Password = "__REDACTED_BUT_VERIFIED_CORRECT_CLEARTEXT__" NAS-IP-Address = 100.73.8.85 NAS-Identifier = "apcE89163.d.umn.edu" NAS-Port = 0 Proxy-State = 0x3431 Proxying request 0 to home server 10.212.109.12 port 1812 Sending Access-Request of id 230 to 10.212.109.12 port 1812 User-Name = "foo" User-Password = "__REDACTED_BUT_VERIFIED_CORRECT_CLEARTEXT__" NAS-IP-Address = 100.73.8.85 NAS-Identifier = "apcE89163.d.umn.edu" NAS-Port = 0 Proxy-State = 0x3431 Going to the next request Waking up in 0.9 seconds. rad_recv: Access-Accept packet from host 10.212.109.12 port 1812, id=230, length=30 Proxy-State = 0x3431 Service-Type = Administrative-User # Executing section post-proxy from file /etc/freeradius/sites-enabled/default +- entering group post-proxy {...} [eap] No pre-existing handler found ++[eap] returns noop Found Auth-Type = Accept Auth-Type = Accept, accepting the user Login OK: [foo] (from client apc-UPS-network-1 port 0) # Executing section post-auth from file /etc/freeradius/sites-enabled/default +- entering group post-auth {...} ++[exec] returns noop Sending Access-Accept of id 41 to 100.73.8.85 port 44482 Service-Type = Administrative-User Finished request 0. Going to the next request Waking up in 4.9 seconds. Cleaning up request 0 ID 41 with timestamp +10 3.0 system: (0) Received Access-Request Id 230 from 10.212.109.94:1814 to 10.212.109.12:1812 length 117 (0) User-Name = "foo" (0) User-Password = "__REDACTED_BUT_VERIFIED_CORRECT_CLEARTEXT__" (0) NAS-IP-Address = 100.73.8.85 (0) NAS-Identifier = "apcE89163.d.umn.edu" (0) NAS-Port = 0 (0) Proxy-State = 0x3431 (0) # Executing section authorize from file /etc/freeradius/3.0/sites-enabled/default (0) authorize { (0) policy filter_username { (0) if (&User-Name) { (0) if (&User-Name) -> TRUE (0) if (&User-Name) { (0) if (&User-Name =~ / /) { (0) if (&User-Name =~ / /) -> FALSE (0) if (&User-Name =~ /@[^@]*@/ ) { (0) if (&User-Name =~ /@[^@]*@/ ) -> FALSE (0) if (&User-Name =~ /\.\./ ) { (0) if (&User-Name =~ /\.\./ ) -> FALSE (0) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/)) { (0) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/)) -> FALSE (0) if (&User-Name =~ /\.$/) { (0) if (&User-Name =~ /\.$/) -> FALSE (0) if (&User-Name =~ /@\./) { (0) if (&User-Name =~ /@\./) -> FALSE (0) } # if (&User-Name) = notfound (0) } # policy filter_username = notfound (0) [preprocess] = ok (0) [chap] = noop (0) [mschap] = noop (0) [digest] = noop (0) suffix: Checking for suffix after "@" (0) suffix: No '@' in User-Name = "foo", looking up realm NULL (0) suffix: No such realm "NULL" (0) [suffix] = noop (0) eap: No EAP-Message, not doing EAP (0) [eap] = noop (0) [files] = noop (0) [expiration] = noop (0) [logintime] = noop (0) pap: WARNING: No "known good" password found for the user. Not setting Auth-Type (0) pap: WARNING: Authentication will fail unless a "known good" password is available (0) [pap] = noop (0) if ("%{client:group}" == 'two-factor-authentication-group') { (0) EXPAND %{client:group} (0) --> default-authentication-group (0) if ("%{client:group}" == 'two-factor-authentication-group') -> FALSE (0) else { (0) update control { (0) Proxy-To-Realm := 'default-authentication-realm' (0) } # update control = noop (0) } # else = noop (0) } # authorize = ok (0) Starting proxy to home server 10.84.192.196 port 1812 (0) server default { (0) } (0) Proxying request to home server 10.84.192.196 port 1812 timeout 60.000000 (0) Sent Access-Request Id 13 from 0.0.0.0:42276 to 10.84.192.196:1812 length 146 (0) User-Name = "foo" (0) User-Password = "__REDACTED_BUT_VERIFIED_CORRECT_CLEARTEXT__" (0) NAS-IP-Address = 100.73.8.85 (0) NAS-Identifier = "apcE89163.d.umn.edu" (0) NAS-Port = 0 (0) Proxy-State = 0x3431 (0) Event-Timestamp = "Jan 12 2023 16:33:29 CST" (0) Message-Authenticator := 0x00 (0) Proxy-State = 0x323330 Waking up in 0.3 seconds. (0) Marking home server 10.84.192.196 port 1812 alive (0) Clearing existing &reply: attributes (0) Received Access-Accept Id 13 from 10.84.192.196:1812 to 10.212.109.12:42276 length 29 (0) Proxy-State = 0x3431 (0) Proxy-State = 0x323330 (0) server default { (0) # Executing section post-proxy from file /etc/freeradius/3.0/sites-enabled/default (0) post-proxy { (0) eap: No pre-existing handler found (0) [eap] = noop (0) } # post-proxy = noop (0) } (0) Found Auth-Type = Accept (0) Auth-Type = Accept, accepting the user (0) # Executing section post-auth from file /etc/freeradius/3.0/sites-enabled/default (0) post-auth { (0) if (session-state:User-Name && reply:User-Name && request:User-Name && (reply:User-Name == request:User-Name)) { (0) if (session-state:User-Name && reply:User-Name && request:User-Name && (reply:User-Name == request:User-Name)) -> FALSE (0) update { (0) No attributes updated for RHS &session-state: (0) } # update = noop (0) [exec] = noop (0) policy remove_reply_message_if_eap { (0) if (&reply:EAP-Message && &reply:Reply-Message) { (0) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE (0) else { (0) [noop] = noop (0) } # else = noop (0) } # policy remove_reply_message_if_eap = noop (0) update reply { (0) Service-Type = Administrative-User (0) } # update reply = noop (0) } # post-auth = noop (0) Login OK: [foo] (from client radius-netgear.d.umn.edu_10.212.109.94 port 0) (0) Sent Access-Accept Id 230 from 10.212.109.12:1812 to 10.212.109.94:1814 length 0 (0) Proxy-State = 0x3431 (0) Service-Type = Administrative-User (0) Finished request and the scenario B (not working) debug: (0) Received Access-Request Id 45 from 100.73.8.85:55435 to 10.212.109.12:1812 length 113 (0) User-Name = "foo" (0) User-Password = "__REDACTED_BUT_VERIFIED_CORRECT_CLEARTEXT__" (0) NAS-IP-Address = 100.73.8.85 (0) NAS-Identifier = "apcE89163.d.umn.edu" (0) NAS-Port = 0 (0) # Executing section authorize from file /etc/freeradius/3.0/sites-enabled/default (0) authorize { (0) policy filter_username { (0) if (&User-Name) { (0) if (&User-Name) -> TRUE (0) if (&User-Name) { (0) if (&User-Name =~ / /) { (0) if (&User-Name =~ / /) -> FALSE (0) if (&User-Name =~ /@[^@]*@/ ) { (0) if (&User-Name =~ /@[^@]*@/ ) -> FALSE (0) if (&User-Name =~ /\.\./ ) { (0) if (&User-Name =~ /\.\./ ) -> FALSE (0) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/)) { (0) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/)) -> FALSE (0) if (&User-Name =~ /\.$/) { (0) if (&User-Name =~ /\.$/) -> FALSE (0) if (&User-Name =~ /@\./) { (0) if (&User-Name =~ /@\./) -> FALSE (0) } # if (&User-Name) = notfound (0) } # policy filter_username = notfound (0) [preprocess] = ok (0) [chap] = noop (0) [mschap] = noop (0) [digest] = noop (0) suffix: Checking for suffix after "@" (0) suffix: No '@' in User-Name = "foo", looking up realm NULL (0) suffix: No such realm "NULL" (0) [suffix] = noop (0) eap: No EAP-Message, not doing EAP (0) [eap] = noop (0) [files] = noop (0) [expiration] = noop (0) [logintime] = noop (0) pap: WARNING: No "known good" password found for the user. Not setting Auth-Type (0) pap: WARNING: Authentication will fail unless a "known good" password is available (0) [pap] = noop (0) if ("%{client:group}" == 'two-factor-authentication-group') { (0) EXPAND %{client:group} (0) --> (0) if ("%{client:group}" == 'two-factor-authentication-group') -> FALSE (0) else { (0) update control { (0) Proxy-To-Realm := 'default-authentication-realm' (0) } # update control = noop (0) } # else = noop (0) } # authorize = ok (0) Starting proxy to home server 10.84.192.196 port 1812 (0) server default { (0) } (0) Proxying request to home server 10.84.192.196 port 1812 timeout 60.000000 (0) Sent Access-Request Id 206 from 0.0.0.0:57643 to 10.84.192.196:1812 length 141 (0) User-Name = "foo" (0) User-Password = "__REDACTED_BUT_VERIFIED_CORRECT_CLEARTEXT__" (0) NAS-IP-Address = 100.73.8.85 (0) NAS-Identifier = "apcE89163.d.umn.edu" (0) NAS-Port = 0 (0) Event-Timestamp = "Jan 12 2023 16:36:29 CST" (0) Message-Authenticator := 0x00 (0) Proxy-State = 0x3435 Waking up in 0.3 seconds. (0) Marking home server 10.84.192.196 port 1812 alive (0) Clearing existing &reply: attributes (0) Received Access-Accept Id 206 from 10.84.192.196:1812 to 10.212.109.12:57643 length 24 (0) Proxy-State = 0x3435 (0) server default { (0) # Executing section post-proxy from file /etc/freeradius/3.0/sites-enabled/default (0) post-proxy { (0) eap: No pre-existing handler found (0) [eap] = noop (0) } # post-proxy = noop (0) } (0) Found Auth-Type = Accept (0) Auth-Type = Accept, accepting the user (0) # Executing section post-auth from file /etc/freeradius/3.0/sites-enabled/default (0) post-auth { (0) if (session-state:User-Name && reply:User-Name && request:User-Name && (reply:User-Name == request:User-Name)) { (0) if (session-state:User-Name && reply:User-Name && request:User-Name && (reply:User-Name == request:User-Name)) -> FALSE (0) update { (0) No attributes updated for RHS &session-state: (0) } # update = noop (0) [exec] = noop (0) policy remove_reply_message_if_eap { (0) if (&reply:EAP-Message && &reply:Reply-Message) { (0) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE (0) else { (0) [noop] = noop (0) } # else = noop (0) } # policy remove_reply_message_if_eap = noop (0) update reply { (0) Service-Type = Administrative-User (0) } # update reply = noop (0) } # post-auth = noop (0) Login OK: [foo] (from client 100.73.8.0/23_100.73.8.0/23 port 0) (0) Sent Access-Accept Id 45 from 10.212.109.12:1812 to 100.73.8.85:55435 length 0 (0) Service-Type = Administrative-User (0) Finished request Both scenarios send Access-Accept and the Service-Type back to the client. I'm not sure if there is more to look at between the 2.0 and 3.0 systems. It is difficult to do any debugging on the UPS, so I was hoping to figure out the issue on the FR systems. I've performed a diff of the scenario A and B 3.0 debug outputs and I don't see anything significant in the difference. I have removed the Service-Type from the configurations and I still get a success authentication, I am just entered into a non-administrative role on the UPS. Does anyone have any ideas for further debugging? Thanks for any pointers or help! -m
On Jan 12, 2023, at 6:18 PM, Matt Zagrabelny via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
However if I attempt to auth directly from the UPS to the 3.0 system, it does not work - call this scenario B:
Hmm... the typical reason is that the shared secret is wrong. But if that's correct, there isn't much else that can go wrong. If you're running v2 and v3 on the same machine, and the Access-Accept packets are the same, then it really should work.
I'm not sure if there is more to look at between the 2.0 and 3.0 systems. It is difficult to do any debugging on the UPS, so I was hoping to figure out the issue on the FR systems.
I've performed a diff of the scenario A and B 3.0 debug outputs and I don't see anything significant in the difference.
Yeah, that's a problem. Even the debug output doesn't matter as much as the Access-Accept. i.e. the the Access-Accepts have the same contents, then it should work.
I have removed the Service-Type from the configurations and I still get a success authentication, I am just entered into a non-administrative role on the UPS.
So the UPS is recognizing the Access-Accept, but not the Service-Type. That is just weird.
Does anyone have any ideas for further debugging?
I really don't have much to offer here. I don't recall ever seeing this before. It has to be a networking issue. I can't think of anything else. Alan DeKok.
Hi Alan, On Thu, Jan 12, 2023 at 6:19 PM Alan DeKok <aland@deployingradius.com> wrote:
On Jan 12, 2023, at 6:18 PM, Matt Zagrabelny via Freeradius-Users < freeradius-users@lists.freeradius.org> wrote:
However if I attempt to auth directly from the UPS to the 3.0 system, it does not work - call this scenario B:
Hmm... the typical reason is that the shared secret is wrong. But if that's correct, there isn't much else that can go wrong.
If you're running v2 and v3 on the same machine, and the Access-Accept packets are the same, then it really should work.
No, not the same machine.
I'm not sure if there is more to look at between the 2.0 and 3.0 systems. It is difficult to do any debugging on the UPS, so I was hoping to figure out the issue on the FR systems.
I've performed a diff of the scenario A and B 3.0 debug outputs and I don't see anything significant in the difference.
Yeah, that's a problem. Even the debug output doesn't matter as much as the Access-Accept. i.e. the the Access-Accepts have the same contents, then it should work.
I have removed the Service-Type from the configurations and I still get a success authentication, I am just entered into a non-administrative role on the UPS.
So the UPS is recognizing the Access-Accept, but not the Service-Type. That is just weird.
Sorry. I wasn't clear. The Service-Type is working as expected. If I remove it from Scenario A, I drop into the console with reduced privileges. I removed the update reply stanza to simplify the FR configs. Didn't seem to change anything - obviously.
Does anyone have any ideas for further debugging?
I really don't have much to offer here. I don't recall ever seeing this before.
It has to be a networking issue. I can't think of anything else.
That's where I'll look. Though the UPS does contact the 3.0 system just fine (when it is configured to do so) - it just appears that it isn't respecting the Access-Accept. -m
On Jan 12, 2023, at 8:14 PM, Matt Zagrabelny via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
No, not the same machine.
Then test it on the same machine. Perhaps there's some networking issue which prevents the client from receiving replies sent by the machine running v3. The only way to debug this issue is to eliminate possible differences one by one. That requires a systematic approach.
Sorry. I wasn't clear. The Service-Type is working as expected. If I remove it from Scenario A, I drop into the console with reduced privileges.
So what happens in scenario B? The same thing? What happens if the RADIUS server is simply down? Do you still get dropped into the console? Again, try eliminating possibilities one by one. You're not going to fix this by poking the FreeRADIUS configuration.
That's where I'll look. Though the UPS does contact the 3.0 system just fine (when it is configured to do so) - it just appears that it isn't respecting the Access-Accept.
Is the shared secret correct? Is the Access-Accept being received by the UPS? What happens when the UPS doesn't receive the Access-Accept? There's no magic here. If you run v3 on the same machine which runs v2, *and* send the same Access-Accept with the same contents, it will work. It has to work. There's nothing in the RADIUS packets which is different from v2 to v3. So... track down what's different. It's not the RADIUS configuration. Alan DeKok.
On Thu, Jan 12, 2023 at 9:17 PM Alan DeKok <aland@deployingradius.com> wrote:
On Jan 12, 2023, at 8:14 PM, Matt Zagrabelny via Freeradius-Users < freeradius-users@lists.freeradius.org> wrote:
No, not the same machine.
Then test it on the same machine.
Perhaps there's some networking issue which prevents the client from receiving replies sent by the machine running v3.
Indeed. Router ACL. Thanks for initial suspicion of it being network related, Alan. That was helpful. ...and for the rest of this email, which is a set of good debugging steps. Case closed. I look forward to having one fewer 2.0 system to manage. :) -m
Hi I have seen weird responses from some NAS's, specifically on some Ciscos if the reply packet includes a Framed-Compression attribute. If you are handing any of these out in the response, remove it to see if it changes. I hope this is useful to you. Conrad On 2023/01/13 03:14, Matt Zagrabelny via Freeradius-Users wrote:
Hi Alan,
On Thu, Jan 12, 2023 at 6:19 PM Alan DeKok<aland@deployingradius.com> wrote:
On Jan 12, 2023, at 6:18 PM, Matt Zagrabelny via Freeradius-Users < freeradius-users@lists.freeradius.org> wrote:
However if I attempt to auth directly from the UPS to the 3.0 system, it does not work - call this scenario B: Hmm... the typical reason is that the shared secret is wrong. But if that's correct, there isn't much else that can go wrong.
If you're running v2 and v3 on the same machine, and the Access-Accept packets are the same, then it really should work.
No, not the same machine.
I'm not sure if there is more to look at between the 2.0 and 3.0 systems. It is difficult to do any debugging on the UPS, so I was hoping to figure out the issue on the FR systems.
I've performed a diff of the scenario A and B 3.0 debug outputs and I don't see anything significant in the difference. Yeah, that's a problem. Even the debug output doesn't matter as much as the Access-Accept. i.e. the the Access-Accepts have the same contents, then it should work.
I have removed the Service-Type from the configurations and I still get a success authentication, I am just entered into a non-administrative role on the UPS. So the UPS is recognizing the Access-Accept, but not the Service-Type. That is just weird.
Sorry. I wasn't clear. The Service-Type is working as expected. If I remove it from Scenario A, I drop into the console with reduced privileges.
I removed the update reply stanza to simplify the FR configs. Didn't seem to change anything - obviously.
Does anyone have any ideas for further debugging?
I really don't have much to offer here. I don't recall ever seeing this before.
It has to be a networking issue. I can't think of anything else.
That's where I'll look. Though the UPS does contact the 3.0 system just fine (when it is configured to do so) - it just appears that it isn't respecting the Access-Accept.
-m - List info/subscribe/unsubscribe? Seehttp://www.freeradius.org/list/users.html
participants (3)
-
Alan DeKok -
Conrad Classen -
Matt Zagrabelny