Symptom: After changing the samAccountName (User Principal Name (UPN)) of a user in your on-premise Active Directory environment, run the DirSync tool to update the user on Office 365 (or wait 3 hours) [and have verified the user's new UPN synchronized in the Office 365 admin portal], the user is presented with the following error when trying to sign into Outlook, SharePoint, CRM, etc. on Office 365.
Sorry, but we're having trouble signing you in Please try again in a few minutes. If this doesn't work, you might want to contact your admin and report the following error: 80041034.
Solution: This turns out to be an issue with ADFS (Active Directory Federated Services), caching user account attributes, which prevents a successful login. Here are a couple of solutions to solve this issue:
- Try reupdating/repairing party trust with Office 365.
- Login to one of your ADFS servers.
- Click Start, All Programs, Windows Azure Active Directory, and then select Windows Azure Active Directory Module for Windows PowerShell.
- Execute the following command to connect to Microsoft's online services (when prompted, type in your Office 365 Administrator credentials)
- Connect-MSOLService
- Execute the following command to update federated trust
- Update-MSOLFederatedDomain –DomainName:<Federated Domain Name>
- Try temporarily disabling Local Security Authority (LSA) credential caching on your AD FS servers (note this can increase the load on your ADFS and AD DS servers)
- Login to each of your ADFS servers and complete the following steps
- Click Start -> Run -> regedit to open up the registry editor
- Navigate to the following registry key
- Right click on Lsa, select New -> DWORD (32-bit) Value
- Enter LsaLookupCacheMaxSize as the value name and press Enter
- Right click on LsaLookupCacheMaxSize and select Modify
- Ensure the value data is set to 0 and select OK
- Verify the user can successfully login. Once they can, continue on to delete the key we created
- Right click on the LsaLookupCacheMaxSize value we created and select Delete
- Login to each of your ADFS servers and complete the following steps
- Reboot all ADFS and ADFS proxy servers in your environment
Microsoft has released an official KB article referencing this issue, you can find it here: http://support.microsoft.com/kb/2535191
Thanks for this post, the registry edit worked for me. Here's my scenario:
Our usernames have 2 numbers followed by their initials (EX. 12ABC), the numbers indicate the property which they work. If a user switches property's, we want to know if we can change the UPN/Username, which I determined we could do. This all worked on our corporate network, and wireless network, but going external, would give the 80041034 error.
Performing the reg edits, then having the two users sign in again worked. This means we can adjust a user's UPN/Username if they move properties.
Thanks again for this!