Solucionar problemas no suporte à autenticação do Arquivos do Azure AD DS para criptografia Kerberos AES-256

Aplica-se a: ✔️ compartilhamentos de arquivos do Azure SMB

Resumo

Este artigo explica como uma atualização de Windows futura alterará o tipo de criptografia Kerberos padrão no Active Directory Domain Services (AD DS) do RC4 para o AES-256 e como atualizar sua conta de armazenamento para que você não seja afetado. Arquivos do Azure clientes que já atualizaram suas contas de armazenamento para usar a criptografia AES-256 não serão afetados.

Métodos de criptografia suportados para acesso baseado em identidade do Arquivos do Azure

Arquivos do Azure usa a autenticação Kerberos para acesso baseado em identidade por SMB. A criptografia Kerberos AES-256 tem suporte desde o módulo AzFilesHybrid v0.2.2 e tem sido o método de criptografia padrão desde o módulo v0.2.5. Historicamente, o RC4 era a única opção de criptografia com suporte até que o suporte ao AES-256 fosse adicionado.

Uma alteração de Windows futura (July 2026 Windows Server Update) alterará o tipo de criptografia Kerberos padrão no AD DS de RC4 para AES-256. Se você usar a autenticação baseada em identidade com Arquivos do Azure e sua fonte de identidade for o AD DS local, poderá ocorrer falhas de montagem quando essa alteração for implantada. Recomendamos tomar medidas agora e atualizar suas contas de armazenamento para usar a criptografia AES-256 para garantir o acesso ininterrupto aos seus compartilhamentos de arquivos do Azure.

Contas de armazenamento configuradas com sufixos DNS personalizados ou nomes personalizados da entidade de serviço Kerberos (por exemplo, storageaccount.domain.com em vez de <storageaccount>.file.core.windows.net) podem ser afetadas anteriormente, começando com o Windows Update de abril de 2026. Se você usar SPNs personalizados, atualize para o AES-256 antes de aplicar a atualização de abril.

Para obter mais informações sobre esta mudança no Windows, consulte Como gerenciar o uso do RC4 pelo Kerberos KDC para alterações na emissão de tíquetes de contas de serviço relacionadas ao CVE-2026-20833.

Etapa 1: Verificar se você foi afetado

Verificar o impacto é um processo de duas partes:

1. No lado do Azure, localize todas as contas de armazenamento que usam autenticação do AD DS e descubra a quais domínios do AD essas contas estão associadas.
2. Para cada um desses domínios, execute uma consulta LDAP no AD DS para localizar objetos de conta de armazenamento que não foram atualizados para o AES-256.

Etapa 1a: Encontre contas de armazenamento associadas ao AD e seus domínios (Azure Resource Graph)

Se você tiver muitas assinaturas ou não souber a quais domínios do Active Directory suas contas de armazenamento estão associadas, execute a seguinte consulta no Azure Resource Graph Explorer. Ele enumera todas as contas de armazenamento no locatário que usa a autenticação do AD DS e retorna o domínio, a floresta, o sAMAccountName e o tipo de conta para cada um:

resources
| where type =~ 'microsoft.storage/storageaccounts'
| where properties.azureFilesIdentityBasedAuthentication.directoryServiceOptions == 'AD'
| project subscriptionId, resourceGroup, name,
          domainName = properties.azureFilesIdentityBasedAuthentication.activeDirectoryProperties.domainName,
          forestName = properties.azureFilesIdentityBasedAuthentication.activeDirectoryProperties.forestName,
          samAccountName = properties.azureFilesIdentityBasedAuthentication.activeDirectoryProperties.samAccountName,
          accountType = properties.azureFilesIdentityBasedAuthentication.activeDirectoryProperties.accountType
| order by subscriptionId, name

Se essa consulta não retornar resultados, nenhuma conta de armazenamento nas assinaturas consultadas usará a autenticação do AD DS e você não precisará executar nenhuma ação. Caso contrário, observe os valores distintos domainName retornados. Você os usará na próxima etapa.

Etapa 1b: identificar contas de armazenamento que não foram atualizadas para o AES-256 (AD DS)

Para cada domínio exclusivo retornado pela Etapa 1a, execute o seguinte comando do PowerShell em um computador ingressado nesse domínio para identificar objetos de conta de armazenamento que ainda estão usando RC4 (ou seja, o msDS-SupportedEncryptionTypes atributo não está definido):

Get-ADObject `
    -LDAPFilter "(&(servicePrincipalName=*.file.core.windows.net)(!(msDS-SupportedEncryptionTypes=*)))" -Properties servicePrincipalName, msDS-SupportedEncryptionTypes |
    Select-Object Name, ObjectClass, servicePrincipalName, msDS-SupportedEncryptionTypes

Se nenhum resultado for retornado, as contas de armazenamento nesse domínio já dão suporte ao AES-256 e você não precisará executar nenhuma ação para esse domínio. Se alguma conta for retornada, atualize essas contas para dar suporte ao AES-256.

Etapa 1c (opcional): identificar quais clientes ainda estão solicitando tíquetes RC4

As etapas 1a e 1b informam quais contas de armazenamento ainda precisam ser atualizadas. Eles não informam quais computadores cliente estão montando esses compartilhamentos com tíquetes RC4 no momento. Esta etapa é opcional e se destina a clientes que desejam mais segurança antes da atualização, por exemplo, para identificar clientes legados que possam precisar de correção ou para estimar o impacto de um chamado de gerenciamento de mudanças.

Em um controlador de domínio, filtre o log de eventos de segurança para eventos de tíquete de serviço Kerberos (ID do evento 4769), em que o Nome do Serviço é o SPN da conta de armazenamento (cifs/<storage-account-name>.file.core.windows.net) e o Tipo de Criptografia de Tíquete é 0x17 (RC4-HMAC). O campo Endereço do Cliente identifica o cliente solicitante.

Etapa 2: Garantir que o AES-256 seja permitido pelos clientes e pela conta de armazenamento

Antes de atualizar a conta de armazenamento na Etapa 3, confirme se o AES-256 é permitido em três camadas: o sistema operacional cliente, a política Kerberos do cliente e as configurações de segurança SMB da conta de armazenamento. Se o AES-256 estiver bloqueado em qualquer camada, as montagens falharão após a atualização.

Etapa 2a: Verificar se o sistema operacional cliente dá suporte ao AES-256

Verifique se os clientes estão executando uma versão do sistema operacional que dá suporte à criptografia de tíquete Kerberos AES-256. Todas as versões de sistema operacional atualmente suportadas têm suporte à criptografia AES-256 para tickets do Kerberos. Windows versões anteriores ao Vista, as versões do MacOS mais antigas que o OS X Lion 10.7 e as distribuições do Linux que executam o krb5 1.3.2 ou mais antigo não dão suporte à criptografia de tíquete AES-256. Se você tiver dúvidas sobre as versões do cliente, entre em contato com a Arquivos do Azure equipe de autenticação.

Etapa 2b: Verifique se a política Kerberos do cliente Windows permite AES-256

Para clientes Windows, verifique se os computadores cliente não têm um valor na chave do Registro HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters\SupportedEncryptionTypes que não permitiria explicitamente a criptografia AES-256. Consulte Montar Arquivos do Azure falha quando se usa o Entra Kerberos devido a tipos de criptografia Kerberos sem suporte para obter mais detalhes.

Para verificar a política de cliente em um computador Windows, execute o seguinte comando do PowerShell em uma sessão com privilégios elevados:

$path = 'HKLM:\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters'
$v = (Get-ItemProperty -Path $path -Name SupportedEncryptionTypes -ErrorAction SilentlyContinue).SupportedEncryptionTypes
if ($null -eq $v) {
    'OK: SupportedEncryptionTypes is not set. Windows uses its defaults (AES allowed).'
} elseif ($v -band 0x10) {
    "OK: SupportedEncryptionTypes = 0x{0:X} includes AES-256 (0x10)." -f $v
} else {
    "PROBLEM: SupportedEncryptionTypes = 0x{0:X} does NOT include AES-256 (0x10). AES-256 is disallowed on this client." -f $v
}

SupportedEncryptionTypes é uma máscara de bits. AES-256 é bit 0x10 (decimal 16). Se o valor do registro existir e o bit 0x10 não estiver ativado, o AES-256 será explicitamente desabilitado, e o cliente não poderá montar o compartilhamento de arquivos após a atualização da conta de armazenamento.

Por exemplo, 0x18 (24) permite AES-128 e AES-256 e é um valor seguro. 0x4 (4) permite apenas RC4 e não é seguro. 0x1C (28) permite RC4, AES-128 e AES-256 e é um valor de transição válido. Se o valor for definido pela Política de Grupo, atualize a política em: Configuração do Computador > Políticas > Configurações do Windows > Configurações de Segurança > Políticas Locais > Opções de Segurança > Segurança de rede: configurar os tipos de criptografia permitidos para Kerberos.

Etapa 2c: Verificar se as configurações de segurança SMB da conta de armazenamento permitem o AES-256

Verifique se as configurações de segurança SMB da conta de armazenamento não permitem a criptografia de tíquete Kerberos AES-256.

Etapa 3: atualizar sua conta de armazenamento para a AES-256

O que esperar durante a atualização. A atualização não é disruptiva para a maioria das cargas de trabalho. As sessões SMB no voo permanecem conectadas por meio de tíquetes existentes. Novas montagens após a atualização negociam o AES-256. Não há perda de dados e nenhum tempo de inatividade do serviço Arquivos do Azure. Os usuários finais com tíquetes RC4 armazenados em cache obtêm transparentemente um tíquete AES-256 na próxima renovação de tíquete (normalmente dentro de 10 horas) ou imediatamente após a execução klist purge.

Há duas opções para atualizar sua conta de armazenamento para o AES-256. É altamente recomendável usar a Opção 1 usando o módulo AzFilesHybrid PowerShell, pois ele manipula todas as etapas necessárias automaticamente com um único comando. A opção 2 fornece etapas manuais se não for possível usar o módulo.

Opção 1: usar o cmdlet AzFilesHybrid (recomendado)

Lista de verificação pré-voo. Antes de executar o cmdlet, confirme todas as opções a seguir. A maioria das falhas da Opção 1 remonta a um destes pré-requisitos ausentes:

• Azure RBAC: O usuário em execução (ou entidade de serviço) tem a função Storage Account Contributor (ou superior) na conta de armazenamento de destino.
• Permissões do Active Directory: O usuário que executa a operação é membro de Domain Admins ou tem uma delegação explícita na OU que contém o objeto do AD da conta de armazenamento, concedendo os direitos Reset Password e Write msDS-SupportedEncryptionTypes.
• Contexto do computador: O cmdlet é executado em um computador associado a um domínio na mesma floresta do AD DS que a conta de armazenamento, com conectividade de rede sem impedimentos para um controlador de domínio (portas LDAP/Kerberos abertas).
• Módulos do PowerShell: A versão atual do AzFilesHybrid é instalada e importada.
• Sessão autenticada: Você está conectado à assinatura correta (Connect-AzAccount seguido por Set-AzContext -Subscription <subscriptionId>).

Depois que os pré-requisitos estiverem atendidos, execute o seguinte cmdlet em uma sessão elevada do PowerShell:

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

Update-AzStorageAccountAuthForAES256 -ResourceGroupName $ResourceGroupName -StorageAccountName $StorageAccountName

O que o cmdlet faz:Update-AzStorageAccountAuthForAES256 executa três etapas coordenadas em uma única operação. Saber o que está acontecendo ajuda você a entender os requisitos de RBAC (Colaborador da Conta de Armazenamento na SA + permissões de modificação no AD na UO) e a explicar a alteração às equipes de AD/segurança que talvez precisem revisá-la:

1. Rotaciona uma das chaves Kerberos da conta de armazenamento (kerb1 por padrão). A chamada New-AzStorageAccountKey -KeyName kerb1 gera uma nova senha para o objeto do AD que faz backup da conta de armazenamento. Esta é uma operação do lado do Azure no provedor de recursos da conta de armazenamento.
2. Define msDS-SupportedEncryptionTypes o objeto AD para habilitar o AES-256. Esta é uma operação de gravação no AD no objeto de computador ou de usuário que representa a conta de armazenamento, motivo pelo qual a identidade em execução precisa de permissão de gravação msDS-SupportedEncryptionTypes na OU.
3. Redefine a senha do objeto AD para a chave de kerb girada. Isso sincroniza a senha do lado do AD com a nova chave para que a conta de armazenamento possa emitir tíquetes AES-256 que os controladores de domínio validarão. É por isso que a identidade de execução precisa de Reset Password na UO.

$sa = Get-AzStorageAccountADObject -StorageAccountName "<storage-account-name>" -ResourceGroupName "<resource-group-name>"
$ou = ($sa.DistinguishedName -split ',', 2)[1]
Get-Acl -Path "AD:$ou" | Format-List

Opção 2: etapas manuais

Se você não puder usar o módulo AzFilesHybrid, poderá atualizar manualmente para o AES-256 seguindo estas etapas.

Primeiro, verifique as propriedades de domínio configuradas na conta de armazenamento:

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

$sa = Get-AzStorageAccount -ResourceGroupName $ResourceGroupName -Name $StorageAccountName
$sa.AzureFilesIdentityBasedAuth.ActiveDirectoryProperties | Select-Object DomainName, SamAccountName, AccountType

Você deve verificar se DomainName, SamAccountName e AccountType todos retornem valores, e se eles correspondem aos valores da conta do AD. Você pode verificar esses valores na conta do AD com o seguinte cmdlet do PowerShell.

$domainInformation = Get-ADDomain
$domainName = $domainInformation.DnsRoot
$samAccountName = $saAdObject.sAMAccountName.TrimEnd('$')
$type = if ($saAdObject.objectClass -contains "computer") { "Computer" } `
    elseif ($saAdObject.objectClass -contains "user") { "User" }

Write-Host "DomainName=$domainName, samAccountName=$samAccountName, type=$type"

Para garantir que todas as propriedades de domínio estejam configuradas corretamente na conta de armazenamento, execute o script a seguir. É seguro executar mesmo se as propriedades de domínio já estiverem configuradas corretamente na conta de armazenamento.

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

$domainInformation = Get-ADDomain
$domainGuid = $domainInformation.ObjectGUID.ToString()
$domainName = $domainInformation.DnsRoot
$domainSid = $domainInformation.DomainSID.Value
$forestName = $domainInformation.Forest
$netBiosDomainName = $domainInformation.DnsRoot

$saAdObject = Get-ADObject `
    -LDAPFilter "(servicePrincipalName=cifs/$StorageAccountName.file.core.windows.net)" `
    -Properties *

$saADObjectSid = $saAdObject.objectSid.Value
$samAccountName = $saAdObject.sAMAccountName.TrimEnd('$')
$type = if ($saAdObject.objectClass -contains "computer") { "Computer" } `
    elseif ($saAdObject.objectClass -contains "user") { "User" }

Set-AzStorageAccount `
    -ResourceGroupName $ResourceGroupName `
    -Name $StorageAccountName `
    -EnableActiveDirectoryDomainServicesForFile $true `
    -ActiveDirectoryDomainName $domainName `
    -ActiveDirectoryNetBiosDomainName $netBiosDomainName `
    -ActiveDirectoryForestName $forestName  `
    -ActiveDirectoryDomainGuid $domainGuid `
    -ActiveDirectoryDomainSid $domainSid `
    -ActiveDirectoryAzureStorageSid $saADObjectSid `
    -ActiveDirectorySamAccountName $samAccountName `
    -ActiveDirectoryAccountType $type

Para obter mais informações, consulte Habilitar a autenticação do AD DS para arquivos do Azure.

Habilitar o AES-256 no objeto de domínio

Se você já executou o script de propriedades de domínio anteriores e tem a $saAdObject variável em sua sessão, ignore a consulta a seguir e defina $identity = $saAdObject.DistinguishedName diretamente.

$saAdObject = Get-ADObject `
    -LDAPFilter "(servicePrincipalName=cifs/$StorageAccountName.file.core.windows.net)" `
    -Properties *

$identity = $saAdObject.DistinguishedName

Para determinar o tipo de conta, verifique o AccountType valor da verificação de propriedades de domínio ou execute $saAdObject.objectClass. Se a classe de objeto for computer, use Set-ADComputer. Se for user, use Set-ADUser.

Set-ADUser `
    -Identity $identity `
    -Server <domain-name> `
    -UserPrincipalName cifs/$StorageAccountName.file.core.windows.net@<domain-dns-root>

Para habilitar a criptografia AES-256 em uma conta de computador, execute o comando a seguir.

Set-ADComputer -Identity $identity -KerberosEncryptionType "AES256"

Para habilitar a criptografia AES-256 em uma conta de logon de serviço, execute o comando a seguir.

Set-ADUser -Identity $identity -KerberosEncryptionType "AES256"

Atualizar a senha do objeto de domínio

Depois de executar o cmdlet anterior, execute o script a seguir para atualizar a senha do objeto de domínio. Essa etapa é essencial para gerar os metadados de autenticação apropriados no lado do serviço.

$KeyName = "kerb1" # Could be either the first or second kerberos key, this script assumes we're refreshing the first
$KerbKeys = New-AzStorageAccountKey -ResourceGroupName $ResourceGroupName -Name $StorageAccountName -KeyName $KeyName
$KerbKey = $KerbKeys.keys | Where-Object {$_.KeyName -eq $KeyName} | Select-Object -ExpandProperty Value
$NewPassword = ConvertTo-SecureString -String $KerbKey -AsPlainText -Force

Set-ADAccountPassword -Identity $identity -Reset -NewPassword $NewPassword

Etapa 4: Confirmar a atualização do AES-256

Depois de concluir a Opção 1 ou a Opção 2, limpe os tíquetes Kerberos armazenados em cache no cliente e verifique a atualização ao remontar o compartilhamento de arquivos.

1. Execute o klist purge a partir de um prompt de comando elevado para excluir quaisquer tíquetes Kerberos armazenados em cache que ainda usam RC4.
2. Monte novamente o compartilhamento de arquivos do Azure.
3. Execute klist get cifs/<storage-account-name>.file.core.windows.net para verificar se o novo ticket do Kerberos utiliza criptografia AES-256.

A saída deve apresentar AES-256-CTS-HMAC-SHA1-96 tanto para o Tipo de Criptografia do KerbTicket quanto para o Tipo de Chave de Sessão, similar ao seguinte:

#1>     Client: user @ DOMAIN.CONTOSO.COM
        Server: cifs/<storage-account-name>.file.core.windows.net @ DOMAIN.CONTOSO.COM
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
        Start Time: 3/20/2026 23:16:32 (local)
        End Time:   3/21/2026 9:16:32 (local)
        Renew Time: 3/27/2026 23:16:32 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0
        Kdc Called: <domain-controller-name>

Para confirmar a atualização em um domínio inteiro (em vez de um cliente por vez), execute novamente a consulta LDAP da etapa 1b . Todas as contas de armazenamento atualizadas não devem mais aparecer nos resultados. Uma vez msDS-SupportedEncryptionTypes definido no objeto AD, o filtro o exclui.

Revertendo a atualização do AES-256

Se você encontrar problemas de autenticação após a atualização para o AES-256, poderá reverter para RC4 usando as etapas a seguir. Embora você ainda deva atualizar para o AES-256 antes que o Windows Update altere o tipo de criptografia padrão no AD DS, essas etapas permitem que você reverta temporariamente para RC4 enquanto resolve problemas do AES-256.

1. Verifique se os computadores cliente não têm o seguinte valor de chave do Registro. Verifique a chave do Registro HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters\SupportedEncryptionTypes. Ele não permite explicitamente a criptografia RC4. Para obter detalhes, consulte falha ao montar nos Arquivos do Azure ao usar Entra Kerberos devido a tipos de criptografia Kerberos não suportados.

2. Verifique se as configurações de segurança SMB da conta de armazenamento não impedem a criptografia de tíquete Kerberos RC4. Para obter mais informações, consulte as configurações de segurança SMB da conta de armazenamento.

3. Obtenha o nome diferenciado do objeto AD que representa a conta de armazenamento. Use o seguinte comando do PowerShell.

$StorageAccountName = "<storage-account-name-here>"

$saAdObject = Get-ADObject `
    -LDAPFilter "(servicePrincipalName=cifs/$StorageAccountName.file.core.windows.net)" `
    -Properties *

$identity = $saAdObject.DistinguishedName

Se o objeto AD for uma conta de computador, execute o comando a seguir para limpar a propriedade msDS-SupportedEncryptionTypes .

Set-ADComputer -Identity $identity -Clear msDS-SupportedEncryptionTypes

Se o objeto AD for uma conta de logon de serviço, execute o comando a seguir.

Set-ADUser -Identity $identity -Clear msDS-SupportedEncryptionTypes

4. Execute o klist purge a partir de um prompt de comando com privilégios elevados em computadores cliente afetados. Limpe quaisquer tíquetes Kerberos armazenados em cache que usam ainda o AES-256. Após a próxima montagem, klist deve mostrar uma conta de armazenamento com Tipo de Criptografia KerbTicket de RC4-HMAC. Use o seguinte comando para verificar o tipo de criptografia do tíquete Kerberos:

#1>     Client: user @ DOMAIN.CONTOSO.COM
        Server: cifs/<storage-account-name>.file.core.windows.net @ DOMAIN.CONTOSO.COM
        KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
        Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
        Start Time: 3/20/2026 23:16:32 (local)
        End Time:   3/21/2026 9:16:32 (local)
        Renew Time: 3/27/2026 23:16:32 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0
        Kdc Called: <domain-controller-name>

Consulte também

• Windows Vulnerabilidade de Divulgação de Informações do Kerberos
• Como gerenciar o uso de RC4 pelo Kerberos KDC para emissão de tíquetes de contas de serviço em mudanças relacionadas ao CVE-2026-20833.
• Habilitar autenticação AD DS para Arquivos do Azure