Dynamics Community Forum Thread Details

Hi cvolcross,

To perform a successful upgrade, the user who runs Dynamics 365 Server Setup must:

Have an account in the same Active Directory domain as the server or servers that are being upgraded.
Be a member of both the Deployment Administrator Role and the Dynamics 365 System Administrator Role for any organizations that will be upgraded
Have administrator rights on the SQL Server and Reporting Services server associated with the deployment that is being upgraded.
Have sufficient permissions to create new security groups and add members to those groups in the Active Directory organizational unit that contains the existing Dynamics 365 groups.

Referred from MS Doc on 'User permissions and privileges before set up': https://docs.microsoft.com/en-us/dynamics365/customer-engagement/on-premises/plan-your-upgrade-to-microsoft-dynamics-365-server#user-permissions-and-privileges

You could remove the permission after you install. While you need to notify the following some simple rules of administration, you can significantly improve the security of your Dynamics 365 for Customer Engagement on-premises deployment

Typically, there is no need for Customer Engagement users to have administrative privileges over the domain. Therefore, all Customer Engagement user accounts should be restricted to Domain Users membership. Also, following the principle of least-privilege, anyone who uses the Customer Engagement system should have minimal rights. This starts at the domain level. A domain user account should be created and used to run Customer Engagement. Domain Administrator accounts should never be used to run Customer Engagement.
Limit the number of Dynamics 365 for Customer EngagementDeployment Administrator and System Administrator roles to a few people who are responsible for rule changes. Others who are SQL Server, Microsoft Exchange Server, or Active Directory administrators do not have to be members of the Customer Engagement users group.
Make sure that at least two or three trusted people have the Deployment Administrator role. This avoids system lockout if the primary Deployment Administrator is unavailable.
In some organizations it is a common practice to reuse passwords across systems and domains. For example, an administrator responsible for two domains may create Domain Administrator accounts in each domain that use the same password, and even set local administrator passwords on domain computers that are the same across the domain. In such a case, a compromise of a single account or computer could lead to a compromise of the entire domain. Passwords should never be reused in this manner.
It is also common practice to use Domain Administrator accounts as service accounts for common services such as back-up systems. However, it is a security risk to use Domain Administrator accounts as service accounts. The password can easily be retrieved by anyone who has administrative rights over the computer. In such a case, the compromise could affect the entire domain. Service accounts should never be Domain Administrator accounts, and they should be limited in privilege as much as possible.
A domain user account that is specified to run a Dynamics 365 for Customer Engagement service must not also be configured as a Customer Engagement user. This can cause unexpected behavior in the application.

Referred from MS Doc : https://docs.microsoft.com/en-us/dynamics365/customer-engagement/on-premises/best-practices-on-premises-deployments

Hope the above search could help.

Regards

Johnny

Community site session details

User right for on premise installation

Helpful resources

Quick Links

November Spotlight Star - Khushbu Rajvi

Forum Structure Changes Coming on 11/8!

Dynamics 365 Community Platform update – Oct 28

Leaderboard

Featured topics

Product updates