Suit up and Superpower your Azure AD Tenant

Suit up and Superpower your Azure AD Tenant

This article ‘Suit up and Superpower your Azure AD tenant‘ is part of the Festive Tech Calendar 2020. An online event by the community, for the community!

superpower your azure ad tenant

 

1. What is this blog post all about?

Well, most of you know me from writing Intune related blog posts, but I wanted to do something completely different this time! So I’m gonna go over some of my best practices of settings in Azure AD.

Why? Because a lot of settings that come out-of-the-box with a new Azure AD tenant are not that safe, not in my eyes though.

Let’s get on with it!

 

2. Security Defaults

First thing to talk about is Security Defaults. It’s something well hidden in Azure AD, but for the smaller organizations, I can only recommend putting this one.

In what case will we not use Security Defaults? If you use custom Conditional Access policy’s you’ll have to turn it off. You’ll have more control with custom CA policies. But for smaller organizations who want their security uplifted in a very easy way. You can just put it on.

How to get there? We’ll navigate to the azure portal (portal.azure.com). Go to ‘Azure Active Directory’, click on ‘Properties’, click on ‘Manage Security Defaults’. Then choose to Enable or Disable this setting.

Now what happens when we activate this? This will enable the following:

  • Requiring all users to register for Azure AD Multi-Factor Authentication.
  • Requiring administrators to perform multi-factor authentication.
  • Blocking legacy authentication protocols.
  • Requiring users to perform multi-factor authentication when necessary.
  • Protecting privileged activities like access to the Azure portal.

So as you can see, a standard set of security features will be activated. No custom Conditional Access policies necessary.

More information on Security Defaults Azure Active Directory security defaults.

 

3. User settings

Some of the user settings in Azure AD come not so safe out-of-the-box also. Take a look at this newly created tenant’s settings:

First thing that’s not logical here is the ‘User can register applications’ setting. Do we really want our end users to be able to register applications in Azure AD? In my opinion, I don’t think so. We don’t want any hacks happening through registering applications. I’ll dive deeper into this subject a bit later, but my advice here is to put it on ‘No’.

You can also restrict your non-admin users access to the Azure AD administration portal. But this setting does not matter that much in my eyes. I’ll keep it at ‘No’ in my tenant also.

Let’s click on ‘Manage external collaboration settings’ and see how those settings come out-of-the-box:

The most important thing to discuss here for me is the following settings: ‘Guests can invite’.

Do we really want our guest accounts in Azure AD to be able to invite other guest accounts. In my opinion this is a hard No Go. So I always put this setting on ‘No’.

Let’s go back one blade, to the ‘User settings’ and click on ‘Manage user preview settings’.

These settings come out-of-the-box:

Now for production environments, it’s maybe not optimal of enabling these settings to ‘All’. Because all preview settings in Azure AD will be enabled for all your users, and we don’t want that. But what we do want is enabling them for a closed group, like the IT department. Or the ambassadors of your organization. This way you can enable preview features faster for a closed group and they can start playing with it.

For demo environments of lab environments you can easily put these to All of course.

 

4. Group settings

Let’s take a look at the out-of-the-box settings first:

I’m gonna go over two settings here that may be up for discussion: ‘Users can create security groups in Azure portals’ and ‘Users can create Microsoft 365 groups in Azure portals’.

Do we really want all users (also non-admin users) to be able to fill up our Azure AD tenant with groups, groups and even more groups? I mostly put these settings to ‘No’. But this will all depend on your project, the size of the organization and the governance of your tenant of course.

 

5. Enterprise Applications

This is a very interesting topic, and so many settings that come in a badly configured way. I could write a book about this topic, but Thijs Lecomte already spoke about this in depth. So I’ll just recommend you watch his video on YouTube:

Also make sure to check out Thijs his blog: 365 by Thijs – Blogging about Microsoft 365, Azure and Automation!. A lot of good stuff in there!

 

6. Device settings

Again, let’s first take a look at the settings as they come out-of-the-box:

There is not that much to say here, but I really am not a fan of putting scopes to ‘All’. I’d rather scope all of this off. Why? I don’t like enrollment errors, I like it scoped off, is it my OCD? Nah, it’s just my best practice.

How do I scope it off? I scope it off to User Groups with users in it who have the right license to enroll devices in Azure AD. Ain’t that neat.

If you have MFA already enabled in your organization (and if you don’t, just f******* do it!), I also recommend enabling ‘Require MFA Auth to join devices’.

 

So that’s about it with my best practices for Azure AD settings. This was fun to write about so I’ll be posting follow up blog posts about my best practices for Intune settings and much more in the coming weeks. Hang on!

And happy festive holiday testing!

 

 

 

More Festive Tech Calendar posts: