Dela via

Felsöka Azure Files problem med identitetsbaserad autentisering och auktorisering (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

Filresurstyp SMB NFS
Standardfilresurser (GPv2), LRS/ZRS
Standardfilresurser (GPv2), GRS/GZRS
Premium-filresurser (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 den 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 inträffat. Åtkomst nekas.

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

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

Obs!

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 Azure Files anslutningsproblem och åtkomstproblem.

Lösning

Kontrollera att behörigheterna är korrekt konfigurerade:

  • Active Directory Domain Services (AD DS) finns i Tilldela behörigheter på resursnivå.

    Behörighetstilldelningar på resursnivå stöds för grupper och användare som har synkroniserats från AD DS till Microsoft Entra ID med hjälp av 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 i molnet".

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

Felet AadDsTenantNotFound vid aktivering av Microsoft Entra Domain Services-autentisering för Azure Files "Det går inte att hitta aktiva klienter med klientorganisations-ID Microsoft Entra klientorganisations-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 har skapats på Microsoft Entra klientorganisation för den associerade prenumerationen.

Lösning

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

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.

För det andra kan du prova att montera Azure-filresursen med lagringskontonyckeln. Om resursen inte kan monteras laddar du ned AzFileDiagnostics som hjälper dig att verifiera klientens miljö som körs. 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 på AzFilesHybrid v0.1.2+-versionen. Du måste köra den här cmdleten med en AD-användare som har ägarbehörighet för 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 korrekt konfigurerat kör du cmdleten Set-AD som returneras i felsöknings-cmdleten för att konfigurera SPN.
  3. CheckDomainJoined: Kontrollera att klientdatorn är domänansluten till AD. Om datorn inte är domänansluten till AD kan du läsa anvisningarna i Ansluta en dator till en domän för domänanslutning.
  4. CheckPort445Connectivity: Kontrollera att 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 att den inloggade AD-användaren är synkroniserad med Microsoft Entra ID. Om du vill kontrollera om en specifik AD-användare synkroniseras till Microsoft Entra ID kan du ange -UserName och -Domain i indataparametrarna. För ett visst SID kontrollerar den om det finns en Microsoft Entra associerad användare.
  6. CheckAadUserHasSid: Kontrollera att den inloggade AD-användaren är synkroniserad med Microsoft Entra ID. Om du vill kontrollera om en specifik AD-användare synkroniseras till 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 den 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 hämtning av biljetter.
  8. CheckStorageAccountDomainJoined: Kontrollera om AD-autentiseringen har aktiverats och kontots AD-egenskaper har fyllts i. Annars 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 Azure Files. Om inte konfigurerar du behörigheten på resursnivå. (Stöds på AzFilesHybrid v0.2.3+ version)
  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 på AzFilesHybrid v0.2.3+ version)
  11. CheckAadKerberosRegistryKeyIsOff: Kontrollera om Microsoft Entra Kerberos-registernyckeln är inaktiverad. Om nyckeln är aktiverad kör reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 0 du från en upphöjd kommandotolk för att inaktivera den och startar sedan om datorn. (Stöds på AzFilesHybrid v0.2.9+ version)

Om du bara vill köra en undermarkering 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 konfigurera behörigheter på katalog-/filnivå (Windows-ACL:er) med Windows Utforskaren

Symptom

Du kan uppleva något av de symptom som beskrivs nedan när du försöker konfigurera Windows-ACL:er med Utforskaren på en monterad filresurs:

  • När du klickar på Redigera behörighet på 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 att välja 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.

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 innehåller RID Master FSMO-rollen inte är tillgänglig eller har tagits bort från domänen och återställts från säkerhetskopian. Bekräfta att alla domänkontrollanter körs och är tillgängliga.

Fel: "Det går inte att binda positionsparametrar eftersom inga 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.

Azure Files lokalt stöd för AD DS-autentisering 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 PowerShell nedan. 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ändaridentitet som tidigare hade rolltilldelningen Ägare eller Deltagare har fortfarande åtkomst till lagringskontonyckeln

Lagringskontots ägar- och deltagarroller ger möjlighet att lista lagringskontonycklarna. Lagringskontonyckeln ger fullständig åtkomst till lagringskontots data, inklusive filresurser, blobcontainrar, tabeller och köer samt begränsad åtkomst till Azure Files hanteringsåtgärder via äldre hanterings-API:er som exponeras via FileREST API. Om du ändrar rolltilldelningar bör du tänka på att de användare som tas bort från ägar- eller deltagarrollerna kan fortsätta att behålla åtkomsten 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änkontrollant 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 önskat lagringskonto 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 är registrerat i din Microsoft Entra klientorganisation för att slutföra konfigurationen. Du kan konfigurera API-behörigheter 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ör inaktivera möjligheten att bevilja administratörsmedgivande till Microsoft Entra program. Nedan visas skärmbilden av hur detta kan se 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.

Om så är fallet 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 om att 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 beta-/förhandsgranskningsfunktionen 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 inte 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örhandsversionssteg. Om du vill ta bort det befintliga programmet kan kunden eller deras IT-administratör 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 skapas automatiskt och hantera det nyligen skapade programmet. När du har initierat anslutningen till Microsoft Graph loggar du in på microsoft graph-programmet Kommandoradsverktyg på din enhet 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 är lösenordet för lagringskontots tjänsthuvudnamn inställt på 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 skapas det nya programmet automatiskt och hanteras 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 skriver troligen in sina autentiseringsuppgifter, men autentiseringsuppgifterna avvisas.

Orsak

Det beror på att SMB-klienten har försökt använda Kerberos men misslyckats, så den återgår till att använda NTLM-autentisering och Azure Files inte stöder 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ågon befintlig Microsoft Entra program.

Lösning

Lösningen är att lägga till FQDN för privateLink i lagringskontots Microsoft Entra-program innan du monterar filresursen. Du kan lägga till nödvändiga identifierUris 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 till identifierUris 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 om 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 hämta en Kerberos-biljett, och Microsoft Entra inloggningsloggar 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 program för lagringskontot eftersom vi inte fyller i berättiganden 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.