Nesta página, descrevemos a integração do Active Directory do Google Cloud NetApp Volumes.
Sobre a integração
Uma política do Active Directory informa ao NetApp Volumes como se conectar ao Active Directory. As configurações do pool de armazenamento usam políticas do Active Directory para definir as configurações do Active Directory dos volumes criados neles.
As políticas do Active Directory são específicas de cada região, e é possível configurar até cinco políticas por região.
Os protocolos de compartilhamento de arquivos, como SMB (CIFS), NFSv3 com grupos estendidos e NFSv4, que usam entidades 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 Active Directory para serviços de diretório. O Active Directory fornece os seguintes serviços:
Servidores LDAP: pesquisar objetos como usuários, grupos ou máquinas
Servidores DNS: resolvem nomes de host e descoberta de controladores de domínio do Active Directory
Servidores Kerberos: realizam a autenticação.
Para mais informações, consulte Práticas recomendadas para executar o Active Directory no Google Cloud.
Casos de uso do Active Directory
O NetApp Volumes usa o Active Directory em vários casos de uso:
Serviço de domínio SMB: o Active Directory é o serviço de domínio central para SMB. Ele usa o SMB para autenticação e pesquisas de identidade para usuários e grupos. O NetApp Volumes entra no domínio como um membro, mas não oferece suporte a 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, as pesquisas de ID de usuário e ID de grupo exigem um servidor LDAP compatível com
RFC2307bis
. O suporte a LDAP é ativado em 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 procura todos os IDs de grupo para o ID de 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 ID do usuário e ID do grupo para principal de segurança NFSv4.x: para NFSv4.x, o NetApp Volumes usa o Active Directory para mapear principais de segurança para IDs de usuário e IDs de grupo. O NFSv4 usa um modelo de autenticação baseado em principais. Na autenticação baseada em principais, as entidades de segurança identificam usuários que assumem a forma
user@dns_domain
. Consulte Considerações de segurança doRFC 7530
em vez de IDs de usuários e grupos. Para mapear os principais de segurança para IDs de usuário e de grupo ao acessar o volume com um protocolo NFSv4.x, o NetApp Volumes exige um servidor LDAP compatível comRFC2307bis
. NetApp Volumes só são compatíveis com servidores LDAP do Active Directory. O suporte a LDAP é ativado nos pools de armazenamento durante a criação deles.Para usar principais de segurança, o cliente e o servidor NFS precisam se conectar à mesma fonte LDAP, e você precisa configurar o arquivo
idmapd.conf
no cliente. Para mais informações sobre como configurar o arquivoidmapd.conf
, consulte Documentação do Ubuntu sobre como configurar o arquivoidmapd.conf
paralibnfsidmap
.O
dns_domain
usa o nome de domínio do Active Directory, e ouser
é o nome do usuário do Active Directory. Use esses valores ao definir os atributos POSIX do LDAP.Para usar o NFSv4.1 sem mapeamento de ID e usar apenas IDs de usuário e IDs de grupo semelhantes ao NFSv3, use IDs numéricos para ignorar os principais de segurança. O NetApp Volumes é compatível com IDs numéricos. 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ê usa o Kerberos, é obrigatório usar o Active Directory como o servidor LDAP para pesquisas de entidade de segurança. Os principais do Kerberos são usados como identificadores de segurança. O centro de distribuição de chaves do Kerberos usa o Active Directory. Para isso, anexe uma política do Active Directory que contenha configurações do Kerberos ao pool e ative o suporte a LDAP em um pool de armazenamento ao criar o pool.
Permissões necessárias para criar contas de máquina do Active Directory
Para usar o Active Directory, NetApp Volumes precisam associar um ou mais
servidores de arquivos virtuais ao seu domínio como contas de computador. Para entrar no domínio, você precisa fornecer as credenciais de um usuário que tenha permissão para associar computadores ao seu domínio. Por padrão, apenas os membros do grupo Domain Admins
podem associar computadores ao domínio, mas o Active Directory tem a capacidade de delegar as permissões necessárias a usuários ou grupos individuais em um domínio completo ou no nível da unidade organizacional (UO).
Para volumes da NetApp, é recomendável criar uma conta de serviço de domínio dedicada. Delegue apenas as permissões necessárias para associar novos computadores
a uma UO específica. Depois que um usuário com associação a um grupo Domain User
ou Domain Guest
for criado, use as instruções a seguir para delegar as permissões necessárias.
Faça login no sistema como administrador do seu domínio do Active Directory.
Abra o snap-in do MMC de Usuários e computadores do Active Directory.
Na barra de menus, selecione Visualizar e verifique se a opção Recursos avançados está ativada.
Uma marca de seleção vai aparecer se os Recursos avançados estiverem ativados.
No painel de tarefas, expanda o nó do domínio.
Localize a UO que você quer modificar, clique com o botão direito do mouse e selecione Propriedades no menu de contexto.
Na janela Propriedades da UO, selecione a guia Segurança.
Em Segurança, clique em Avançado e em Adicionar.
Na caixa de diálogo Entrada de permissão, siga estas etapas:
Clique em Selecionar um principal.
Digite o nome da conta de serviço ou do grupo e clique em OK.
Em Aplicável a, selecione Este objeto e todos os objetos descendentes.
Verifique se as seguintes permissões estão selecionadas:
Modificar permissões
Criar objetos de computador
Excluir objetos de computador
Marque a caixa de seleção Aplicar e clique em OK.
Feche o snap-in do MMC de Usuários e computadores do Active Directory.
Depois que a conta de serviço for delegada, você poderá fornecer o nome de usuário e a senha como credenciais da política do Active Directory.
Para aumentar a segurança, durante a consulta e a criação do objeto da conta de máquina, o nome de usuário e a senha transmitidos ao domínio do Active Directory usam criptografia Kerberos.
Controladores de domínio do Active Directory
Para conectar o NetApp Volumes ao seu domínio, o serviço usa a descoberta baseada em DNS para identificar uma lista de controladores de domínio disponíveis para uso.
O serviço executa as seguintes etapas para encontrar um controlador de domínio a ser usado:
Descoberta de sites do Active Directory: o NetApp Volumes usa um ping LDAP para o IP do servidor DNS especificado na política do Active Directory para buscar as informações da sub-rede do site do Active Directory. Ele retorna uma lista de CIDRs e os sites do Active Directory atribuídos a eles.
Get-ADReplicationSubnet -Filter * | Select-Object Name,Site
Definir nomes de sites: se o endereço IP do volume corresponder a alguma das sub-redes definidas, o nome do site associado será usado. As correspondências de sub-redes menores têm precedência sobre as de sub-redes maiores. Se o endereço IP do volume for desconhecido, crie manualmente um volume temporário com o tipo de protocolo NFS para determinar o CIDR
/28
usado.Se nenhum nome de site for definido no Active Directory, será usado o nome configurado na política do Active Directory. Se nenhum nome de site for configurado, os níveis de serviço Standard, Premium e Extreme usarão o site
Default-First-Site-Name
. Se o nível de serviço flexível tentar usar o siteDefault-First-Site-Name
, ele vai falhar e, em vez disso, usará a descoberta completa do controlador de domínio. As mudanças no parâmetro do site do Active Directory são ignoradas pelos pools de armazenamento do nível de serviço Flex.Descoberta de controladores de domínio: com todas as informações necessárias adquiridas, o serviço identifica possíveis controladores de domínio usando a seguinte consulta de DNS:
nslookup -type=srv _ldap._tcp.<site_name>._sites.dc._msdcs.<domain-name> <dns-server>
Para a descoberta completa de domínio, o serviço usa a seguinte consulta DNS:
nslookup -type=srv _ldap._tcp.dc._msdcs.<domain-name> <dns-server>
Geração da lista de controladores de domínio: uma lista de controladores de domínio é gerada. O NetApp Volumes monitora constantemente todos eles para verificar a disponibilidade. Entre os controladores de domínio disponíveis, ele seleciona um para junção e pesquisas de domínio. Se o controlador de domínio selecionado desaparecer, outro controlador de domínio da lista Disponível será usado automaticamente. O controlador de domínio escolhido não é necessariamente o servidor DNS especificado.
É necessário fornecer pelo menos um controlador de domínio acessível para o serviço usar. Recomendamos vários para melhorar a disponibilidade do controlador de domínio. Verifique se há um caminho de rede roteado entre o NetApp Volumes e os controladores de domínio e se as regras de firewall nos controladores de domínio permitem a conexão do NetApp Volumes.
Para mais informações, consulte Considerações e práticas recomendadas para o design do Active Directory.
Topologias de controladores de domínio do Active Directory
Depois de se conectar aos controladores de domínio do Active Directory, você poderá usar os seguintes protocolos de compartilhamento de arquivos:
SMB
NFSv3 com grupos estendidos
NFSv4 com principais de segurança e Kerberos
Os cenários a seguir descrevem possíveis topologias. Os cenários descrevem apenas o controlador de domínio usado pelo NetApp Volumes. Outros controladores de domínio para o mesmo domínio são descritos apenas quando necessário. Recomendamos implantar pelo menos dois controladores de domínio para redundância e disponibilidade.
Controlador de domínio do Active Directory e volumes em uma região: esse cenário é a estratégia de implantação mais simples, em que um controlador de domínio está na mesma região que o volume.
Controlador de domínio do Active Directory e volumes em regiões separadas: é possível usar um controlador de domínio em uma região diferente de um volume. Isso pode afetar negativamente a autenticação e o desempenho do acesso a arquivos.
Controladores de domínio do Active Directory em várias regiões usando sites do AD: se você usa 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 controlador de domínio para usar, recomendamos que você gerencie a seleção com sites do Active Directory.
Controlador de domínio do Active Directory em uma rede local: é possível usar um controlador de domínio local por VPN, mas isso pode afetar negativamente a autenticação do usuário final e o desempenho do acesso a arquivos. Não adicione outros hops de peering da nuvem privada virtual ao caminho da rede. O peering de VPC está sujeito a restrições de roteamento transitivo. O tráfego não é encaminhado além do salto de peering de VPC que o NetApp Volumes já consome.
Controlador de domínio do Active Directory em outra rede VPC: não é possível colocar o controlador de domínio em outra VPC porque o peering de VPCGoogle Cloud não permite o roteamento transitivo. Como alternativa, é possível conectar as VPCs usando VPN ou anexar NetApp Volumes a uma rede VPC compartilhada que hospede os controladores de domínio do Active Directory. Se você anexar o NetApp Volumes a uma rede VPC compartilhada, arquitetonicamente, esse cenário será o mesmo de um dos cenários nas seções anteriores.
A seguir
Crie uma política do Active Directory.