Implantar um cluster de Big Data do SQL Server no modo do Active Directory Domain Services

Este artigo descreve como implantar um cluster de Big Data do SQL Server no modo do Active Directory. As etapas deste artigo exigem acesso a um domínio do Active Directory. Antes de prosseguir, você precisará concluir os requisitos explicados em Implantar Clusters de Big Data do SQL Server no modo do Active Directory.

Preparar a implantação

Para a implantação de um cluster de Big Data com a integração com o AD, algumas informações adicionais precisam ser fornecidas para a criação de objetos relacionados aos clusters de Big Data no AD.

Usando o perfil kubeadm-prod (ou openshift-prod da versão CU5 em diante), você terá automaticamente os espaços reservados para as informações relacionadas à segurança e ao ponto de extremidade que são necessárias para a integração ao AD.

Além disso, você precisa fornecer credenciais que os Clusters de Big Data usarão para criar os objetos necessários no AD. Essas credenciais são fornecidas como variáveis de ambiente.

Tráfego e portas

Verifique se os firewalls ou aplicativos de terceiros permitem as portas necessárias para a comunicação com o Active Directory.

As solicitações são feitas nesses protocolos dos serviços de cluster Kubernetes para o domínio do Active Directory e vice-versa, portanto, devem ter permissão de entrada e saída em qualquer firewall ou aplicativo de terceiros que escuta as portas necessárias para TCP e UDP. Os números de porta padrão que o Active Directory usa:

Definir variáveis de ambiente de segurança

As variáveis de ambiente a seguir fornecem as credenciais para os Clusters de Big Data de serviço de domínio, que serão usados para configurar a integração com o AD. Essa conta também é usada pelos Clusters de Big Data para manter os objetos do AD no futuro.

export DOMAIN_SERVICE_ACCOUNT_USERNAME=<AD principal account name>
export DOMAIN_SERVICE_ACCOUNT_PASSWORD=<AD principal password>

Fornecer parâmetros de segurança e ponto de extremidade

Além das variáveis de ambiente para as credenciais, você também precisa fornecer informações de segurança e de ponto de extremidade para que a integração com o AD funcione. Os parâmetros necessários fazem parte automaticamente do perfil de implantação kubeadm-prod/openshift-prod.

A integração com o AD requer os seguintes parâmetros. Adicione esses parâmetros aos arquivos control.json e bdc.json usando os comandos config replace mostrados mais adiante neste artigo. Todos os exemplos a seguir estão usando o domínio de exemplo contoso.local.

• security.activeDirectory.ouDistinguishedName: nome diferenciado de uma UO (unidade organizacional) a que todas as contas do AD criadas pela implantação do cluster serão adicionadas. Se o nome do domínio for contoso.local, o nome diferenciado da UO será OU=BDC,DC=contoso,DC=local.

• security.activeDirectory.dnsIpAddresses: contém a lista de endereços IP de servidores DNS do domínio.

• security.activeDirectory.domainControllerFullyQualifiedDns: lista de FQDNs do controlador de domínio. O FQDN contém o nome do computador/host do controlador de domínio. Se tiver vários controladores de domínio, você poderá fornecer uma lista aqui. Exemplo: HOSTNAME.CONTOSO.LOCAL.

  Importante

  Quando vários controladores de domínio estão atendendo a um domínio, use o controlador de domínio primário como a primeira entrada na lista domainControllerFullyQualifiedDns na configuração de segurança. Para obter o nome do controlador de domínio primário, digite netdom query fsmo no prompt de comando e clique em ENTER.

• Parâmetro opcional security.activeDirectory.realm: na maioria dos casos, o realm é igual ao nome de domínio. Para casos em que eles não são iguais, use esse parâmetro para definir o nome do realm (por exemplo, CONTOSO.LOCAL). O valor fornecido para esse parâmetro precisa ser totalmente qualificado.

• Parâmetro opcional security.activeDirectory.netbiosDomainName: esse é o nome NETBIOS do domínio do AD. Na maioria dos casos, esse será o primeiro rótulo do nome de domínio do AD. Para casos em que ele difere, use esse parâmetro para definir o nome NETBIOS do domínio. Esse valor não deve conter pontos. Normalmente, esse nome é usado para qualificar as contas de usuário no domínio. Por exemplo, CONTOSO\user, em que CONTOSO é o nome de domínio NETBIOS.

  Observação

  O suporte para uma configuração em que o nome de domínio Active Directory é diferente do nome NETBIOS do domínio Active Directory usando o security.activeDirectory.netbiosDomainName foi habilitado desde a versão CU9 do SQL Server 2019.

• security.activeDirectory.domainDnsName: nome do domínio DNS que será usado para o cluster (por exemplo, contoso.local).

• security.activeDirectory.clusterAdmins: esse parâmetro usa um grupo do AD. O escopo do grupo do AD precisa ser universal ou global. Os membros desse grupo terão a função de cluster bdcAdmin, que fornecerá permissões de administrador no cluster. Isso significa que eles têm permissões sysadmin no SQL Server, permissões superuser no HDFS e permissões de administrador quando conectados ao ponto de extremidade do controlador.

  Importante

  Crie esse grupo no AD antes do início da implantação. Se o escopo desse grupo do AD for o local do domínio, a implantação falhará.

• security.activeDirectory.clusterUsers: lista dos grupos do AD que são usuários comuns (sem permissões de administrador) no cluster de Big Data. A lista pode incluir grupos do AD que têm o escopo definido como grupos universais ou globais. Eles não podem ser grupos locais de domínio.

Os grupos do AD dessa lista são mapeados para a função de cluster de Big Data bdcUser e precisam receber acesso ao SQL Server (confira Permissões do SQL Server) ou ao HDFS (confira Guia de permissões do HDFS). Quando conectados ao ponto de extremidade do controlador, esses usuários só poderão listar os pontos de extremidade disponíveis no cluster usando o comando azdata bdc endpoint list.

Para obter detalhes sobre como atualizar os grupos do AD para essas configurações, confira Gerenciar o acesso ao cluster de Big Data no modo do Active Directory.

{
    ...
    "spec": {
        "resources": {
            ...
            "gateway": {
                "spec": {
                    "replicas": 1,
                    "endpoints": [{...}],
                    "settings": {
                        "gateway-site.gateway.httpserver.requestHeaderBuffer": "65536"
                    }
                }
            },
            ...
        },
        "services": {
            ...
            "hdfs": {
                "resources": [...],
                "settings": {
                  "core-site.hadoop.security.group.mapping.ldap.search.group.hierarchy.levels": "4"
                }
            },
            ...
        }
    }
}

• security.activeDirectory.enableAES Optional parameter Parâmetro opcional: valor booliano que indica se AES 128 e AES 256 devem ser habilitados nas contas do AD geradas automaticamente. O valor padrão é false. Quando esse parâmetro for definido como true, os sinalizadores 'Esta conta dá suporte à criptografia Kerberos AES de 128 bits' e 'Esta conta dá suporte à criptografia Kerberos AES de 256 bits' serão marcados nos objetos do AD gerados automaticamente durante a implantação do cluster de Big Data.

• Parâmetro opcional security.activeDirectory.appOwners: lista dos grupos do AD que têm permissões para criar, excluir e executar qualquer aplicativo. A lista pode incluir grupos do AD que têm o escopo definido como grupos universais ou globais. Eles não podem ser grupos locais de domínio.

• Parâmetro opcional security.activeDirectory.appReaders: lista dos grupos do AD que têm permissões para executar qualquer aplicativo. A lista pode incluir grupos do AD que têm o escopo definido como grupos universais ou globais. Eles não podem ser grupos locais de domínio.

A tabela abaixo mostra o modelo de autorização para o gerenciamento de aplicativo:

• security.activeDirectory.subdomain: Parâmetro opcional Esse parâmetro foi introduzido na versão SQL Server 2019 CU5 para dar suporte à implantação de vários Clusters de Big Data no mesmo domínio. Usando essa configuração, você pode especificar nomes DNS diferentes para cada cluster de Big Data implantado. Se o valor desse parâmetro não for especificado na seção do Active Directory do arquivo control.json, por padrão, o nome do cluster de Big Data (o mesmo que o nome do namespace do Kubernetes) será usado para calcular o valor da configuração de subdomínio.

  Observação

  O valor transmitido pela configuração de subdomínio não é um novo domínio do AD, mas apenas um domínio DNS usado pelo cluster de Big Data internamente.

  Importante

  Você precisará instalar ou atualizar a última versão da CLI de Dados do Azure (azdata) da versão SQL Server 2019 CU5 em diante para aproveitar essas novas funcionalidades e implantar vários Clusters de Big Data no mesmo domínio.

  Confira Conceito: implantar Clusters de Big Data do SQL Server no modo do Active Directory para obter mais detalhes sobre a implantação de vários Clusters de Big Data no mesmo domínio do Active Directory.

• security.activeDirectory.accountPrefix: Parâmetro opcional Esse parâmetro foi introduzido na versão SQL Server 2019 CU5 para dar suporte à implantação de vários Clusters de Big Data no mesmo domínio. Essa configuração garante a exclusividade dos nomes de contas para vários serviços de Clusters de Big Data, que precisam ser diferentes entre dois clusters. A personalização do nome do prefixo da conta é opcional; por padrão, o nome do subdomínio é usado como o prefixo da conta. Se o nome do subdomínio tiver mais de 12 caracteres, os primeiros 12 caracteres do nome do subdomínio serão usados como o prefixo da conta.

  Observação

  O Active Directory exige que os nomes das contas sejam limitados a 20 caracteres. O cluster de Big Data precisa usar oito dos caracteres para distinguir pods e StatefulSets. Isso deixa 12 caracteres como limite para o prefixo da conta

Verifique o escopo do grupo do AD para determinar se ele é DomainLocal.

Se ainda não tiver inicializado o arquivo de configuração de implantação, você poderá executar esse comando para obter uma cópia da configuração. Os exemplos abaixo usam o perfil kubeadm-prod; o mesmo se aplica a openshift-prod.

azdata bdc config init --source kubeadm-prod  --target custom-prod-kubeadm

Para definir os parâmetros acima no arquivo control.json, use os comandos da CLI de dados do Azure (azdata) a seguir. Os comandos substituem a configuração e fornecem seus próprios valores antes da implantação.

O exemplo abaixo se baseia no uso do SQL Server 2019 CU2. Ele mostra como substituir os valores de parâmetro relacionados ao AD na configuração de implantação. Os detalhes do domínio a seguir são valores de exemplo.

azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.ouDistinguishedName=OU\=bdc\,DC\=contoso\,DC\=local"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.dnsIpAddresses=[\"10.100.10.100\"]"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.domainControllerFullyQualifiedDns=[\"HOSTNAME.CONTOSO.LOCAL\"]"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.domainDnsName=contoso.local"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.clusterAdmins=[\"bdcadminsgroup\"]"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.clusterUsers=[\"bdcusersgroup\"]"
#Example for providing multiple clusterUser groups: [\"bdcusergroup1\",\"bdcusergroup2\"]

Opcionalmente, da versão SQL Server 2019 CU5 em diante, você pode substituir os valores padrão das configurações de subdomain e accountPrefix.

azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.subdomain=[\"bdctest\"]"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.accountPrefix=[\"bdctest\"]"

Da mesma forma, em versões anteriores à SQL Server 2019 CU2, você pode executar:

azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.ouDistinguishedName=OU\=bdc\,DC\=contoso\,DC\=local"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.dnsIpAddresses=[\"10.100.10.100\"]"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.domainControllerFullyQualifiedDns=[\"HOSTNAME.CONTOSO.LOCAL\"]"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.domainDnsName=contoso.local"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.clusterAdmins=[\"bdcadminsgroup\"]"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.clusterUsers=[\"bdcusersgroup\"]"
#Example for providing multiple clusterUser groups: [\"bdcusergroup1\",\"bdcusergroup2\"]

Além das informações acima, você também precisa fornecer nomes DNS para os diferentes pontos de extremidade do cluster. As entradas DNS que usam os nomes DNS fornecidos por você serão criadas automaticamente no servidor DNS após a implantação. Você usará esses nomes ao se conectar aos diferentes pontos de extremidade do cluster. Por exemplo, se o nome DNS da instância mestra do SQL for mastersql e considerando que o subdomínio usará o valor padrão do nome do cluster em control.json, você usará mastersql.contoso.local,31433 ou mastersql.mssql-cluster.contoso.local,31433 (dependendo dos valores fornecidos nos arquivos de configuração da implantação para os nomes DNS do ponto de extremidade) a fim de se conectar à instância mestra por meio das ferramentas.

# DNS names for Big Data Clusters services
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.spec.endpoints[0].dnsName=<controller DNS name>.contoso.local"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.spec.endpoints[1].dnsName=<monitoring services DNS name>.<Domain name. e.g. contoso.local>"
azdata bdc config replace -c custom-prod-kubeadm/bdc.json -j "$.spec.resources.master.spec.endpoints[0].dnsName=<SQL Master Primary DNS name>.<Domain name. e.g. contoso.local>"
azdata bdc config replace -c custom-prod-kubeadm/bdc.json -j "$.spec.resources.master.spec.endpoints[1].dnsName=<SQL Master Secondary DNS name>.<Domain name. e.g. contoso.local>"
azdata bdc config replace -c custom-prod-kubeadm/bdc.json -j "$.spec.resources.gateway.spec.endpoints[0].dnsName=<Gateway (Knox) DNS name>.<Domain name. e.g. contoso.local>"
azdata bdc config replace -c custom-prod-kubeadm/bdc.json -j "$.spec.resources.appproxy.spec.endpoints[0].dnsName=<app proxy DNS name>.<Domain name. e.g. contoso.local>"

# DNS names for Big Data Clusters services
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.spec.endpoints[0].dnsName=<controller DNS name>.<subdomain e.g. mssql-cluster>.contoso.local"

Você pode encontrar aqui um script de exemplo para implantar um cluster de Big Data do SQL Server no cluster do Kubernetes de nó único (kubeadm) com a integração com o AD.

azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.useSubdomain=false"

Agora, você precisa definir todos os parâmetros necessários para uma implantação dos Clusters de Big Data com a integração do Active Directory.

Agora você pode implantar o cluster de Big Data integrado com Active Directory usando o comando da CLI de Dados do Azure (azdata) e o perfil de implantação kubeadm-prod. Para obter a documentação completa de como implantar Clusters de Big Data, confira Como implantar Clusters de Big Data do SQL Server no Kubernetes.

Verificar a entrada DNS inversa para o controlador de domínio

Verifique se há uma entrada DNS inversa (registro PTR) para o próprio controlador de domínio, registrada no servidor DNS. Para verificar isso, execute nslookup do endereço IP do controlador de domínio para ver se ele pode ser resolvido para o FQDN do controlador de domínio.

Limitações e problemas conhecidos

Limitações a serem consideradas no SQL Server 2019 CU5

• atualmente, o Painel de Pesquisa de Logs e o Painel de Métricas não dão suporte à autenticação do AD. O nome de usuário e a senha básicos definidos na implantação podem ser usados para autenticação nesses painéis. Todos os outros pontos de extremidade do cluster dão suporte à autenticação do AD.

• No momento, o modo de segurança do AD só funciona em ambientes de implantação do kubeadm e do openshift, não no AKS nem no ARO. Por padrão, os perfis de implantação kubeadm-prod e openshift-prod incluem as seções de segurança.

• Antes da versão SQL Server CU5 2019, somente um cluster de Big Data por domínio (Active Directory) era permitido. A habilitação de vários clusters de Big Data por domínio está disponível da versão CU5 em diante.

• Nenhum dos grupos do AD especificados nas configurações de segurança pode estar com escopo DomainLocal. Para verificar o escopo de um grupo do AD, siga estas instruções.

• As contas do AD que podem ser usadas para fazer logon no cluster de Big Data são permitidas do mesmo domínio que foi configurado para os Clusters de Big Data do SQL Server. Não há suporte para a habilitação de logons em outro domínio confiável.

Próximas etapas

Conectar Clusters de Big Data do SQL Server: Modo do Active Directory

Solucionar problemas de integração do Active Directory ao cluster de Big Data do SQL Server

Conceito: implantar Clusters de Big Data do SQL Server no modo do Active Directory