Remote Access authentication issue with FreeRADIUS and AD

[kamilazat]

Hello everyone. 

I’m trying to set up a lab with Remote Access authentication scheme where a user will enter his credentials as exist in Active Directory, and then use google authenticator for the second factor.

First, I set up AD on SmartConsole and tested the Endpoint Client with only AD auth. It works fine.

Then I set up FreeRADIUS on a linux machine so that I can use google-authenticator-libpam in the next step (where I haven’t arrived yet). I configured FreeRADIUS to authenticate against AD. Then I checked if it works using the command:

radtest username password localhost 0 testing123

This command returns Access-Accept and I can see the traffic between FreeRADIUS and AD in fw monitor output on port 389. All looked OK.

After making sure that authentication against AD works, I went further and created the RADIUS server on SmartConsole, selected NEW-RADIUS that uses port 1812 as service, and defined it as authentication method under VPN Clients in gateway properties.

Right at this point I go to the Endpoint Client machine and try to connect. No matter what I try I get “Access denied - wrong username or password”. I made sure that there are necessary access rules and also observed traffic during the connection attempt. I definitely see that the GW sends packets on port 1812 to FreeRADIUS, and FreeRADIUS sends packets to AD on port 389. 

I know for a fact that the username and password is correct. I triple checked. So I’m confused as to why I’m getting that error when trying to connect. I can’t even move further to google-auth because I’m stuck at this step.

I’d love to receive your recommendations for how to fix this. It feels like I’m missing something somewhere, but can’t put my finger on it. This is a lab, so I can share all the information you may ask.

Cheers!

[Alex-]

Do you have the "generic*" user in the Legacy SmartDashboard?

[kamilazat]

Yes, radius is also defined there. Although I tried with and without it. No change...

[PhoneBoy]

I assume the default configuration of FreeRADIUS now requires Message Authenticator attributes to be sent/received.
We added support for this as part of the response to Blast RADIUS CVE.
See: https://support.checkpoint.com/results/sk/sk182516 

[kamilazat]

Hi @PhoneBoy I had JHF 76. Installed 99, and compared the recommendations in the sk. Apparently I already have them as required. 

Maybe I'm not getting the architecture properly. What I want to see is something like this:

1. VPN client sends request to GW
2. GW sends the creds to radius server
3. Radius server sends the creds it receives to AD for verification
4. Radius server sends the results of the verification back to GW
5. GW tells the client that it can connect. 

Here I don't have anything setup on freeRADIUS other than ldap-module so that it can authenticate against AD. All user information is on AD.

Maybe I lack some understanding on any of these steps.

[PhoneBoy]

Never heard of someone using FreeRADIUS for the use case of Active Directory.
Microsoft's NPS is known to work for this use case.

[ShemHunter]

Hi PhoneBoy,

I tried using NPS, edicts and attribute 26 and Vendor specific setting, and the problem in windows nps is that it gives two errors: either 16 or 21. If I disable NTLM completely and enable only auditing, it still gives these errors. I tried different versions in 2019 and 2022.. There's no difference at all.

[the_rock]

Weird...so if you do fw monitor on port 1812, what does it show?

Andy

[kamilazat]

Hey Andy, sorry for the late response. I've been trying to find time to pull my hair out trying to understand why it doesn't work and studying the heck out of documentations 🙂 It looks like FreeRADIUS is successfully authenticating, fw monitor sees the traffic on ports 1812 and 389. This is a safe lab for now so I can share all the info here without worries.

FreeRADIUS - 192.168.1.44

AD - 192.168.5.23

And GW's relevant interfaces are .254 on relevant subnets. In the FreeRADIUS logs i see "Can't contact LDAP server. Got new socket, retrying..." but then it looks like it connects, and since the authentication succeeds, I assume the servers can communicate.

As for the settings on the SmartConsole, in the VPN Authentication I only have RADIUS set up (also tried together with username/password, still failed).

- RADIUS settings are:

Service: NEW-RADIUS
Version: RADIUS Ver. 2.0 (I found out that FreeRADIUS is RADIUS Ver. 2.0)
Protocol: PAP

- External User Profile in SmartDashboard:

generic with Authentication Scheme RADIUS

- In Global Properties, radius_ignore is 0 (as recommended in sk182516 as Dameon suggested)
and
SOFTWARE/CheckPoint/VPN1 : { CurrentVersion=[s]6.0 users_hash_capacity=[n]1024 MEPfor3rdParty=[n]1 require_message_authenticator=[n]1 }

If I can understand where to look, then I'll dive right in. I just can't seem to do that.

[the_rock]

Well, first off, dont pull any hair out, its not healthy for you lol

Second, let make sure I get all this, kind of hard to read it properly on an airplane, haha.

I remember while back I got this working for a client by changing radius version and protocol...have you tried that?

Andy

[kamilazat · Accepted solution]

After doing several runs and kinds of kernel debugs, I found my issue. It turns out that I set everything up correctly, but completely forgot that some months ago I created an internal user with the same name. Apparently Check Point prioritizes the internal users over anything else. I deleted that user (since it was not in use), made sure that radius_ignore is set to 80. It all works. In my case, setting "require_message_authenticator" to either 1 or 0 didn't make a difference.

On the other hand I have another question regarding adding two RADIUS servers for authentication, but that's for another post:) 

[PhoneBoy]

Locally defined users always take precedence over ones defined on the authentication server.
You could also set the locally defined user to use RADIUS instead of Internal Password (or whatever method it was before).