Administration best practices for on-premises deployments of Microsoft Dynamics 365

  • Article

 

Applies To: Dynamics 365 (on-premises), Dynamics CRM 2016

By following some simple rules of administration, you can significantly improve the security of your Microsoft Dynamics 365 on-premises deployment.

  • Typically, there is no need for Dynamics 365 users to have administrative privileges over the domain. Therefore, all Dynamics 365 user accounts should be restricted to Domain Users membership. Also, following the principle of least-privilege, anyone who uses the Dynamics 365 system should have minimal rights. This starts at the domain level. A domain user account should be created and used to run Dynamics 365. Domain Administrator accounts should never be used to run Dynamics 365.

  • Limit the number of Microsoft Dynamics 365Deployment 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 Dynamics 365 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 Microsoft Dynamics 365 service must not also be configured as a Dynamics 365 user. This can cause unexpected behavior in the application.

See Also

Security considerations for Microsoft Dynamics 365
Security best practices for Microsoft Dynamics 365
Network ports for Microsoft Dynamics 365
Security concepts for Microsoft Dynamics 365

© 2016 Microsoft. All rights reserved. Copyright