Dela via

Felsöka problem med identitetsbaserad autentisering och auktorisering i Azure Files (SMB)

  • Artikel

Den här artikeln innehåller vanliga problem när du använder SMB Azure-filresurser med identitetsbaserad autentisering. Det ger också möjliga orsaker och lösningar på dessa problem. Identitetsbaserad autentisering stöds för närvarande inte för NFS Azure-filresurser.

Gäller för

Typ av filresurs SMB NFS
Standardfilresurser (GPv2), LRS/ZRS
Standardfilresurser (GPv2), GRS/GZRS
Premiumfilresurser (FileStorage), LRS/ZRS

Fel vid körning av AzFilesHybrid-modulen

När du försöker köra AzFilesHybrid-modulen kan du få följande fel:

Klienten har inte behörighet som krävs.

Orsak: AD-behörigheter är otillräckliga

Det här problemet beror på att du inte har de active directory-behörigheter som krävs för att köra modulen.

Lösning

Se AD-behörigheterna eller kontakta AD-administratören för att ange de behörigheter som krävs.

Fel 5 vid montering av en Azure-filresurs

När du försöker montera en filresurs kan du få följande fel:

Systemfel 5 har uppstått. Åtkomst nekas.

Orsak: Behörigheter på resursnivå är felaktiga

Om slutanvändarna kommer åt Azure-filresursen med hjälp av Active Directory-domän Services (AD DS) eller Microsoft Entra Domain Services-autentisering misslyckas åtkomsten till filresursen med felet "Åtkomst nekas" om behörigheter på resursnivå är felaktiga.

Kommentar

Det här felet kan orsakas av andra problem än felaktiga behörigheter på resursnivå. Information om andra möjliga orsaker och lösningar finns i Felsöka problem med anslutning och åtkomst till Azure Files.

Lösning

Kontrollera att behörigheterna är korrekt konfigurerade:

  • Active Directory-domän Services (AD DS) se Tilldela behörigheter på resursnivå.

    Behörighetstilldelningar på resursnivå stöds för grupper och användare som synkroniseras från AD DS till Microsoft Entra ID med Microsoft Entra Connect Sync eller Microsoft Entra Connect-molnsynkronisering. Bekräfta att grupper och användare som tilldelas behörigheter på resursnivå inte stöds "endast molngrupper".

  • Microsoft Entra Domain Services se Tilldela behörigheter på resursnivå.

Fel AadDsTenantNotFound vid aktivering av Microsoft Entra Domain Services-autentisering för Azure Files "Det gick inte att hitta aktiva klienter med klient-ID:t Microsoft Entra klient-ID"

Orsak

Felet AadDsTenantNotFound inträffar när du försöker aktivera Microsoft Entra Domain Services-autentisering för Azure Files på ett lagringskonto där Microsoft Entra Domain Services inte skapas i Microsoft Entra-klientorganisationen för den associerade prenumerationen.

Lösning

Aktivera Microsoft Entra Domain Services i Microsoft Entra-klientorganisationen för den prenumeration som ditt lagringskonto distribueras till. Du behöver administratörsbehörighet för Microsoft Entra-klientorganisationen för att skapa en hanterad domän. Om du inte är administratör för Microsoft Entra-klientorganisationen kontaktar du administratören och följer den stegvisa vägledningen för att skapa och konfigurera en hanterad domän i Microsoft Entra Domain Services.

Det går inte att montera Azure-filresurser med AD-autentiseringsuppgifter

Självdiagnostiksteg

Kontrollera först att du har följt stegen för att aktivera Azure Files AD DS-autentisering.

Testa därefter att montera Azure-filresursen med lagringskontonyckeln. Om resursen inte kan monteras laddar du ned AzFileDiagnostics som hjälper dig att verifiera klientkörningsmiljön. AzFileDiagnostics kan identifiera inkompatibla klientkonfigurationer som kan orsaka åtkomstfel för Azure Files, ge förebyggande vägledning om självkorrigering och samla in diagnostikspårningarna.

För det tredje kan du köra cmdleten Debug-AzStorageAccountAuth för att utföra en uppsättning grundläggande kontroller av AD-konfigurationen med den inloggade AD-användaren. Den här cmdleten stöds i versionen AzFilesHybrid v0.1.2+. Du måste köra denna cmdlet med en AD-användare som har ägarbehörighet på mållagringskontot.

$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"

Debug-AzStorageAccountAuth `
    -StorageAccountName $StorageAccountName `
    -ResourceGroupName $ResourceGroupName `
    -Verbose

Cmdleten utför dessa kontroller i följd och ger vägledning för fel:

  1. CheckADObjectPasswordIsCorrect: Kontrollera att lösenordet som konfigurerats för DEN AD-identitet som representerar lagringskontot matchar lagringskontots kerb1- eller kerb2-nyckel. Om lösenordet är felaktigt kan du köra Update-AzStorageAccountADObjectPassword för att återställa lösenordet.
  2. CheckADObject: Bekräfta att det finns ett objekt i Active Directory som representerar lagringskontot och har rätt SPN (tjänstens huvudnamn). Om SPN inte är rätt konfigurerat kan du konfigurera SPN genom att köra cmdleten Set-AD som returneras i felsöknings-cmdleten.
  3. CheckDomainJoined: Kontrollera att klientdatorn är domänansluten till AD. Om datorn inte är domänansluten till AD kan du läsa anvisningarna för att ansluta en dator till en domän för domänanslutning.
  4. CheckPort445Connectivity: Kontrollera om port 445 är öppen för SMB-anslutning. Om port 445 inte är öppen kan du läsa felsökningsverktyget AzFileDiagnostics för anslutningsproblem med Azure Files.
  5. CheckSidHasAadUser: Kontrollera om den inloggade AD-användaren är synkroniserad med Microsoft Entra-ID. Om du vill se om en specifik AD-användare synkroniseras med Microsoft Entra-ID kan du ange -UserName och -Domain i indataparametrarna. För ett visst SID kontrollerar den om det finns en Associerad Microsoft Entra-användare.
  6. CheckAadUserHasSid: Kontrollera om den inloggade AD-användaren är synkroniserad med Microsoft Entra-ID. Om du vill se om en specifik AD-användare synkroniseras med Microsoft Entra-ID kan du ange -UserName och -Domain i indataparametrarna. För en viss Microsoft Entra-användare kontrollerar den dess SID. Om du vill köra den här kontrollen måste du ange parametern -ObjectId tillsammans med objekt-ID:t för Microsoft Entra-användaren.
  7. CheckGetKerberosTicket: Försök att hämta en Kerberos-biljett för att ansluta till lagringskontot. Om det inte finns en giltig Kerberos-token kör du cmdleten klist get cifs/storage-account-name.file.core.windows.net och undersöker felkoden för att fastställa orsaken till fel vid biljetthämtning.
  8. CheckStorageAccountDomainJoined: Kontrollera om AD-autentiseringen är aktiverad och kontots AD-egenskaper har fyllts i. Om inte aktiverar du AD DS-autentisering på Azure Files.
  9. CheckUserRbacAssignment: Kontrollera om AD-identiteten har rätt RBAC-rolltilldelning för att ge behörigheter på resursnivå för åtkomst till Azure Files. Om inte konfigurerar du behörigheten på resursnivå. (Stöds i versionen AzFilesHybrid v0.2.3+)
  10. CheckUserFileAccess: Kontrollera om AD-identiteten har rätt katalog-/filbehörighet (Windows-ACL:er) för att få åtkomst till Azure Files. Om inte konfigurerar du behörigheten på katalog-/filnivå. Om du vill köra den här kontrollen måste du ange parametern -FilePath tillsammans med sökvägen till den monterade fil som du vill felsöka åtkomsten till. (Stöds i versionen AzFilesHybrid v0.2.3+)
  11. CheckAadKerberosRegistryKeyIsOff: Kontrollera om Microsoft Entra Kerberos-registernyckeln är inaktiverad. Om nyckeln är på kör du reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 0 från en upphöjd kommandotolk för att stänga av den och starta sedan om datorn. (Stöds på AzFilesHybrid v0.2.9+ version)

Om du bara vill köra en delmarkering av de tidigare kontrollerna kan du använda parametern -Filter tillsammans med en kommaavgränsad lista över kontroller som ska köras. Om du till exempel vill köra alla kontroller relaterade till behörigheter på resursnivå (RBAC) använder du följande PowerShell-cmdletar:

$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"

Debug-AzStorageAccountAuth `
    -Filter CheckSidHasAadUser,CheckUserRbacAssignment `
    -StorageAccountName $StorageAccountName `
    -ResourceGroupName $ResourceGroupName `
    -Verbose

Om du har filresursen monterad på och om du bara vill köra kontrollen som rör behörigheter på X:filnivå (Windows-ACL:er) kan du köra följande PowerShell-cmdletar:

$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"
$FilePath = "X:\example.txt"

Debug-AzStorageAccountAuth `
    -Filter CheckUserFileAccess `
    -StorageAccountName $StorageAccountName `
    -ResourceGroupName $ResourceGroupName `
    -FilePath $FilePath `
    -Verbose

Det går inte att montera Azure-filresurser med Microsoft Entra Kerberos

Självdiagnostiksteg

Kontrollera först att du har följt stegen för att aktivera Microsoft Entra Kerberos-autentisering.

För det andra kan du köra cmdleten Debug-AzStorageAccountAuth för att utföra en uppsättning grundläggande kontroller. Den här cmdleten stöds för lagringskonton som konfigurerats för Microsoft Entra Kerberos-autentisering, på AzFilesHybrid v0.3.0+ version.

$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"

Debug-AzStorageAccountAuth -StorageAccountName $StorageAccountName -ResourceGroupName $ResourceGroupName -Verbose

Cmdleten utför dessa kontroller i följd och ger vägledning för fel:

  1. CheckPort445Connectivity: Kontrollera om port 445 är öppen för SMB-anslutning. Om port 445 inte är öppen använder du felsökningsverktyget AzFileDiagnostics för anslutningsproblem med Azure Files.
  2. CheckAADConnectivity: Sök efter Entra-anslutning. SMB-monteringar med Kerberos-autentisering kan misslyckas om klienten inte kan kontakta Entra. Om den här kontrollen misslyckas indikerar det att det finns ett nätverksfel (kanske ett brandväggs- eller VPN-problem).
  3. CheckEntraObject: Bekräfta att det finns ett objekt i Entra som representerar lagringskontot och har rätt namn på tjänstens huvudnamn (SPN). Om SPN inte är korrekt konfigurerat inaktiverar du och återaktiverar Entra Kerberos-autentisering på lagringskontot.
  4. CheckRegKey: Kontrollera om registernyckeln CloudKerberosTicketRetrieval är aktiverad. Den här registernyckeln krävs för Entra Kerberos-autentisering.
  5. CheckRealmMap: Kontrollera om användaren har konfigurerat några sfärmappningar som skulle ansluta kontot till en annan Kerberos-sfär än KERBEROS.MICROSOFTONLINE.COM.
  6. CheckAdminConsent: Kontrollera om Entra-tjänstens huvudnamn har beviljats administratörsmedgivande för de Microsoft Graph-behörigheter som krävs för att få en Kerberos-biljett.
  7. CheckWinHttpAutoProxySvc: Söker efter WinHTTP Web Proxy Auto-Discovery Service (WinHttpAutoProxySvc) som krävs för Microsoft Entra Kerberos-autentisering. Dess tillstånd ska vara inställt på Running.
  8. CheckIpHlpScv: Sök efter ip-hjälptjänsten (iphlpsvc) som krävs för Microsoft Entra Kerberos-autentisering. Dess tillstånd ska vara inställt på Running.
  9. CheckFiddlerProxy: Kontrollera om det finns en Fiddler-proxy som förhindrar Microsoft Entra Kerberos-autentisering.
  10. CheckEntraJoinType: Kontrollera om datorn är entra-domänansluten eller hybridentra domänansluten. Det är en förutsättning för Microsoft Entra Kerberos-autentisering.

Om du bara vill köra en delmarkering av de tidigare kontrollerna kan du använda parametern -Filter tillsammans med en kommaavgränsad lista över kontroller som ska köras.

Det går inte att konfigurera behörigheter på katalog- och filnivå (Windows-åtkomstkontrollistor) med Utforskaren i Windows

Symptom

Du kan uppleva ett av de symptom som beskrivs nedan när du försöker konfigurera Windows-åtkomstkontrollistor med Utforskaren på en monterad fildelning:

  • När du har klickat på Redigera behörighet under fliken Säkerhet läses inte guiden Behörighet in.
  • När du försöker välja en ny användare eller grupp visas inte rätt AD DS-domän på domänplatsen.
  • Du använder flera AD-skogar och får följande felmeddelande: ”Active Directory-domänkontrollanterna som krävs för att hitta de markerade objekten i följande domäner är inte tillgängliga. Kontrollera att Active Directory-domänkontrollanterna är tillgängliga och försök markera objekten igen.”

Lösning

Vi rekommenderar att du konfigurerar behörigheter på katalog-/filnivå med icacls i stället för att använda Windows Utforskaren.

Det går inte att visa UserPrincipalName (UPN) för en fil-/katalogägare i Utforskaren

Symptom

Utforskaren visar säkerhetsidentifieraren (SID) för en fil-/katalogägare, men inte UPN.

Orsak

Utforskaren anropar ett RPC-API direkt till servern (Azure Files) för att översätta SID till ett UPN. Azure Files stöder inte det här API:et, så UPN visas inte.

Lösning

På en domänansluten klient använder du följande PowerShell-kommando för att visa alla objekt i en katalog och deras ägare, inklusive UPN:

Get-ChildItem <Path> | Get-ACL | Select Path, Owner

Fel vid körning av cmdleten Join-AzStorageAccountForAuth

Fel: "Katalogtjänsten kunde inte allokera en relativ identifierare"

Det här felet kan inträffa om en domänkontrollant som har FSMO-rollen RID-hanterare inte är tillgänglig eller har tagits bort från domänen och återställts från en säkerhetskopia. Bekräfta att alla domänkontrollanter körs och är tillgängliga.

Fel: ”Det går inte att binda positionsparametrar eftersom inget namn angavs”

Det här felet utlöses troligen av ett syntaxfel i Join-AzStorageAccountforAuth kommandot. Kontrollera om det finns felstavningar eller syntaxfel i kommandot och kontrollera att den senaste versionen av AzFilesHybrid-modulen (https://github.com/Azure-Samples/azure-files-samples/releases) är installerad.

Stöd för lokal AD DS-autentisering i Azure Files för AES-256 Kerberos-kryptering

Azure Files stöder AES-256 Kerberos-kryptering för AD DS-autentisering från och med AzFilesHybrid-modulen v0.2.2. AES-256 är den rekommenderade krypteringsmetoden och det är standardkrypteringsmetoden som börjar i AzFilesHybrid-modulen v0.2.5. Om du har aktiverat AD DS-autentisering med en modulversion som är lägre än v0.2.2 måste du ladda ned den senaste AzFilesHybrid-modulen och köra följande PowerShell-skript. Om du inte har aktiverat AD DS-autentisering på ditt lagringskonto ännu följer du den här vägledningen.

Viktigt!

Om du tidigare använde RC4-kryptering och uppdaterade lagringskontot för att använda AES-256 bör du köra klist purge på klienten och sedan montera om filresursen för att hämta nya Kerberos-biljetter med AES-256.

$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"

Update-AzStorageAccountAuthForAES256 -ResourceGroupName $ResourceGroupName -StorageAccountName $StorageAccountName

Som en del av uppdateringen roterar cmdleten Kerberos-nycklarna, vilket är nödvändigt för att växla till AES-256. Du behöver inte rotera tillbaka om du inte vill återskapa båda lösenorden.

Användaridentiteten som tidigare hade rolltilldelningen Ägare eller Deltagare har fortfarande åtkomst till lagringskontonyckeln

Rollerna ägare och deltagare för lagringskontot ger möjlighet att visa en lista över lagringskontonycklarna. Lagringskontonyckeln ger fullständig åtkomst till lagringskontots data, inklusive filresurser, blobar, tabeller och köer. Det ger också begränsad åtkomst till Azure Files-hanteringsåtgärder via äldre hanterings-API:er som exponeras via FileREST-API:et. Om du ändrar rolltilldelningar bör du överväga att de användare som tas bort från rollerna Ägare eller Deltagare kan fortsätta att ha åtkomst till lagringskontot via sparade lagringskontonycklar.

Lösning 1

Du kan enkelt åtgärda det här problemet genom att rotera lagringskontonycklarna. Vi rekommenderar att du roterar nycklarna en i taget och växlar åtkomst från en till en annan när de roteras. Det finns två typer av delade nycklar som lagringskontot tillhandahåller: lagringskontonycklarna, som ger superadministratörsåtkomst till lagringskontots data, och Kerberos-nycklarna, som fungerar som en delad hemlighet mellan lagringskontot och Windows Server Active Directory-domänkontrollanten för Windows Server Active Directory-scenarier.

Information om hur du roterar Kerberos-nycklarna för ett lagringskonto finns i Uppdatera lösenordet för din lagringskontoidentitet i AD DS.

Gå till önskat lagringskonto i Azure Portal. I innehållsförteckningen för det önskade lagringskontot väljer du Åtkomstnycklar under rubriken Säkerhet + nätverk . I fönstret Åtkomstnyckel väljer du Rotera nyckel ovanför önskad nyckel.

Skärmbild som visar fönstret Åtkomstnyckel.

Ange API-behörigheter för ett nyligen skapat program

När du har aktiverat Microsoft Entra Kerberos-autentisering måste du uttryckligen ge administratörsmedgivande till det nya Microsoft Entra-programmet som registrerats i din Microsoft Entra-klientorganisation för att slutföra konfigurationen. Du kan konfigurera API-behörigheterna från Azure Portal genom att följa dessa steg.

  1. Öppna Microsoft Entra ID.
  2. Välj Appregistreringar i det vänstra fönstret.
  3. Välj Alla program i den högra rutan.
  4. Välj programmet med namnet som matchar [Lagringskonto] $storageAccountName.file.core.windows.net.
  5. Välj API-behörigheter i det vänstra fönstret.
  6. Välj Lägg till behörigheter längst ned på sidan.
  7. Välj Bevilja administratörsmedgivande för "DirectoryName".

Potentiella fel vid aktivering av Microsoft Entra Kerberos-autentisering för hybridanvändare

Du kan stöta på följande fel när du aktiverar Microsoft Entra Kerberos-autentisering för hybridanvändarkonton.

Fel – Bevilja administratörsmedgivande inaktiverat

I vissa fall kan Microsoft Entra-administratören inaktivera möjligheten att bevilja administratörsmedgivande till Microsoft Entra-program. Här är en skärmbild av hur detta ser ut i Azure Portal.

Skärmbild som visar bladet Konfigurerade behörigheter som visar en varning om att vissa åtgärder kan inaktiveras på grund av dina behörigheter.

I så fall ber du din Microsoft Entra-administratör att bevilja administratörsmedgivande till det nya Microsoft Entra-programmet. Om du vill hitta och visa dina administratörer väljer du roller och administratörer och sedan Molnprogramadministratör.

Fel – "Begäran till Azure AD Graph misslyckades med koden BadRequest"

Orsak 1: En programhanteringsprincip förhindrar att autentiseringsuppgifter skapas

När du aktiverar Microsoft Entra Kerberos-autentisering kan det här felet uppstå om följande villkor uppfylls:

  1. Du använder funktionen beta/förhandsversion i programhanteringsprinciper.
  2. Du (eller administratören) har angett en princip för hela klientorganisationen som:
    • Har inget startdatum eller har ett startdatum före den 1 januari 2019.
    • Anger en begränsning för lösenord för tjänstens huvudnamn, som antingen tillåter anpassade lösenord eller anger en maximal livslängd för lösenord på mindre än 365,5 dagar.

Det finns för närvarande ingen lösning på det här felet.

Orsak 2: Det finns redan ett program för lagringskontot

Du kan också stöta på det här felet om du tidigare har aktiverat Microsoft Entra Kerberos-autentisering via manuella, begränsade förhandsgranskningssteg. Om du vill ta bort det befintliga programmet kan kunden eller it-administratören köra följande skript. Om du kör det här skriptet tas det gamla manuellt skapade programmet bort och den nya upplevelsen kan automatiskt skapa och hantera det nyligen skapade programmet. När du har initierat anslutningen till Microsoft Graph loggar du in på Microsoft Graph-programmet Kommandoradsverktyg på enheten och beviljar behörigheter till appen.

$storageAccount = "exampleStorageAccountName"
$tenantId = "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"
Install-Module Microsoft.Graph
Import-Module Microsoft.Graph
Connect-MgGraph -TenantId $tenantId -Scopes "User.Read","Application.Read.All"

$application = Get-MgApplication -Filter "DisplayName eq '${storageAccount}'"
if ($null -ne $application) {
   Remove-MgApplication -ObjectId $application.ObjectId
}

Fel – Lösenordet för tjänstens huvudnamn har upphört att gälla i Microsoft Entra-ID

Om du tidigare har aktiverat Microsoft Entra Kerberos-autentisering via manuella begränsade förhandsversionssteg kommer lösenordet för lagringskontots tjänsthuvudnamn att upphöra att gälla var sjätte månad. När lösenordet upphör att gälla kan användarna inte hämta Kerberos-biljetter till filresursen.

För att undvika detta har du två alternativ: antingen rotera lösenordet för tjänstens huvudnamn i Microsoft Entra var sjätte månad eller följ dessa steg för att inaktivera Microsoft Entra Kerberos, ta bort det befintliga programmet och konfigurera om Microsoft Entra Kerberos.

Se till att spara domänegenskaper (domainName och domainGUID) innan du inaktiverar Microsoft Entra Kerberos, eftersom du behöver dem under omkonfigurationen om du vill konfigurera katalog- och filnivåbehörigheter med Hjälp av Windows Utforskaren. Om du inte sparade domänegenskaper kan du fortfarande konfigurera behörigheter på katalog-/filnivå med icacls som en lösning.

  1. Inaktivera Microsoft Entra Kerberos
  2. Ta bort det befintliga programmet
  3. Konfigurera om Microsoft Entra Kerberos via Azure Portal

När du har konfigurerat om Microsoft Entra Kerberos kommer den nya upplevelsen att skapa och hantera det nyligen skapade programmet automatiskt.

Fel 1326 – Användarnamnet eller lösenordet är felaktigt när du använder privat länk

Om du ansluter till ett lagringskonto via en privat slutpunkt/privat länk med Microsoft Entra Kerberos-autentisering uppmanas klienten att ange autentiseringsuppgifter när du försöker montera en filresurs via net use eller någon annan metod. Användaren kommer troligen att skriva in sina autentiseringsuppgifter, men autentiseringsuppgifterna avvisas.

Orsak

Det beror på att SMB-klienten har försökt använda Kerberos men misslyckades, så den återgår till att använda NTLM-autentisering och Azure Files stöder inte användning av NTLM-autentisering för domänautentiseringsuppgifter. Klienten kan inte få en Kerberos-biljett till lagringskontot eftersom det privata länk-FQDN inte är registrerat i något befintligt Microsoft Entra-program.

Lösning

Lösningen är att lägga till privateLink FQDN i lagringskontots Microsoft Entra-program innan du monterar filresursen. Du kan lägga till nödvändiga identifierar-IURI:er i programobjektet med hjälp av Azure Portal genom att följa dessa steg.

  1. Öppna Microsoft Entra ID.

  2. Välj Appregistreringar i det vänstra fönstret.

  3. Välj Alla program.

  4. Välj programmet med namnet som matchar [Lagringskonto] $storageAccountName.file.core.windows.net.

  5. Välj Manifest i den vänstra rutan.

  6. Kopiera och klistra in det befintliga innehållet så att du har en duplicerad kopia.

  7. Redigera JSON-manifestet. Lägg till en motsvarande <storageAccount>.privatelink.file.core.windows.net post för varje <storageAccount>.file.core.windows.net post. Om manifestet till exempel har följande värde för identifierUris:

    "identifierUris": [
    "api://<tenantId>/HOST/<storageaccount>.file.core.windows.net",
    "api://<tenantId>/CIFS/<storageaccount>.file.core.windows.net",
    "api://<tenantId>/HTTP/<storageaccount>.file.core.windows.net",
    "HOST/<storageaccount>.file.core.windows.net",
    "CIFS/<storageaccount>.file.core.windows.net",
    "HTTP/<storageaccount>.file.core.windows.net"
],

    Sedan bör du redigera fältet identifierUris till följande:

    "identifierUris": [
    "api://<tenantId>/HOST/<storageaccount>.file.core.windows.net",
    "api://<tenantId>/CIFS/<storageaccount>.file.core.windows.net",
    "api://<tenantId>/HTTP/<storageaccount>.file.core.windows.net",
    "HOST/<storageaccount>.file.core.windows.net",
    "CIFS/<storageaccount>.file.core.windows.net",
    "HTTP/<storageaccount>.file.core.windows.net",

    "api://<tenantId>/HOST/<storageaccount>.privatelink.file.core.windows.net",
    "api://<tenantId>/CIFS/<storageaccount>.privatelink.file.core.windows.net",
    "api://<tenantId>/HTTP/<storageaccount>.privatelink.file.core.windows.net",
    "HOST/<storageaccount>.privatelink.file.core.windows.net",
    "CIFS/<storageaccount>.privatelink.file.core.windows.net",
    "HTTP/<storageaccount>.privatelink.file.core.windows.net"
],

  8. Granska innehållet och välj Spara för att uppdatera programobjektet med den nya identifierarenUris.

  9. Uppdatera eventuella interna DNS-referenser så att de pekar på den privata länken.

  10. Försök att montera resursen igen.

Fel AADSTS50105

Begäran avbröts av följande fel AADSTS50105:

Administratören har konfigurerat programmet "Företagsprogramnamn" för att blockera användare såvida de inte uttryckligen beviljas (tilldelad) åtkomst till programmet. Den inloggade användaren {EmailHidden} blockeras eftersom de inte är direkt medlem i en grupp med åtkomst och inte heller har åtkomst direkt tilldelad av en administratör. Kontakta administratören för att tilldela åtkomst till det här programmet.

Orsak

Om du konfigurerar "tilldelning krävs" för motsvarande företagsprogram kan du inte få en Kerberos-biljett, och Inloggningsloggarna för Microsoft Entra visar ett fel trots att användare eller grupper har tilldelats till programmet.

Lösning

Välj inte Tilldelning som krävs för Microsoft Entra-programmet för lagringskontot eftersom vi inte fyller i rättigheter i Kerberos-biljetten som returneras tillbaka till beställaren. Mer information finns i Fel AADSTS50105 – Den inloggade användaren har inte tilldelats någon roll för programmet.

Se även

Kontakta oss för att få hjälp

Om du har frågor eller behöver hjälp skapar du en supportförfrågan eller frågar Azure community support. Du kan också skicka produktfeedback till Azure-feedbackcommunityn.