Difficult problem that I have banged my head on for almost a week with no signs of making progress. Any help would be greatly appreciated. I know the "86" error has several documented fixes but none have worked for me so far. If I can provide any additional information, please ask. Synopsis : We are moving file servers into the cloud and I want to use Azure file shares for our migration. We have an on-premise AD and an Azure tenant. I want my users to be able to access these file shares using their AD credentials from anywhere in the world, with no VPN requirement. Configuration: 1.) Storage Account: created in Azure & in on-prem AD (both computer & user accounts). 2.) Storage Account: all Azure AD users temporarily have "Owner" role. 3.) File Share: configured with "Azure AD Kerberos" Active Directory. 4.) File Share: default share-level permissions configured with "Read-Only". 5.) File Share: security set to "Maximum Compatibility". 6.) Networking: port 445 has been confirmed open to Azure. 7.) Networking: public network access enabled. 8.) Workstation: Windows 10 Enterprise 20H2 - joined to on-premise domain, logged in with O365-enabled account. 9.) Workstation: registry key "CloudKerberosTicketRetrievalEnabled" set to 1 10.) Workstation: local security policy LAN Manager Authentication Level set to "Send NTLMv2 response only". 11.) Active Directory: synced to Azure via AAD Connect (password sync, no writeback) "DSRegCmd /status" Results: AzureAdJoined : YES EnterpriseJoined : NO DomainJoined : YES DomainName : <on-prem domain> Device Name : <computer>.<on-prem domain> "Net Use" Results: net use Z: \<storage account>.file.core.windows.net<share name> /User:<O365_Login> /PERSISTENT:YES Enter password for "<O365_Login"> to connect to '<storage account>.file.core.windows.net: <entered password> System error 86 has occurred. The specified network password is not correct. Interestingly, if I change the local security policy LAN Manager authentication level, I get different results. See below. "Send LM & NTLM Responses" error 53 - network path not found. "Send LM & NTLM Responses - use NTLMv2 if negotiated" error 53 - network path not found. "Send NTLM responses only" error 53 - network path not found. "Send NTLMv2 responses only" error 1326 - user name or password is incorrect. "Send NTLMv2 responses only - refuse LM" error 1326 - user name or password is incorrect. "Send NTLMv2 responses only - refuse LM & NTLM" error 86 - the specified network password is not correct.

It seems that you have configured everything correctly on the Azure side, and you are getting an error on the client-side when trying to access the Azure file share using the net use command. The error indicates that the specified network password is not correct. Based on the information you have provided, it appears that you are using your O365-enabled account to access the file share. The first thing I would suggest is to verify that the password for the O365-enabled account is correct. You can try logging in to Office 365 using the same credentials to confirm this. If the password is correct, then I would suggest checking the following: Check the time synchronization between the client machine and the domain controller. Ensure that the time zone and the time are correct. Ensure that the DNS is set up correctly and can resolve the domain name of the on-premises domain controller. Verify that the client machine is properly joined to the on-premises domain. Ensure that the Azure AD Connect tool is configured correctly, and the password synchronization feature is enabled. Try using the IP address of the Azure file share instead of the hostname when connecting. Ensure that the O365-enabled account has the necessary permissions to access the Azure file share. Try using a different user account to connect to the Azure file share. I hope this helps you resolve the issue. If the problem persists, please let me know, and we can explore other potential solutions.

I found some links that addresses this same issues as far back as 2009, I would like you to have a look, perharps a simple information there might help you solve the issue: System error 86 has occurred. The specified network password is not correct: https://answers.microsoft.com/en-us/windows/forum/all/system-error-86-has-occurredthe-specified-network/6dbfc4a0-de6e-493f-ba7b-7b0f56d5b410 https://answers.microsoft.com/en-us/windows/forum/windows_vista-networking/windows-logon-unsuccessful-during-map-network/055d61a5-00d0-4798-9e98-66e6ba0726de?page=2 Error 1326 when you change domain account password in Windows: https://support.microsoft.com/en-us/topic/error-1326-when-you-change-domain-account-password-in-windows-a238729e-4b79-b9e2-ebfa-2967c91ef5bf

Error 86 mapping Azure SMB File Share from Win10

Brandon Paulk 0

I have used same O365 username & password to sign into multiple M365 services today without issue (Exchange, Sharepoint, etc.)

Confirmed time sync on client & DC, along with correct time zones.
Pinging DC server name, domain name, and UNC all successful.
Client machine is joined to local domain, and can map local file server drives without issue.
AAD Connect on-prem has no warnings. Password sync is enabled & working for all users. (all 'writeback' is disabled from cloud to on-premise)
Using IP address yields same error.
O365 account is Global Admin, has "Owner" permission on storage account, and is inherited on file share.
Different user account (with same perms on storage account & share) yields different error: System error 1396 has occurred.
The target account name is incorrect.

Ayomide Oluwaga 941

This is an interesting problem, I need you to try the following suggestions:

Verify that the UPN suffix of the user account you are using to access the Azure file share matches the domain name of the Azure AD. If they don't match, you may face authentication issues.
Ensure that the Azure AD Connect configuration is correct and up to date. You can attempt to synchronize the configuration to see if it fixes the issue.
Confirm that the password hash synchronization is functioning properly. You may reset the password of the user account you're using to access the Azure file share to test if it syncs correctly to Azure AD.
Make sure that the DNS resolution for the Azure file share is functioning properly. You can try using the FQDN of the Azure file share to determine if it resolves the issue.
Verify that the user account you're using to access the Azure file share is properly mapped to the on-premises AD account. You can test this by resetting or creating a new mapping.
Ensure that the Kerberos authentication settings for the file share are correctly configured. You can attempt to disable Kerberos authentication and use NTLM authentication to determine if it fixes the issue.

Hopefully, these additional suggestions will help you troubleshoot and resolve the issue. If none of these solutions work, please provide more information, such as error logs or screenshots, so that we can assist you further.

Brandon Paulk 0

1.) Compared on-prem AD to Azure AD, found a difference. I changed the Azure AD to match on-prem AD.

2.) Confirmed AAD Connect configuration is current. I did a "Refresh Schema" in AAD Connect for both cloud & on-prem.

3.) Reset password for affected account. Confirmed password worked in O365 services.

4.) Pinged "<storage account>.file.core.windows.net" and received IP 20.150.95.200 which did not reply, but I assume is a valid Azure IP.

5.) How do I "reset on-premise AD mapping" for my account?

6.) Under the Storage Account "File Share Settings", I changed security from "Maximum Compatibility" to "Custom". I checked only NTLMv2 under "Authentication Mechanism".

After all the above, I am still receiving the same "System Error 86 has occurred. The specified network password is not correct." error.

Ayomide Oluwaga 941

Since you have tried several solutions without success, let's try a different approach:

Check if the SMB 1.0/CIFS File Sharing Support feature is enabled on your Windows 10 machine. If it's not, enable it and try to map the Azure SMB File Share again.
Try using the Azure AD Domain Services feature instead of Azure AD Kerberos for authentication. This feature allows you to join Azure VMs to a domain managed by Azure AD Domain Services, which would allow you to map the Azure SMB File Share as a network drive.
Check the firewall settings on your Windows 10 machine to ensure that the required ports are open. In addition to port 445, port 139 should also be open.
Try creating a new Azure file share and see if you can map it successfully. If you can, the issue might be with the original file share.
Try mapping the Azure SMB File Share using the Azure Storage Explorer tool. This tool provides a GUI interface to map the file share, and might help you identify the issue.
Check the Azure Storage account access key to ensure that it hasn't been changed or expired. If it has, regenerate the access key and try mapping the Azure SMB File Share again.
Finally, if none of the above solutions work, you can try opening a support ticket with Microsoft Azure Support. They can assist you with troubleshooting the issue further.

Ayomide Oluwaga 941

To reset the on-premise AD mapping, you might need the help of your organization's I.T support or helpdesk

Brandon Paulk 0

1.) Confirmed SMB 1.0/CIFS Client/Server/Auto Removal are all installed & enabled.

2.) I do not believe this is a possibility because we are not ready to move to the cloud from our on-premise AD.

3.) Following Rules are enabled on all networks (Domain/Private/Public):

File and Printer Sharing (NB-Session-In) - port 139
File and Printer Sharing (SMB-In) - port 445

4.) Created new Storage Account & new File Share - configured for Maximum Compatibility & Azure AD Kerberos. Same error.

5.) Using Azure Storage Tool I was able to get into the file share & upload a file successfully. BUT I had to select between a Personal and a Work account both under the same email address. Is it possible this is a problem?

6.) Rotated access keys. No change.

7.) I was sent here to these forums by Azure Support online when they were unable to resolve the issue.

Brandon Paulk 0

To reset the on-premise AD mapping, you might need the help of your organization's I.T support or helpdesk

I am the organization's IT support & helpdesk...

Ayomide Oluwaga 941

Now I am really pricked, and I really want to solve this, give me some time. I need to make some research.

There is always a solution for every I.T problem.

Ayomide Oluwaga 941

As for the case of resetting the On-Prem AD mapping, please employ the following steps while i make further research on the former issue:

Open the Command Prompt as an administrator on the affected computer.
Type the command "dsregcmd /leave" and hit Enter. This will leave the current Azure AD domain and unjoin the device from the domain.
Next, type the command "dsregcmd /join" and hit Enter. This will join the device back to the domain and register it with Azure AD again.
Restart the computer and try to map the Azure SMB File Share again.

Note: You may need to enter your credentials again when you try to access the share after resetting the AD mapping.

Ayomide Oluwaga 941

These links might be helpful:

Microsoft Docs: Reset-ComputerMachinePassword: https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/reset-computermachinepassword?view=powershell-7.1
Microsoft Docs: Reset a computer account in Active Directory: https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/reset-computer-account

Brandon Paulk 0

1.) I followed the commands to reset On-Prem AD Mapping using "dsregcmd". Running with /status between the /leave and /join showed it was done correctly. No change.

2.) I decided to delete everything I have done so far, and try again. This time I tried using on-premise AD DS as the security option. I followed the directions provided. I got the same error (86) when doing this.

Ayomide Oluwaga 941

Hey @Brandon Paulk please use the free technical support ticket provided by @Sumarigo-MSFT below. This will include more hands-on support

Error 86 mapping Azure SMB File Share from Win10

2 answers