Protocolos de compartilhamento de arquivos, como SMB (CIFS), NFSv3 com grupos estendidos e NFSv4, que usam princípios de segurança, dependem de serviços de diretório externos para fornecer informações de identidade do usuário. O NetApp Volumes depende do Microsoft Active Directory para serviços de diretório. O Active Directory oferece serviços como servidores LDAP para pesquisar objetos, como usuários, grupos, contas de máquina, servidores DNS para resolver nomes de host e servidores Kerberos para autenticação.
Para mais informações, consulte Práticas recomendadas para executar o Active Directory no Google Cloud.
O Microsoft Active Directory gerenciado do Google Cloud não é compatível com os volumes do NetApp.
Casos de uso
O NetApp Volumes usa o Active Directory para os casos nas seções a seguir.
Serviço de domínio SMB
O Active Directory é o serviço de domínio central para SMB. O SMB é usado para autenticação e pesquisas de identidade para usuários e grupos. O NetApp Volumes se junta ao domínio como membro e não oferece suporte ao SMB no modo de grupo de trabalho.
Suporte a grupos estendidos do NFSv3
Para o NFSv3 com suporte a grupos estendidos, o Active Directory fornece o servidor LDAP necessário para pesquisar objetos, como usuários, grupos ou contas de máquina. Especificamente, um servidor LDAP compatível com RFC2307bis é necessário para pesquisas de ID de usuário e de grupo. O suporte a LDAP é ativado nos pools de armazenamento durante a criação do pool.
O suporte a grupos estendidos ignora todos os IDs de grupo enviados pelo cliente NFS em uma chamada NFS. Em vez disso, ele usa o ID do usuário da solicitação e pesquisa todos os IDs de grupo para o ID do usuário especificado no servidor LDAP para fazer verificações de permissão de arquivo.
Para mais informações, consulte Gerenciar atributos POSIX do LDAP RFC2307bis.
Mapeamento de principal de segurança do NFSv4.x para ID do usuário e ID do grupo
No NFSv4.x, o Active Directory é usado para mapear princípios de segurança para IDs de usuário e
de grupo. O NFSv4 usa um modelo de autenticação baseado em principal. Na autenticação baseada
em principal, os usuários são identificados por entidades de segurança que assumem a
forma user@dns_domain (consulte https://www.rfc-editor.org/rfc/rfc7530.html#section-19)
em vez de serem identificados por IDs de usuário e de grupo. Para mapear os principais elementos de segurança para
IDs de usuário e de grupo ao acessar o volume usando um protocolo NFSv4.x, os Volumes
NetApp exigem um servidor LDAP compatível com RFC2307bis. O único servidor LDAP compatível
é o Active Directory. O suporte a LDAP é ativado nos pools de armazenamento durante a criação.
Para usar os principais componentes de segurança, o cliente e o servidor NFS precisam se conectar à mesma origem LDAP, e o arquivo idmapd.conf precisa ser configurado no cliente. Para mais informações sobre como configurar o arquivo idmapd.conf, consulte Ubuntu Manpage: idmapd.conf - arquivo de configuração para libnfsidmap.
O nome de domínio do Active Directory é usado para dns_domain. O user é o nome dos usuários do Active Directory. Use esses valores ao definir seus atributos POSIX LDAP.
Para usar o NFSv4.1 sem configurar o mapeamento de ID e usar apenas IDs de usuário e de grupo semelhantes ao NFSv3, use IDs numéricos para ignorar os principais de segurança. Os volumes NetApp oferecem suporte a IDs numéricos, e os clientes NFS atuais usam IDs numéricos por padrão, se o mapeamento de ID não estiver configurado.
NFSv4.x com Kerberos
Se você usar o Kerberos, será obrigatório usar o Active Directory como o servidor LDAP para pesquisas de principal de segurança. Os principais do Kerberos são usados como identificadores de segurança. O Active Directory também é usado como a central de distribuição de chaves (KDC) do Kerberos. Para que isso funcione, anexe uma política do Active Directory que contenha as configurações do Kerberos ao pool e ative o suporte ao LDAP em um pool de armazenamento durante a criação do pool.
Para mais informações, consulte Criar um pool de armazenamento.
Acesso LDAP do Active Directory
Para casos de uso do NFS, o Active Directory é usado como um servidor LDAP. Os volumes do NetApp esperam dados de identidade usando um esquema RFC2307bis. O Active Directory já oferece esse esquema, mas você precisa preencher os atributos necessários para seus usuários e grupos.
Os volumes da NetApp usam as credenciais fornecidas pela política do Active Directory para vincular o LDAP usando a assinatura LDAP.
Se o usuário ou grupo não for encontrado, o acesso será negado.
Armazenamento em cache de atributos
O NetApp Volumes armazena em cache os resultados das consultas LDAP. A tabela a seguir descreve as configurações de time to live (TTL) para o cache LDAP. Se o cache tiver dados inválidos devido a configurações incorretas que você está tentando corrigir, aguarde até que o cache seja atualizado antes que as mudanças no Active Directory sejam detectadas. Caso contrário, o servidor NFS continua usando os dados antigos para verificar o acesso, o que provavelmente resulta em mensagens de permissão negada no cliente. Após o período de TTL, as entradas expiram para que as entradas desatualizadas não permaneçam. As solicitações de pesquisa que não são encontradas são retidas por um TTL de um minuto para evitar problemas de desempenho.
| Cache | Tempo limite padrão |
|---|---|
| Lista de participantes do grupo | TTL de 24 horas |
| Grupos Unix (GID) | TTL de 24 horas, TTL negativo de 1 minuto |
| Usuários Unix (UID) | TTL de 24 horas, TTL negativo de 1 minuto |
Topologias de controladores de domínio do Active Directory
Depois de se conectar aos controladores de domínio do Active Directory, você pode usar os seguintes protocolos de compartilhamento de arquivos:
- SMB
- NFSv3 com grupos estendidos
- NFSv4
As seções a seguir ilustram várias topologias possíveis. Os diagramas mostram apenas o controlador de domínio usado pelos volumes do NetApp. Outros controladores de domínio do mesmo domínio são mostrados apenas quando necessário.
A Microsoft recomenda implantar pelo menos dois controladores de domínio (DCs) para redundância e disponibilidade.
Controlador de domínio do Active Directory na mesma região dos volumes do NetApp Volumes
O diagrama a seguir mostra o modo de implantação mais simples, um controlador de domínio na mesma região dos volumes do NetApp Volumes.
Controladores de domínio do Active Directory em várias regiões usando sites do AD
Se você estiver usando volumes do NetApp Volumes em várias regiões, recomendamos colocar pelo menos um controlador de domínio em cada região. Embora o serviço tente escolher automaticamente o melhor DC a ser usado, é recomendável gerenciar a seleção de DC usando sites de AD.
Controlador de domínio do Active Directory em uma rede local
O uso de um controlador de domínio local pela VPN é aceito, mas pode afetar negativamente a autenticação do usuário final e o desempenho do acesso a arquivos. Não adicione outros saltos de peering VPC no caminho da rede.
Considerações para DCs no local
As conexões com DCs locais usam TCP e IP. Essas conexões geralmente falham devido às seguintes limitações:
Peering de VPC: os volumes da NetApp só podem alcançar DCs que estão no VPC do pool de armazenamento ou conectados a ele por VPN. Os volumes NetApp não podem alcançar DCs em nenhuma outra VPC, incluindo aquelas que são pareadas com a VPC que se conecta ao pool de armazenamento.
Firewalls: é necessário permitir que os volumes da NetApp entrem em contato com os DCs. Consulte as regras de firewall para acesso ao Active Directory.
Controlador de domínio do Active Directory em uma rede VPC diferente
Não é possível colocar o controlador de domínio em uma VPC diferente porque o peering de VPC do Google Cloud não permite o roteamento transitivo. Como alternativa, é possível anexar volumes do NetApp a uma rede VPC compartilhada que hospeda os controladores de domínio do Active Directory. Se você anexar volumes NetApp a uma rede VPC compartilhada, esse cenário se tornará um dos cenários nas seções anteriores.
Gerenciar seleções de DC usando sites do AD
Para representar os locais reais do data center, escritórios e topologia de rede da maneira mais precisa possível, coloque os controladores de domínio na mesma região dos seus volumes e defina um site do Active Directory para essa região.
Quando o NetApp Volumes está conectado ao seu domínio, o serviço usa a descoberta baseada em DNS para encontrar os controladores de domínio certos com os quais se comunicar. Usando os resultados da descoberta, o serviço mantém uma lista de DCs válidos para se conectar e usa o que tem a menor latência.
Ao especificar um site nas configurações do Active Directory dos volumes NetApp, é possível limitar a lista de DCs aos especificados no site do AD.
Se a seleção automática de DC falhar, o uso de sites do AD pode ajudar a resolver o problema:
Implante pelo menos um controlador de domínio na região dos Volumes da NetApp e conecte-o ao Active Directory atual.
Crie um site do Active Directory para sua região do Google Cloud e coloque os controladores de domínio apropriados nesse site.
Use o site do Active Directory ao configurar conexões do Active Directory.
Para verificar manualmente a lista de DCs em potencial que o serviço pode usar, consulte Como identificar controladores de domínio do Active Directory usados pelos volumes do NetApp.
Para mais informações, consulte o Active Directory: considerações de design e práticas recomendadas.