Solución de problemas de compatibilidad de autenticación de AD DS de Azure Files para el cifrado Kerberos AES-256

Aplica a: ✔️ comparticiones de archivos Azure SMB

Resumen

En este artículo se explica cómo una próxima actualización de Windows cambiará el tipo de cifrado Kerberos predeterminado en Active Directory Domain Services (AD DS) de RC4 a AES-256 y cómo actualizar la cuenta de almacenamiento para que no se vea afectada. Azure Files los clientes que ya han actualizado sus cuentas de almacenamiento para usar el cifrado AES-256 no se verán afectados.

Métodos de cifrado admitidos para el acceso basado en identidad de Azure Files

Azure Files usa la autenticación Kerberos para el acceso basado en identidades a través de SMB. El cifrado Kerberos AES-256 se ha admitido desde el módulo AzFilesHybrid v0.2.2 y ha sido el método de cifrado predeterminado desde el módulo v0.2.5. Históricamente, RC4 era la única opción de cifrado admitida hasta que se agregó compatibilidad con AES-256.

Un próximo cambio de Windows (July 2026 Windows Server Update) cambiará el tipo de cifrado Kerberos predeterminado en AD DS de RC4 a AES-256. Si usa la autenticación basada en identidades con Azure Files y el origen de identidad es AD DS local, es posible que experimente errores de montaje al implementar este cambio. Se recomienda tomar medidas ahora y actualizar las cuentas de almacenamiento para usar el cifrado AES-256 para garantizar el acceso ininterrumpido a los recursos compartidos de archivos de Azure.

Las cuentas de almacenamiento configuradas con sufijos DNS personalizados o nombres principales de servicio Kerberos personalizados (por ejemplo, storageaccount.domain.com en lugar de <storageaccount>.file.core.windows.net) podrían verse afectados antes, a partir de la actualización de Windows de abril de 2026. Si usa SPN personalizados, actualice a AES-256 antes de aplicar la actualización de abril.

Para obtener más información sobre este cambio de Windows, consulte Cómo gestionar el uso de RC4 por el KDC de Kerberos para los cambios en la emisión de tickets de cuentas de servicio relacionados con CVE-2026-20833.

Paso 1: Comprobar si está afectado

La comprobación del impacto es un proceso de dos partes:

1. Desde el lado Azure, busque cada cuenta de almacenamiento que use la autenticación de AD DS y descubra a qué dominios de AD están unidos esas cuentas.
2. Para cada uno de esos dominios, ejecute una consulta LDAP en AD DS para buscar objetos de cuenta de almacenamiento que no se hayan actualizado a AES-256.

Paso 1a: Búsqueda de cuentas de almacenamiento unidas a AD y sus dominios (Azure Resource Graph)

Si tiene muchas suscripciones o no está seguro de a qué dominios de AD están unidos las cuentas de almacenamiento, ejecute la siguiente consulta en Azure Resource Graph Explorer. Enumera todas las cuentas de almacenamiento en todo el inquilino que utilizan la autenticación de AD DS y devuelve el dominio, el bosque, sAMAccountName y el tipo de cuenta para cada una:

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

Si esta consulta no devuelve ningún resultado, ninguna cuenta de almacenamiento de las suscripciones consultadas usa la autenticación de AD DS y no es necesario realizar ninguna acción. De lo contrario, tome nota de los valores únicos domainName devueltos. Los usarás en el siguiente paso.

Paso 1b: Identificar las cuentas de almacenamiento que no se han actualizado a AES-256 (AD DS)

Para cada dominio único devuelto por el paso 1a, ejecute el siguiente comando de PowerShell en un equipo unido a ese dominio para identificar objetos de cuenta de almacenamiento que todavía usan RC4 (es decir, el msDS-SupportedEncryptionTypes atributo no está establecido):

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

Si no se devuelve ningún resultado, las cuentas de almacenamiento de ese dominio ya admiten AES-256 y no es necesario realizar ninguna acción para ese dominio. Si se devuelven cuentas, actualice esas cuentas para admitir AES-256.

Paso 1c (opcional): identificar qué clientes siguen solicitando vales RC4

Los pasos 1a y 1b indican qué cuentas de almacenamiento deben actualizarse. No le dicenqué equipos cliente están montando actualmente esos recursos compartidos con tickets RC4. Este paso es opcional y está pensado para los clientes que desean una mayor seguridad antes de actualizar, por ejemplo, para identificar clientes antiguos que podrían necesitar parches o para estimar el alcance del impacto de un ticket de gestión de cambios.

En un controlador de dominio, filtre el registro de eventos de seguridad para los eventos de vale de servicio de Kerberos (Id. de evento 4769), donde el Nombre del servicio es el SPN de la cuenta de almacenamiento (cifs/<storage-account-name>.file.core.windows.net) y el Tipo de cifrado del vale es 0x17 (RC4-HMAC). El campo Dirección de cliente identifica el cliente solicitante.

Paso 2: Asegúrese de que los clientes y la cuenta de almacenamiento permiten AES-256

Antes de actualizar la cuenta de almacenamiento en el paso 3, confirme que AES-256 está permitido en tres capas: el sistema operativo cliente, la directiva Kerberos de cliente y la configuración de seguridad de SMB de la cuenta de almacenamiento. Si AES-256 está bloqueado en cualquier capa, se producirá un error en los montajes después de la actualización.

Paso 2a: Comprobar que el sistema operativo cliente admite AES-256

Asegúrese de que sus clientes ejecuten una versión del sistema operativo que admita el cifrado AES-256 de tickets de Kerberos. Todas las versiones de sistemas operativos que cuentan actualmente con soporte activo son compatibles con el cifrado AES-256 de tiques de Kerberos. Las versiones de Windows anteriores a Vista, las versiones de MacOS anteriores a OS X Lion 10.7 y las distribuciones de Linux que utilizan krb5 1.3.2 o una versión anterior no admiten el cifrado AES-256 de tickets. Si tiene preguntas sobre las versiones de cliente, póngase en contacto con el equipo de autenticación de Azure Files.

Paso 2b: Comprobar que la directiva Kerberos del cliente de Windows permite AES-256

Para los clientes Windows, asegúrese de que los equipos cliente no tengan ningún valor en la clave del Registro HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters\SupportedEncryptionTypes que impida explícitamente el cifrado AES-256. Consulte Mount to Azure Files error al usar Entra Kerberos debido a tipos de cifrado Kerberos no admitidos para obtener más información.

Para comprobar la directiva de cliente en una máquina Windows, ejecute el siguiente comando de PowerShell en una sesión con privilegios 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 es una máscara de bits. AES-256 es bit 0x10 (decimal 16). Si el valor del Registro existe y el bit 0x10 no está establecido, AES-256 está explícitamente deshabilitado y el cliente no podrá montar el recurso compartido de archivos una vez que se actualice la cuenta de almacenamiento.

Por ejemplo, 0x18 (24) permite AES-128 y AES-256 y es un valor seguro. 0x4 (4) solo permite RC4 y no es seguro. 0x1C (28) permite RC4, AES-128 y AES-256 y es un valor transitorio válido. Si la directiva de grupo establece el valor, actualice la directiva en Configuración de equipo > Directivas > Windows Configuración > Configuración de seguridad > Directivas locales > Opciones de seguridad > Seguridad de red: configure los tipos de cifrado permitidos para Kerberos.

Paso 2c: Compruebe que la configuración de seguridad SMB de la cuenta de almacenamiento permita AES-256

Asegúrese de que la configuración de seguridad SMB de la cuenta de almacenamiento no impida el cifrado AES-256 de los vales Kerberos.

Paso 3: Actualización de la cuenta de almacenamiento a AES-256

Qué esperar durante la actualización. La actualización no es perjudicial para la mayoría de las cargas de trabajo. Las sesiones de SMB en vuelo permanecen conectadas a través de vales existentes. Los nuevos puntos de montaje, tras la actualización, negocian el uso de AES-256. No hay pérdida de datos ni tiempo de inactividad del servicio de Azure Files. Los usuarios finales con vales RC4 almacenados en caché obtienen de forma transparente un vale AES-256 en la siguiente renovación de vales (normalmente en un plazo de 10 horas) o inmediatamente después de ejecutar klist purge.

Hay dos opciones para actualizar la cuenta de almacenamiento a AES-256. Se recomienda encarecidamente la opción 1 mediante el módulo AzFilesHybrid de PowerShell, ya que controla todos los pasos necesarios automáticamente con un solo comando. La opción 2 proporciona pasos manuales si no puede usar el módulo.

Opción 1: Uso del cmdlet AzFilesHybrid (recomendado)

Lista de comprobación previa al vuelo. Antes de ejecutar el cmdlet, confirme lo siguiente. La mayoría de los errores de la opción 1 realizan un seguimiento a uno de estos requisitos previos que faltan:

• Azure RBAC: El usuario que ejecuta la operación (o la entidad de servicio) tiene el rol Colaborador de la cuenta de almacenamiento (o uno superior) en la cuenta de almacenamiento de destino.
• Permisos de Active Directory: El usuario que ejecuta la operación pertenece a Domain Admins o tiene una delegación explícita en la OU que contiene el objeto de Active Directory de la cuenta de almacenamiento, que concede los derechos Reset Password y Write msDS-SupportedEncryptionTypes.
• Contexto de la máquina: El cmdlet se ejecuta desde una máquina que está unida a un dominio del mismo bosque de AD DS que la cuenta de almacenamiento, con conectividad de red sin restricciones con un controlador de dominio (puertos LDAP/Kerberos abiertos).
• Módulos de PowerShell: La versión actual de AzFilesHybrid está instalada e importada.
• Sesión autenticada: Ha iniciado sesión en la suscripción correcta (Connect-AzAccount seguida de Set-AzContext -Subscription <subscriptionId>).

Una vez implementados los requisitos previos, ejecute el siguiente cmdlet desde una sesión de PowerShell con privilegios elevados:

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

Update-AzStorageAccountAuthForAES256 -ResourceGroupName $ResourceGroupName -StorageAccountName $StorageAccountName

Qué hace el cmdlet:Update-AzStorageAccountAuthForAES256 realiza tres pasos coordinados en una sola operación. Entender qué está ocurriendo le ayuda a razonar sobre los requisitos de RBAC (Colaborador de la cuenta de almacenamiento en la SA + permisos de modificación en AD sobre la OU) y a explicar el cambio a los equipos de AD y de seguridad que podrían necesitar revisarlo:

1. Rota una de las claves Kerberos de una cuenta de almacenamiento (kerb1 de forma predeterminada). La llamada a New-AzStorageAccountKey -KeyName kerb1 genera una nueva contraseña para el objeto de AD que respalda la cuenta de almacenamiento. Se trata de una operación en el lado de Azure sobre el proveedor de recursos de la cuenta de almacenamiento.
2. Establece msDS-SupportedEncryptionTypes en el objeto AD para habilitar AES-256. Se trata de una operación de escritura en AD sobre el objeto de equipo o de usuario correspondiente a la cuenta de almacenamiento, por lo que la identidad que ejecuta la operación necesita Escribir msDS-SupportedEncryptionTypes en la unidad organizativa.
3. Restablece la contraseña del objeto de Active Directory a la clave kerb rotada. Esto sincroniza la contraseña del lado AD con la nueva clave para que la cuenta de almacenamiento pueda emitir vales AES-256 que validarán los controladores de dominio. Este es el motivo por el que la identidad en ejecución necesita restablecer la contraseña en la unidad organizativa.

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

Opción 2: Pasos manuales

Si no puede usar el módulo AzFilesHybrid, puede actualizar manualmente a AES-256 siguiendo estos pasos.

En primer lugar, compruebe las propiedades de dominio configuradas en la cuenta de almacenamiento:

$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

Debe comprobar que DomainName, SamAccountName y AccountType todos devuelven valores, y que coinciden con los valores de la cuenta de AD. Puede comprobar estos valores en la cuenta de AD con el siguiente cmdlet de 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 asegurarse de que todas las propiedades de dominio están configuradas correctamente en la cuenta de almacenamiento, ejecute el siguiente script. Es seguro ejecutarse incluso si las propiedades del dominio ya están configuradas correctamente en la cuenta de almacenamiento.

$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 más información, consulte Habilitación de la autenticación de AD DS para Azure Files.

Habilitar AES-256 en el objeto de dominio

Si ya ejecutó el script de propiedades de dominio anterior y tiene la $saAdObject variable en la sesión, puede omitir la siguiente consulta y establecerla $identity = $saAdObject.DistinguishedName directamente.

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

$identity = $saAdObject.DistinguishedName

Para determinar el tipo de cuenta, compruebe el AccountType valor de la comprobación de propiedades del dominio o ejecute $saAdObject.objectClass. Si la clase de objeto es computer, use Set-ADComputer. Si es user, use Set-ADUser.

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

Para habilitar el cifrado AES-256 en una cuenta de equipo, ejecute el siguiente comando.

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

Para habilitar el cifrado AES-256 en una cuenta de inicio de sesión de servicio, ejecute el siguiente comando en su lugar.

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

Actualizar la contraseña del objeto de dominio

Después de ejecutar el cmdlet anterior, ejecute el siguiente script para actualizar la contraseña del objeto de dominio. Este paso es fundamental para generar los metadatos de autenticación adecuados en el lado del servicio.

$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

Paso 4: Confirmar la actualización AES-256

Después de completar la Opción 1 u Opción 2, elimine los tickets Kerberos almacenados en caché en el cliente y compruebe la actualización al volver a montar el recurso compartido de archivos.

1. Ejecute klist purge desde un símbolo del sistema como administrador para borrar los tickets de Kerberos aún almacenados en caché que usan RC4.
2. Vuelva a montar el recurso compartido de archivos de Azure.
3. Ejecute klist get cifs/<storage-account-name>.file.core.windows.net para comprobar que el nuevo ticket Kerberos usa la encriptación AES-256.

La salida debe mostrarse AES-256-CTS-HMAC-SHA1-96 para el tipo de cifrado KerbTicket y el tipo de clave de sesión, de forma similar a la siguiente:

#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 la actualización en todo un dominio (en lugar de un cliente a la vez), vuelva a ejecutar la consulta LDAP del paso 1b . Las cuentas de almacenamiento que haya actualizado ya no deberían aparecer en los resultados. Una vez msDS-SupportedEncryptionTypes establecido en el objeto de AD, el filtro lo excluye.

Reversión de la actualización AES-256

Si encuentra problemas de autenticación después de actualizar a AES-256, puede revertir a RC4 mediante los pasos siguientes. Aunque todavía debe actualizar a AES-256 antes de que Windows Update cambie el tipo de cifrado predeterminado en AD DS, estos pasos le permiten revertir temporalmente a RC4 al solucionar problemas de AES-256.

1. Asegúrese de que las máquinas cliente no tienen el siguiente valor de clave del Registro. Compruebe la clave del Registro HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters\SupportedEncryptionTypes. No permite explícitamente el cifrado RC4. Para obtener más información, consulte El montaje en Azure Files falla al usar Entra Kerberos debido a tipos de cifrado Kerberos no admitidos.

2. Asegúrese de que la configuración de seguridad SMB de la cuenta de almacenamiento no deshabilite el cifrado de billetes Kerberos con RC4. Para más información, consulte configuración de seguridad de SMB de la cuenta de almacenamiento.

3. Obtenga el nombre distintivo del objeto de AD que representa la cuenta de almacenamiento. Use el siguiente comando de PowerShell.

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

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

$identity = $saAdObject.DistinguishedName

Si el objeto de AD es una cuenta de equipo, ejecute el siguiente comando para borrar la propiedad msDS-SupportedEncryptionTypes .

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

Si el objeto de AD es una cuenta de inicio de sesión de servicio, ejecute el siguiente comando en su lugar.

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

4. Ejecute klist purge desde un indicador de comandos con permisos de administrador en las máquinas cliente afectadas. Borre los tickets de Kerberos almacenados en caché que todavía utilizan AES-256. Después del siguiente montaje, klist debe mostrar una cuenta de almacenamiento con el tipo de cifrado KerbTicket de RC4-HMAC. Use el siguiente comando para comprobar el tipo de cifrado de ticket 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 también

• Vulnerabilidad de divulgación de información de Kerberos de Windows
• Cómo gestionar el uso de RC4 por el KDC de Kerberos para los cambios en la emisión de tickets de cuentas de servicio relacionados con CVE-2026-20833.
• Habilitar la autenticación AD DS para Azure Files