Restricting login to RAS

Hello
Does anyone know if there is a way to restrict which Active Directory users can login to RAS?
I know there is a way to filter Published Resources by user or group. However wondered if you could stop all Active Directory users from being able to login.

 

Hi MatE1,
Could you please describe to us why do you want it and what behavior do you expect? Your answers might help me to suggest you something or probably file a new feature request in RAS.
Thanks in advance!

 

Hi Eugene
I can't think of anything specific at the moment. Maybe if there was some security concern where you didn't want a user/group of users to be able to login to RAS. At the moment it seems that any AD user can login and what they can do is only based on the published resources filtering. If that is the case then that is fine. I just want to make sure i am not missing something.
Thanks

 

Hi Mat, thanks for your time.
Indeed a normal practice is to publish resources to a particular AD group and manage members of this group from AD. When people out of the group log into RAS they don't see resources and can't connect to servers.

We don't see a real use case for preventing login to RAS per-user and don't really get such requests (often). That's why we don't have this functionality in the product.
Anyway, I'll count you as "+1" requestor for the corresponding feature and maybe it will be released someday.

At the same time there are few ways to prohibit logon to RAS which work for some situations:
1) Two Factor Authentication.
Parallels RAS has built-in support for various 2FA services. You could configure who can log in to RAS on 2FA side. It helps to increase security in general and save account passwords from being brute-forced.
2) Trusts.
If you have 2 domains in a trust and want only users of 1 domain to be able to login to RAS, then you can configure it in Administration -> Authentication

I can't come up with anything extra at the moment.

 

I have a Windows Server 2019 Environment. I have several VPN users who connect from their home machines to the VPN and then initial outbound RDP connections from the corporate network to another network.

 

Also in active directory you can configure a static remote ip address. Also in the Network Access Permission click Allow to allow the user to connect through VPN, Deny -self explainatory, Control access through NPS network policy you would click if you used NAP.

 

Any other update?

 

This is quite an old forum post, but feel it is extremely important.
If Parallels is accessible from the Internet, I certainly don't want it to be used to bruteforce admin accounts or DDoS them.

Even if 2FA is enabled, username and password can be tried from anywhere in the world. Yes, they can't log in then, but there are accounts where this simply shouldn't be possible at all.

From me (and all colleagues and customers) a very big +1 for this feature. For me it is completely incomprehensible that this supposedly bothers so few people 0.o

 

Counter intuitively, when using MFA (especially if enrollment is ready or admin-managed), brute force in this manner will not be possible.
While RAS has some DOS prevention functionality, it is mostly out of its direct scope.
An allow/deny list sounds like a good idea, but I'm not sure if it can help if there are same named users (administrator) with different domains (local or one in the forest). RDP itself doesn't do that (it authenticates the user before checking the allow list). I'm sure that with some restrictions, it can be done. Hopefully this limitation might be re-reviewed.

 

@jpc Thank you for the answer.
I checked that again and it is not perfect but not as bad as I thought. Guessing usernames is possible, because if a username is unknown, I get a corresponding error message. But guessing passwords does not work. Even if the provided password is wrong, the 2FA request appears and is send to my phone. Only after providing the correct 2FA token, I the password wrong info.

 

A way to control initial login to the RAS Portal is through Themes. You can filter the AD user groups that have access to the theme, restricting in this way the initial login.

 

Good morning,
Be careful, there is a bug. if you use flush from the outside, it is possible for the user to change the theme and go back to the default theme.
Gateways accessible from the Internet should be able to filter the theme.
I reported the security flaw, but nothing is progressing at Parallels

 

If the environment is not very complex, you can use the default theme and apply the restrictions there. No need to create a separate theme.

 

I also have a big issue with Parallels allowing a hacker to sign into an account (via dark web password lists) and register their MFA. Then waiting at the landing page, for desktops/apps to get published.

It just seems like a hacker is getting to 3rd base.

With Citrix, a hacker would get greeted with user name, password, and pass code. They couldn't even get past 1st base. They couldn't even register MFA unless they did so within our workplace, and that was a completely different web link.

But the fact that with Parallels, the hacker can register their own device for MFA and wait for IT personnel to accidentally grant desktops or apps, freaks me out to no end.

Is there a way to use AD groups to limit who can even sign into Parallels? That is where I would want it to stop - at sign in, not after sign in approval and MFA registration.

 

@BillH14 You can limit who has access to the <default> theme if you go to the RAS Console > Farm > Site > Themes > Access.
It will still require the user to successfully auth into AD. That seems how RAS currently identifies the internal user's ID and group ID for access purposes.

 

@jpc I get that we can limit using that method, but imagine this scenario:
- Hacker has a list of passwords collected from the dark web and tries many accounts in parallels. Finally, that hacker scores and gets a password right.
- Hacker is now able to enroll MFA to their device (big issue #1 - if I don't allow a user, a user shouldn't even be able to sign in and register MFA)
- Now the hacker is at the theme landing page, with no apps or desktops currently showing (good), just waiting for someone in IT to give them permissions by assigning them to the AD "Parallels Remote Access" group (accidentally or planned). Hacker then has free rein to all of our servers, before the actual user was even able to enroll their MFA device.

That is where I struggle. As a the head of security in IT, Parallels is severely lacking in all things MFA. This are what needs improving:

1. Blocking a user via AD groups / themes still allows MFA enrollment (bad). Once a user signs in, if they are not a part of the allowed AD group, they should be blocked immediately after sign in, and not allowed to continue on to enroll their phone. That blows my mind that they can.
2. We need to see a list of all employees who are currently enrolled in MFA. Currently we can only search per employee. Why not show the whole list of MFA users?
3. We need to have the ability for Parallels to send notifications when a user enrolls in MFA. Currently there are no notification or alerts that do this.

So when it comes to Parallels TOTP, it need just a little more for the IT Security staff to be able to sleep well at night. But I have hopes that the development team will improve this.

 

@BillH14 I agree that things can be improved. It is usually a good idea to suggest such changes in the "Features Suggestion" sub section of the forum. You already make a very good usage scenario. Since Parallels does monitor the forums for user reported issues, I am sure they already took note of your suggestions but it wouldn't hurt to post there

However, I think issue number 1 can already be mitigated by restricting the theme access to only allowed users. When I set the option "Limit access to this theme to members of these Active Directory groups:" under Farm > Site > Themes > <Default>, only users in the allowed groups list can register for MFA. I tested this and I get the following message before registering for MFA:



The "restrictions" tab under MFA settings is there to limit where MFA is used (i.e., allow admins to disable or enable MFA only under certain scenarios). I do NOT think that tab is useful for your use case.

 

@jpc I already set those settings (see below). If a user isn't a part of the Parallels Remote Access AD group, they can still sign in AND enroll before they are denied access.

Make sure the account you are testing with isn't already enrolled in MFA and if they are, delete the MFA and try it again.

 

@BillH14 I was rebuilding a testing environment today and I can confirm that you are right. I am pretty sure that with the previous test environment it was working without any MFA request during login, however there might have been some other settings (maybe something stupid like incorrect or missing MFA settings). In any case, on a new environment, I replicate your behaviour. I hope that you reported this issue to Parallels Support so that it can get looked into.