Multiple Login Options - RADIUS

[Daniel_Collins]

Hello,

Hoping the community can help me with an issue I'm trying to solve. Our customer is trying to migrate away from one RADIUS based solution to another RADIUS based solution, doing so incrementally. They mentioned "Multiple Login Options" which seems to do what we want to do.

I setup Multiple Login Options as per the guide (this is for R80.10 with a client supported for the multiple login options) with two profiles, both RADIUS but pointing towards different RADIUS servers. This all looks correct, but it does not work - when using the MLO settings the authentication fails with "Failed to generate RADIUS auth request" but works fine when we use the legacy authentication settings. When attempting to use the MLO options the RADIUS server is not contacted at all.

My question here is thus:

1. Can anyone else think of a way to migrate away (in a staged manner) from one RADIUS based authentication solution to another other than what's suggested above?

2. I believe my configuration may not be setup correctly, but it is as far as I can tell as per the documentation. How does the firewall handle authentciation when using third party auth? (I was of the understanding both user and password were sent to the RADIUS server, but I don't think this is happening) I understand the old fashioned way of doings but this appears to be different.

3. Is MLO designed to work with profiles where each one points to different authentication servers using the same protocol? (I can see it being aimed more towards customers that use a mix of AD and say RSA SecurID tokens)

Any help appreciated.

Thanks

Daniel

[PhoneBoy]

I think Multiple Login Options is meant to support two different types of authentication, not two types of the same authentication.

But just in case, does this older SK apply? FireWall-1 drops FTP Server usernames with @ symbol 

[Daniel_Collins]

I had thought as much, but couldn't find much out about "proper" deployment.

Yeah, support had mentioned that to me - but there's no @ in the username, plus with the age of the article I thought it might not be relevant.

[PhoneBoy]

It refers to the FTP Security Server, which no one should be using at this point

[npulido]

Hi Daniel,

I have the same customer scenario than yours. Someone in support suggested to use an intermediate or proxy Radius that would redirect towards original or new Radius servers, based upon some user attribute (ideally user group). But it seems too complicated to me. Did you find any other smater solution for your migration?

Many thanks in advance.

[Daniel_Collins]

So I'd like to add some more to this, after a few years! 

From my understanding of the way that Check Point works, this is not possible. I've yet to find a way migrate users from one authentication scheme to another, except in a "big bang" change of course. 

I've found that when I create an MLO profile, on a customer's environment that's been using legacy "Defined on User Record" authentication as soon as that profile is detected - the VPN client's use that instead of the existing authentication scheme. This is a challenge, when you're trying to stage changes in steps.

Setting a RADIUS server on an account unit, also only respected when doing legacy authentication. If you use MLO then that configuration is ignored - as an alternative to migrate users from AD Auth to RADIUS would have been to set the default auth scheme on the Account Unit to RADIUS and send MFA traffic to the RADIUS proxy that way. 

Useless when trying to use MLO as this is ignored.