Partilhar via

Compreender o Kerberos nos arquivos NetApp do Azure

  • Artigo

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

Os Centros de Distribuição de Chaves (KDCs), como o Windows Ative Directory, mantêm um banco de dados de entidades Kerberos e suas senhas com hash. Em Kerberos, a chave secreta é a prova de uma identidade única. Portanto, o KDC pode ser confiável para autenticar qualquer entidade em qualquer outra entidade, como autenticar um SPN (Nome da Entidade de Serviço) do cliente NFS em um SPN de servidor NFS na montagem. Também pode ser confiável para autenticar uma entidade de usuário em um SPN de servidor NFS para acesso do 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 através do fio.

Os Arquivos NetApp do Azure dão suporte ao uso de Kerberos para fornecer segurança em voo para os protocolos SMB e NFS.

Tipos de encriptação suportados

Os Arquivos NetApp do Azure dão suporte a Kerberos NFS com tipos de criptografia específicos, dependendo do modo de operação 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 na entidade de objeto localizada 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 do KDC é mais escalável em ambientes corporativos de grande porte, é mais fácil de automatizar e força o cliente a usar tipos de criptografia mais fortes quando eles são suportados.

Nota

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

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

Protocolo Tipos de encriptação suportados
SMB
  • RC4-HMAC
  • AES-128
  • AES-256
NFS AES-256

Modos de segurança Kerberos NFS suportados

Além do conceito de tipos de criptografia, há também 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 o tráfego NFS.

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

Por exemplo: # mount -o sec=krb5p

Nota

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

Os seguintes modos de segurança são suportados pelos Arquivos NetApp do Azure para uso com Kerberos NFS:

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

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

Usa o 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 adulteração de dados e ataques man-in-the-middle.
krb5p Conversa NFS inteira 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 deteção de pacotes. Essa configuração é a mais segura, mas também cria 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 ser desconhecidos para os administradores de armazenamento.

Termo Definição
Centro de distribuição de chaves (KDC) O KDC é o servidor de autenticação que inclui o serviço de concessão de tíquetes (TGS) e o serviço de autenticação (AS). Os termos KDC, AS e TGS são usados indistintamente. Em ambientes Microsoft, um controlador de domínio do Ative Directory é um KDC.
Realm (ou reino Kerberos) Um realm (ou Kerberos realm) pode usar qualquer cadeia de caracteres ASCII. O padrão é usar o nome de domínio em maiúsculas; Por exemplo, contoso.com se torna o reino CONTOSO.COM. Os realms Kerberos geralmente são configurados em arquivos krb5.conf em clientes e servidores.

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

Um nome principal tem três partes:
  • Primário - A parte principal 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 deve ser exclusiva no KDC. Por exemplo, Fred pode ter um principal que é para uso diário (fred@contoso.com) e um principal 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 nome de domínio totalmente qualificado (FQDN) do host que fornece o serviço.
  • Realm - Um realm Kerberos é o conjunto de entidades Kerberos registradas em um servidor Kerberos. Por convenção, o nome do território é 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 reino.
Pedidos 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 bilhete pode ser um serviço, um bilhete de aplicação ou um bilhete de concessão de bilhetes (TGT). Os tíquetes são trocados entre cliente, servidor e KDC para autenticação Kerberos.
Chaves secretas 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 hash unidirecional. O KDC armazena a senha de cada entidade de segurança e, assim, 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. Os principais de serviço e daemon normalmente não usam uma senha; em vez disso, o resultado da função hash unidirecional é armazenado em um keytab.
Tecla Tab Um keytab contém uma lista de entidades 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 sobre a 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 devem ser abertas para permitir a funcionalidade Kerberos adequada. Você pode encontrar mais informações sobre essas portas no Registro de Nome de Serviço IANA e Número de Porta do Protocolo de Transporte.

Serviço Porta
Kerberos 88 (TCP/UDP)
kpasswd 464 (TCP/UDP)
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ários do Windows) 3268 (TCP/UDP)

Valores de idade do cache nos Arquivos NetApp do Azure

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

Cache Idade do cache
Conexões ociosas do servidor de nomes 60 segundos
Tempo limite da consulta LDAP 10 segundos
Entrada de host DNS local para KDC TTL 24 horas
Idade do bilhete Kerberos Especificado pelo KDC* e/ou cliente

* O padrão é de 10 horas para KDCs do Windows Ative Directory
Credenciais do utilizador 24 horas
Distorção do tempo de Kerberos 5 minutos

Requisitos para o funcionamento adequado de ambientes Kerberos nos Arquivos NetApp do Azure

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

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

Ao usar o Microsoft Ative Directory nativo (o único tipo de KDC que os Arquivos NetApp do Azure suportam atualmente), a maioria das dependências externas para Kerberos nos Arquivos NetApp do Azure são cobertas, como DNS, KDC e serviços de senha. Em alguns casos, os serviços necessários podem ser hospedados fora do domínio do Ative Directory (como DNS). Nesses casos, é importante garantir que os serviços necessários estejam configurados corretamente.

Os Arquivos NetApp do Azure têm dependências específicas para o Kerberos NFS funcionando corretamente. Continue lendo para mais informações.

Serviços de sincronização de tempo

Os serviços de sincronização de tempo são obrigatórios ao usar Kerberos para autenticação, pois os mecanismos de tíquete Kerberos dependem de distorções de tempo entre cliente e 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 intercetar mensagens entre o KDC e o cliente e, em seguida, reproduzir essas mensagens posteriormente para se passar por 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 tempo:

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

Sistemas de Nomes de Domínio (DNS)

Os sistemas de nomes de domínio (DNS) são obrigatórios para 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, pesquisas diretas para 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 Windows SMB, 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 falhar. 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 SPN, o DNS é muito utilizado para resolver nomes de host e endereços IP para serviços de domínio, como LDAP, KDCs Kerberos, etc. por meio de registros SRV. Para obter informações mais detalhadas sobre o DNS nos Arquivos NetApp do Azure (incluindo quais registros SRV são necessários), consulte Sobre o DNS nos Arquivos NetApp do Azure.

Nota

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 Endereços IP para acesso com Kerberos.

LDAP

O protocolo 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éricos, que são usados 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 Ative Directory oferece suporte a isso por padrão. Em alguns casos (como ao criar aliases ou entidades de serviço), os usuários e computadores exigem a adição ou modificação de nomes de entidade de serviço. Você pode atender a esse requisito usando o MMC (Console de Gerenciamento Microsoft) de Usuários e Computadores do Ative Directory ou com o PowerShell. Para obter mais informações sobre como gerenciar nomes de entidade de serviço, consulte Gerenciando nomes de entidade de serviço.

Além de nomes de entidade de serviço e IDs numéricos 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 nomes de identidades em Arquivos NetApp do Azure, 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 Kerberos NFS funciona nos Arquivos NetApp do Azure e a função do LDAP com Kerberos nos Arquivos NetApp do Azure.

Como o Kerberos SMB funciona nos Arquivos NetApp do Azure

O Kerberos SMB funciona separadamente dos serviços Kerberos NFS, pois as contas de máquina criadas para cada protocolo não podem compartilhar keytabs devido ao potencial de alterações no Key Version Number (kvno) em um keytab que afetam o outro serviço. Como resultado disso, bem como as 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 dos serviços SMB

Os serviços SMB nos Arquivos NetApp do Azure são inicialmente configurados pela configuração de uma conexão do Ative Directory, que define várias partes críticas para a interação com os serviços de domínio, incluindo:

  • Servidor DNS primário (obrigatório)
  • DNS secundário
  • Nome DNS do Ative Directory*
  • Nome do site do Ative Directory (para descoberta de DC) (obrigatório)
  • Nome do prefixo do servidor SMB
  • Unidade organizacional (onde as contas de máquina devem ser armazenadas no domínio do Azure AD)
  • Ativar/desativar a encriptação AES
  • Ativar/desativar a assinatura LDAP
  • Configuração LDAP
  • Criptografia SMB para DC
  • Utilizadores com privilégios
  • Credenciais de nome de usuário/senha do usuário com permissões de UO

Nota

Apenas uma conexão do Azure Ative Directory (AD) é permitida por conta. 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 máquina no Ative 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 nos Arquivos NetApp do Azure, a configuração de conexões do Ative Directory é usada para interação na criação de uma conta de máquina para fornecer acesso seguro a um compartilhamento SMB por meio da autenticação Kerberos (ou NTLM, se habilitada).

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

Cenário Result
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 reutilizada/nome DNS (na maioria dos casos).
Volumes SMB subsequentes criados muito mais tarde do que o primeiro volume SMB O serviço determina se uma nova conta de máquina é necessária. É possível que várias contas de máquina 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 reutilizada/nome DNS (na maioria dos casos)
Volumes de protocolo duplo subsequentes criados muito mais tarde do que o primeiro volume de protocolo duplo O serviço determina se uma nova conta de máquina é necessária. É possível que várias contas de máquina 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 máquina SMB criada para o volume SMB (ou protocolo duplo) dos Arquivos NetApp do Azure usa uma convenção de nomenclatura que adere ao máximo de 15 caracteres imposto pelo Ative 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 máquina SMB criada pelos Arquivos NetApp do Azure se assemelha 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.

Nota

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 máquina/entradas DNS nos Arquivos NetApp do Azure.

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

Se um único namespace para acesso de usuário entre os volumes for desejado, isso pode representar um desafio na configuração, já que 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 do acesso a dados no acesso a volumes em diferentes contas de máquina SMB, como não há garantia de que o ponto de extremidade selecionado pelo cliente na pesquisa de DNS contenha o volume esperado devido à natureza round-robin da seleção de registros DNS nessas configurações.

Para resolver essa limitação, os volumes do Azure NetApp Files podem participar como destinos em uma configuração do Microsoft Distributed File System (DFS), 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 em Arquivos NetApp do Azure.

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

O diagrama a seguir ilustra como um SPN Kerberos SMB é criado quando um SMB de Arquivos NetApp do Azure ou um volume de protocolo duplo é criado. Os SPNs SMB estão associados a objetos de conta de máquina SMB no domínio. O SPN pode ser visualizado e gerenciado por meio das propriedades da conta da máquina usando o editor de atributos na visualização Avançado.

Captura de ecrã das propriedades do Azure-SMB.

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

Screenshot 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 sobre pipes nomeados).

Diagrama da conta da máquina Kerberos.

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

Passos detalhados

Para obter etapas detalhadas sobre como uma conta de máquina SMB é criada nos Arquivos NetApp do Azure, expanda a lista.

  • A pesquisa de DNS é realizada usando a configuração DNS para o registro SRV de um KDC Kerberos. Os Arquivos NetApp do Azure usam 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 nenhum resultado)

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

    • Um ping LDAP (LDAP bind e RootDSE query) é 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 pelos Arquivos NetApp do Azure para localizar os servidores LDAP no domínio usando os seguintes registros SRV:

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

    Nota

    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 limites, falhas completas. - Se as consultas não conseguirem encontrar uma entrada ou se as entradas encontradas não puderem ser contatadas, a criação de volume SMB falhará. - Se as consultas DNS forem bem-sucedidas, as próximas etapas serão processadas.

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

  • Se o ping estiver 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 Ative Directory.

  • O DC responde com KRB5KDC_ERR_PREAUTH_REQUIRED, que está pedindo ao serviço para enviar 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 e prosseguir com a criação da conta da máquina. Se for bem-sucedido, um Ticket Granting Ticket (TGT) é enviado para o serviço.

  • Se for bem-sucedido, um TGS-REQ é 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 associação LDAP usando o tíquete de serviço CIFS é executada. As consultas são enviadas dos Arquivos NetApp do Azure:

    • Pesquisa de base RootDSE para o DN ConfigurationNamingContext do domínio
    • Pesquisa OneLevel de CN=partições 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 Ative Directory. Se não for especificado, o padrão OU=Computers será usado. 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 existir, ela será reutilizada.
    • 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 Value
    CN ANF-XXXX
    sAMAccountName ANF-XXXX$
    objectClass
    • Parte Superior
    • Pessoa
    • Pessoa Organizacional
    • User
    • Computador
    servicePrincipalName
    • ANFITRIÃO/ANF-XXXX
    • ANFITRIÃO/anf-xxxx.contoso.com
    • CIFS/anf-xxxx.contoso.com
    userAccountControl 4096
    sistema operacional Versão da NetApp
    dnsHostName ANF-XXXX.CONTOSO.COM
    • Se o addRequest falhar, a criação do volume falhará. Um addRequest pode falhar devido a permissões incorretas no objeto de contêiner.
    • Se for addRequest bem-sucedido, uma pesquisa LDAP usando o filtro (sAMAccountName=ANF-XXXX$) será executada para recuperar o atributo objectSid.
    • Uma conversa SMB2 "Negociar protocolo" é executada para recuperar o Kerberos mechTypes suportado 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, em seguida, lido.
    • As seguintes solicitações LSA são então executadas:

  • Um tgs-req usando o TGT é realizado para recuperar o ticket para o kadmin/changepw SPN associado à krbtgt conta.

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

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

  • Se a conta for isCriticalSystemObject false (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).

  • Um segundo "Negotiate protocol"/Kerberos ticket exchange/"Session setup"/"Tree connect" para IPC$ é executado. A conta de máquina do servidor SMB (ANF-XXXXX$) serve como entidade Kerberos.

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

  • Um terceiro "Negotiate protocol:/Kerberos ticket exchange/"Session setup"/"Tree connect" para IPC$ é executado; a conta de máquina do servidor SMB (ANF-XXXXX$) é usada como entidade Kerberos.

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

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

Quando um volume de Arquivos NetApp do Azure é montado usando Kerberos, uma troca de tíquete 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 etapas detalhadas em profundidade não é necessário para as tarefas diárias de administração. Esse conhecimento é útil na solução de problemas de falhas ao tentar acessar um volume SMB nos Arquivos NetApp do Azure.

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

Para conhecer as etapas que detalham como o compartilhamento SMB é acessado nos Arquivos NetApp do Azure, expanda a lista.
  • O cliente tenta acessar um compartilhamento SMB usando o caminho UNC mostrado nos Arquivos NetApp do Azure. 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 SMB2 "Negotiate Protocol" 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
      • Capacidades suportadas (DFS, leasing, MTU grande, multicanal, identificadores persistentes, locação de diretórios, encriptação)
      • Tamanho máximo da transação
      • Tamanho máximo de leitura/escrita
      • Blob de segurança (Kerberos ou NTLM)
  • Uma segunda conversa SMB2 "Negotiate Protocol" ocorre como "pré-autorização"/login
    • O pedido do cliente inclui:
      • Hash de pré-autorização
      • Modos de segurança suportados (assinatura ou não)
      • Capacidades suportadas (DFS, leasing, MTU grande, multicanal, identificadores persistentes, locação de diretórios, encriptação)
      • GUID do cliente
      • Dialetos SMB suportados
    • Se o hash de pré-autorização for aceito, o servidor responderá com:
      • Modo de segurança (assinatura ou não)
      • Capacidades suportadas (DFS, leasing, MTU grande, multicanal, identificadores persistentes, locação de diretórios, encriptação)
      • Tamanho máximo da transação
      • Tamanho máximo de leitura/escrita
      • Blob de segurança (Kerberos ou NTLM)
      • Integridade de pré-autorização SMB e recursos de criptografia
  • Se a negociação do protocolo for bem-sucedida, uma solicitação de "Configuração da 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 vinculação de sessão
      • Modo de segurança (Assinatura ativada/necessária)
      • Capacidades
      • Tipos de criptografia Kerberos suportados
  • Uma resposta "Configuração da sessão" é enviada.
    • São concedidos créditos SMB.
    • O ID da sessão é estabelecido.
    • Os sinalizadores de sessão são definidos (guest, null, encrypt).
    • 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 nos Arquivos NetApp do Azure relata com as informações de rede, incluindo: * Endereço IP * Capacidade de interface (RSS ligado ou desligado) * 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. A partilha IPC$ é utilizada durante a administração remota de um computador e quando visualiza os recursos partilhados de um computador. Não é possível alterar as configurações de compartilhamento, propriedades de compartilhamento ou ACLs do compartilhamento IPC$. Também não é possível mudar o nome ou eliminar a partilha IPC$.
    • Um arquivo nomeado srvsvc é criado no compartilhamento como um identificador de serviço.
  • 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 tíquete de serviço (ST) 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.
  • Os Arquivos NetApp do Azure tentam 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 para uma ligação de servidor LDAP.
    • O LDAP é procurado por um usuário UNIX que é mapeado para o usuário SMB que solicita acesso de compartilhamento. Se nenhum usuário UNIX existir no LDAP, o usuário pcuser UNIX padrão será usado pelos Arquivos NetApp do Azure para mapeamento de nomes (arquivos/pastas escritos em volumes de protocolo duplo usam o usuário UNIX mapeado como proprietário do UNIX).
  • Outra conexão de protocolo/solicitação de sessão/árvore de negociação é executada, desta vez usando o SPN Kerberos do servidor SMB para o compartilhamento IPC$ do DC do Ative Directory.
    • Um tubo nomeado é estabelecido para o compartilhamento através 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.

Nota

Os Arquivos NetApp do Azure adicionam 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 os Arquivos NetApp do Azure criam 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 da máquina SMB Kerberos). Essa formatação significa que os nomes de servidores SMB não são construídos de forma 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 (SMB-7806.contoso.com) adequado, que é usado na recuperação do SPN Kerberos (cifs/SMB-7806). Isso permite que Kerberos acesse o compartilhamento SMB enquanto usa o nome com alias.

Se um registro DNS A/AAAA for criado (por exemplo, AZURE-FILESHARE.contoso.com) e tentado 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 pode ser atenuada se outro SPN for criado e anexado à conta da máquina do servidor SMB (como cifs/AZURE-FILESHARE).

Recursos de servidor SMB suportados nos Arquivos NetApp do Azure

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

Capacidade SMB Suportado pelos Ficheiros NetApp do Azure?
Destino DFS Sim
Locação Sim
MTU grande Sim
SMB multicanal Sim
Identificadores persistentes SMB Sim
Locação de diretórios Não
Encriptação SMB Sim (se ativado)

Recursos e propriedades de compartilhamento SMB suportados nos Arquivos NetApp do Azure

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

Capacidade de compartilhamento SMB Suportado pelos Ficheiros NetApp do Azure?
Disponível continuamente (CA) Sim, para cargas de trabalho específicas* (se habilitado)
Expansão Não
Cluster Não
Assimétrica Não
Redirecionar para o proprietário Não

* Consulte Habilitar disponibilidade contínua em volumes SMB existentes para cargas de trabalho suportadas.

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

Capacidade de compartilhamento SMB Suportado pelos Ficheiros NetApp do Azure?
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)
Bloqueio de nível de força II Não
Ativar hash V1 Não
Ativar hash v2 Não
Encriptação necessária Sim (se ativado)
Comunicação remota de identidade Não
E/S comprimida Não
Transporte isolado Não

Como o Kerberos NFS funciona nos Arquivos NetApp do Azure

O Kerberos NFS 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 Key Version Number (kvno) em um 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 NFS é configurado quando as informações do realm Kerberos são preenchidas no portal Azure NetApp Files na página conexões do Ative 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 KDC do Azure AD na criação inicial da conta da máquina. 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 NFS é configurado, uma entrada de hosts locais é adicionada no serviço com o KDC especificado na configuração. Quando o realm é modificado, 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 na consulta de KDCs redundantes via DNS.

Nota

Se o KDC no realm Kerberos precisar ser derrubado para manutenção (como para upgrades ou descomissionamento 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 de conta de máquina/SPN

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

Nota

Ao adicionar clientes Linux com nomes de host maiores que 15 caracteres a um domínio do Ative Directory, seus SPNs de conta de máquina Kerberos são truncados. Por exemplo, um cliente Linux com um nome de tem um nome de conta de MORE-THAN-FIFTEEN máquina de MORE-THAN-FIFT$, que se torna um SPN de MORE-THAN-FIFT$@CONTOSO.COM. Quando o DNS procura 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 no keytab na solicitação (geralmente host/hostname). Somente SPNs de nome de conta de máquina funcionam nativamente com Kerberos NFS de Arquivos NetApp do Azure. Como resultado, certifique-se de que os nomes de host do cliente Linux usados para NFS Kerberos com Arquivos NetApp do Azure não excedam 15 caracteres. Como alternativa, se você quiser usar o SPN de nome de host/host, configure um usuário UNIX no LDAP com o nome de usuário "host". Esta configuração fornece um mapeamento de nome krb-unix para o SPN.

Nos Arquivos NetApp do Azure, os keyblocks 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 suportado. Nos Arquivos NetApp do Azure, somente o tipo de criptografia AES-256 é suportado para Kerberos NFS.

Na maioria dos casos, conhecer essas etapas em profundidade não será necessário para tarefas de administração diárias, mas são úteis na solução de problemas de falhas ao tentar criar um volume Kerberos NFS nos Arquivos NetApp do Azure.

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

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

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

Para obter etapas detalhadas sobre como um SPN Kerberos NFS é criado com Arquivos NetApp do Azure, 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 Ative 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 Ative Directory dos Arquivos NetApp do Azure são consultados pelos Arquivos NetApp do Azure para os registros de serviço Kerberos (SRV) nos seguintes formatos:
    • Consulta URI para _kerberos.CONTOSO.COM
    • Consulta SRV para _kerberos-master._udp. CONTOSO.COM
    • Consulta SRV para _kerberos-master._tcp. CONTOSO.COM

Nota

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 Ative Directory e devem ser criados manualmente.

  • Se as consultas não conseguirem encontrar 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 território encontrado na configuração do realm Kerberos NFS será usada como último recurso para se conectar ao KDC pela porta 88.
  • Durante a configuração do Kerberos NFS, uma entrada de host estática para o KDC especificado é adicionada ao arquivo de hosts locais como um backup se as pesquisas de DNS falharem.
  • Se houver uma entrada DNS armazenada em cache para o realm, ela será usada. Se não, então a entrada de arquivo local é usada. As entradas DNS armazenadas em cache permanecem ativas enquanto o tempo de vida (TTL) estiver 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 nos Arquivos NetApp do Azure usa primeiro os arquivos e, em seguida, o DNS. Quando a entrada local é encontrada, não são realizadas mais consultas.
  • A conta de máquina SMB criada quando a conexão do Ative Directory é criada é usada como credenciais para uma associação LDAP do Ative Directory usando SASL/GSS pela porta 389 para procurar quaisquer entradas existentes do SPN desejado ou do nome da conta da máquina. Se o SPN ou o nome da conta da máquina já existir, um erro será enviado. Se o SPN não existir na consulta LDAP, a criação da conta da máquina será executada na UO designada com entradas para os seguintes atributos definidos pelos Arquivos NetApp do Azure:
    • cn (NFS-MÁQUINA)
    • 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 pela porta 464.
  • Os keyblocks 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 Arquivos NetApp do Azure para garantir que o usuário raiz de cada cliente Kerberos NFS seja mapeado para raiz quando Kerberos for usado.
  • Um arquivo krb5.conf é adicionado aos sistemas internos do serviço com as informações do domínio NFS.

Montagens Kerberos NFS

Quando um volume de Arquivos NetApp do Azure é montado usando os sabores de segurança Kerberos sobre NFS, o fluxo de trabalho a seguir é executado. Para obter uma descrição mais detalhada do Kerberos, consulte Sinopse do Serviço de Autenticação de Rede Kerberos (V5).

Diagrama do fluxo de trabalho de montagem do Kerberos NFS.

Para obter etapas detalhadas sobre como um volume Kerberos NFS é montado com os Arquivos NetApp do Azure, expanda a lista.
  • O cliente tenta montar um caminho de exportação NFS nos Arquivos NetApp do Azure e especifica o sabor de -osegurança krb5 (ou krb5i ou krb5p).
  • O DNS é usado para formular uma solicitação de uma entidade de serviço NFS para os Arquivos NetApp do Azure por meio de registro A/AAAA ou PTR (dependendo de como o comando mount foi emitido).
  • O cliente recupera um TGT do KDC através de uma chamada AS-REQ usando o nome principal do CLIENT encontrado na keytab do cliente.
  • O caminho de exportação é verificado para garantir que existe no sistema de arquivos.
  • A regra de política de exportação é verificada para garantir que o acesso Kerberos tenha permissão ao caminho de exportação.<
  • O ticket de serviço NFS é solicitado ao KDC pelo cliente através de uma chamada AP-REQ. Os Arquivos NetApp do Azure verificam o keytab 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, é emitido um bilhete de serviço.
  • O SPN do cliente (por exemplo, CLIENT$@CONTOSO.COM) é mapeado para o usuário raiz por meio da regra de mapeamento de nome nos Arquivos NetApp do Azure.
  • O usuário raiz é consultado nos bancos de dados de serviços de nomes (arquivos e LDAP) para associações de existência/grupo.
  • Uma associação LDAP usando a conta da máquina do servidor SMB é executada para permitir uma pesquisa LDAP para o usuário raiz.
  • Como a raiz sempre existe nos Arquivos NetApp do Azure, 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 root tem acesso root à montagem Kerberos por meio da entidade de conta da máquina do cliente (visível com o klist -e comando do cliente).
  • Os Arquivos NetApp do Azure adicionam entradas ao cache de contexto Kerberos para o cliente. Essas entradas residirão em 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 Kerberos NFS com entidades de usuário

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

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

Para obter etapas detalhadas sobre como um volume Kerberos NFS é acessado com um usuário não raiz com Arquivos NetApp do Azure, 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 Azure NetApp Files.
  • A regra de política de exportação é verificada para garantir que o acesso Kerberos tenha permissão ao caminho de exportação da máquina cliente
  • Os Arquivos NetApp do Azure verificam se há um tíquete de serviço NFS armazenado em cache. Se não existir, o tíquete de serviço NFS é solicitado por meio de uma chamada AP-REQ e o serviço verifica a tecla 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, é emitido um bilhete de serviço
  • O nome UPN (nome principal do usuário) do usuário é mapeado por meio de 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 locais nos Arquivos NetApp do Azure, o LDAP é usado.
  • Uma associação LDAP usando a conta da máquina do servidor SMB é tentada para permitir uma pesquisa LDAP para o usuário mapeado. Uma consulta DNS SRV é feita para registros DNS Kerberos (_kerberos e _kerberos-master). Se nenhum registro válido puder ser usado, a configuração retornará à configuração do realm. Essas consultas KDC DNS SRV não têm escopo de site.
  • Os registros SRV LDAP são consultados para servidores LDAP válidos. Eles têm escopo para o 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 expira, 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 nos Arquivos NetApp do Azure

Os Arquivos NetApp do Azure dependem do LDAP para Kerberos NFS. O Kerberos NFS nos Arquivos NetApp do Azure requer Kerberos para mapeamentos de nomes UNIX para SPNs de usuários de entrada. Como o Azure NetApp Files não oferece 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 Ative Directory é usado para especificar o processo para pesquisar 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 de ping) é usado como o servidor LDAP para conexão pela porta 389.
  • Uma associação LDAP é tentada usando a conta da máquina SMB via GSS/Kerberos.
  • Se não houver conexão 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 nos Arquivos NetApp do Azure permanecem ativas por 60 segundos. Se estiver inativo 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 KDC puder ser encontrado via 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, uma vez que não ocorreu nenhuma autenticação válida.
    • Se a associaçã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 de host 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 UNC (Convenção de Nomenclatura Universal), como \SMBVOLUME.CONTOSO.COM, uma solicitação DNS é emitida para o SMBVOLUME.CONTOSO.COM de Nome de Domínio Totalmente Qualificado e o endereço IP do volume Arquivos NetApp do Azure é recuperado. Se não houver nenhuma entrada DNS presente (ou se 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 pode ser desautorizado se o método de autenticação de fallback (como o New Technology LAN Manager) estiver desativado.

As entradas DNS nos Arquivos NetApp do Azure são criadas automaticamente usando DNS dinâmico e são formuladas usando o nome do servidor SMB. Para quaisquer variações/aliases para o nome definido, um registro CNAME DNS manual deve ser criado e apontado para a entrada DNS dinâmica. Para obter mais informações, consulte Compreender o DNS nos arquivos NetApp do Azure.

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

Se um endereço IP (em vez de um nome de host) for usado em uma solicitação de acesso a um volume de Arquivos NetApp do Azure, uma solicitação Kerberos funcionará de forma diferente, dependendo do protocolo em uso.

Comportamento Kerberos SMB com endereços IP e nomes DNS

Ao usar o SMB, uma solicitação para 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 onde o 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 de Arquivos NetApp do Azure é 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 oferecer suporte a nomes de host IPv4 e IPv6 em SPNs para comunicação SMB para contornar esse problema.

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

Ao usar NFSv4.1, uma solicitação de montagem para um endereço IP usando uma das opções usa pesquisas de DNS reverso via PTR para resolver um endereço IP para um nome de sec=[krb5/krb5i/krb5p] host. Esse nome de host é usado para formular o SPN para recuperação de tíquete Kerberos. Se você usar NFSv4.1 com Kerberos, deverá ter um A/AAAA e PTR para o volume Arquivos NetApp do Azure para cobrir o acesso de nome de host e endereço IP às montagens. Os Arquivos NetApp do Azure criam 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 padrão de nome de host dos Arquivos NetApp do Azure, use registros CNAME para aliases DNS.

Para obter mais informações, consulte Compreender o DNS nos arquivos NetApp do Azure