Remote Access improvements

[Pedro_Boavida]

Hello CheckMates members,

In the past weeks, due to this new remote work requirements, I have been doing otimizations and fine tunning in many VPN gateways, this time with much more demanding scenarios.

While performing such configurations, I've noticed some questions / constraints:

• How to specify that a given group (ex: LDAP group) is tied to a specific authentication method ? If we are talking about the same domain (LDAP Account Unit) there seem to be no means for that.

• For the case where several gateways are managed by the same management (most of the cases) it should be possible to have more than one Remote Access community, for several reasons.... 

• Mobile Access (Unified vs Legacy)

Previously on Legacy Mobile Access, only users posing on at least one MAB Access rule were allowed to authenticate to the portal. Now, with Unified Mobile Access, users must belong to remote access community in order to authenticate properly.

This brings a limitiation where I can no longer differentiate who can authenticate on the Mobile Acess Portal from who can authenticate using remote access clients. I have to rely on access rules to permit or forbid access to resources, but in what concerns authentication process it didn't improved from legacy to unified...

I think this constraints are affecting many people and therefore it should be improved, don't you think ?

Regards

[PhoneBoy]

Can you provide a concrete example of the different LDAP Groups requiring different authentication methods?

Right now, there is only one Remote Access community per management domain.
I can see where that might be useful but you can achieve the same effective result with appropriate Access Rules.

As for issue with Unified versus Legacy, I suspect there is more work to do in terms of simplifying this.

[Pedro_Boavida]

Hi Dameon,

Of course, an easy example is to have a given set of users (regular users) who belong to a specific ad group (say group A) and another set of users (power users) belonging to another specific group (say group B), both within the same Active Directory.

Now, the goal is to assign to group A (regular users) a specific method for authentication (eg: username and password) and to group B (power users) another specific method (eg: Two Factor - username and password + DynamicID).

So if one want to make a more strong /secure authentication for group B (power users) BUT simultaneously want to provide simple method for group A (regular users), this will subvert such principle because power users can also access with username and password....

Now imagine that you want to have several authentication methods and several users profiles (groups), tied to their respective methods. How would you solve this ?

Regards,

[PhoneBoy]

I believe a lot of what you want is right here in the gateway object:

In short you can:

1. Define multiple authentication schemes.
2. Tie each one to specific LDAP groups. 

I will admit, I don't know if this will work exactly the way you want it, but this seems the most promising.
I'll check with R&D.

[Norbert_Bohusch]

For that you need two different directories. It can't be tied to individual groups in the same directory.

[Pedro_Boavida]

Dameon,

Thanks for your answer but like I described earlier the challenge is between LDAP_Groups within the same directory - wich is the most common scenario.

Regards,

[PhoneBoy]

It seems to me you can choose different LDAP groups within the same directory for the different authentication methods (at least as I understand this dialog).
What happens when you do that?

[Pedro_Boavida]

Hi,

Unfortunately you cannot. You can only choose a specific directory or a set of directories but not an LDAP_Group.

Also, you cannot have two LDAP Account units for the same domain (with different search bases).

I think it's a "dead end".... thats why I was suggesting an improvement.

Regards,

[Gaurav_Pandya]

Yeah. I agree with Pedro. 

I am facing same issue. We want to use 2 different authentication for different user group but it is not possible as we have only one LDAP account unit.