Originally, I had Morpheus set up such that users who were unmapped to a role from their LDAP-authenticated Identity Source, would fall into a role called DEFAULT-CATALOG. I have now decided that I should not let people in our corporation who theoretically could log in via LDAP, but whose groups are not “properly provisioned” have the ability to log in and instantiate VMs. This is a bad security practice for starters, and these people would not have set up budget codes and therefore could be launching VMs on our platform without proper tracking and cost recovery. So now, I have put a role up that is called UNASSIGNED-RESTRICTED-DEFAULT, and disabled Catalog Persona and ALL Features are set to None. What this does, is give the user their Personal Settings page. I would prefer to give these kinds folks a default landing page for unmapped users that lets them know they’re in jail, and what to do to get out of jail (meaning, who to contact to get set up properly). Are there any recommendations and suggestions on the best way to pull this off?
As you mentioned, the user will land at their user settings, but cannot navigate anywhere else, due to their lack of access. An alternative could be to utilize the Required Group field, and have the user receive an authentication error at the Morpheus login page. You’d just need to make sure to nest your current Morpheus groups under that required group, to ensure they can still access Morpheus and anyone not in a Morpheus group would be denied access to logging in.
Although it is not exactly what you are looking for, it may reduce the confusion to the users and they’d know that they are not authorized at least. This might end up being an Idea to submit on the Ideas area, such as a default page (Morpheus internal or external) that users of a certain role are directed to, a generic error page, or custom error pages of sorts. Just to note, all users receive the Default Role as well as any mapped groups, so the this may not work out as hopped but just coming up with some ideas.
Hope that helps!
Well, the problem with Required Group, is that we have a ton of different groups, and these all have individual AD Security Groups upstream in Active Directory. Some users are members of multiples of these, but we never know who is in what group, and we don’t have the ability to easily administer the corporate LDAP/AD servers to set up some kind of a “common denominator” group that every Morpheus user would be in. The other issue, is that we have contractors. And sometimes these contractors might be working with Group A, but they’re not in the AD Security Group for Group A and I have to manually plop them into the right role. When I was testing this stuff out, I realized that one of our employees in a complete other business unit (under the Cox umbrella) could authenticate, and get to a Dashboard page and launch some VMs. We can’t just let anyone in the large corp, regardless of subsidiary company, log into Morpheus and do that. Too risky. We need a nice page to push people to who authenticate successfully, but are not properly “onboarded”.