Hello, @dante8888, in AEMaaCS you can give permissions in two main ways.
If you have given access to a user through the Admin Console, a series of Adobe's own groups are assigned to him, which give access to all the content of pages and dam. You can see these groups if you go to Tools > Security > Users, look for a user and in their properties go to the Groups part. It doesn't matter if you delete or not the groups of that user, since they are given from the Admin Console, when the user logs in again, the same groups will be loaded again. The same happens if you decide to create your own group with denys (or allows) to certain paths, it will be indifferent to assign it to the user because their accesses will not be modified (it will ignore the permissions of the group you have created).
The second way, and the only way I know with which you can have a more defined permissions management, is to register users directly in the AEMaaCS environment instead of from Admin Console. You could also make an external login management, that associates groups and users (for example through Azure), that is a separate issue not really necessary, but that would facilitate what I am going to discuss now:
By registering users within the environment, they would have to enter through the “Login locally” option, which is located under the blue button option “Login with Adobe”, where they must enter username and password. For this to work you would have to register them and generate a password for each of them (which can be really tedious if there are many). This password could then be changed by them as they wish. With the users thus registered you can make your own groups and permissions management that will have an effect.
Depending on the need, you would not have to do this management for all users, maybe only for some more specific ones, so that the rest can enter normally. If you have many users, instead of giving them by hand, I would consider making an external login, in our case, we are implementing a Single Sign-On (SSO) with Azure that saves us the problem of passwords and register users in the environment. The creation of groups and their permission settings would be the same for both login cases.
Maybe you already know this, but I would like to add, that when you configure the permissions of the groups try to use as little as possible (and if it is nothing, better), the denys, since they give problems when combined with other groups.
I hope I have answered your questions and have been helpful.
Best regards!
Paula
