ADFS Server Updatepassword 407 Error
Hi fellow tech community participants, I have an ADFS Server (Windows Server 2016) which has recently started to throw errors when trying to use https://adfs.contoso.com/adfs/portal/updatepassword to change a user password. The user is getting a message like "user id or password is incorrect even though the username and password are correct. In the Eventlog of the ADFS I can see a 407 Error with the following content: Password change failed for following user: Additional Data User: user@domain.com Server on which password change was attempted: Error details: UserNotFound What bothers me the most is that there seems to be no server on whicht the change was attempted. Using nltest I get the following output: C:\Windows\system32>nltest /DsGetDc:contoso.com /pdc Getting DC name failed: Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN I can ping the PDC just fine and I can see that it tried using that server 3 days ago when someone entered a wrong password in the change password dialog. Does anyone know how to resolve this? Regards Carste
Google Federation with Entra ID - doesn't support MultipleAuthN SAML claim
Entra ID has a new Microsoft-managed conditional access policy that will be enabled from October 2024. However, Google doesn't support the MultipleAuthN claim that ADFS (and other IdPs) do. Is there a work-around for this, or we just need to ensure that the new Microsoft-managed conditional access policy is disabled for all users? Otherwise, we somehow need to enable double MFA (MFA at both Google and Microsoft). I imagine this might be an issue for any other federated IdPs that don't support this specific SAML claim. There is a new alternative to the `SupportsMFA` setting in the `Set-MsolDomainFederationSettings` powershell command, but it doesn't allow you to 'always assume MFA is utilised in the federation' - https://learn.microsoft.com/en-us/graph/api/internaldomainfederation-update?view=graph-rest-1.0&tabs=http#federatedidpmfabehavior-values Thanks in advance, Nigel
ADFS URL change for federated login to O365
Hello, I'm looking to update our ADFS URL, for example, adfs.123uk.com to adfs.123.com. The ADFS servers and infrastructure are remaining the same. I know how to update the federation server but I'm struggling to find a way to tell Office365 about the new url. Is it just a case of running 'Set-MsolADFSContext –computer <the FQDN of the AD FS server>' . Which is the step when you first setup ADFS with O365.O365 Email Migration to Another Tenant while Deferring Migration of Sharepoint files
Hi, This is the context: ChildCompany has O365 and it has an Azure AD in hybrid mode synchronizing to a on-prem AD server. They have an internal domain ChildCompany.com, and an external domain ChildCompany.com where they also receive and send email using O365. ParentCompany is going absorb the ChildCompany some time in next year, and I was asked about the integration options. According to this https://download.microsoft.com/download/b/a/1/ba19dfe7-96e2-4983-8783-4dcff9cebe7b/microsoft-365-tenant-to-tenant-migration.pdf I could do a phased migration, where the end state is that they decomm their onprem AD and that they only use our ParentCompany systems. The business requirement is to start their integration with Email, and then in later phases do the Sharepoint integration as that requires way more analysis on their data sources, as they also have wikis and many other on prem legacy stuff. They are less than 50 users, so I can use Quest migration tools for the email part, but I wonder what needs to happen in what order. This is what I have in mind: Migrate their current O365 into our ParentCompany Office 365 subscription, so that they can continue logging in into their domain joined windows machines using childCompany.co, so they start using ParentCompany.com email addresses, but the problem then is how can they continue using their sharepoint and onedrive resources associated with the Azure and local domain at ChildCompany.com? This is more or less what I have in mind, for the intermediate step, the cutover: Child Company ParentCompany --------------------- ---------------- On-Prem | MS Cloud: | MS Cloud: ---------------|----------------------|-------------- Local AD (ADFS)| Azure Subscription | Azure Sub | Azure AD | Azure AD |--------------------- |--------------------- | O365 Sub -> | O365 Sub | Exchange mailboxes-> | Exchange mailboxes | Sharepoint? -> | ??? | -------------------- |--------------------- I wonder how could it be possible to defer the sharepoint and onedrive migration, so that the child company users can still work on their sharepoint files using their normal auth methods, while disabling childcompany.com as MX so they start using ParentCompany.com mailboxes.Is that even possible? Would make more sense to try to migrate everything at once? That is way more work, but I'm weighting my options.ADFS Custom 401 Error Page for denied Access
Hi, is it possible to display a custom 401 error page if a user is not permitted to access a certain SAML/OIDC application due to the applied access policy? Currently, if the user tries to access an application, he gets redirected to ADFS. After authentication, the user gets redirected back to the application although ADFS has not generated a token due to the configured access policy denies access. After that, the application displays a generic error message like "Unknown Login Error. Please try again". Current flow: User accesses application Gets redirected to ADFS Authenticates in ADFS (user is not permitted to authenticate) Gets redirected back to the application Gets a generic error message from the application Is there any way to configure a custom error message in ADFS to change this behaviour? I don't want to redirect the user back to the application if he is not allowed to access it. In my opinion, the following flow would be much user friendly: User accesses application Gets redirected to ADFS Authenticates in ADFS (user is not permitted to authenticate) ADFS displays an error message (You are not allowed to use this application) Any help is appreciated!
Authentication request goes in infinite loop
We have several users in our org have been experiencing authentication issues, as specially on their iOS and Android device, when they enroll a new device or setup Outlook, Teams or any other MS apps on their mobile devices and try to authenticate to setup an account, they all get below error. MSIS7042: The same client browser session has made '{0}' requests in the last '{1}' seconds. Contact your administrator for details. We checked the ADFS and everything appears to be fine that end and ADFS successfully issues token to the request. it seems like MS identity platform or relaying party application is misbehaving and is not successfully consuming the token issued by AD FS, and the application is sending the passive client back to AD FS, repeatedly, for a new token. AD FS will issue the passive client a new token each time, as long as they do not exceed 5 requests within 20 seconds. We also opened up a case with Microsoft but so far, no updates and as usual they have no clue. Any help resolving this issue will be greatly appreciated.
Self Service Password Reset for trusted domain
Hi, I manage a self-contained Forest/Domain in Geo1 which has a two way AD trust with our parent company in Geo2. The Geo1 domain sits in the Geo2 owned and maintained Azure/M365 tenant. SSPR is selectively enabled in Azure by way of Domain Local AD group into which all required AD groups from other business units within the organisation are nested and this works fine for users in Geo1 (all users in Geo1 are in domains which are in the same AD forest as the parent organisation). A Domain Global AD group from Geo2 has also been nested in Geo1's Domain Local Group so, in theory, SSPR should be available to Geo2 users but it isn't working (we see a message on the SSPR page stating that SSPR 'isn't available for this user'). The Geo2 forest syncs to the Geo1 managed Azure AD via AAD connectors located in Geo1's data centres. I can see our users in the Azure Portal and have access to all permitted M365 apps such as Exchange Online, SharePoint et al. All users are have either E3 or E5 licenses. Can anyone suggest a reason why SSPR isn't working for the Geo1 users or maybe point me to any documentation which might deal with this particular scenario? Regards Paul
