Sign-in to Azure AD through 3rd Party Federation Service
Sometimes customers want to implement redirection for Azure AD authentication with their IDP already in use. This 3rd party solution has been around for a long time and the customer doesn't want to change the provisioning process at all. Also, this 3rd party federation does not provide a wizard for authentication connection with Azure AD like ADFS, Okta and Ping Identity. How can we configure authentication redirection in the customer environment below? As you already know, it cannot be configured in the "User Sign-in" menu of Azure AD Connect. There are no options to choose from. Therefore, the "User Sign-in" method can only be "Do not Configure". After that, the federation connection can be set up manually using the powershell at the link below. Set-MsolDomainAuthentication (MSOnline) | Microsoft Docs When using this PowerShell, information such as the DomainName, Sign-in Certificate and the URL to be used must be checked in advance. For reference on which values can be used, you can check the configuration information by using Get-MsolDomainAuthentication powershell when connecting to ADFS. If you have completed the 3rd party federation configuration with ‘Set-MsolDomainAuthentication’ powershell, you will be able to check that the logon page is redirected when you try to log on to Azure AD. However, if you try to log on from the federation logon page, you will check an error message as shown in the figure below. However, this user account will actually exist in Azure AD. To solve this issue, we will still find the answer in ADFS. If you refer to the link below, you can find out what information is required when ADFS and Azure AD are connected. Azure AD RPT Claim Rules | AD FS Help (microsoft.com) Among the claims of ADFS, the two most important things will be ‘Sign-in’ and ‘ImmutableID(=SourceAnchor)’ information. In order for Azure AD to allow authentication, these two claims information in the ADFS token must match the information in Azure AD. Azure AD Connect uses the 'objectGUID' (actually base64-encoded values are used) value among the properties of the AD user account to determine uniqueness between the AD account and the account synced to Azure AD. (Detail : Azure AD Connect: Design concepts | Microsoft Docs) 'objectGUID' is a value assigned when an AD user object is created. If you look at the configuration diagram at the beginning of this post, this 'objectGUID' value cannot exist in 3rd party LDAP (ID Store). So it is not possible to make a claim that can match the 'ImmutableID' of Azure AD. As a result, in order to solve the logon failure issue, it is necessary to change the items that determine uniqueness. When configuring Azure AD Connect for the first time, it can be changed to a specific value other than the default value (objectGUID). In addition, in the federation service, it is also necessary to designate a claim with an LDAP attribute that can match this changed value. For example, it was defined as shown in the table below, and Azure AD logon through 3rd party federation succeeded normally. Finally, the authentication uniqueness error between Azure AD and federation could also be found on the Okta website. SSO from Okta to office365 shows error: AADSTS51004
PIN authentication error after hybrid join
I have just rolled out hybrid join to several older devices in my company, which worked pretty well at first and those devices also joined Intune right away. However, for some reason only today, the WHFB policy set in and required every user to set up a PIN. But authentication with the PIN does not work after the users reboot. We either get the errors 0xc00000BB or 0xc000005E. After several hours of googling, a pattern is starting to form that points to certificate errors. We currently don't have any Kerberos-KDC, SCPA, PKCS or PKI set up in our environment and I'm honestly a little overwhelmed by the sheer documentation size revolving around this issue. Does hybrid Azure AD join only work with a sophisticated certificate authentication in place? If so, is there an easy way to implement this?
Azure AD Connect swing migration when using ADFS
Hi, one of my customers runs an old version of Azure AD Connect with ADFS. I were planing to build a new AADC server and set it to staging mode to do a "swing" migration . But when configuring new AADC, I am presented with a list of UPN suffixes used in the domain and I have to choose which one to federate with Azure AD. I was not expecting this, as all the UPN suffixes in the list are already federated by using the old AADC server. Is it safe to just let the wizard federate again, or will this break federation activated on the old server? Or is the process for swing migration when using ADFS different than when not using ADFS? Switching away from ADFS to other authentication is not relevant yet. Thanks, RuslanChange User Sign In method from Password hash Synchronization to ADFS Authentication
Hi All, We have a requirement, users in the environment is currently using the primary Authentication method as Password hash synchronization, which has to be changed to ADFS authentication. In the current environment we have existing ADFS infrastructure in place, We wanted to have the federation between on premises active directory and Azure AD, then we want the users primary authentication method to be changed from Password hash synchronization to ADFS authentication. In addition, there are multiple custom domains added as verified domains in Azure AD, which are currently set as with the domain type as "Managed" Below is the plan we have Created to change the Authentication Mechanism 1. Convert all the domains type from Managed to federated using the commands Convert-MsolDomainToFederated -DomainName abc.com -SupportMultipleDomain Followed by the above command, We will execute the below commands for all other domains. Convert-MsolDomainToFederated -DomainName xyz.com Convert-MsolDomainToFederated -DomainName test.com 2. Then change the user sign in method present in Azure AD connect server from Password hash synchronization to Federation with ADFS We would like to clarify the following queries Is there a way to go with the staged approach, Say for example, change any single domain at a time from Managed to Federated, then change user sign in on the Azure AD connect server from Password hash synchronization to Federation ? If your answer is yes, the other managed domains would continue to use Password Hash synchronization as the primary authentication method ? What would be the end user experience and Impact , when we convert the domain type from managed to federated and set the primary authentication method as ADFS ? Should users need to sign out and sign in back to office 365 services ? What would be the default time taken configured by Microsoft to switch all the users authentication completely from PHS to ADFS authentication ? Any other important considerations which is not captured and that has to be taken care for this activity ? Appreciate your view and inputs on this query.
Converting Domain from Managed to Federated - Google Workspace IdP
Hi Team, Just need some help here to setup SSO between Microsoft 365 and Google Workspace, where Google is the IdP. Initial issue: Cannot sign into Office 365 with Google credentials (screenshot below). After following Google articles and Youtube videos on fixing both Google & Office365 settings, I've arrived at the issue below: What I now understand is that because we don't use Azure AD, there is no server for me to log into so that I can convert the domain to federated. Is there a way I can federate a domain without ADFS? Thanks FredAdmin roles for external collaboration settings not working
We are attempting to grant access to the external collaboration settings in Entra to facilitate adding and removing domains. We've gone over all the documentation and tried every single role that supposedly grants this access, but none of them work. Those underlined below have some sort of domain changing access according to Microsoft's documentation. Even with all these roles, the screen remains completely grayed out. Even on the Entra side of things, we can see all the respective roles assigned to the user, but it still doesn't work. Are we missing something here? Maybe some sort of dependency role for these other ones to work?
How to migrate ADFS servers to Azure while keeping a backup setup on-premise?
We currently host our ADFS and ADFS proxy servers on-premise. We want to set up these two servers on Azure, but we would also like to keep our existing on-premise servers offline as a backup. The idea is that if the Azure environment were to become unavailable, we would flip a switch and revert traffic back to the on-premise ADFS. How would we go about achieving this without causing any conflicts with the newly migrated ADFS servers on Azure? I was wondering if someone had any experience with what we are trying to do. I imagine that this shouldn't be too complicated. By the way, our Azure ADFS setup is not live yet. We would like to do a trial run before we go live. I do have a question about this step and having both ADFS servers and proxies running at the same time. What kind of complications could we run into if we were to run two ADFS servers, with different names and different proxies at the same time, even if it were for a brief period of time? Will redirecting the DNS traffic from the on-premise ADFS proxy to the azure ADFS proxy cause any problems with our on-premise domain controllers and the replica domain controller hosted on Azure? Thank you
Single forest GCC high azure ad connect
Hello We are about to setup an Azure GCC high tenant. We are in the initial stages of discussion around what is the best identity model to use. Currently we have one Active Directory forest. We sync objects from onprem to Azure Commercial, and we use ADFS for federation with the Azure commercial tenant. Devices in commercial tenant are either hybrid azure join or azure ad joined. I know devices can only be a member of one Azure tenant, so my question is what is the best course of action regarding syncing users to the GCC high tenant? Should i stand up a new AD forest, migrate users from commercial forest to GCC high forest and then sync to Azure GCC high? or for the users that need to sync to GCC high should i disjoin there device from commercial, change the upn for these users , so they sync to GCC high azure? I want to try and avoid setting up an additional forest for this, but i'm trying to understand how this can work using one AD forest?Use 3rd party federation Service with Microsoft conditional access?
Hi there, a customer of us is in a pilot period of utilizing a 3rd party federation service. To be exact the FortiAuthenticator is installed On-Premises and should handle the MFA process. So we already changed the domain status with Set-MsolDomainAuthentication to federated for a specific domain. The customer and we know that there are certain limitations regarding conditional access. But I don't find a solid documentation about this. Is no conditional access possible at all, or just regarding conditional access policies enforcing MFA? The goal would be (if possible) that a user should meet the compliant device or hybrid joinded device state after he authenticated with the FortiAuthenticator. Thanks in advance. Kind regards, woelki
