You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/storage/files/files-troubleshoot-smb-authentication.md
+23-2Lines changed: 23 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,7 @@ description: Troubleshoot problems using identity-based authentication to connec
4
4
author: khdownie
5
5
ms.service: storage
6
6
ms.topic: troubleshooting
7
-
ms.date: 02/21/2023
7
+
ms.date: 03/28/2023
8
8
ms.author: kendownie
9
9
ms.subservice: files
10
10
---
@@ -183,7 +183,7 @@ After enabling Azure AD Kerberos authentication, you'll need to explicitly grant
183
183
184
184
## Potential errors when enabling Azure AD Kerberos authentication for hybrid users
185
185
186
-
You might encounter the following errors when trying to enable Azure AD Kerberos authentication for hybrid user accounts.
186
+
You might encounter the following errors when enabling Azure AD Kerberos authentication for hybrid user accounts.
187
187
188
188
### Error - Grant admin consent disabled
189
189
@@ -320,6 +320,27 @@ If you don't want to rotate the service principal password every six months, you
320
320
321
321
Once you've reconfigured Azure AD Kerberos, the new experience will auto-create and manage the newly created application.
322
322
323
+
### Error 1326 - The username or password is incorrect when using private link
324
+
325
+
If you're connecting to a storage account via a private endpoint/private link using Azure AD Kerberos authentication, when attempting to mount a file share via `net use` or other method, the client is prompted for credentials. The user will likely type their credentials in, but the credentials are rejected.
326
+
327
+
#### Cause
328
+
329
+
This is because the SMB client has tried to use Kerberos but failed, so it falls back to using NTLM authentication, which Azure Files doesn't support. The client can't get a Kerberos ticket to the storage account because the private link FQDN isn't registered to any existing Azure AD application.
330
+
331
+
#### Solution
332
+
333
+
The solution is to add the privateLink FQDN to the storage account's Azure AD application before you mount the file share. You can add the required identifierUris to the application object using the [Azure portal](https://portal.azure.com) by following these steps.
334
+
335
+
1. Open **Azure Active Directory**.
336
+
1. Select **App registrations** in the left pane.
337
+
1. Select **All Applications**.
338
+
1. Select the application with the name matching **[Storage Account] $storageAccountName.file.core.windows.net**.
339
+
1. Select **Manifest** in the left pane.
340
+
1. Copy and paste the existing content so you have a duplicate copy. Replace all instances of `<storageaccount>.file.core.windows.net` with `<storageaccount>.privatelink.file.core.windows.net`.
341
+
1. Review the content and select **Save** to update the application object with the new identifierUris.
342
+
1. Retry mounting the share.
343
+
323
344
## Need help?
324
345
If you still need help, [contact support](https://portal.azure.com/?#blade/Microsoft_Azure_Support/HelpAndSupportBlade) to get your problem resolved quickly.
0 commit comments