Compartilhar via

Compreenda o Kerberos no Azure NetApp Files

  • Artigo

Kerberos é um protocolo de autenticação que usa uma chave secreta para validar a identidade das entidades principais. As chaves secretas são geradas pegando a senha de um principal e convertendo-a em um formato de chave criptográfica com hash usando um método de criptografia acordado pelo cliente e pelo servidor (como AES). Consulte a seção de terminologia Kerberos para saber mais sobre os termos usados neste documento.

Os KDCs (Centros de Distribuição de Chaves), como o Windows Active Directory, mantêm um banco de dados de entidades de segurança Kerberos e suas senhas com hash. Em Kerberos, a chave secreta é a prova de uma identidade exclusiva. Portanto, o KDC pode ser confiável para autenticar qualquer entidade de segurança em qualquer outra entidade de segurança, como autenticar um SPN (Nome da Entidade de Serviço) do cliente NFS em um SPN de servidor NFS na montagem. Ele também pode ser confiável para autenticar uma entidade de usuário em um SPN de servidor NFS para acesso de usuário a um ponto de montagem NAS. Como medida de segurança adicional, o Kerberos não envia senhas de texto não criptografado para autenticação pela rede.

O Azure NetApp Files dá suporte ao uso de Kerberos para fornecer segurança em trânsito para os protocolos SMB e NFS.

Verificação da criptografia com suporte

O Azure NetApp Files dá suporte ao NFS Kerberos com tipos de criptografia específicos, dependendo do modo operacional e da versão que você usa.

Para garantir que um cliente use o tipo de criptografia apropriado, você pode limitar os tipos de criptografia válidos no principal de objetos localizado no KDC (por exemplo, a conta da máquina) ou no arquivo keytab criado manualmente pelo cliente, em vez de globalmente no arquivo /etc/krb5.conf, se possível, já que o gerenciamento de vários arquivos krb5.conf do cliente pode ser uma dor de cabeça de gerenciamento. O gerenciamento centralizado do Kerberos a partir do KDC é mais escalonável em ambientes corporativos grandes, é mais fácil de automatizar e força o cliente a usar tipos de criptografia mais fortes quando há suporte.

Observação

Recomenda-se definir a opção allow_weak_crypto como false no arquivo krb5.conf nos clientes. Essa configuração evita menos segurança enctypes para a comunicação Kerberos (como DES ou 3DES).

A tabela a seguir mostra os tipos de criptografia com suporte para Kerberos (SMB e NFS) para Azure NetApp Files.

Protocolo Verificação da criptografia com suporte
SMB
  • RC4-HMAC
  • AES-128
  • AES-256
NFS AES-256

Modos de segurança NFS Kerberos suportados

Além do conceito de tipos de criptografia, também há níveis de verificação de segurança e integridade no Kerberos. Dependendo do modo de segurança em uso, esses modos de segurança ajudam a evitar ataques man-in-the-middle, oferecendo criptografia de ponta a ponta para tráfego NFS.

No Azure NetApp Files, esses modos de segurança são especificados nas regras de política de exportação definidas para o volume do NFS e definidas durante a montagem inicial do NFS por meio da opção de montagem sec.

Por exemplo: # mount -o sec=krb5p

Observação

Para o SMB Kerberos, os modos de segurança para Kerberos são controlados por meio configurações de criptografia SMB no compartilhamento, proteção UNC e políticas de assinatura/vedação SMB nos controladores de domínio.

Os seguintes modos de segurança são compatíveis com o Azure NetApp Files para uso com o Kerberos NFS:

Modo de segurança Descrição
krb5 Somente criptografia de autenticação.

Usa cadeias de caracteres de nome e nomes principais de usuário do Kerberos V5 em vez de IDs de usuário (UIDs) e IDs de grupo (GIDs) locais do UNIX para autenticar usuários.
krb5i Criptografia de autenticação e verificação de integridade criptografada.

usa Kerberos V5 para autenticação de usuário e também executa a verificação de integridade de operações NFS usando somas de verificação seguras para evitar violação de dados e ataques man-in-the-middle.
krb5p Toda a conversa NFS criptografada.

Usa o Kerberos V5 para autenticação do usuário e verificação de integridade e também criptografa todo o tráfego NFS para evitar a detecção de pacotes. Essa opção é a configuração mais segura, mas também envolve a maior sobrecarga de desempenho.

Terminologia Kerberos

Esta seção define a terminologia principal usada ao descrever os processos Kerberos. Esta seção destina-se a ajudar a esclarecer termos que podem não ser familiares aos administradores de armazenamento.

Termo Definição
KDC (Centro de Distribuição de Chaves) O KDC é o servidor de autenticação que inclui o TGS (serviço de concessão de tíquetes) e o AS (serviço de autenticação). Os termos KDC, AS e TGS são usados de maneira intercambiável. Em ambientes Microsoft, um controlador de domínio do Active Directory é um KDC.
Realm (ou realm Kerberos) Um realm (ou realm Kerberos) pode usar qualquer string ASCII. O padrão é usar o nome de domínio em maiúsculas; por exemplo, contoso.com se torna o reino CONTOSO.COM. As regiões Kerberos geralmente são configuradas em arquivos krb5.conf em clientes e servidores.

Administrativamente, cada principal@REALM deve ser único. Para evitar um único ponto de falha, cada realm pode ter vários KDCs que compartilham o mesmo banco de dados (entidades principais e suas senhas) e têm as mesmas chaves mestras do KDC. O Microsoft Windows Active Directory faz isso nativamente por meio da replicação do Active Directory, que ocorre a cada 15 minutos por padrão.
Principal O termo principal refere-se a todas as entidades em um banco de dados Kerberos. Usuários, computadores e serviços são entidades de segurança atribuídas para autenticação Kerberos. Cada entidade deve ser exclusiva no banco de dados Kerberos e é definida por seu nome distinto. Uma entidade de segurança pode ser um nome UPN (nome UPN) ou um SPN (nome de entidade de serviço).

Um nome principal tem três partes:
  • Primária - A parte primária pode ser um usuário ou um serviço, como o serviço NFS. Também pode ser o "host" de serviço especial, o que significa que essa entidade de serviço está configurada para fornecer vários serviços de rede.
  • Instância - Esta parte é opcional no caso de um usuário. Um usuário pode ter mais de uma entidade de segurança, mas cada entidade de segurança deve ser exclusiva no KDC. Por exemplo, Fred pode ter uma entidade de segurança que é para uso diário (fred@contoso.com) e uma entidade de segurança que permite o uso privilegiado, como uma conta sysadmin (admin-fred@contoso.com). A instância é necessária para entidades de serviço e designa o FQDN (nome de domínio totalmente qualificado) do host que fornece o serviço.
  • Realm - Um realm Kerberos é o conjunto de entidades principais Kerberos registradas em um servidor Kerberos. Por convenção, o nome do realm geralmente é o mesmo que o nome DNS, mas é convertido em letras maiúsculas. Letras maiúsculas não são obrigatórias, mas a convenção fornece uma distinção fácil entre o nome DNS e o nome do realm.
Tíquetes Um tíquete é um conjunto temporário de credenciais que verifica a identidade de uma entidade de segurança para um serviço e contém a chave de sessão. Um tíquete pode ser um serviço, um tíquete de aplicativo ou um tíquete de concessão de tíquete (TGT). Os tíquetes são trocados entre cliente, servidor e KDC para autenticação Kerberos.
Chave secreta O Kerberos usa um sistema de chave simétrica no qual a chave secreta é usada para criptografia e descriptografia. A chave secreta é gerada a partir da senha Kerberos da entidade de segurança com uma função de hash unidirecional. O KDC armazena a senha de cada entidade de segurança e, portanto, pode gerar a chave secreta da entidade de segurança. Para usuários que solicitam um serviço Kerberos, a chave secreta normalmente é derivada de uma senha apresentada ao programa kinit. As entidades de serviço e daemon normalmente não usam uma senha; em vez disso, o resultado da função de hash unidirecional é armazenado em um KeyTab.
Keytab Um keytab contém uma lista de entidades principais e suas chaves secretas. As chaves secretas em um keytab geralmente são criadas usando uma senha aleatória e são usadas principalmente para entidades de serviço ou daemon.

Informações da porta de rede

A tabela a seguir aborda quais portas de rede são usadas para comunicações Kerberos. Se um firewall de rede estiver em vigor, essas portas deverão ser abertas para permitir a funcionalidade Kerberos adequada. Você pode encontrar mais informações sobre essas portas no Registro de nome de serviço e número de porta do protocolo de transporte da IANA.

Serviço Porta
Kerberos 88 (TCP/UDP)
kpasswd 464(TCP/UDP)
Protocolo LDAP (lightweight directory access protocol) (para mapeamentos de nomes) 389 (TCP/UDP)
Servidor de administração 749(TCP/UDP)
Catálogo global (pesquisas de usuário do Windows) 3268(TCP/UDP)

Valores de idade do cache no Azure NetApp Files

A tabela a seguir exibe a quantidade de tempo que uma entrada de cache reside em um volume do Azure NetApp Files.

Cache Idade do cache
Conexões de servidor ociosas 60 segundos
Tempos limite de consulta LDAP 10 segundos
Entrada de host DNS local para TTL do KDC 24 horas
Usar tíquete Kerberos Especificado pelo KDC* e/ou cliente

* O padrão é 10 horas para KDCs do Windows Active Directory
Credenciais de usuário 24 horas
Distorção de tempo Kerberos 5 minutos

Requisitos para o funcionamento adequado de ambientes Kerberos no Azure NetApp Files

A autenticação Kerberos é altamente dependente de serviços externos para funcionalidade adequada. No Microsoft Active Directory, a maioria desses serviços é combinada em um único servidor em muitos casos. Por exemplo, um controlador de domínio do Active Directory pode atender às seguintes dependências Kerberos:

  • Serviço e sincronização de tempo
  • DNS
  • Centro de Distribuição de Chaves Kerberos
  • Serviços de senha/logon único
  • Serviços de identidade (como LDAP)

Ao usar o Microsoft Active Directory nativo (o único tipo de KDC compatível com o Azure NetApp Files atualmente), a maioria das dependências externas do Kerberos no Azure NetApp Files é coberta, como DNS, KDC e serviços de senha. Em alguns casos, os serviços necessários podem ser hospedados fora do domínio do Active Directory (como DNS). Nesses casos, é importante garantir que os serviços necessários estejam configurados corretamente.

O Azure NetApp Files tem dependências específicas para o funcionamento adequado do Kerberos do NFS. Continue lendo para obter mais informações.

Serviço e sincronização de tempo

Os serviços de sincronização de horário são obrigatórios ao usar o Kerberos para autenticação, pois os mecanismos de tíquete Kerberos dependem de distorções de tempo entre o cliente e o servidor estarem dentro de um intervalo padrão de 5 minutos. Se as configurações de tempo no cliente ou servidor excederem esse intervalo de cinco minutos, a autenticação Kerberos falhará com um erro de distorção de tempo (KRB_AP_ERR_SKEW) e o acesso será negado ao compartilhamento NAS. Esse tempo limite é um recurso de segurança que ajuda a evitar "ataques de repetição", em que um invasor pode interceptar mensagens entre o KDC e o cliente e, em seguida, reproduzir essas mensagens posteriormente para representar um usuário autenticado. Os limites de distorção de tempo ajudam a minimizar o risco desses tipos de ataques.

Principais considerações para problemas de sincronização de horário:

Para obter mais informações, confira Tolerância máxima para a sincronização do relógio do computador

Sistema de nome de domínio (DNS)

Os sistemas de nomes de domínio (DNS) são obrigatórios para o Kerberos como um recurso de segurança. A resolução de nome de host é usada para formular as entidades de serviço Kerberos usadas para autenticação. Nesse processo, as pesquisas diretas de nomes de host (registros A/AAAA) são usadas para se conectar a compartilhamentos que aproveitam a autenticação Kerberos. Essa pesquisa direta é usada para formular o SPN (Nome da Entidade de Serviço) usado na solicitação de autenticação Kerberos. Se um SPN existente não puder ser encontrado no KDC, a autenticação Kerberos falhará.

Em ambientes SMB do Windows, um método de autenticação de backup pode ser tentado (como NTLM). No entanto, em muitos casos, o NTLM é desabilitado por motivos de segurança, o que causaria uma falha de acesso ao compartilhamento quando a autenticação Kerberos falhasse. O visualizador de eventos do Windows geralmente registra a causa raiz das falhas (como SPNs duplicados/ausentes, falhas de pesquisa de DNS, falhas de NTLM etc.).

Além da resolução de SPN, o DNS é muito utilizado para resolver nomes de host e endereços IP para serviços de domínio, como LDAP, Kerberos KDCs etc. por meio de registros SRV. Para obter informações mais detalhadas sobre o DNS no Azure NetApp Files (incluindo quais registros SRV são necessários), consulte Sobre o DNS no Azure NetApp Files.

Observação

Se um endereço IP for usado para acesso Kerberos, o comportamento dependerá do protocolo NAS (NFS ou SMB) em uso. Para obter mais informações, consulte Configurando Kerberos para endereços IP.

LDAP

O LDAP (Lightweight Directory Access Protocol) aproveita os bancos de dados de identidade de back-end para fornecer uma fonte de serviço de nome unificada para clientes e servidores NAS, de modo que todos os dispositivos participantes concordem com a autenticidade do usuário, associações de grupo e IDs numéricas, que são usadas para permissões de arquivo.

Para Kerberos, as entidades de usuário e serviço são armazenadas com as entradas nos bancos de dados LDAP como atributos nas contas principais. O Windows Active Directory oferece suporte a isso por padrão. Em alguns casos (como ao criar aliases ou entidades de serviço), usuários e computadores exigem a adição ou modificação de nomes de entidades de serviço. Você pode atender a esse requisito usando o MMC (Console de Gerenciamento Microsoft) de Usuários e Computadores do Active Directory ou com o PowerShell. Para obter mais informações sobre como gerenciar nomes de entidades de serviço, consulte Gerenciando nomes de entidades de serviço.

Além dos nomes da entidade de serviço e das IDs numéricas para autenticação Kerberos, o LDAP também pode ser usado para identidades de usuário e grupo UNIX, que são usadas para mapeamento de nome de identidades no Azure NetApp Files, bem como autenticação inicial para montagens Kerberos NFS por meio de um mapeamento de nome de usuário SPN –> UNIX. Para obter mais detalhes, consulte Como o NFS Kerberos funciona no Azure NetApp Files e a função do LDAP com Kerberos no Azure NetApp Files.

Como o Kerberos SMB funciona no Azure NetApp Files

O Kerberos SMB funciona separadamente dos serviços Kerberos do NFS, pois as contas de computador criadas para cada protocolo não podem compartilhar keytabs devido ao potencial de alterações no número de versão da chave (kvno) em uma keytab que afetam o outro serviço. Como resultado disso, bem como das diferenças naturais nos protocolos NAS, os fluxos de trabalho para serviços SMB para Kerberos e NFS para Kerberos diferem em funcionalidade em algumas áreas.

Configuração inicial de serviços SMB

Os serviços SMB no Azure NetApp Files são configurados inicialmente configurando uma conexão do Active Directory, que define várias partes críticas para interação com serviços de domínio, incluindo:

  • DNS primário (obrigatório)
  • DNS secundário
  • * Somente DNS do Active Directory
  • Nome do site do Active Directory (para descoberta de DC) (obrigatório)
  • Nome do prefixo do servidor SMB
  • Unidade organizacional (em que as contas de computador devem ser armazenadas no domínio do Azure AD)
  • Ativar/desativar criptografia AES
  • Ativar/desativar assinatura LDAP
  • Configuração LDAP
  • Criptografia SMB para DC
  • Usuários privilegiados
  • Credenciais de nome de usuário/senha do usuário com permissões de UO

Observação

Apenas uma conexão Active Directory é permitida em uma região. Depois que a conexão do Azure AD é criada, qualquer novo volume SMB do Azure NetApp Files usa a configuração de conexão do Azure AD.

Conta de máquina Kerberos SMB

Uma conta de computador no Active Directory contém informações relevantes para uso em solicitações de autenticação, incluindo o SPN (Nome da Entidade de Serviço). Quando você cria um volume SMB no Azure NetApp Files, a configuração de conexões do Active Directory é usada para interação na criação de uma conta de computador para fornecer acesso seguro a um compartilhamento SMB por meio da autenticação Kerberos (ou NTLM, se habilitada).

Novas contas de computador são criadas quando um volume SMB do Azure NetApp Files é provisionado em um recurso de back-end específico no serviço. Veja a seguir diferentes cenários em que uma conta de computador SMB pode ser criada ou reutilizada nas configurações de volume do Azure NetApp Files.

Cenário Resultado
Primeiro novo volume SMB Nova conta de máquina SMB/nome DNS
Volumes SMB subsequentes criados em curta sucessão a partir do primeiro volume SMB Conta de máquina SMB/nome DNS reutilizado (na maioria dos casos).
Volumes SMB subsequentes criados muito depois do primeiro volume SMB O serviço determina se uma nova conta de computador é necessária. É possível que várias contas de computador possam ser criadas, o que cria vários pontos de extremidade de endereço IP.
Primeiro volume de protocolo duplo Nova conta de máquina SMB/nome DNS
Volumes de protocolo duplo subsequentes criados em curta sucessão a partir do primeiro volume de protocolo duplo Conta de máquina SMB/nome DNS reutilizado (na maioria dos casos)
Volumes de protocolo duplo subsequentes criados muito depois do primeiro volume de protocolo duplo O serviço determina se uma nova conta de computador é necessária. É possível que várias contas de computador possam ser criadas, o que cria vários pontos de extremidade de endereço IP
Primeiro volume SMB criado após o volume de protocolo duplo Nova conta de máquina SMB/nome DNS
Primeiro volume de protocolo duplo criado após o volume SMB Nova conta de máquina SMB/nome DNS

A conta de computador SMB criada para o volume SMB (ou protocolo duplo) do Azure NetApp Files usa uma convenção de nomenclatura que adere ao máximo de 15 caracteres imposto pelo Active Directory. O nome usa a estrutura de [prefixo do servidor SMB especificado na configuração de conexão do Azure AD]-[identificador numérico exclusivo].

Por exemplo, se você configurou suas conexões do Azure AD para usar o prefixo de servidor SMB "AZURE", a conta de computador SMB criada pelo Azure NetApp Files será semelhante a "AZURE-7806". Esse mesmo nome é usado no caminho UNC para o compartilhamento SMB (por exemplo, \AZURE-7806) e é o nome que os serviços DNS dinâmicos usam para criar o registro A/AAAA.

Observação

Como um nome como "AZURE-7806" pode ser difícil de lembrar, é benéfico criar um registro CNAME como um alias DNS para volumes do Azure NetApp Files. Para obter mais informações, consulte Criando aliases de servidor SMB.

Diagrama de várias contas de computador/entradas DNS no Azure NetApp Files.

Em alguns casos, ao criar vários volumes SMB e/ou de protocolo duplo, a configuração pode acabar com várias contas de máquina SMB e nomes DNS diferentes.

Se um único namespace para acesso do usuário entre os volumes for desejado, isso poderá representar um desafio na configuração, pois um único alias CNAME só pode apontar para um único registro de host A/AAAA, enquanto o uso de vários aliases de registro A/AAAA idênticos pode resultar em imprevisibilidade de acesso a dados no acesso a volumes em diferentes contas de máquina SMB, pois não há garantia de que o ponto de extremidade selecionado pelo cliente na pesquisa de DNS contenha o volume esperado devido à natureza de rodízio da seleção de registro DNS nessas configurações.

Para resolver essa limitação, os volumes do Azure NetApp Files podem participar como destinos em uma configuração do DFS (Sistema de Arquivos Distribuído) da Microsoft, que pode fornecer uma maneira de associar vários volumes SMB a um único ponto de entrada de namespace.

Diagrama de um sistema de arquivos distribuído no Azure NetApp Files.

Fluxo de trabalho de criação de SPN Kerberos SMB

O diagrama a seguir ilustra como um SPN Kerberos SMB é criado quando um volume SMB ou de protocolo duplo do Azure NetApp Files é criado. Os SPNs SMB são associados a objetos de conta de computador SMB no domínio. O SPN pode ser exibido e gerenciado por meio das propriedades da conta do computador usando o editor de atributos no modo de exibição Avançado.

Captura de tela das propriedades do Azure-SMB.

Você também pode visualizar e gerenciar propriedades com o setspn comando.

Captura de tela do comando 'setspn'.

Esse processo segue as mesmas etapas de quando um cliente Windows regular ingressa em um domínio (DNS, LDAP, Kerberos, consultas RPC em pipes nomeados).

Diagrama da conta da máquina Kerberos.

Na maioria dos casos, conhecer etapas detalhadas em profundidade não é necessário para tarefas diárias de administração, mas é útil para solucionar falhas ao tentar criar um volume SMB no Azure NetApp Files.

Etapas detalhadas

Para obter etapas detalhadas sobre como uma conta de computador SMB é criada no Azure NetApp Files, expanda a lista.

  • A pesquisa de DNS é executada usando a configuração de DNS para o registro SRV de um KDC Kerberos. O Azure NetApp Files usa os seguintes registros SRV em suas solicitações.

    • _kerberos._tcp.dc._msdcs.CONTOSO.COM
    • _kerberos._tcp.CONTOSO.COM (se a consulta anterior não retornar resultados)

  • A pesquisa de DNS é executada usando os nomes de host retornados na consulta SRV para os registros A/AAAA dos KDCs.

    • Um ping LDAP (ligação LDAP e consulta RootDSE) é executado para procurar servidores NetLogon herdados disponíveis usando a consulta (&(DnsDomain=CONTOSO.COM)(NtVer=0x00000016)) com um filtro de atributo para NetLogon. As versões mais recentes do controlador de domínio do Windows (maiores que 2008) não têm o NtVer valor presente.

  • Uma consulta DNS é executada pelo Azure NetApp Files para localizar os servidores LDAP no domínio usando os seguintes registros SRV:

    • _ldap._tcp.CONTOSO.COM
    • _kerberos._tcp.CONTOSO.COM

    Observação

    Essas consultas ocorrem várias vezes na mesma chamada em diferentes partes do processo. Problemas de DNS podem criar lentidão nessas chamadas ou, com tempos limite, falhas completas. - Se as consultas não encontrarem uma entrada ou se as entradas encontradas não puderem ser contatadas, a criação do volume SMB falhará. - Se as consultas de DNS forem bem-sucedidas, as próximas etapas serão processadas.

  • O ICMP (ping) é enviado para verificar se os endereços IP retornados do DNS estão acessíveis.

  • Se o ping for bloqueado na rede por políticas de firewall, a solicitação ICMP falhará. Em vez disso, pings LDAP são usados.

  • Outro ping LDAP é executado para procurar servidores NetLogon herdados disponíveis usando a consulta (&(&(DnsDomain=CONTOSO.COM)(Host=KDChostname.contoso.com))(NtVer=0x00000006)) com o filtro de atributo NetLogon. As versões mais recentes do controlador de domínio do Windows (maiores que 2008) não têm o valor NtVer presente.

  • Uma autenticação AS-REQ é enviada do serviço Azure NetApp Files usando o nome de usuário configurado com a conexão do Active Directory.

  • O controlador de domínio responde com KRB5KDC_ERR_PREAUTH_REQUIRED, que está solicitando que o serviço envie a senha para o usuário com segurança.

  • Um segundo AS-REQ é enviado com os dados de pré-autenticação necessários para autenticar com o KDC para acesso para prosseguir com a criação da conta do computador. Se for bem-sucedido, um TGT (Ticket de Concessão de Tíquete) será enviado ao serviço.

  • Se for bem-sucedido, um TGS-REQ será enviado pelo serviço para solicitar o tíquete de serviço CIFS (cifs/kdc.contoso.com) do KDC usando o TGT recebido no AS-REP.

  • Uma nova ligação LDAP usando o tíquete de serviço CIFS é executada. As consultas são enviadas do Azure NetApp Files:

    • Pesquisa de base RootDSE para o DN ConfigurationNamingContext do domínio
    • Pesquisa OneLevel de CN=partitions no DN recuperado para o ConfigurationNamingContext usando o filtro (&(&(objectClass=crossRef)(nETBIOSName=*))(dnsRoot=CONTOSO.COM)) para o atributo NETBIOSname.
    • Uma pesquisa de base usando o filtro (|(objectClass=organizationalUnit)(objectClass=container)) é executada na UO especificada na configuração de conexões do Active Directory. Se não for especificado, o padrão será OU=Computers. Isso verifica se o contêiner existe.
    • Uma pesquisa de subárvore é realizada no DN base do domínio usando o filtro (sAMAccountName=ANF-XXXX$) para verificar se a conta já existe.
      • Se a conta criada já existir, ela será reutilizado.
    • Se a conta não existir, ela será criada, desde que o usuário tenha permissões para criar e modificar objetos no contêiner usando um addRequest comando LDAP. Os seguintes atributos LDAP são definidos na conta:
    Atributo Valor
    CN ANF-XXXX
    sAMAccountName ANF-XXXX$
    objectClass
    • Superior
    • Pessoa
    • OrganizationalPerson
    • Usuário
    • Computador
    servicePrincipalName
    • HOST/ANF-XXXX
    • HOST/anf-xxxx.contoso.com
    • CIFS/anf-xxxx.contoso.com
    userAccountControl 4096
    operatingSystem Lançamento da NetApp
    dnsHostName ANF-XXXX.CONTOSO.COM
    • Se o addRequest falhar, a criação do volume falhará. An addRequest pode falhar devido a permissões incorretas no objeto de contêiner.
    • Se o addRequest for bem-sucedido, uma pesquisa LDAP usando o filtro (sAMAccountName=ANF-XXXX$) será executada para recuperar o atributo objectSid.
    • Uma conversa de "protocolo de negociação" SMB2 é executada para recuperar o Kerberos mechTypes com suporte do KDC.
    • Uma "Configuração de sessão" SMB2 usando o SPN CIFS e o mais alto suportado mechType e uma "Conexão de árvore" para IPC$ é executada.
    • Um arquivo SMB2 lsarpc é criado no compartilhamento IPC$.
    • Uma ligação ao DCERPC é executada. O lsarpc arquivo é gravado e lido.
    • As seguintes solicitações de LSA são executadas:

  • Um TGS-REQ usando o TGT é executado para recuperar o tíquete do kadmin/changepw SPN associado à krbtgt conta.

  • Uma solicitação KPASSWD é feita do serviço para o KDC para alterar a senha da conta do computador.

  • Uma consulta LDAP é executada com o filtro (sAMAccountName=ANF-XXXX) para os atributos distinguishedName e isCriticalSystemObject.

  • Se a conta isCriticalSystemObject for falsa (o padrão), o DN recuperado será usado para formular um modifyRequest para o atributo msDs-SupportedEncryptionTypes. Esse valor é definido como 30, o que equivale a DES_CBC_MD5 (2) + RC4 (4) + AES 128 (8) + AES 256 (16).

  • Uma segunda troca de tíquetes "Negociar protocolo"/Kerberos/"Configuração de sessão"/"Conexão de árvore" para IPC$ é executada. A conta de computador do servidor SMB (ANF-XXXX$) serve como a entidade de segurança Kerberos.

  • As comunicaçõesNetLogon, NetrServer ReqChallenge/Authenticate2 são concluídas.

  • Um terceiro "Protocolo de negociação:/Troca de tíquetes Kerberos/"Configuração de sessão"/"Conexão de árvore" para IPC$ é executado; a conta de computador do servidor SMB (ANF-XXXX$) é usada como a entidade de segurança Kerberos.

  • As conexões e lsarpc o NetLogon são feitas como uma verificação final da conta.

Fluxo de trabalho de conexão de compartilhamento SMB (Kerberos)

Quando um volume do Azure NetApp Files é montado usando Kerberos, uma troca de tíquetes Kerberos é usada durante as várias solicitações de configuração de sessão para fornecer acesso seguro ao compartilhamento. Na maioria dos casos, conhecer as etapas detalhadas em profundidade não é necessário para as tarefas diárias de administração. Esse conhecimento é útil na solução de falhas ao tentar acessar um volume SMB no Azure NetApp Files.

Diagrama do fluxo de trabalho de conexão de compartilhamento SMB.

Para obter etapas detalhadas sobre como o compartilhamento SMB é acessado no Azure NetApp Files, expanda a lista.
  • O cliente tenta acessar um compartilhamento SMB usando o caminho UNC mostrado no Azure NetApp Files. Por padrão, o caminho UNC incluiria o nome do servidor SMB (como ANF-XXXX)
  • O DNS é consultado para mapear o nome do host para um endereço IP
  • Uma conversa inicial sobre o "Protocolo de Negociação" do SMB2 ocorre
    • Uma solicitação é enviada do cliente para descobrir quais dialetos SMB são suportados pelo servidor e inclui o que o cliente solicitante suporta
    • O servidor responde com o que suporta, incluindo:
      • Modo de segurança (assinatura ou não)
      • Versão do SMB
      • GUID do servidor
      • Recursos suportados (DFS, leasing, MTU grande, multicanal, identificadores persistentes, leasing de diretório, criptografia)
      • Tamanho máximo de transações
      • Tamanho máximo de leitura/gravação
      • Blob de segurança (Kerberos ou NTLM)
  • Uma segunda conversa SMB2 "Negociar Protocolo" ocorre como "pré-autorização"/login
    • A solicitação do cliente inclui:
      • Pré-autorização
      • Modos de segurança suportados (assinatura ou não)
      • Recursos suportados (DFS, leasing, MTU grande, multicanal, identificadores persistentes, leasing de diretório, criptografia)
      • GUID do Cliente
      • Dialetos SMB com suporte
    • Se o hash de pré-autorização for aceito, o servidor responderá com:
      • Modo de segurança (assinatura ou não)
      • Recursos suportados (DFS, leasing, MTU grande, multicanal, identificadores persistentes, leasing de diretório, criptografia)
      • Tamanho máximo de transações
      • Tamanho máximo de leitura/gravação
      • Blob de segurança (Kerberos ou NTLM)
      • Recursos de criptografia e integridade de pré-autorização SMB
  • Se a negociação do protocolo for bem-sucedida, uma solicitação de "Configuração de sessão" será feita.
    • A instalação usa o hash de pré-autorização da negociação de protocolo.
    • A instalação informa ao servidor SMB o que o cliente solicitante suporta, incluindo:
      • StructureSize
      • Sinalizador de associação de sessão
      • Modo de segurança (assinatura habilitada/necessária)
      • Funcionalidades
      • Tipos de criptografia Kerberos com suporte
  • Uma resposta "Configuração de sessão" é enviada.
    • Créditos SMB são concedidos.
    • O ID da sessão é estabelecido.
    • Os sinalizadores de sessão são definidos (convidado, nulo, criptografar).
    • O tipo de criptografia Kerberos é definido.
  • Uma solicitação de conexão de árvore é enviada pelo cliente para conexão com o compartilhamento SMB.
    • Os sinalizadores/recursos de compartilhamento são enviados do servidor, juntamente com as permissões de compartilhamento.
  • O ioctl comando FSCTL_QUERY_NETWORK_INTERFACE_INFO é enviado para obter o endereço IP do servidor SMB.
  • O servidor SMB no Azure NetApp Files relata as informações de rede, incluindo: * Endereço IP * Capacidade de interface (RSS ativado ou desativado) * Contagem de filas RSS * Velocidade do link
  • Uma solicitação de conexão de árvore é enviada pelo cliente para conexão com o compartilhamento administrativo IPC$.
    • O compartilhamento IPC$ é um recurso que compartilha os pipes nomeados que são essenciais para a comunicação entre programas. O compartilhamento IPC$ é usado durante a administração remota de um computador e ao exibir os recursos compartilhados de um computador. Você não pode alterar as configurações de compartilhamento, as propriedades de compartilhamento ou as ACLs do compartilhamento IPC$. Você também não pode renomear ou excluir o compartilhamento IPC$.
  • Uma ligação DCERPC é feita ao srvsvc arquivo para estabelecer uma conexão segura.
    • O arquivo é gravado com as informações recuperadas anteriormente.
  • Um Kerberos TGS-REQ é emitido pelo cliente Windows para o KDC para obter um ST (tíquete de serviço) para o serviço SMB.
  • Um NetShareGetInfo comando é executado pelo cliente SMB para o servidor e uma resposta é enviada.
  • O tíquete de serviço SMB é recuperado do KDC.
  • O Azure NetApp Files tenta mapear o usuário do Windows que solicita acesso ao compartilhamento para um usuário UNIX válido.
    • Uma solicitação TGS Kerberos é feita usando as credenciais Kerberos do servidor SMB armazenadas com o keytab do servidor SMB desde a criação inicial do servidor SMB para usar em uma ligação de servidor LDAP.
    • O LDAP é procurado por um usuário UNIX mapeado para o usuário SMB que solicita acesso de compartilhamento. Se não houver nenhum usuário UNIX no LDAP, o usuário pcuser UNIX padrão será usado pelo Azure NetApp Files para mapeamento de nome (arquivos/pastas gravados em volumes de protocolo duplo usam o usuário UNIX mapeado como o proprietário do UNIX).
  • Outra conexão de protocolo/sessão/árvore de negociação é executada, desta vez usando o SPN Kerberos do servidor SMB para o compartilhamento IPC$ do DC do Active Directory.
    • Um pipe nomeado é estabelecido para o compartilhamento por meio do srvsvc.
    • Uma sessão NETLOGON é estabelecida para o compartilhamento e o usuário do Windows é autenticado.
  • Se as permissões permitirem para o usuário, o compartilhamento listará os arquivos e pastas contidos no volume.

Observação

O Azure NetApp Files adiciona entradas ao cache de contexto Kerberos para o cliente. Essas entradas residem no cache durante a vida útil do tíquete Kerberos (definido pelo KDC e controlado pela política Kerberos.

Criando aliases de servidor SMB

Quando o Azure NetApp Files cria um servidor SMB usando uma convenção de nomenclatura de [prefixo do servidor SMB especificado na configuração de conexão do Azure AD]-[identificador numérico exclusivo]. (Para obter detalhes sobre o identificador numérico exclusivo, consulte Conta de máquina Kerberos SMB). Essa formatação significa que os nomes de servidor SMB não são construídos de maneira amigável. Por exemplo, um nome de "SMB-7806" é mais difícil de lembrar do que algo semelhante a "AZURE-FILESHARE".

Devido a esse comportamento, os administradores podem querer criar nomes de alias amigáveis para volumes do Azure NetApp Files. Para fazer isso, é necessário apontar um nome canônico DNS (CNAME) para o registro DNS A/AAAA existente no servidor.

Quando um CNAME é criado e usado em solicitações de caminho UNC (por exemplo, \\AZURE-FILESHARE em vez de \\SMB-7806), o DNS redireciona a solicitação CNAME (AZURE-FILESHARE.contoso.com) para o registro A/AAAA apropriado (SMB-7806.contoso.com), que é usado na recuperação de SPN Kerberos (cifs/SMB-7806). Isso permite que o Kerberos acesse o compartilhamento SMB usando o nome com alias.

Se um registro DNS A/AAAA for criado (por exemplo, AZURE-FILESHARE.contoso.com) e tentar ser usado como um alias, as solicitações Kerberos falharão. A falha é o resultado do SPN construído usado para autenticar o compartilhamento (cifs/AZURE-FILESHARE) não corresponder ao que o SPN Kerberos é para o servidor SMB (cifs/SMB-7806). A falha poderá ser atenuada se outro SPN for criado e acrescentado à conta de computador do servidor SMB (como cifs/AZURE-FILESHARE).

Recursos de servidor SMB com suporte no Azure NetApp Files

Quando a solicitação de "protocolo de negociação" SMB é feita, o servidor SMB do Azure NetApp Files é consultado para dar suporte a recursos específicos. A tabela a seguir mostra os recursos consultados e a resposta retornada de um volume SMB do Azure NetApp Files quando uma conexão de Configuração/Árvore de Sessão é executada.

Capacidade SMB Com suporte do Azure NetApp Files?
Destino DFS Sim
Leasing Sim
MTU grande Sim
SMB Multichannel Sim
Identificadores persistentes SMB Sim
Concessão de Diretório do SMB Não
Criptografia SMB Sim (se ativado)

Recursos e propriedades de compartilhamento SMB com suporte no Azure NetApp Files

Durante o acesso ao compartilhamento SMB, uma solicitação de "conexão de árvore" é executada e os recursos e propriedades de compartilhamento SMB com suporte são consultados pelo cliente para o servidor do Azure NetApp Files. A tabela a seguir mostra os recursos de compartilhamento consultados e a resposta retornada de um volume SMB do Azure NetApp Files, conforme visto em uma captura de pacote.

Capacidade de compartilhamento SMB Com suporte do Azure NetApp Files?
Disponível continuamente Sim, para cargas de trabalho específicas* (se ativadas)
Expansão Não
Cluster Não
Assimétrica Não
Redirecionar para o proprietário Não

* Confira como Habilitar a Disponibilidade Contínua em volumes SMB existentes.

A tabela a seguir exibe as propriedades de compartilhamento consultadas e a resposta retornada de um volume SMB do Azure NetApp Files.

Capacidade de compartilhamento SMB Com suporte do Azure NetApp Files?
Destino DFS Sim
Raiz DFS Não
Restringir aberturas exclusivas Não
Exclusão compartilhada forçada Não
Permitir cache de namespace Não
Enumeração baseada em acesso Sim (se ativado)
Forçar o oplock de nível II Não
Habilitar o hash V1 Não
Habilitar o hash v2 Não
Criptografia necessária Sim (se ativado)
Comunicação remota de identidade Não
E/S compactada Não
Transporte isolado Não

Como o NFS Kerberos funciona no Azure NetApp Files

O NFS Kerberos funciona separadamente dos serviços SMB, pois as contas de máquina criadas para cada protocolo não podem compartilhar keytabs devido ao potencial de alterações no número de versão da chave (kvno) em uma keytab que afetam o outro serviço. Como resultado, os fluxos de trabalho para serviços SMB para Kerberos e NFS para Kerberos diferem em funcionalidade em algumas áreas.

Configuração inicial do realm Kerberos

O realm Kerberos do NFS é configurado quando as informações do realm Kerberos são preenchidas no portal do Azure NetApp Files na página de conexões do Active Directory.

Captura de tela da configuração do realm Kerberos.

O nome do servidor do Azure AD e o IP do KDC são usados para se conectar aos serviços do Azure AD KDC na criação inicial da conta do computador. O serviço Azure NetApp Files aproveita as informações de domínio existentes para preencher o restante da configuração do realm. Por exemplo:

Kerberos Realm: CONTOSO.COM
KDC Vendor: Microsoft
KDC IP Address: x.x.x.x 
KDC Port: 88
Clock Skew: 5
Active Directory Server Name: dc1.contoso.com
Active Directory Server IP Address: x.x.x.x
Comment: -
Admin Server IP Address: x.x.x.x
Admin Server Port: 749
Password Server IP Address: x.x.x.x
Password Server Port: 464
Permitted Encryption Types: aes-256
-    Configured by Azure NetApp Files administrator in the portal
-    Automatically configured by the service using Active Directory connection information/system defaults

Quando o realm Kerberos do NFS é configurado, uma entrada de hosts locais é adicionada ao serviço com o KDC especificado na configuração. Quando a região é modificada, a entrada de hosts locais também é modificada no serviço.

Diagrama da configuração do realm Kerberos.

Essa entrada de host local atua como um "último recurso" se ocorrer uma interrupção do KDC no KDC especificado na configuração do realm e falha ao consultar KDCs redundantes via DNS.

Observação

Se o KDC no realm Kerberos precisar ser desativado para manutenção (como para atualizações ou desativação de um servidor), é recomendável configurar o realm para usar um KDC que não esteja passando por manutenção para evitar interrupções.

Criação inicial da conta de computador/SPN

Quando o Kerberos é habilitado em um volume do Azure NetApp Files, uma conta/entidade de computador chamada NFS-{SMB-server-name} é criada no domínio na UO especificada em conexões do Active Directory (Unidade Organizacional). Os nomes de conta de máquina são truncados após 15 caracteres.

Observação

Ao adicionar clientes Linux com nomes de host maiores que 15 caracteres a um domínio do Active Directory, seus SPNs de conta de computador Kerberos são truncados. Por exemplo, um cliente Linux com um nome de tem um nome de MORE-THAN-FIFTEEN conta de máquina de MORE-THAN-FIFT$, que se torna um SPN de MORE-THAN-FIFT$@CONTOSO.COM. Quando o DNS pesquisa um nome de host de cliente, ele encontra o nome mais longo e tenta usar esse nome em uma solicitação SPN ( MORE-THAN-FIFTEEN@CONTOSO.COM). Como esse SPN não existe, o cliente tenta usar o próximo SPN na guia de teclas da solicitação (geralmente host/nome do host). Somente SPNs de nome de conta de computador funcionam nativamente com o Kerberos NFS do Azure NetApp Files. Como resultado, verifique se os nomes de host do cliente Linux usados para NFS Kerberos com Azure NetApp Files não excedem 15 caracteres. Como alternativa, se você quiser usar o SPN do host/nome do host, configure um usuário UNIX no LDAP com o nome de usuário "host". Essa configuração fornece um mapeamento de nome krb-unix para o SPN.

No Azure NetApp Files, os blocos de chave Kerberos (ou entradas keytab) são adicionados ao serviço com o SPN do serviço NFS (nfs/nfs-server-name.contoso.com@CONTOSO.COM). Várias entradas são criadas: uma para cada tipo de criptografia com suporte. No Azure NetApp Files, somente o tipo de criptografia AES-256 tem suporte para NFS Kerberos.

Na maioria dos casos, conhecer essas etapas em profundidade não será necessário para tarefas de administração diárias, mas é útil para solucionar falhas ao tentar criar um volume Kerberos NFS no Azure NetApp Files.

Fluxo de trabalho de criação de SPN Kerberos NFS

O diagrama a seguir mostra como um SPN NFS é criado quando um NFS do Azure NetApp Files ou um volume de protocolo duplo é criado com o Kerberos habilitado. Na maioria dos casos, conhecer etapas detalhadas em profundidade não será necessário para tarefas de administração diárias, mas é útil para solucionar falhas ao tentar criar um volume SMB no Azure NetApp Files.

Diagrama do fluxo de trabalho de criação de SPN Kerberos NFS.

Para obter etapas detalhadas sobre como um SPN Kerberos NFS é criado com o Azure NetApp Files, expanda a lista.
  • Credenciais de administrador passadas para o KDC especificadas na configuração do realm usando o nome de usuário fornecido para uso na conexão do Active Directory – o usuário deve ter permissão para exibir/criar objetos na UO especificada.
  • Os servidores DNS especificados na configuração de conexão do Active Directory do Azure NetApp Files são consultados pelo Azure NetApp Files para obter os registros de serviço Kerberos (SRV) nos seguintes formatos:
    • Consulta de URI para _kerberos.CONTOSO.COM
    • Consulta SRV para _kerberos-master._udp. CONTOSO.COM
    • Consulta SRV para _kerberos-master._tcp. CONTOSO.COM

Observação

Essas consultas ocorrem várias vezes na mesma chamada em diferentes partes do processo. Problemas de DNS podem criar lentidão nessas chamadas ou falhas completas. Esses registros não parecem existir por padrão em implantações do Active Directory e devem ser criados manualmente.

  • Se as consultas não conseguirem localizar uma entrada ou se as entradas encontradas não puderem ser contatadas ou usadas como o KDC mestre, uma consulta de registro A usando o nome do realm encontrado na configuração do realm Kerberos do NFS será usada como último recurso para se conectar ao KDC pela porta 88.
  • Durante a configuração do NFS Kerberos, uma entrada de host estático para o KDC especificado é adicionada ao arquivo de hosts local como um backup se as pesquisas de DNS falharem.
  • Se houver uma entrada DNS armazenada em cache para o realm, ela será usada. Caso contrário, a entrada do arquivo local será usada. As entradas DNS armazenadas em cache são ativadas desde que o Time to Live (TTL) esteja configurado para o registro DNS. A entrada de arquivo local é configurada com um TTL de 86.400 segundos (24 horas). A configuração ns-switch para pesquisas de host no Azure NetApp Files usa arquivos primeiro e, em seguida, DNS. Quando a entrada local é encontrada, nenhuma outra consulta é executada.
  • A conta de máquina SMB criada quando a conexão do Active Directory é criada é usada como credenciais para uma associação LDAP do Active Directory usando SASL/GSS pela porta 389 para pesquisar quaisquer entradas existentes do SPN desejado ou nome da conta da máquina. Se o SPN ou o nome da conta do computador já existir, um erro será enviado. Se o SPN não existir na consulta LDAP, a criação da conta do computador será executada na UO designada com entradas para os seguintes atributos definidos pelo Azure NetApp Files:
    • cn (NFS-MACHINE)
    • sAMAccountName (NFS-MACHINE$)
    • objectClass (top, person, organizationalPerson, user, computer)
    • servicePrincipalName (host/NFS-MACHINE, host/NFS-MACHINE.CONTOSO.COM, nfs/NFS-MACHINE, nfs/NFS-MACHINE.CONTOSO.COM)
    • userAccountControl (4096)
    • msDs-SupportedEncryptionTypes (AES-256_CTS_HMAC_SHA1_96)
    • dnsHostName (NFS-MACHINE.CONTOSO.COM)
  • A senha da conta da máquina Kerberos NFS é definida para a conta NFS-MACHINE na porta 464.
  • Os blocos de teclas Kerberos (keytabs) para o SPN NFS são salvos no serviço Azure NetApp Files.
  • Uma regra de mapeamento de nome estático é criada no serviço Azure NetApp Files para garantir que o usuário raiz de cada cliente Kerberos NFS seja mapeado para raiz quando o Kerberos for usado.
  • Um arquivo krb5.conf é adicionado aos sistemas internos do serviço com as informações da região NFS.

Montagens NFS Kerberos

Quando um volume do Azure NetApp Files é montado usando tipos de segurança Kerberos por NFS, o fluxo de trabalho a seguir é executado. Para obter um relato mais detalhado do Kerberos, consulte Sinopse do Serviço de Autenticação de Rede Kerberos (V5).

Diagrama do fluxo de trabalho de montagem do NFS Kerberos.

Para obter etapas detalhadas sobre como um volume Kerberos NFS é montado com o Azure NetApp Files, expanda a lista.
  • O cliente tenta uma montagem em um caminho de exportação NFS no Azure NetApp Files e especifica o -otipo de segurança krb5 (ou krb5i ou krb5p ).
  • O DNS é usado para formular uma solicitação de uma entidade de serviço NFS para o Azure NetApp Files por meio de registro A/AAAA ou PTR (dependendo de como o comando mount foi emitido).
  • O cliente recupera um TGT do KDC por meio de uma chamada AS-REQ usando o nome da entidade de segurança CLIENT encontrado na guia de teclas do cliente.
  • O caminho de exportação é verificado para garantir que ele exista no sistema de arquivos.
  • A regra de política de exportação é verificada para garantir que o acesso Kerberos seja permitido ao caminho de exportação.<
  • O tíquete de serviço NFS é solicitado do KDC pelo cliente por meio de uma chamada AP-REQ. O Azure NetApp Files verifica se há uma entrada válida no keytab com um tipo de criptografia válido usando o TGT do cliente adquirido do KDC.
  • Se o TGT for válido, um tíquete de serviço será emitido.
  • O SPN do cliente (por exemplo, CLIENT$@CONTOSO.COM) é mapeado para o usuário raiz por meio da regra de mapeamento de nome no Azure NetApp Files.
  • O usuário raiz é consultado nos bancos de dados de serviços de nome (arquivos e LDAP) para associações de existência/grupo.
  • Uma ligação LDAP usando a conta de computador do servidor SMB é executada para permitir uma pesquisa LDAP para o usuário raiz.
  • Como a raiz sempre existe no Azure NetApp Files, isso não deve causar problemas, mas as consultas LDAP para raiz podem falhar. Essas falhas podem ser ignoradas.
  • O tíquete de serviço NFS é retornado ao cliente e a montagem é bem-sucedida. O usuário raiz tem acesso raiz à montagem Kerberos por meio da entidade de conta de computador do cliente (visível com o klist -e comando do cliente).
  • O Azure NetApp Files adiciona entradas ao cache de contexto Kerberos para o cliente. Essas entradas residirão no cache durante a vida útil do tíquete Kerberos definido pelo KDC e controlado pela Política Kerberos.
  • O NFSv4.1 periodicamente (a cada 20 segundos) envia atualizações de atualização de tíquete Kerberos como "keepalives".

Acesso de montagem NFS Kerberos com entidades de usuário

Quando uma montagem Kerberos NFS do Azure NetApp Files é acessada por um usuário (diferente do usuário raiz, que usa o SPN da conta do computador), o fluxo de trabalho a seguir é executado.

Diagrama do acesso de montagem NFS Kerberos com entidades de usuário.

Para obter etapas detalhadas sobre como um volume Kerberos NFS é acessado com um usuário não raiz com o Azure NetApp Files, expanda a lista.
  • O usuário faz logon no KDC com uma troca de nome de usuário/senha ou por meio de um arquivo keytab para obter um TGT por meio de uma chamada AS-REQ a ser usada para coletar um tíquete de serviço do volume do Azure NetApp Files.
  • A regra de política de exportação é verificada para garantir que o acesso Kerberos seja permitido ao caminho de exportação para a máquina cliente
  • O Azure NetApp Files verifica se há um tíquete de serviço NFS armazenado em cache. Se não houver nenhum, o tíquete de serviço NFS será solicitado por meio de uma chamada AP-REQ e o serviço verificará a guia de teclas em busca de uma entrada válida com um tipo de criptografia válido usando o TGT do cliente adquirido do KDC
  • Se o TGT for válido, um bilhete de serviço é emitido
  • O nome UPN (nome UPN) do usuário é mapeado por meio do mapeamento implícito. Por exemplo, se o UPN for user1@CONTOSO.COM, o serviço consultará um usuário UNIX chamado user1. Como esse usuário UNIX não existe no banco de dados de arquivos local no Azure NetApp Files, o LDAP é usado.
  • Uma ligação LDAP usando a conta de máquina do servidor SMB é tentada para permitir uma pesquisa LDAP para o usuário mapeado. Uma consulta de SRV DNS é feita para registros DNS Kerberos (_kerberos e _kerberos-master). Se nenhum registro válido puder ser usado, a configuração retornará à configuração de domínio. Essas consultas KDC DNS SRV não têm escopo no site.
  • Os registros LDAP SRV são consultados em busca de servidores LDAP válidos. Eles têm escopo de site.
  • Se o usuário não existir no LDAP ou o LDAP não puder ser consultado (o servidor está inativo, a pesquisa de DNS falha, a ligação falha, a pesquisa LDAP atinge o tempo limite, o usuário não existe), o mapeamento falha e o acesso é negado.
  • Se o usuário existir, as associações de grupo serão coletadas.
  • O mapeamento é bem-sucedido e um tíquete de serviço NFS é emitido para o cliente (visto em klist -e comandos). O acesso é permitido com base nas permissões de arquivo no caminho de exportação.

Função do LDAP com Kerberos no Azure NetApp Files

O Azure NetApp Files depende do LDAP para NFS Kerberos. O Kerberos do NFS no Azure NetApp Files requer mapeamentos de nome do Kerberos para UNIX para SPNs de usuário de entrada. Como o Azure NetApp Files não dá suporte à criação de usuários UNIX locais, o LDAP é necessário para executar pesquisas para usuários UNIX quando um mapeamento de nome é solicitado.

  • Quando uma conexão do Azure AD é criada, o nome de domínio do Active Directory é usado para especificar o processo de pesquisa de servidores LDAP.
  • Quando um servidor LDAP é necessário, _ldap.domain.com é usado para a pesquisa SRV para servidores LDAP.
  • Depois que uma lista de servidores é descoberta, o melhor servidor disponível (com base no tempo de resposta do ping) é usado como o servidor LDAP para conexão pela porta 389.
  • Uma ligação LDAP é tentada usando a conta de máquina SMB via GSS/Kerberos.
  • Se não houver nenhuma conexão armazenada em cache ou credenciais Kerberos, uma nova solicitação para um tíquete Kerberos será emitida. As conexões armazenadas em cache para servidores de nomes no Azure NetApp Files revivem por 60 segundos. Se ocioso por mais de 60 segundos, o cache de conexão será limpo.
  • O DNS é usado para encontrar os KDCs Kerberos apropriados por meio de registros SRV.
  • Se nenhum KDCs puder ser encontrado por meio de consulta DNS, o KDC especificado no arquivo krb5.conf para os serviços SMB será usado.
    • Se esse KDC estiver inacessível ou não puder processar a solicitação Kerberos, a associação LDAP falhará. A pesquisa de nome também falha. O acesso é negado à montagem, pois nenhuma autenticação válida ocorreu.
    • Se a ligação for bem-sucedida, uma consulta LDAP será executada para o usuário e suas credenciais. Se o tempo de pesquisa exceder 10 segundos, a pesquisa falhará.
  • Se a pesquisa encontrar o usuário, o mapeamento será bem-sucedido e o acesso será concedido via Kerberos (desde que o tíquete seja válido/não tenha expirado).

Endereços IP para acesso com Kerberos

Por padrão, a autenticação Kerberos aproveita a resolução de nome para endereço IP para formular o SPN (Nome da Entidade de Serviço) usado para recuperar o tíquete Kerberos. Por exemplo, quando um compartilhamento SMB é acessado com um caminho de UNC (Convenção de Nomenclatura Universal), como \SMBVOLUME.CONTOSO.COM, uma solicitação DNS é emitida para SMBVOLUME.CONTOSO.COM e o endereço IP do volume do Azure NetApp Files é recuperado. Se não houver nenhuma entrada DNS presente (ou a entrada atual for diferente da solicitada, como com aliases/CNAMEs), um SPN adequado não poderá ser recuperado e a solicitação Kerberos falhará. Como resultado, o acesso ao volume poderá ser desabilitado se o método de autenticação de fallback (como New Technology LAN Manager) estiver desabilitado.

As entradas DNS no Azure NetApp Files são criadas automaticamente usando o DNS dinâmico e são formuladas usando o nome do servidor SMB. Para quaisquer variações/aliases para o nome definido, um registro DNS CNAME manual deve ser criado e apontado para a entrada DNS dinâmica. Para obter mais informações, consulte Noções básicas sobre protocolos NAS no Azure NetApp Files.

O NFSv4.1 Kerberos opera de maneira semelhante para recuperação de SPN, em que as pesquisas de DNS são parte integrante do processo de autenticação e também podem ser usadas para a descoberta de realm do Kerberos.

Se um endereço IP for usado em uma solicitação de acesso para um volume do Azure NetApp Files, uma solicitação Kerberos funcionará de maneira diferente, dependendo do protocolo em uso.

Comportamento do Kerberos SMB com endereços IP e nomes DNS

Ao usar o SMB, uma solicitação de um caminho UNC usando um endereço IP (por exemplo, \\x.x.x.x) por padrão tenta usar NTLM para autenticação. Em ambientes em que NTLM não é permitido por motivos de segurança, uma solicitação SMB usando um endereço IP não pode usar Kerberos ou NTLM para autenticação por padrão. Como resultado, o acesso ao volume do Azure NetApp Files é negado. Em versões posteriores do Windows (começando com o Windows 10 versão 1507 e Windows Server 2016), os clientes Kerberos podem ser configurados para dar suporte a nomes de host IPv4 e IPv6 em SPNs para comunicação SMB.

Comportamento do Kerberos NFSv4.1 com endereços IP e nomes DNS

Ao usar o NFSv4.1, uma solicitação de montagem para um endereço IP usando uma das opções sec=[krb5/krb5i/krb5p] usa pesquisas de DNS reverso por meio de um PTR (registro de ponteiro) para resolver um endereço IP para um nome de host, que é usado para formular o SPN para recuperação de tíquete. Esse nome de host é usado para formular o SPN para recuperação de tíquetes Kerberos. Se você usar NFSv4.1 com Kerberos, deverá ter um A/AAAA e PTR para o volume do Azure NetApp Files para cobrir o nome do host e o acesso de endereço IP às montagens. O Azure NetApp Files cria um registro DNS A/AAAA dinâmico. Se existir uma zona DNS reversa para essa sub-rede, um registro PTR também será criado automaticamente. Para desvios das convenções de nome de host padrão do Azure NetApp Files, use registros CNAME para aliases DNS.

Para obter mais informações, consulte Entender grandes volumes no Azure NetApp Files