Keep your Microsoft Dynamics 365 CRM Data Secure – Azure AD Best Practices After MFA – Part 1
Your Microsoft Dynamics 365 CRM is a database packed with invaluable information on your business. It deserves the best protection you can provide. From prospects, customers and service issues, purchasing, and so much more, your business can’t function without this information. A security breach that puts this data in the wrong hands would be nothing short of devastation.
While your everyday CRM users are probably focused on serving or selling, they’re probably not thinking about their every action as it relates to security. Setting up Multi-Factor Authentication (MFA) with Microsoft Azure AD is a great first step, but there are other best practices that can maximize your organization’s data security in the cloud while still providing an end user experience that promotes productivity.
Eric Raff, Cloud Practice Director at JourneyTEAM, in a presentation hosted by buckleyPLANET to the Utah SharePoint User Group (UTSPUG) and Microsoft User Group (MUGUT), shared the top 10 security tips and considerations after you’ve rolled out MFA in your Microsoft Dynamics 365 tenant. Raff is a 25+ year expert in Identity and Access Management in and .
This is a two-part blog. In Part 1 we cover first five of the top 10 Microsoft Dynamics 365, Windows Azure and Microsoft Cloud Services security tips after you’ve deployed MFA. Many of the security steps involved with these best practices require that you have Azure ADP2 or the Microsoft Enterprise Mobility + Security (EM+S) mobility management and security platform.
1. Azure Portal Settings: Two Suggestions
Log into portal.azure.com and check on these two settings:
- Go to “User Settings.” You should restrict access to the Azure AD Administration Portal — to do this, make sure this is set to “Yes.”
- Also, check out the name of your tenant. This will show up whenever there is a Microsoft OneDrive sync integration. Make sure it is relevant!
2. Set Restrictions on Guest User Access
Do you know how many guest accounts you have in your tenant? If you don’t know the exact number, you should at least be aware of where you can find out. The default External Sharing Setting is “Allow guests to share items they don’t own,” meaning sharing content with anyone can be done anonymously, including guests. Your guests can also invite other guests. This is an ideal area to create some restrictions. Thankfully, “Restrict access to the Azure AD Administration portal” is “no” by default!
The Identity Governance solution in Azure AD P2 can set restrictions on guest accounts with Access Packages and Access Reviews.
Access Package
- In the Azure AD Portal, click > “Settings.”
- Select what happens when an external user that was added to your directory through an Access Package request loses their last assignment under “Manage the lifecycle of external users.”
- This allows you to block external users from signing into the directory and will remove an external user after a set number of days. This only works if the guest account came in via an Access Package.
Access Review Policy
- From the Azure AD Portal, click “Identity Governance” > “Access Review.”
- To create a new Access Review:
- Select what to review by “Teams + Groups,” or “Applications.”
- Select a specific group, e.g., “All Guests.”
- Select a review scope: “Guest Users Only.”
- Adjust the settings to your preference. You can set up a policy that ensures guest access only to those that truly need it. Your policy could put the responsibility on the users to review their access. If they don’t respond to a review request in a specific amount of time, they may be blocked from signing in for 30 days, then later removed from the tenant.
- At myaccount.microsoft.com you can self-manage your guest account in other directories as well as completely delete guest accounts you don’t use. Go to “Organizations” and click “Leave Organization.”
3. Manage Consent and Permissions for Enterprise Apps
Cyber criminals now use fake enterprise apps to gain access by convincing you into consent. New functionality in the Azure Active Directory Microsoft 365 environment allows for greater consent governance.
- Head to “Enterprise Apps” > “Consent and Permissions.”
- Here you can manage user consent and permissions from verified publishers.
- Once an app is a verified publisher and you set up the permissions, users will only be able to consent to those actions.
Next, check the user settings under “Admin consent requests (Preview).”
- Change “Users can request admin consent to apps they are unable to consent to,” to “Yes.”
- Click “Select users to review admin consent requests” and select an appropriate Admin (should be Global, Application or Cloud Application Administrator) who will be notified and make the decision to allow or reject consent.
A last note, if you as a Global or an Enterprise App Administrator ever see a “permissions requested” box with the option to consent on behalf of your organization, proceed with caution. You will be consenting for everyone in the tenant and should be sure about this decision.
4. Block Legacy Protocols
Hundreds of spray attacks can happen every hour that target legacy protocols such as SMTP, IMAP, POP, Active Sync, Outlook Anywhere (RPC over HTTP), and older Office clients, such as 2010 and 2013.
Identify who is using legacy protocols in the environment:
- Log into the Azure AD portal (portal.azure.com).
- Click to “Sign-Ins” > “Monitoring.”
- Make sure you have the new experience turned on.
- Click “Add Filter” > “Client App” > “Apply.”
- You can then review the client apps and see a list of Legacy Authentication as well as review the successful and failed attempts.
Now you have what you need to build a Conditional Access (CA) policy to block access.
- Navigate to “Security” > “Conditional Access” > “Classic Policies.”
- Here you can create a new policy that blocks legacy protocols. Be sure it targets all users (except your “break glass” account).
- Go to “Conditions” > “Client Apps” > “Legacy Authentical Clients.
- Set access controls to “Block Access”
5. Check Your Security Defaults
Before following this tip, be aware that using Security Defaults is only suggested if:
- No Conditional Access policies are enabled in your environment.
- You don’t need fine-grained control over access and authentication.
- Your organization is relatively small.
Microsoft’s Security Defaults are basic recommendations for identify security mechanisms and provide a great baseline of features, but you should still consult an expert to confirm if Security Defaults is the right choice for your organization.
To turn on defaults:
- From the Azure AD Portal, go to “Properties.”
- Make sure that Security Defaults is set to “Yes.”
What Security Defaults activate or enforce:
- Requires all users to register for Azure MFA.
- Administrators must perform MFA.
- Blocks legacy authentication protocols.
- Users must perform MFA when risky activity is detected.
- Access to the Azure Portal and other “privileged” activities will be protected.
Be sure that “Users can use the combined security information registration experience” is turned on.
Click here to continue and read up on tips 6 – 10!
NEXT STEPS:
- Join a free consultation and ask all the questions you wish.
- Plan your Deep Dive meeting – Get your organization’s Customized Solutions presentation.
Article by:Jenn Alba – Marketing Manager – 801.938.7816
JourneyTEAM is an award-winning consulting firm with proven technology and measurable results. They take Microsoft products; Dynamics 365, SharePoint intranet, Office 365, Azure, CRM, GP, NAV, SL, AX, and modify them to work for you. The team has expert level, Microsoft Gold certified consultants that dive deep into the dynamics of your organization and solve complex issues. They have solutions for sales, marketing, productivity, collaboration, analytics, accounting, security and more.