Os protocolos de partilha de ficheiros, como SMB (CIFS), NFSv3 com grupos alargados e NFSv4, que usam princípios de segurança, dependem de serviços de diretório externos para fornecer informações de identidade do utilizador. Os volumes do NetApp baseiam-se no Microsoft Active Directory para serviços de diretório. O Active Directory fornece serviços como servidores LDAP para procurar objetos, como utilizadores, grupos e contas de máquinas, servidores DNS para resolver nomes de anfitriões e servidores Kerberos para autenticação.
Para mais informações, consulte o artigo Práticas recomendadas para executar o Active Directory no Google Cloud.
O Microsoft Active Directory gerido do Google Cloud não é suportado pelos volumes da NetApp.
Exemplos de utilização
Os volumes do NetApp usam o Active Directory para os casos nas secções seguintes.
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 utilizadores e grupos. Os volumes do NetApp juntam-se ao domínio como membro e não suportam o SMB no modo de grupo de trabalho.
Suporte de grupos alargado do NFSv3
Para o NFSv3 com suporte de grupo alargado, o Active Directory fornece o servidor LDAP necessário para procurar objetos, como utilizadores, grupos ou contas de máquinas. Especificamente, é necessário um servidor LDAP compatível com RFC2307bis para pesquisas de ID do utilizador e ID do grupo. O suporte de LDAP está ativado nos conjuntos de armazenamento durante a criação do conjunto.
O suporte de grupos alargado ignora todos os IDs de grupos enviados pelo cliente NFS numa chamada NFS; em vez disso, usa o ID do utilizador do pedido e procura todos os IDs de grupos para o ID do utilizador especificado no servidor LDAP para fazer verificações de autorizações de ficheiros.
Para mais informações, consulte o artigo Faça a gestão dos atributos POSIX RFC2307bis do LDAP.
Mapeamento do principal de segurança NFSv4.x para o ID do utilizador e o ID do grupo
Para o NFSv4.x, o Active Directory é usado para mapear os principais de segurança para IDs de utilizadores e IDs de grupos. O NFSv4 usa um modelo de autenticação baseado em diretor. Na autenticação baseada em entidades
autorizadas, os utilizadores são identificados por entidades autorizadas 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 utilizadores e IDs de grupos. Para mapear os principais de segurança para IDs de utilizadores e IDs de grupos quando acede ao volume através de um protocolo NFSv4.x, os volumes NetApp requerem um servidor LDAP em conformidade com a RFC2307bis. O único servidor LDAP suportado é o Active Directory. O suporte de LDAP é ativado nos conjuntos de armazenamento durante a criação do conjunto.
Para usar os princípios de segurança, o cliente e o servidor NFS têm de estabelecer ligação à mesma origem LDAP, e o ficheiro idmapd.conf tem de ser configurado no cliente. Para mais informações sobre a configuração do ficheiro idmapd.conf, consulte o artigo Página do manual do Ubuntu: idmapd.conf – ficheiro de configuração para libnfsidmap.
O nome do domínio do Active Directory é usado para o dns_domain. O utilizador é o nome dos utilizadores do Active Directory. Use estes valores quando definir os atributos POSIX do LDAP.
Para usar o NFSv4.1 sem configurar o mapeamento de IDs e usar apenas IDs de utilizadores e IDs de grupos, pode usar IDs numéricos para ignorar os principais de segurança. Os volumes NetApp suportam IDs numéricos e os clientes NFS atuais usam IDs numéricos por predefinição se o mapeamento de IDs não estiver configurado.
NFSv4.x com Kerberos
Se usar o Kerberos, é obrigatório usar o Active Directory como o servidor LDAP para procuras de entidades de segurança. Os principais do Kerberos são usados como identificadores de segurança. O Active Directory também é usado como o centro de distribuição de chaves (KDC) do Kerberos. Para que isto funcione, tem de anexar uma política do Active Directory com definições do Kerberos ao conjunto e ativar o suporte do LDAP num conjunto de armazenamento durante a criação do conjunto.
Para mais informações, consulte o artigo Crie um conjunto de armazenamento.
Acesso LDAP do Active Directory
Para exemplos de utilização do NFS, o Active Directory é usado como um servidor LDAP. Os volumes NetApp esperam dados de identidade através de um esquema RFC2307bis. O Active Directory já fornece este esquema, mas tem de se certificar de que preenche os atributos necessários para os seus utilizadores e grupos.
Os volumes do NetApp usam as credenciais fornecidas pela política do Active Directory para fazer a associação ao LDAP através da assinatura LDAP.
Se não for possível encontrar o utilizador ou o grupo, o acesso é recusado.
Colocação em cache de atributos
O NetApp Volumes armazena em cache os resultados das consultas LDAP. A tabela seguinte descreve as definições de tempo de vida (TTL) para a cache LDAP. Se a cache contiver dados inválidos devido a configurações incorretas que está a tentar corrigir, tem de aguardar até que a cache seja atualizada antes de as alterações no Active Directory serem detetadas. Caso contrário, o servidor NFS continua a usar os dados antigos para validar o acesso, o que provavelmente resulta em mensagens de acesso recusado no cliente. Após o período de TTL, as entradas ficam obsoletas para que as entradas desatualizadas não permaneçam. Os pedidos de pesquisa que não são encontrados são retidos durante um TTL de um minuto para ajudar a evitar problemas de desempenho.
| Cache | Limite de tempo predefinido |
|---|---|
| Lista de membros do grupo | TTL de 24 horas |
| Grupos Unix (GID) | TTL de 24 horas, TTL negativo de 1 minuto |
| Utilizadores Unix (UID) | TTL de 24 horas, TTL negativo de 1 minuto |
Topologias de controladores de domínio do Active Directory
Depois de se ligar com êxito aos controladores de domínio do Active Directory, pode usar os seguintes protocolos de partilha de ficheiros:
- SMB
- NFSv3 com grupos alargados
- NFSv4
As secções seguintes ilustram várias topologias potenciais. Os diagramas mostram apenas o controlador de domínio usado pelos volumes NetApp. Os outros controladores de domínio para o mesmo domínio são apresentados apenas quando necessário.
A Microsoft recomenda a implementação de, pelo menos, dois controladores de domínio (DCs) para redundância e disponibilidade.
Controlador de domínio do Active Directory na mesma região que os volumes do NetApp Volumes
O diagrama seguinte mostra o modo de implementação mais simples, um controlador de domínio na mesma região que os volumes do NetApp Volumes.
Controladores de domínio do Active Directory em várias regiões com sites do AD
Se estiver a usar volumes NetApp Volumes em várias regiões, recomendamos que coloque, pelo menos, um controlador de domínio em cada região. Embora o serviço tente escolher automaticamente o melhor DC a usar, recomenda-se que faça a gestão da seleção de DCs através de sites de AD.
Controlador de domínio do Active Directory numa rede no local
A utilização de um controlador de domínio no local através de VPN é suportada, mas pode afetar negativamente a autenticação do utilizador final e o desempenho do acesso a ficheiros. Certifique-se de que não adiciona saltos de peering de VPC adicionais no caminho da rede.
Considerações para DCs no local
As ligações a DCs nas instalações usam TCP e IP. Estas ligações falham frequentemente devido às seguintes limitações:
Interligação de VPCs: os volumes da NetApp só podem alcançar DCs que estejam na VPC do conjunto de armazenamento ou que estejam ligados a ela por VPN. Os volumes do NetApp não conseguem alcançar os DCs em nenhuma outra VPC, incluindo os que estão em intercâmbio com a VPC que se liga ao conjunto de armazenamento.
Firewalls: tem de permitir que os volumes da NetApp contactem os seus DCs. Consulte as regras de firewall para acesso ao Active Directory.
Controlador de domínio do Active Directory numa rede VPC diferente
Não pode colocar o controlador de domínio numa VPC diferente porque o intercâmbio de VPCs do Google Cloud não permite o encaminhamento transitivo. Em alternativa, pode anexar volumes NetApp a uma rede VPC partilhada que aloja os controladores de domínio do Active Directory. Se anexar volumes NetApp a uma rede VPC partilhada, então, do ponto de vista da arquitetura, este cenário torna-se um dos cenários nas secções anteriores.
Faça a gestão das seleções de DC através de sites de AD
Para representar as localizações reais dos centros de dados, os escritórios e a topologia de rede da forma mais próxima possível, coloque os controladores de domínio na mesma região que os seus volumes e defina um site do Active Directory para essa região.
Quando o NetApp Volumes está ligado ao seu domínio, o serviço usa a deteção baseada em DNS para encontrar os controladores de domínio certos com os quais comunicar. Com base nos resultados da deteção, o serviço mantém uma lista de DCs válidos para estabelecer ligação e usa o que tiver a latência mais baixa.
Quando especifica um site nas definições do Active Directory dos volumes NetApp, pode limitar a lista de DCs aos especificados no site do AD.
Se a seleção automática de DCs falhar, a utilização de sites de AD pode ajudar a corrigir o problema:
Implemente, pelo menos, um controlador de domínio na região dos volumes NetApp e associe-os ao seu Active Directory existente.
Crie um site do Active Directory para a sua região do Google Cloud e coloque os controladores de domínio adequados nesse site.
Use o site do Active Directory quando configurar associações do Active Directory.
Para validar manualmente a lista de potenciais DCs que o serviço pode usar, consulte o artigo Como identificar controladores de domínio do Active Directory usados pelos volumes NetApp
Para mais informações, consulte o artigo Active Directory: considerações de design e práticas recomendadas.