The screenshot below shows an example of an endpoint document for a user:
At the top of the document, you can see:
- the user's name (Amilia Admin)
- the server this information is relevant for
- the type of user it is (which can be person, server, or unknown).
The first tab on the bottom part of the document shows all the databases that the user has access to on this server, along with:
- what their access level is
- what groups gave them this access
- all the roles and actions (like create documents, delete documents, etc.) they have.
The database names and group names are hyperlinks, so you can click on them to get more information about the specific databases or groups in the list.
The second tab shows all the groups the user is in, and all the ways they are members of those groups:
In this example, you can see there are five different ways that they are members of the Administrator Group:
- through the Database Administrators group
- through the Server Administrators group
- through the Web Administrators group
- and also because the Server Administrators group is a member of the Database Administrators and Web Administrators group
It also shows what kind of group access they have: security, mail, or both. Security groups are used for ACL access to databases, and mail groups are used for sending email to the group.
Group membership can be tricky. In the example above, if you just remove the user from the Database Administrators group, they will still be members of the Administrator Group through membership in other subgroups. In fact, if you remove them directly from the Database Administrators group, they will still be members of that group because they are members of the Security Administrators group, which is a subgroup of Database Administrators.
Without endpoint processing, it's very hard to see the web of relationships that are involved with group membership and, ultimately, database access.