The delegation of administrative rights in SaaS e-mail protection seems odd, and I wanted to see if anyone can confirm or deny the problem.
I can understand this protocol, but it would be better if there was a level of administration below the level of customer. Since a mail domain is either redirected to McAfee or not, for all users, then it would make sense to have a domain administrator who caould manage all aspects of the domain (including user accounts, mail servers, policies etc. AND have no visibility of other domains.
Have I missed something?
Is there a different product that can do this?
I think there might be some confusion of the different roles.
You may want to refer to the following KB article:
The domain administrator role has the majority of access needed to manage a domain under an account:
Domain Administrator Role -
Domain Level Permissions:
o Add change mail servers/ disaster recovery configuration/ user creation mode
The Group Administrator was not designed to include user-management rights, only the ability to edit policies assigned to that group, e.g. a Domain or Customer Administrator must first assign a user to a group, and from that point the Group Administrator can affect the policies they have ownership of.
Let me know if you have any other questions.
My question / comment is based on that article.
So whereas a domain administrator is only aware of their own domain, but cannot fully manage it, the group administrator has visibility of all users in all domains, but cannot fully manage them. As far as I can tell, only a Customer Administrator can fully manage ANY subset of the users, whether in a group, a domain or any other subset; but they can also manage ALL subsets.
What is needed is a genuine domain administrator, who can administer all aspects of mail for their domain and not see any other domain.
Unless I have misunderstood something, which was the reason for my question.
Correct, the different administrator types are limited in what they can and cannot do, and the only role with all of the customer level actions are Customer Administrators. Domain Administrators were designed to manage the Email Domain, and group administrators were designed to only edit the policies their group owns. While a group administrator can see users and see what groups they are subscribed to, they cannot make changes.
Essentially the Group Administrator was created to allow, for example, the Manager of a department to adjust their own email protection policies independently to avoid placing those burdens on a help desk. Simulaneously each of the other roles were designed to focus on limited areas, with the Customer Administrator having the highest level of access. As far as I understand, part of the reason user account creation is limited to Customer Administrators and the Directory Integration service is because the Customer Administrator will typically be an individual with knowledge of how many user-licenses there are.
I'm going to send up an enhancement request for your desired changes to the Domain Administrator role (which will be described as having full customer administrator access except limited to a single domain on an account). All requests are reviewed by our Product Management team for feasibility but is not assured to be implemented.
Thanks for your suggestions!
Thanks Brad, that is constructive. I appreciate that different customers have different needs, and the current delegation may suit some customers perfectly well.
I have come at it from SaaS endpoint protection, so it is a problem not to have the same type of delegation. It would be fine if group administrators could not see users outside their group. Then a delegate could be either a domain administrator, or a group administrator, or both.