Showing posts with label Identity management. Show all posts
Showing posts with label Identity management. Show all posts

Azure AD Device Management


Azure AD Device Management:  Azure AD provides the foundation for the ability to manage devices from the cloud. Devices in Azure AD can be managed using Mobile Device Management (MDM) tools like Microsoft Intune, System Center Configuration Manager, Group Policy (hybrid Azure AD join), Mobile Application Management (MAM) tools, or other third-party tools.



There are 3 main methods for registering devices with Azure AD:


Azure AD registered devices:

  1. ·    Typically used for personal devices not owned by organization (BYOD)
  2. ·        Registers the object in Azure AD, providing an identity for the device.
  3. ·        Support access to an organization’s Azure AD controlled resources
  4. ·        Windows 10, IOS, Android, MacOS.


Azure AD joined devices:

  1. ·        Typically used for devices owned by organization which does not use on-prem AD
  2. ·        Changes the local state of the device so that Azure AD logins can be used to log into the       device
  3. ·        Provide access to SSO to Azure AD managed resources, enterprise state roam ESR,                   restriction of access based on device compliance and other benefits.
  4. ·        Windows 10



Hybrid Azure AD joined devices:


  1. Typically used when an organization already uses and has device joined to on-prem AD.
  2. Supports feature of Azure AD join such as SSO and ESR.
  3. Windows 7, 8.1 or 10 & Windows Server 2008 or newer.


**Enterprise State Roaming is available to any organization with an Azure AD Premium or Enterprise Mobility + Security (EMS) license.When you enable Enterprise State Roaming, your organization is automatically granted a free, limited-use license for Azure Rights Management protection from Azure Information Protection.**



Registering and joining give your users Seamless Sign-on (SSO) to cloud resources and administrators the ability to apply Conditional Access policies to those resources.


Devices that are Azure AD joined or hybrid Azure AD joined benefit from SSO to your organization's on-premises resources as well as cloud resources








Users may join devices to Azure AD - This setting enables you to select the users who can register their devices as Azure AD joined devices. The default is All. This setting is applicable for Windows 10 only.


Users may register their devices with Azure AD - You need to configure this setting to allow Windows 10 personal, iOS, Android, and macOs devices to be registered with Azure AD. If you select None, devices are not allowed to register with Azure AD. Enrollment with Microsoft Intune or Mobile Device Management (MDM) for Office 365 requires registration. If you have configured either of these services, ALL is selected and NONE is not available



Require Multi-Factor Auth to join devices - You can choose whether users are required to provide an additional authentication factor to join their device to Azure AD. The default is No. We recommend requiring multi-factor authentication when registering a device






If you see a device that is "Hybrid Azure AD joined" with a state "Pending" under the REGISTERED column, it indicates that the device has been synchronized from Azure AD connect and is waiting to complete registration from the client.


If you are an Intune administrator, you can manage devices marked as Microsoft Intune. If the device is not enrolled with Microsoft Intune the "Manage" option will be greyed out.


As a global administrator or cloud device administrator, you can manage the registered or joined devices. Intune Service administrators can:

  • Update devices - Examples are daily operations such as enabling/disabling devices
  • Delete devices – When a device is retired and should be deleted in Azure AD


Azure AD registered devices


Azure AD registered devices are signed in to using a local account like a Microsoft account on a Windows 10 device, but additionally have an Azure AD account attached for access to organizational resources. Access to resources in the organization can be further limited based on that Azure AD account and Conditional Access policies applied to the device identity.


Administrators can secure and further control these Azure AD registered devices using Mobile Device Management (MDM) tools like Microsoft Intune.



# 1) A user in your organization wants to access tools for email, reporting time-off, and benefits enrollment from their home PC. Your organization has these tools behind a Conditional Access policy that requires access from an Intune compliant device. The user adds their organization account and registers their home PC with Azure AD and the required Intune policies are enforced giving the user access to their resources.



#2) Another user wants to access their organizational email on their personal Android phone that has been rooted. Your company requires a compliant device and has created an Intune compliance policy to block any rooted devices. The employee is stopped from accessing organizational resources on this device.



Azure AD joined devices


Azure AD joined devices are signed in to using an organizational Azure AD account. Access to resources in the organization can be further limited based on that Azure AD account and Conditional Access policies applied to the device identity.


Administrators can secure and further control Azure AD joined devices using Mobile Device Management (MDM) tools like Microsoft Intune.


These tools provide a means to enforce organization-required configurations like requiring storage to be encrypted, password complexity, software installations, and software updates. Administrators can make organization applications available to Azure AD joined devices using System Center Configuration Manager and the Microsoft Store for Business.


Scenarios for Azure AD Joined devices.


While Azure AD join is primarily intended for organizations that do not have an on-premises Windows Server Active Directory infrastructure, you can certainly use it in scenarios where:

  • You want to transition to cloud-based infrastructure using Azure AD and MDM like Intune.
  • You can’t use an on-premises domain join, for example, if you need to get mobile devices such as tablets and phones under control.
  • Your users primarily need to access Office 365 or other SaaS apps integrated with Azure AD.


The goal of Azure AD joined devices is to simplify:

  • Windows deployments of work-owned devices
  • Access to organizational apps and resources from any Windows device
  • Cloud-based management of work-owned devices
  • Users to sign into their devices with their Azure AD or synced Active Directory work or school accounts.


Azure AD joined devices can still maintain single sign-on access to on-premises resources when they are on the organization's network. Devices that are Azure AD joined can still authenticate to on-premises servers like file, print, and other applications.


Hybrid Azure AD joined devices :


If your environment has an on-premises AD footprint and you also want benefit from the capabilities provided by Azure Active Directory, you can implement hybrid Azure AD joined devices. These devices, are devices that are joined to your on-premises Active Directory and registered with your Azure Active Directory.



Use Azure AD hybrid joined devices if:

  • You have Win32 apps deployed to these devices that rely on Active Directory machine authentication.
  • You want to continue to use Group Policy to manage device configuration.
  • You want to continue to use existing imaging solutions to deploy and configure devices.
  • You must support down-level Windows 7 and 8.1 devices in addition to Windows 10


Reference link







Hybrid Identities - Azure


Many organizations moving to the cloud & already managing identities on-premises. To utilizes the cloud resources, you need identities as well and to fulfill the task Azure provides the Azure AD.

Now this situation leads to Hybrid identities where on-premises and cloud both has identities and you need to manage both, and it depends on you how you want to manage your authentication and authorization.

Azure provides wonderful service to manage the Hybrid identities called Azure AD Connect. With Azure AD Connect you can extend your identities to the cloud and allow users to access cloud applications with existing credentials. Now to accomplish this task we have various options like ADFS, PHS & PTA.

In this post we would talk about briefly about all the 3 options and then will compare these.




Azure AD Connect: -

AD Connect is the underlying Microsoft tool used to deploy, configure, manage and monitor hybrid identities between On-prem AD and Azure AD.

AD Connect supports Server 2012 R2 and above.

AD Connect provides the ability to configure and deploy the following hybrid identity solutions

è Password hash synchronization (PHS)
è Pass-through authentication (PTA)
è Federation integration including AD Federation Services


AD Connect synchronizes users, groups and other objects between on-prem and Azure AD.

You can not install multiple AD Connect for HA that’s why for DR you install AD-Connect in staging mode on secondary server.

AD Connect comes with health monitoring and provides monitoring data which is visible in Azure Portal.

To check the status of the sync service use, Get-ADSyncSheduler
Sync Operation can be triggered with Start-ADsyncsyncCycle


We will be discussing AD Connect in next post in detail.


Lets compare the above mentioned 3 methods for Hybrid Identities :

ADFS PTA PHS
Using AD Connect , we can configure federation with ADFS & with federated identity, all user authentication occurs on-prem PTA configure in AD Connect configuration & all PTA user authentication occurs on-prem but though an outbound-only connection from an on-prem authentication agent AD Connect deployed with either PTA or PHS. With PHS password hash get synchronized and authentication happens in cloud
ADFS enables users to sign-in & access cloud services/apps using on-prem credentials (SSO) ADFS enables users to sign-in & access cloud services/apps using on-prem credentials (SSO) PHS enables seamless SSO , a feature intended to improve the user sign-in experience.
Does not require to store password hash in the cloud Does not require to store password hash in the cloud Password Hash stored in the cloud
Supports On-prem MFA  On-prem MFA NOT supported by PTA On-prem MFA NOT supported by PTA
Supports all on-prem policies like expiry, hours logged in etc as on-prem sign in occurs All on-prem account policies enforced at the time of sign in like expiry, login hours etc  
Requires more infrastructure & complex to configure and maintain  Only require outbound connectivity from on-prem Authentication agents No infrastructure needed
Does not support Seamless SSO PTA provides the same seamless SSO experience as PHS but offers additional security benefits Its Same sign-on as authentication happens in cloud not in on-prem ad but user enters same password



Well i did try to include as much as possible but if something is missing or you guys think should be added here , Please mention in the comments.

Next we will be discussing above topics in details for sure.


FinOps Vs Cost Optimization

 Here's the detailed comparison clearly structured in pointers FinOps Vs Cost Recommendations: Aspect 1: Scope and Approach FinOps: H...