January 17, 2017 at 5:52 pm #5368
I’ve successfully created 4 RDS collections.
I also created the 5th – from 0.
New client, new hosted org, etc.
Now – I create the collection, I create org users, then I add users to the session collection.
Here’s the problem:
Absolutely all users in this organization (even those not added to the collection) can login to the rds gateway, and after they login they can see all the collections (even those that belong to other clients). This is a big problem for me.
I’ve done other testing too, like manually creating the user in the same OU, using ADUC, and to my surprise, same issue!
Even if the user is created manually, not part of any other groups other than domain users.
The previous 4 collections that I’ve created using MSPC don’t have this problem.
THanks!0Be the first one to like this.Please wait...January 17, 2017 at 5:54 pm #5369
Worth mentioning that I don’t have a gateway policy which allows “domain users”.
All policies are based on their respective groups.0Be the first one to like this.Please wait...January 17, 2017 at 6:25 pm #5370
You should check your NPS rules, I can confirm that this works properly in our environment and blocks these type of access, it’s in the default rules which are added when creating the RDS system where it allows this to happen, not totally sure which I would check NPS.0Be the first one to like this.Please wait...January 17, 2017 at 8:22 pm #5371
However, NPS looks normal. Nothing that I can’t recognize there, and they’re nicely compartmentized per client/group.
I believe it’s related to how the OU is created, because any user I create in that OU has this problem.
If I create the user in any other OU, it works as expected.
To be honest – I don’t even understand how an OU can authorize users. Give that all these policies use groups, it doesn’t make any sense.0Be the first one to like this.Please wait...January 17, 2017 at 8:23 pm #5372
Not to mention – every session collection has only 1 group authorized.
I don’t understand how a random user can see it.0Be the first one to like this.Please wait...January 17, 2017 at 8:33 pm #5373
If I move the user to another OU, then move back to the original OU – then they can see only their collection.
But they can’t connect to it.
Any user created still sees everything.
I will try to create a brand new collection again, under a new user account, and see.0Be the first one to like this.Please wait...January 17, 2017 at 8:50 pm #5374
OU’s have nothing to do with authorization, ZERO.0Be the first one to like this.Please wait...January 17, 2017 at 9:06 pm #5375
Also make sure your environment complies with the ACL tool.0Be the first one to like this.Please wait...January 17, 2017 at 9:57 pm #5376
Not gonna argue with that 🙂
What’s the ACL tool?0Be the first one to like this.Please wait...January 17, 2017 at 10:24 pm #5377
Created a new collection on a new RDSH – same issue.
The user sees all collections that exist on the broker. And can’t even connect to its own collection.
huh.0Be the first one to like this.Please wait...January 17, 2017 at 10:33 pm #5378
This is not really an MSPControl issue, we don’t have any issues with this from our provisioning. I would say the issue is specific to your environment. I would lean towards some wrong ACL. We added a Security Tool Button on the Org Services. Before applying anything understand then, run backups and make sure you have a way to revert if something goes wrong we are not responsible for usage of this tool.0Be the first one to like this.Please wait...January 17, 2017 at 10:53 pm #5379
This one is funny 🙂
The only orgs that don’t work as expected are the ones that show “correct” in the tool.0Be the first one to like this.Please wait...January 18, 2017 at 1:17 pm #5403
It’s definitely related to the permissions mspc configures on the OU. Accaording to the acl tool, these ou’s are correct. According to real life, it’s a big issue.
Any OU that’s created inside mspc has this issue.
RCAP and RAP are completely ignored. All users by default are allowed to login to the gateway.
Next step is to manually modify the permissions according to a working OU.0Be the first one to like this.Please wait...January 18, 2017 at 1:22 pm #5404
That didn’t work.
At this point, I don’t know what exactly what mspc does to allow the user access to the rds gateway and to see all collections, but I know it’s related to the OU’s permissions.0Be the first one to like this.Please wait...January 18, 2017 at 2:06 pm #5405Denis ShchepetovKeymaster
Something is definitely wrong in your installation. RDS auth rights has nothing related to OU’s permissions.
Our engineers can check and fix (or rebuild) your RDS deployment for a fee, just contact us.0Be the first one to like this.Please wait...
Denis Shchepetov, MSPC support lead, software producer.
E-mail: firstname.lastname@example.orgJanuary 19, 2017 at 4:09 pm #5492
This installation is for a company I work for. We have a paid license, without support.
I will discuss with my boss.
For now – I kinda managed to get around it. I am re-enabling inheritance on the OU, and then the user can only see his collection.
However, this doesn’t allow the user to connect to the session. It gets the typical “your user is not authorized to connect to gateway, etc). It is the same error as before enabling inheritance.
So my solution was to not create the collection in mspc, and only use an AD group to authorize it, which can be managed through mspc. OFC, I have to create the rdcap rap manually, but it’s not a big deal.
Anyway, this is very weird.
Worth mentioning that all the other clients (actually whole infrastructure) were inherited from websitepanel. So I’m pretty sure there are differences between mspc and websitepanel. Not relevant, but I also have to deal with a .lan domain extansion because the domain ahs been around for many years.
As a matter of fact, I’m almost convinced these issues are because of the migration from websitepanel.
I can’t rebuild this domain, as it also has exchange on it, and I really don’t want to do another migration for it..0Be the first one to like this.Please wait...January 19, 2017 at 9:19 pm #5493
On another mspc instance – I “fixed” all the acl’s usint the tool.
No apparent issues.
However – once I did that – my existing RDS infrastructure stopped working, saying that the user did not meet CAP requirements. This is not right, because the users belong to correct groups. Worth noting that all groups and all users were created exclusively in mspc.
Again, related to permissions, my guess is that the gateway cannot read user membership for any user created in a OU.
This is not something that’s wrong with my environment.
MSPC should NOT prevent you from running a separate RDS deployment.
And by changing the OU permissions, basically the gateway (or NPS, or whatever it is, I don’t know the entity it runs under) is “denied” read access to user membership.
What needs to happen here is figure out under which account NPS or RDS Gateway runs under, and allow read permissions to all OU’s.
This is a bug in my opinion.
Any idea what “the entity” requiring permissions is?0Be the first one to like this.Please wait...January 19, 2017 at 9:35 pm #5494
I get the “there is no domain controller available for domain xxx” from this post.
Definitely read permissions.0Be the first one to like this.Please wait...January 19, 2017 at 10:07 pm #5495
Probably related to the domain the ras server is using, which is netbios.
SO this might be related to the removal of pre-win2000 read.0Be the first one to like this.Please wait...January 19, 2017 at 10:48 pm #5496
There should be a group called Preferred Servers which has the right permissions. The point of this group is to grant special rights to services or servers that require it. RDS servers do not, Gateways do not, they have proper rights.
Also read above, MSPControl ACL will stop your 2nd RDS if its in the same domain, the permissions required is very specific, lack of correct application will lead to possible data leakage between tenants.0Be the first one to like this.Please wait...
The topic ‘RDS collection issue’ is closed to new replies.