{
	"id": "d355e003-0637-42ca-9792-9eaab87ddb61",
	"created_at": "2026-04-06T00:13:15.43713Z",
	"updated_at": "2026-04-10T03:24:30.159406Z",
	"deleted_at": null,
	"sha1_hash": "690469f702deb44a58ee4b07fb5f702d3124e143",
	"title": "Authentication for Microsoft Entra hybrid identity solutions - Microsoft Entra ID",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 402364,
	"plain_text": "Authentication for Microsoft Entra hybrid identity solutions -\r\nMicrosoft Entra ID\r\nBy omondiatieno\r\nArchived: 2026-04-05 13:01:10 UTC\r\nChoose the right authentication method for your Microsoft Entra hybrid identity\r\nsolution\r\nNote\r\nScope of this article: This article describes authentication methods for Microsoft Entra hybrid identity solutions.\r\nThese authentication methods apply independently of the synchronization technology used (Microsoft Entra\r\nConnect Sync or Cloud Sync). The choice of synchronization technology does not determine or change the\r\nauthentication behavior for user sign-ins.\r\nChoosing the correct authentication method is the first concern for organizations wanting to move their apps to the\r\ncloud. Don't take this decision lightly, for the following reasons:\r\n1. It's the first decision for an organization that wants to move to the cloud.\r\n2. The authentication method is a critical component of an organization's presence in the cloud. It controls\r\naccess to all cloud data and resources.\r\n3. It's the foundation of all the other advanced security and user experience features in Microsoft Entra ID.\r\nIdentity is the new control plane of IT security, so authentication is an organization's access guard to the new\r\ncloud world. Organizations need an identity control plane that strengthens their security and keeps their cloud\r\napps safe from intruders.\r\nNote\r\nChanging your authentication method requires planning, testing, and potentially downtime. Staged rollout is a\r\ngreat way to test users' migration from federation to cloud authentication.\r\nOut of scope\r\nOrganizations that don't have an existing on-premises directory footprint aren't the focus of this article. Typically,\r\nthose businesses create identities only in the cloud, which doesn't require a hybrid identity solution. Cloud-only\r\nidentities exist solely in the cloud and aren't associated with corresponding on-premises identities.\r\nAuthentication methods\r\nhttps://learn.microsoft.com/en-us/azure/active-directory/hybrid/choose-ad-authn\r\nPage 1 of 13\n\nWhen the Microsoft Entra hybrid identity solution is your new control plane, authentication is the foundation of\r\ncloud access. Choosing the correct authentication method is a crucial first decision in setting up a Microsoft Entra\r\nhybrid identity solution. The authentication method you choose, is configured by using Microsoft Entra Connect,\r\nwhich also provisions users in the cloud.\r\nTo choose an authentication method, you need to consider the time, existing infrastructure, complexity, and cost of\r\nimplementing your choice. These factors are different for every organization and might change over time.\r\nEtt fel inträffade.\r\nDet går inte att köra JavaScript.\r\nMicrosoft Entra ID supports the following authentication methods for hybrid identity solutions.\r\nCloud authentication\r\nWhen you choose this authentication method, Microsoft Entra ID handles users' sign-in process. Coupled with\r\nsingle sign-on (SSO), users can sign in to cloud apps without having to reenter their credentials. With cloud\r\nauthentication, you can choose from two options:\r\nMicrosoft Entra password hash synchronization. The simplest way to enable authentication for on-premises\r\ndirectory objects in Microsoft Entra ID. Users can use the same username and password that they use on-premises\r\nwithout having to deploy any other infrastructure. Some premium features of Microsoft Entra ID, like Microsoft\r\nEntra ID Protection and Microsoft Entra Domain Services, require password hash synchronization, no matter\r\nwhich authentication method you choose.\r\nMicrosoft Entra pass-through authentication. Provides a simple password validation for Microsoft Entra\r\nauthentication services by using a software agent that runs on one or more on-premises servers. The servers\r\nvalidate the users directly with your on-premises Active Directory, which ensures that the password validation\r\ndoesn't happen in the cloud.\r\nCompanies with a security requirement to immediately enforce on-premises user account states, password\r\npolicies, and sign-in hours might use this authentication method. For more information on the actual pass-through\r\nauthentication process, see User sign-in with Microsoft Entra pass-through authentication.\r\nFederated authentication\r\nWhen you choose this authentication method, Microsoft Entra ID hands off the authentication process to a\r\nseparate trusted authentication system, such as on-premises Active Directory Federation Services (AD FS), to\r\nvalidate the user's password.\r\nhttps://learn.microsoft.com/en-us/azure/active-directory/hybrid/choose-ad-authn\r\nPage 2 of 13\n\nThe authentication system can provide other advanced authentication requirements, for example, third-party\r\nmultifactor authentication.\r\nThe following section helps you decide which authentication method is right for you by using a decision tree. It\r\nhelps you determine whether to deploy cloud or federated authentication for your Microsoft Entra hybrid identity\r\nsolution.\r\nDecision tree\r\nDetails on decision questions:\r\n1. Microsoft Entra ID can handle sign-in for users without relying on on-premises components to verify\r\npasswords.\r\n2. Microsoft Entra ID can hand off user sign-in to a trusted authentication provider such as Microsoft's AD\r\nFS.\r\n3. If you need to apply, user-level Active Directory security policies such as account expired, disabled\r\naccount, password expired, account locked out, and sign-in hours on each user sign-in, Microsoft Entra ID\r\nrequires some on-premises components.\r\n4. Sign-in features not natively supported by Microsoft Entra ID:\r\nSign-in using third-party authentication solution.\r\nMulti-site on-premises authentication solution.\r\nhttps://learn.microsoft.com/en-us/azure/active-directory/hybrid/choose-ad-authn\r\nPage 3 of 13\n\n5. Microsoft Entra ID Protection requires Password Hash Sync regardless of which sign-in method you\r\nchoose, to provide the Users with leaked credentials report. Organizations can fail over to Password Hash\r\nSync if their primary sign-in method fails and it was configured before the failure event.\r\nDetailed considerations\r\nCloud authentication: Password hash synchronization\r\nEffort. Password hash synchronization requires the least effort regarding deployment, maintenance, and\r\ninfrastructure. This level of effort typically applies to organizations that only need their users to sign in to\r\nMicrosoft 365, SaaS apps, and other Microsoft Entra ID-based resources. When turned on, password hash\r\nsynchronization is part of the Microsoft Entra Connect Sync process and runs every two minutes.\r\nUser experience. To improve users' sign-in experience, use Microsoft Entra joined devices or Microsoft\r\nEntra hybrid joined devices. If you can't join your Windows devices to Microsoft Entra ID, we recommend\r\ndeploying seamless SSO with password hash synchronization. Seamless SSO eliminates unnecessary\r\nprompts when users are signed in.\r\nAdvanced scenarios. If organizations choose to, it's possible to use insights from identities with Microsoft\r\nEntra ID Protection reports with Microsoft Entra ID P2. An example is the leaked credentials report.\r\nWindows Hello for Business has specific requirements when you use password hash synchronization.\r\nMicrosoft Entra Domain Services requires password hash synchronization to provision users with their\r\ncorporate credentials in the managed domain.\r\nOrganizations that require multifactor authentication with password hash synchronization must use\r\nMicrosoft Entra multifactor authentication or Conditional Access custom controls. Those organizations\r\ncan't use third-party or on-premises multifactor authentication methods that rely on federation.\r\nBusiness continuity. Using password hash synchronization with cloud authentication is highly available as\r\na cloud service that scales to all Microsoft datacenters. To make sure password hash synchronization\r\ndoesn't go down for extended periods, deploy a second Microsoft Entra Connect server in staging mode in\r\na standby configuration.\r\nConsiderations. Currently, password hash synchronization doesn't immediately enforce changes in on-premises account states. In this situation, a user has access to cloud apps until the user account state is\r\nsynchronized to Microsoft Entra ID. Organizations might want to overcome this limitation by running a\r\nnew synchronization cycle after administrators do bulk updates to on-premises user account states. An\r\nexample is disabling accounts.\r\nUnderstanding authentication timing: While \"authentication occurs in the cloud\" refers to where\r\nMicrosoft Entra ID validates credentials (comparing the provided password hash against the stored hash),\r\nthe availability of password changes for sign-in depends on the synchronization timing. When a user\r\nchanges their password on-premises, the new password hash must be synchronized to Microsoft Entra ID\r\nbefore the user can sign in with it. This synchronization process typically runs every two minutes but may\r\nvary based on configuration.\r\nhttps://learn.microsoft.com/en-us/azure/active-directory/hybrid/choose-ad-authn\r\nPage 4 of 13\n\nNote\r\nThe password expired and account locked-out states aren't currently synced to Microsoft Entra ID with Microsoft\r\nEntra Connect. When you change a user's password and set the user must change password at next logon flag, the\r\npassword hash will not be synced to Microsoft Entra ID with Microsoft Entra Connect until the user changes their\r\npassword.\r\nRefer to implementing password hash synchronization for deployment steps.\r\nCloud authentication: Pass-through Authentication\r\nEffort. For pass-through authentication, you need one or more (we recommend three) lightweight agents\r\ninstalled on existing servers. These agents must have access to your on-premises Active Directory Domain\r\nServices, including your on-premises AD domain controllers. They need outbound access to the Internet\r\nand access to your domain controllers. For this reason, it's not supported to deploy the agents in a perimeter\r\nnetwork.\r\nPass-through Authentication requires unconstrained network access to domain controllers. All network\r\ntraffic is encrypted and limited to authentication requests. For more information on this process, see the\r\nsecurity deep dive on pass-through authentication.\r\nUser experience. To improve users' sign-in experience, use Microsoft Entra joined devices or Microsoft\r\nEntra hybrid joined devices. If you can't join your Windows devices to Microsoft Entra ID, we recommend\r\ndeploying seamless SSO with password hash synchronization. Seamless SSO eliminates unnecessary\r\nprompts when users are signed in.\r\nAdvanced scenarios. Pass-through Authentication enforces the on-premises account policy at the time of\r\nsign-in. For example, access is denied when an on-premises user's account state is disabled, locked out, or\r\ntheir password expires or the logon attempt falls outside the hours when the user is allowed to sign in.\r\nOrganizations that require multifactor authentication with pass-through authentication must use Microsoft\r\nEntra multifactor authentication or Conditional Access custom controls. Those organizations can't use a\r\nthird-party or on-premises multifactor authentication method that relies on federation. Advanced features\r\nrequire that password hash synchronization is deployed whether or not you choose pass-through\r\nauthentication. An example is the leaked credentials detection of Microsoft Entra ID Protection.\r\nBusiness continuity. We recommend that you deploy two extra pass-through authentication agents. These\r\nextras are in addition to the first agent on the Microsoft Entra Connect server. This other deployment\r\nensures high availability of authentication requests. When you have three agents deployed, one agent can\r\nstill fail when another agent is down for maintenance.\r\nThere's another benefit to deploying password hash synchronization in addition to pass-through\r\nauthentication. It acts as a backup authentication method when the primary authentication method is no\r\nlonger available.\r\nhttps://learn.microsoft.com/en-us/azure/active-directory/hybrid/choose-ad-authn\r\nPage 5 of 13\n\nConsiderations. You can use password hash synchronization as a backup authentication method for pass-through authentication, when the agents can't validate a user's credentials due to a significant on-premises\r\nfailure. Fail over to password hash synchronization doesn't happen automatically and you must use\r\nMicrosoft Entra Connect to switch the sign-on method manually.\r\nFor other considerations on Pass-through Authentication, including Alternate ID support, see frequently\r\nasked questions.\r\nRefer to implementing pass-through authentication for deployment steps.\r\nFederated authentication\r\nEffort. A federated authentication system relies on an external trusted system to authenticate users. Some\r\ncompanies want to reuse their existing federated system investment with their Microsoft Entra hybrid\r\nidentity solution. The maintenance and management of the federated system falls outside the control of\r\nMicrosoft Entra ID. It's up to the organization by using the federated system to make sure it's deployed\r\nsecurely and can handle the authentication load.\r\nUser experience. The user experience of federated authentication depends on the implementation of the\r\nfeatures, topology, and configuration of the federation farm. Some organizations need this flexibility to\r\nadapt and configure the access to the federation farm to suit their security requirements. For example, it's\r\npossible to configure internally connected users and devices to sign in users automatically, without\r\nprompting them for credentials. This configuration works because they already signed in to their devices. If\r\nnecessary, some advanced security features make users' sign-in process more difficult.\r\nAdvanced scenarios. A federated authentication solution is required when customers have an\r\nauthentication requirement that Microsoft Entra ID doesn't support natively. See detailed information to\r\nhelp you choose the right sign-in option. Consider the following common requirements:\r\nThird-party multifactor providers requiring a federated identity provider.\r\nAuthentication by using third-party authentication solutions. See the Microsoft Entra federation\r\ncompatibility list.\r\nSign in that requires a sAMAccountName, for example DOMAIN\\username, instead of a User\r\nPrincipal Name (UPN), for example, user@domain.com.\r\nBusiness continuity. Federated systems typically require a load-balanced array of servers, known as a\r\nfarm. This farm is configured in an internal network and perimeter network topology to ensure high\r\navailability for authentication requests.\r\nDeploy password hash synchronization along with federated authentication as a backup authentication\r\nmethod when the primary authentication method is no longer available. An example is when the on-premises servers aren't available. Some large enterprise organizations require a federation solution to\r\nsupport multiple Internet ingress points configured with geo-DNS for low-latency authentication requests.\r\nConsiderations. Federated systems typically require a more significant investment in on-premises\r\ninfrastructure. Most organizations choose this option if they already have an on-premises federation\r\nhttps://learn.microsoft.com/en-us/azure/active-directory/hybrid/choose-ad-authn\r\nPage 6 of 13\n\ninvestment. And if it's a strong business requirement to use a single-identity provider. Federation is more\r\ncomplex to operate and troubleshoot compared to cloud authentication solutions.\r\nFor a nonroutable domain that can't be verified in Microsoft Entra ID, you need extra configuration to implement\r\nuser ID sign in. This requirement is known as Alternate login ID support. See Configuring Alternate Login ID for\r\nlimitations and requirements. If you choose to use a third-party multifactor authentication provider with\r\nfederation, ensure the provider supports WS-Trust to allow devices to join Microsoft Entra ID.\r\nRefer to Deploying Federation Servers for deployment steps.\r\nNote\r\nWhen you deploy your Microsoft Entra hybrid identity solution, you must implement one of the supported\r\ntopologies of Microsoft Entra Connect. Learn more about supported and unsupported configurations at Topologies\r\nfor Microsoft Entra Connect.\r\nArchitecture diagrams\r\nThe following diagrams outline the high-level architecture components required for each authentication method\r\nyou can use with your Microsoft Entra hybrid identity solution. They provide an overview to help you compare\r\nthe differences between the solutions.\r\nSimplicity of a password hash synchronization solution:\r\nAgent requirements of pass-through authentication, using two agents for redundancy:\r\nhttps://learn.microsoft.com/en-us/azure/active-directory/hybrid/choose-ad-authn\r\nPage 7 of 13\n\nComponents required for federation in your perimeter and internal network of your organization:\r\nComparing methods\r\nConsideration\r\nPassword hash\r\nsynchronization\r\nPass-through\r\nAuthentication\r\nFederation with AD\r\nFS\r\nWhere does\r\nauthentication\r\nhappen?\r\nIn the cloud - password\r\nhash is synchronized and\r\nIn the cloud, after a secure\r\npassword verification\r\nexchange with the on-On-premises\r\nhttps://learn.microsoft.com/en-us/azure/active-directory/hybrid/choose-ad-authn\r\nPage 8 of 13\n\nConsideration\r\nPassword hash\r\nsynchronization\r\nPass-through\r\nAuthentication\r\nFederation with AD\r\nFS\r\nMicrosoft Entra ID\r\nvalidates credentials\r\npremises authentication\r\nagent\r\nWhat are the on-premises server\r\nrequirements\r\nbeyond the\r\nprovisioning\r\nsystem: Microsoft\r\nEntra Connect?\r\nNone\r\nOne server for each\r\nadditional authentication\r\nagent\r\nTwo or more AD FS\r\nservers\r\nTwo or more WAP\r\nservers in the\r\nperimeter/DMZ\r\nnetwork\r\nWhat are the\r\nrequirements for on-premises Internet\r\nand networking\r\nbeyond the\r\nprovisioning\r\nsystem?\r\nNone\r\nOutbound Internet access\r\nfrom the servers running\r\nauthentication agents\r\nInbound Internet\r\naccess to WAP servers\r\nin the perimeter\r\nInbound network\r\naccess to AD FS\r\nservers from WAP\r\nservers in the\r\nperimeter\r\nNetwork load\r\nbalancing\r\nIs there a TLS/SSL\r\ncertificate\r\nrequirement?\r\nNo No Yes\r\nIs there a health\r\nmonitoring\r\nsolution?\r\nNot required\r\nAgent status provided by\r\nthe Microsoft Entra admin\r\ncenter\r\nMicrosoft Entra\r\nConnect Health\r\nDo users get single\r\nsign-on to cloud\r\nresources from\r\ndomain-joined\r\ndevices within the\r\ncompany network?\r\nYes with Microsoft Entra\r\njoined devices, Microsoft\r\nEntra hybrid joined\r\ndevices, the Microsoft\r\nEnterprise SSO plug-in for\r\nApple devices, or Seamless\r\nSSO\r\nYes with Microsoft Entra\r\njoined devices, Microsoft\r\nEntra hybrid joined\r\ndevices, the Microsoft\r\nEnterprise SSO plug-in for\r\nApple devices, or Seamless\r\nSSO\r\nYes\r\nWhat sign-in types\r\nare supported?\r\nUserPrincipalName +\r\npassword\r\nUserPrincipalName +\r\npassword\r\nUserPrincipalName +\r\npassword\r\nhttps://learn.microsoft.com/en-us/azure/active-directory/hybrid/choose-ad-authn\r\nPage 9 of 13\n\nConsideration\r\nPassword hash\r\nsynchronization\r\nPass-through\r\nAuthentication\r\nFederation with AD\r\nFS\r\nWindows-Integrated\r\nAuthentication by using\r\nSeamless SSO\r\nAlternate login ID\r\nMicrosoft Entra joined\r\nDevices\r\nMicrosoft Entra hybrid\r\njoined devices\r\nCertificate and smart card\r\nauthentication\r\nWindows-Integrated\r\nAuthentication by using\r\nSeamless SSO\r\nAlternate login ID\r\nMicrosoft Entra joined\r\nDevices\r\nMicrosoft Entra hybrid\r\njoined devices\r\nCertificate and smart card\r\nauthentication\r\nsAMAccountName +\r\npassword\r\nWindows-Integrated\r\nAuthentication\r\nCertificate and smart\r\ncard authentication\r\nAlternate login ID\r\nIs Windows Hello\r\nfor Business\r\nsupported?\r\nKey trust model\r\nHybrid Cloud Trust\r\nKey trust model\r\nHybrid Cloud Trust\r\nBoth require Windows\r\nServer 2016 Domain\r\nfunctional level\r\nKey trust model\r\nHybrid Cloud Trust\r\nCertificate trust model\r\nWhat are the\r\nmultifactor\r\nauthentication\r\noptions?\r\nMicrosoft Entra multifactor\r\nauthentication\r\nCustom Controls with\r\nConditional Access*\r\nMicrosoft Entra multifactor\r\nauthentication\r\nCustom Controls with\r\nConditional Access*\r\nMicrosoft Entra\r\nmultifactor\r\nauthentication\r\nThird-party MFA\r\nCustom Controls with\r\nConditional Access*\r\nWhat user account\r\nstates are\r\nsupported?\r\nDisabled accounts\r\n(up to 30-minute delay)\r\nDisabled accounts\r\nAccount locked out\r\nAccount expired\r\nPassword expired\r\nSign-in hours\r\nDisabled accounts\r\nAccount locked out\r\nAccount expired\r\nPassword expired\r\nSign-in hours\r\nhttps://learn.microsoft.com/en-us/azure/active-directory/hybrid/choose-ad-authn\r\nPage 10 of 13\n\nConsideration\r\nPassword hash\r\nsynchronization\r\nPass-through\r\nAuthentication\r\nFederation with AD\r\nFS\r\nWhat are the\r\nConditional Access\r\noptions?\r\nMicrosoft Entra\r\nConditional Access, with\r\nMicrosoft Entra ID P1 or\r\nP2\r\nMicrosoft Entra\r\nConditional Access, with\r\nMicrosoft Entra ID P1 or\r\nP2\r\nMicrosoft Entra\r\nConditional Access,\r\nwith Microsoft Entra\r\nID P1 or P2\r\nAD FS Access Control\r\nPolicies\r\nIs blocking legacy\r\nprotocols\r\nsupported?\r\nYes Yes Yes\r\nCan you customize\r\nthe logo, image, and\r\ndescription on the\r\nsign-in pages?\r\nYes, with Microsoft Entra\r\nID P1 or P2\r\nYes, with Microsoft Entra\r\nID P1 or P2\r\nYes\r\nWhat advanced\r\nscenarios are\r\nsupported?\r\nSmart password lockout\r\nLeaked credentials reports,\r\nwith Microsoft Entra ID P2\r\nSmart password lockout\r\nMultisite low-latency\r\nauthentication system\r\nAD FS extranet\r\nlockout\r\nIntegration with third-party identity systems\r\nNote\r\nCustom controls in Microsoft Entra Conditional Access do not currently support device registration.\r\nRecommendations\r\nYour identity system ensures your users' access to apps that you migrate and make available in the cloud. Use or\r\nenable password hash synchronization with whichever authentication method you choose, for the following\r\nreasons:\r\n1. High availability and disaster recovery. Pass-through Authentication and federation rely on on-premises\r\ninfrastructure. For pass-through authentication, the on-premises footprint includes the server hardware and\r\nnetworking the Pass-through Authentication agents require. For federation, the on-premises footprint is\r\neven larger. It requires servers in your perimeter network to proxy authentication requests and the internal\r\nfederation servers.\r\nhttps://learn.microsoft.com/en-us/azure/active-directory/hybrid/choose-ad-authn\r\nPage 11 of 13\n\nTo avoid single points of failure, deploy redundant servers. Then authentication requests will always be\r\nserviced if any component fails. Both pass-through authentication and federation also rely on domain\r\ncontrollers to respond to authentication requests, which can also fail. Many of these components need\r\nmaintenance to stay healthy. Outages are more likely when maintenance isn't planned and implemented\r\ncorrectly.\r\n2. On-premises outage survival. The consequences of an on-premises outage due to a cyber-attack or\r\ndisaster can be substantial, ranging from reputational brand damage to a paralyzed organization unable to\r\ndeal with the attack. Recently, many organizations were victims of malware attacks, including targeted\r\nransomware, which caused their on-premises servers to go down. When Microsoft helps customers deal\r\nwith these kinds of attacks, it sees two categories of organizations:\r\nOrganizations that previously also turned on password hash synchronization on top of federated or\r\npass-through authentication changed their primary authentication method to then use password hash\r\nsynchronization. They were back online in a matter of hours. By using access to email via Microsoft\r\n365, they worked to resolve issues and access other cloud-based workloads.\r\nOrganizations that didn't previously enable password hash synchronization had to resort to untrusted\r\nexternal consumer email systems for communications to resolve issues. In those cases, it took them\r\nweeks to restore their on-premises identity infrastructure, before users were able to sign in to cloud-based apps again.\r\n3. ID protection. One of the best ways to protect users in the cloud is Microsoft Entra ID Protection with\r\nMicrosoft Entra ID P2. Microsoft continually scans the Internet for user and password lists that bad actors\r\nsell and make available on the dark web. Microsoft Entra ID can use this information to verify if any of the\r\nusernames and passwords in your organization are compromised. Therefore, it's critical to enable password\r\nhash synchronization no matter which authentication method you use, whether it's federated or pass-through authentication. Leaked credentials are presented as a report. Use this information to block or force\r\nusers to change their passwords when they try to sign in with leaked passwords.\r\nConclusion\r\nThis article outlines various authentication options that organizations can configure and deploy to support access\r\nto cloud apps. To meet various business, security, and technical requirements, organizations can choose between\r\npassword hash synchronization, Pass-through Authentication, and federation.\r\nConsider each authentication method. Does the effort to deploy the solution, and the user's experience of the sign-in process address your business requirements? Evaluate whether your organization needs the advanced scenarios\r\nand business continuity features of each authentication method. Finally, evaluate the considerations of each\r\nauthentication method. Do any of them prevent you from implementing your choice?\r\nNext steps\r\nIn today's world, threats are present 24 hours a day and come from everywhere. Implement the correct\r\nauthentication method, and it will mitigate your security risks and protect your identities.\r\nhttps://learn.microsoft.com/en-us/azure/active-directory/hybrid/choose-ad-authn\r\nPage 12 of 13\n\nGet started with Microsoft Entra ID and deploy the right authentication solution for your organization.\r\nIf you're thinking about migrating from federated to cloud authentication, learn more about changing the sign-in\r\nmethod. To help you plan and implement the migration, use these project deployment plans, or consider using the\r\nnew Staged Rollout feature to migrate federated users to using cloud authentication in a staged approach.\r\nSource: https://learn.microsoft.com/en-us/azure/active-directory/hybrid/choose-ad-authn\r\nhttps://learn.microsoft.com/en-us/azure/active-directory/hybrid/choose-ad-authn\r\nPage 13 of 13",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://learn.microsoft.com/en-us/azure/active-directory/hybrid/choose-ad-authn"
	],
	"report_names": [
		"choose-ad-authn"
	],
	"threat_actors": [
		{
			"id": "aa73cd6a-868c-4ae4-a5b2-7cb2c5ad1e9d",
			"created_at": "2022-10-25T16:07:24.139848Z",
			"updated_at": "2026-04-10T02:00:04.878798Z",
			"deleted_at": null,
			"main_name": "Safe",
			"aliases": [],
			"source_name": "ETDA:Safe",
			"tools": [
				"DebugView",
				"LZ77",
				"OpenDoc",
				"SafeDisk",
				"TypeConfig",
				"UPXShell",
				"UsbDoc",
				"UsbExe"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434395,
	"ts_updated_at": 1775791470,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/690469f702deb44a58ee4b07fb5f702d3124e143.pdf",
		"text": "https://archive.orkl.eu/690469f702deb44a58ee4b07fb5f702d3124e143.txt",
		"img": "https://archive.orkl.eu/690469f702deb44a58ee4b07fb5f702d3124e143.jpg"
	}
}