Month: July 2019

Auto-Enroll AD joined computers into Microsoft Intune using local GPOs and AADConnect

Carlos A Lopez (Twitter: @CLopezDC) AAD Connect, GPO, Intune

Many have asked me about the option on how to automatically enroll AD computer (Hybrid domain joined) in Intune MDM.

Let’s assume the following as a main pre-requisite

  • The computer are AD-joined PCs running Windows 10, version 1709 or later
  • The enterprise has configured a mobile device management (MDM) service (Intune is enabled)
  • Devices are synchronized with Azure Active Directory
  • The device should not already be enrolled in Intune using the classic agents (devices managed using agents will fail enrollment with error 0x80180026)

So now, it is time to add those synced computer objects, that should be appearing in your Azure subscription, to your MDM service. For this process we will use a GPO setting.

If you do not see the policy, it may be because you don’t have the ADMX installed for Windows 10, version 1803 or version 1809. To fix the issue, follow these steps:

  1. Run GPEdit.msc
  2. Create a Group Policy Object (GPO) and enable the Group Policy Computer Configuration > Policies > Administrative Templates > Windows Components > MDM > Enable automatic MDM enrollment using default Azure AD credentials.

  

    • If you do not see the policy, it may be because you don’t have the ADMX installed for Windows 10, version 1803 or version 1809. To fix the issue, follow these steps
    • Download: 1803 –>Administrative Templates (.admx) for Windows 10 April 2018 Update (1803) or 1809 –> Administrative Templates for Windows 10 October 2018 Update (1809).
    • Install the package on the Primary Domain Controller (PDC).
    • Navigate, depending on the version to the folder: 1803 –> C:\Program Files (x86)\Microsoft Group Policy\Windows 10 April 2018 Update (1803) v2, or
      1809 –> C:\Program Files (x86)\Microsoft Group Policy\Windows 10 October 2018 Update (1809) v2
    • Copy policy definitions folder to C:\Windows\SYSVOL\domain\Policies.
    • Restart the Primary Domain Controller for the policy to be available. This procedure will work for any future version as well
  2. Create a Security Group in your PC and all the computer (PCs) you would like to add to Intune.
  3. Link the GPO to the device OU
  4. Filter the GPO using Security Groups (Adding the new group created)
  5. Enforce a GPO link to the OU

Computer will start showing up in the Intune portal as enrolled in MDM.

 

Directory Requirement for Exchange Hybrid Using Okta SSO

Carlos A Lopez (Twitter: @CLopezDC) AAD Connect , ,

This week I have been supporting client that already has a Office365 Tenant with account synchronized using Okta Universal Sync. The client would like migrate the mailboxes and stablish an Exchange Hybrid.  While the client requested that they wanted to avoid using AADConnect and would like to keep using Okta Universal Sync. There are some consideration we need to take into account.

  1. Microsoft does not support an Exchange Hybrid deployment that does not have AADConnect (DirSync legacy) to syncronize the AD objects.
  2. Okta does not recommend using the Okta Universal Sync if there is a hybrid Exchange.
  3. Okta can still be used as the authentication/federation platform.

From Okta Documentation (Okta Office 365 Deployment Guide)

“It is important to note that if another technology is performing the synchronization of accounts to Office 365, and Okta is handling the federation for authentication, you need to ensure the Okta account usernames match the Office 365 usernames. This can easily be configured in Okta using Universal Directory attribute expression, this is described later in this document. During migration to Office 365, some organizations find the need to instantiate an Exchange Hybrid configuration. in doing so, it is likely that you have one of Microsoft’s technologies performing part of the directory synchronization, DirSync, AADConnect or Forefront Identity Manager (FIM). Whilst in these Hybrid deployments, Okta cannot replace the need for these tools and instead can be
used directly alongside for single sign-on and role and license management.”

Enable self-service Password reset with Azure AD Premium (Best Practice 4/10)

Carlos A Lopez (Twitter: @CLopezDC) Office365

Self-Service Password Reset (SSPR) enables users to quickly get unblocked and continue working no matter where they are or the time of day. By allowing users to unblock themselves, your organization can reduce the non-productive time and high support costs for most common password-related issues.

Best practice: Set up self-service password reset (SSPR) for your users. Use the Azure AD self-service password reset feature.

Best practice: Monitor how or if SSPR is really being used. Monitor the users who are registering by using the Azure AD Password Reset Registration Activity report. The reporting feature that Azure AD provides helps you answer questions by using prebuilt reports. If you’re appropriately licensed, you can also create custom queries.

Best practice: Extend cloud-based password policies to your on-premises infrastructure. Detail: Enhance password policies in your organization by performing the same checks for on-premises password changes as you do for cloud-based password changes. Install Azure AD password protection for Windows Server Active Directory agents on-premises to extend banned password lists to your existing infrastructure. Users and admins who change, set, or reset passwords on-premises are required to comply with the same password policy as cloud-only users.