we have our permissions set up in a way, that projects use 2 AD groups, one for pre-production environments and one for production environments. Of course the respective groups only have permissions on the environments, where they should be able to deploy to.
It turns out though, that if a user has the same ID in both of those groups, he gets a permission denied error when running deployments?
The error occurs on the step "ROC - Get Deployment Steps"
So the user is able to start the deployment, but some permission check in this action prevents the execution
CARA Version: 18.104.22.16818
Is this known?
I have not came across similar problem and my anticipation was to have a union of permission based on the user-id. In this case if the user is part of two AD groups he should get union permission set inclusive permission from both groups.
As the error you mentioned it looks like the union permission set is not happening.
May I request if you can please open a support ticket along with the NAC logs (making sure recreation coverage is there) + user-id used.
we thought the same and overall this seems to be the case, otherwise he wouldn't even have been able to start the deployment. But it seems like this action does something fishy in the background and doesn't consider those union permissions.
I will try to recreate it in our dev and open a case with the logs, as I don't think I get it back from the time it actually happened, cause this was last week, when I wasn't in the office.
failed to reproduce it.
The only other thing that would come to my mind now, would be that the permissions itself weren't fully synced because it was a new member in the AD group.
But not sure at all about this.
btw. it wasn't just the get deployment step action, the ROC action to read the parameters failed as well
I was able to reproduce the issue now.
It looks like the problem is caused when the user is also imported directly.
So basically some permissions are granted via an AD group, another on the directly imported user.
I'll grab the logs and will open a case with reference to this thread here.
Here is how I reproduced it:
- Imported AD group with my user in it: granted permission on one environment of one test application
- imported my user that is also in the group directly and gave him no permissions yet (next test would have been to grant it permissions only on another application, but the error already occured)
=> Granting my direclty imported user ONLY permissions on the application, not the environment itself, alraedy solves the issue
Because granting the permissions on application level is enough, I would assume that the ROC actions somehow fail to grab the union permissions, if the imported user as no permissions at all on the application itself. It might be, that the permission check goes in order, to first check the directly imported users and then the ones being part of AD groups. So the first check fails, because the user simply can't even see the application, if only the imported user is taken into account
Why can I only create a case for products "CA SUPPORT PORTAL" or "Licensing" and not Release Automation like before?
Do I need to open one for "CA SUPPORT PORTAL" now? jaisa05
I am not sure if there is an issue with some permissions.
May I request reaching to Global Customer Support and they will be able to assist.