This topic has 21 replies, 3 voices, and was last updated 3 years, 1 month ago by Bogdan Cerbulescu.

  • Author
    Posts
  • #5368

    Hello,

    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.
    I’m puzzled.

    Any ideas?

    THanks!

    0
    Be the first one to like this.
    Please wait...
    #5369

    Worth mentioning that I don’t have a gateway policy which allows “domain users”.
    All policies are based on their respective groups.

    0
    Be the first one to like this.
    Please wait...
    #5370
     MSPControl
    Keymaster

    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.

    0
    Be the first one to like this.
    Please wait...
    #5371

    Good point.
    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.

    0
    Be the first one to like this.
    Please wait...
    #5372

    Not to mention – every session collection has only 1 group authorized.
    I don’t understand how a random user can see it.

    0
    Be the first one to like this.
    Please wait...
    #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.

    0
    Be the first one to like this.
    Please wait...
    #5374
     MSPControl
    Keymaster

    OU’s have nothing to do with authorization, ZERO.

    0
    Be the first one to like this.
    Please wait...
    #5375
     MSPControl
    Keymaster

    Also make sure your environment complies with the ACL tool.

    0
    Be the first one to like this.
    Please wait...
    #5376

    Not gonna argue with that 🙂

    What’s the ACL tool?

    0
    Be the first one to like this.
    Please wait...
    #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.

    0
    Be the first one to like this.
    Please wait...
    #5378
     MSPControl
    Keymaster

    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.

    0
    Be the first one to like this.
    Please wait...
    #5379

    This one is funny 🙂

    The only orgs that don’t work as expected are the ones that show “correct” in the tool.

    0
    Be the first one to like this.
    Please wait...
    #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.
    Scary.

    Next step is to manually modify the permissions according to a working OU.

    0
    Be the first one to like this.
    Please wait...
    #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.

    0
    Be the first one to like this.
    Please wait...
    #5405

    Bogdan,

    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.

    0
    Be the first one to like this.
    Please wait...

    Best regards,
    Denis Shchepetov, MSPC support lead, software producer.
    E-mail: d@hosting.build

    #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..

    0
    Be the first one to like this.
    Please wait...
    #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?

    0
    Be the first one to like this.
    Please wait...
    #5494

    I get the “there is no domain controller available for domain xxx” from this post.
    Definitely read permissions.

    0
    Be the first one to like this.
    Please wait...
    #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.

    0
    Be the first one to like this.
    Please wait...
    #5496
     MSPControl
    Keymaster

    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.

    0
    Be the first one to like this.
    Please wait...
Viewing 20 posts - 1 through 20 (of 22 total)

The topic ‘RDS collection issue’ is closed to new replies.

©2020 MSPControl | Privacy Policy

Log in with your credentials

or    

Forgot your details?

Create Account