Tag: Azure AD

Azure AD Connect and .NET Framework 4.7.2

Introduction

Last week a discussion erupted on Microsoft forums regarding Azure AD Connect due to it’s Monitoring Agent using all free resources of CPU on the servers. These issues were caused by a .NET Framework update and a lot of administrators spent time uninstalling and blocking these patches to resolve the CPU usage issues on their servers. On Saturday Microsoft released an update (KB4340558) which contains a collection of several patches where one of the earlier mentioned .NET Framework updates were included. For more information, see this link.

Microsoft has recently published an article regarding this issue. In addition, Microsoft also published a new version of the health agent where they state that the issue is resolved, it can be downloaded from here. The new health agent version is set to be included in the next version of Azure AD Connect, which will be published for Automatic Upgrade (Auto Upgrade). The following patches have been identified with issues causing Azure AD Connect’s monitoring agent using huge amounts of CPU:

Auto Upgrade

In version 1.1.105.0 of Azure AD Connect, Microsoft introduced Auto Upgrade. Although, not all updates are published for Automatic Upgrade. Whether a version is eligible for automatic download and installation will be announced on Microsofts version-history website for Azure AD Connect.

You can verify whether your Azure AD Connect installation have Auto Upgrade enabled by either using Powershell or viewing your configuration in It’s GUI.


Graphical User Interface of Azure AD Connect
PowerShell-command for determining whether Auto Upgrade is enabled or not.

This command will return either Enabled, Disabled or Suspended, where as the Suspended state only can be set by the system itself. Newer installations of Azure AD Connect enables Auto Upgrade by default, in case your installation applies to Microsoft’s recommendations. For more information, see this link.

Enabling Auto Upgrade

In case you have an installation of Azure AD Connect older than 1.1.105.0 (February 2016), Auto Upgrade will be disabled, if you’ve not enabled it manually. Enabling this function can be done with below PowerShell-command if so wanted.

If you have any questions, feel free to email me at robert.skyllberg@xenit.se



Device cleanup rules for Microsoft Intune

As an IT Administrator you want to keep your IT environment clean and tidy and the same goes for Microsoft Intune.

By default all devices that has been inactive or stale and hasn’t checked in for over 270 days will automatically been removed from the console.

In the latest update for Microsoft Intune dated July 2, Microsoft included a new feature, Device cleanup rules:.

New rules are available that let you automatically remove devices that haven’t checked in for a number of days that you set.

 

You will find it in the Intune pane, select Devices, and select Device Cleanup Rules:

By default, this is not enabled, so you need to change it to Yes and specific the numbers of days between 90 and 270 that suites your company’s policy and requirements.

If nothing is changed or you remain it set to No, it will use the default 270 days:



Block external access for Service Accounts using Conditional Access in Azure AD

Conditional Access in Azure Active Directory is normally used for users and administrators to secure and control company data in Office 365 and Azure, but what about Service Accounts? Aren’t they a potential security risk?

Using Service Accounts for scripts and other tasks related to Office 365, Azure and Azure AD is a normal practice along companies, sometimes the accounts has full administrative permissions (Global Admin for Office 365, Owner of a subscription/resource group in Azure) and sometimes the accounts has delegated privileges but they all have more permissions than a regular user.

In this post we will cover how you can use Conditional Access to block sign-ins from service accounts outside the company main datacenter to make sure they are only used on servers located on networks that the company has control over.

  1. Open portal.azure.com and go to Azure Active Directory and Conditional Access under Security
  2. Go to Named locations and Add the external IP address of the data center(s) that should be allowed for the service accounts to sign-in from.
  3. Create a new policy and name it “Block external access for service accounts
  4. Select the Service Accounts or an Azure AD Group, in our case we use a groups that will contain all the service accounts
  5. In Cloud apps, select All cloud apps
  6. For Conditions, select Locations and Configure. Select Any location in the Include tab
  7. Also in Conditions and Locations, select the Exclude tab and select the location of the data center added in step 2.
  8. For Access, go to Grant and select Block access
  9. Select On for Enable policy, and verify all settings before creating it.
  10. The policy should now look like the following:
    Conditional Access policy - Block external access for service accounts

    Conditional Access policy – Block external access for service accounts

     

You can find out more about Conditional Access on docs.microsoft.com:

https://docs.microsoft.com/en-us/azure/active-directory/active-directory-conditional-access-azure-portal 



How to join a Windows 10 computer to your Azure Active Directory

Introduction

Some of the benefits of having your Windows 10 devices in your Azure AD is that your users can join the computer to your Azure AD without any extra administrator privileges, assuming you have configured this in your Azure AD. They can also login to the computer without the need of being connected to a specific company network the first time, as long as they have internet connection. You can also manage your Windows 10 devices wherever it may be in the world.



Devices i Azure AD – varför det är viktigt

Devices i Azure AD – varför är det viktigt? I princip alla organisationer vi arbetar med har ett traditionellt on-premise Active Directory. Många av dessa börjar nu använda Office 365 och Azure, ofta börjar det med Exchange Online för mail och växer sedan till att börja använda Skype, OneDrive, Teams eller någon av de andra tjänsterna Office 365 erbjuder. I botten av allt detta är ett Azure AD, detta är något alla får eftersom så fort du skapar en Office 365 tenant får du också ett Azure AD som är användarkatalogen. Vare sig du sedan editerar användarna i Office 365 admin portalen (https://portal.office.com) eller Azure AD admin portalen (https://portal.azure.com) så är det grund och botten ditt Azure AD du ändrar i.