Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Neste artigo, saiba como habilitar e usar contas de serviço gerenciado de grupo (gMSA) no Windows Server.
Os protocolos de autenticação que suportam a autenticação mútua, como o Kerberos, não podem ser utilizados a menos que todas as instâncias dos serviços utilizem o mesmo principal. Por exemplo, quando um computador cliente se conecta a um serviço que usa balanceamento de carga ou outro método em que todos os servidores parecem ser o mesmo serviço para o cliente. Ou seja, cada serviço tem de utilizar as mesmas palavras-passe ou chaves para provar a sua identidade. As Contas de Serviço Gerenciado de Grupo são um tipo de conta que pode ser usada com vários servidores. Um gMSA é uma conta de domínio que pode ser usada para executar serviços em vários servidores sem ter que gerenciar a senha. O gMSA fornece gerenciamento automático de senhas e gerenciamento simplificado de nome principal de serviço (SPN), incluindo delegação de gerenciamento a outros administradores.
Note
Os clusters de failover não suportam gMSAs. No entanto, os serviços executados sobre o serviço de Cluster podem usar um gMSA ou um sMSA se forem um serviço do Windows, um pool de aplicativos, uma tarefa agendada ou suportarem nativamente gMSA ou sMSA.
Os serviços podem escolher a principal a ser utilizada. Cada tipo principal suporta serviços diferentes e tem limitações diferentes.
Principals | Services supported | Password management |
---|---|---|
Conta de computador do sistema Windows | Limitado a um servidor que ingressou no domínio | Computer manages |
Conta de computador sem sistema Windows | Qualquer servidor ligado ao domínio | None |
Virtual Account | Limitado a um servidor | Computer manages |
Conta de Serviço Gerenciado autônoma do Windows | Limitado a um servidor que ingressou no domínio | Computer manages |
User Account | Qualquer servidor ligado ao domínio | None |
Conta de Serviço Gerenciado de Grupo | Qualquer servidor associado ao domínio do Windows Server | O controlador de domínio gerencia e o host recupera |
Uma conta de computador Windows, uma Conta de Serviço Gerenciado (sMSA) autônoma do Windows ou contas virtuais não podem ser compartilhadas entre vários sistemas. Quando você usa contas virtuais, a identidade também é local para a máquina e não é reconhecida pelo domínio. Se configurar uma conta para que os serviços em farms de servidores possam ser partilhados, terá de escolher uma conta de utilizador ou uma conta de computador separada de um sistema Windows. De qualquer forma, essas contas não têm a capacidade de gerenciamento de senhas de ponto de controle único. Sem gerenciamento de senhas, cada organização precisa atualizar chaves para o serviço no Ative Directory (AD) e distribuir essas chaves para todas as instâncias desses serviços.
Com o Windows Server, os administradores de serviços e serviços não precisam gerenciar a sincronização de senha entre instâncias de serviço ao usar o gMSA. Você cria o gMSA no AD e, em seguida, configura o serviço que oferece suporte a contas de serviço gerenciado. O uso do gMSA tem como escopo qualquer máquina que possa usar o protocolo LDAP (Lightweight Directory Access Protocol) para recuperar as credenciais do gMSA. Você pode criar um gMSA usando os New-ADServiceAccount
cmdlets que fazem parte do módulo AD. Os serviços a seguir oferecem suporte à configuração de identidade de serviço no host.
As mesmas APIs que o sMSA, portanto, os produtos que suportam o sMSA suportam o gMSA
Serviços que usam o Gerenciador de Controle de Serviços para configurar a identidade de logon
Services that use the Internet Information Services (IIS) manager for application pools to configure identity
Tasks using Task Scheduler.
Prerequisites
Para gerenciar gMSAs, seu dispositivo deve atender aos seguintes requisitos:
Seu dispositivo deve ter a função Serviços de Domínio Ative Directory (AD DS) instalada. Para saber mais, consulte Adicionar ou remover funções e recursos no Windows Server.
You must be a member of the Domain Admins or Enterprise Admins group.
Os níveis funcionais do domínio e da floresta devem ser configurados para Windows Server 2012 ou posterior para suportar os recursos gMSA em todos os dispositivos. Para saber mais sobre como atualizar o esquema, consulte Aumentar os níveis funcionais de domínio e floresta nos Serviços de Domínio Active Directory.
Uma chave raiz dos Serviços de Distribuição de Chaves (KDS) deve ser criada no domínio para gerenciamento seguro de senhas. Verifique sua criação usando o log operacional KdsSvc (ID de evento 4004). Para saber mais sobre como criar a chave raiz do KDS (kdssvc.dll), consulte Criar a chave raiz do KDS dos Serviços de Distribuição de Chaves.
Tip
Para controlar quais hosts ou serviços podem usar um gMSA, adicione suas contas de computador a um grupo de segurança designado (novo ou existente) e atribua as permissões necessárias a esse grupo. Da mesma forma, use um grupo de segurança para gerenciar o acesso a serviços executados em gMSAs, garantindo que o grupo tenha todas as permissões necessárias para operação de serviço e acesso a recursos.
Para que a autenticação Kerberos funcione com serviços usando gMSAs, é necessário o seguinte:
Certifique-se de que os SPNs estão registrados corretamente para cada serviço usando um gMSA. Isso permite que o Kerberos identifique e autentique o serviço.
Verifique se os registros DNS estão configurados corretamente para a resolução de nomes, na qual o Kerberos se baseia para localizar serviços de domínio.
Certifique-se de que os firewalls e as políticas de rede permitam o tráfego Kerberos e as comunicações de serviço necessárias.
Para as configurações de tempo de vida do tíquete Kerberos, configure as políticas de expiração e renovação do tíquete de acordo com seus requisitos operacionais e de segurança.
Todos os sistemas envolvidos no processo de autenticação devem ter relógios sincronizados. O Kerberos é sensível à configuração de tempo e discrepâncias podem causar falhas de autenticação.
Se estiver a gerir o AD a partir de um computador que não seja um controlador de domínio, instale as Ferramentas de Administração de Servidor Remoto (RSAT) para aceder às funcionalidades de gestão necessárias. O RSAT fornece o módulo AD para PowerShell. Depois de instalar o RSAT, abra o PowerShell como administrador e execute Import-Module ActiveDirectory
para habilitar cmdlets de gerenciamento do AD. Isso permite que os administradores gerenciem o AD remotamente e com segurança, minimizando a carga nos controladores de domínio.
Criar um gMSA
Para criar um gMSA usando o PowerShell, siga estas etapas em uma janela elevada do PowerShell:
Important
Os nomes de conta gMSA devem ser exclusivos dentro de um nível de floresta e não apenas de um domínio. A tentativa de criar uma conta gMSA com um nome duplicado falha, mesmo em domínios diferentes.
Crie a Chave Raiz do KDS, se não existir, seguindo as orientações em Criar a Chave Raiz do KDS dos Serviços de Distribuição de Chaves. Se já existir uma chave, ignore esta etapa.
Para criar um gMSA, execute o seguinte comando. Substitua
<gMSAName>
pelo nome gMSA desejado e<domain>
pelo nome do seu domínio. Substitua<SecurityGroup>
pelo nome do grupo de segurança ou contas de computador que devem ter acesso para recuperar a senha do gMSA.New-ADServiceAccount -Name <gMSAName> -DNSHostName <gMSAName>.<domain> -PrincipalsAllowedToRetrieveManagedPassword <SecurityGroup>
Para criar um gMSA apenas para autenticação de saída, execute o seguinte comando. Substitua
<Days>
por um valor numérico. Se um valor não for fornecido, o padrão será30
dias.New-ADServiceAccount -Name <gMSAName> -DNSHostName <gMSAName>.<domain> -RestrictToOutboundAuthenticationOnly -ManagedPasswordIntervalInDays <Days> -PrincipalsAllowedToRetrieveManagedPassword <SecurityGroup>
Important
O intervalo de alteração de senha só pode ser definido durante a criação. Se você precisar alterar o intervalo, deverá criar um novo gMSA e defini-lo no momento da criação.
Em cada computador que usa o gMSA, execute o seguinte comando para instalar o gMSA no dispositivo de destino. Substitua
<gMSAName>
pelo nome do gMSA que você criou.Install-ADServiceAccount -Identity <gMSAName>
Execute o seguinte comando para verificar se a instalação do gMSA foi executada no dispositivo de destino.
Test-ADServiceAccount -Identity <gMSAName>
A associação ao grupo de segurança apropriado ou ter as permissões delegadas necessárias para criar msDS-GroupManagedServiceAccount
objetos é necessária para concluir este procedimento. While members of Account Operators can manage certain user and group objects in AD, they don't have default rights to create gMSAs unless those permissions are delegated to them. Para obter informações detalhadas sobre como usar as contas e associações de grupo apropriadas, consulte Grupos de segurança do Ative Directory.
Você também pode atualizar as propriedades do gMSA usando o Set-ADServiceAccount
cmdlet. Por exemplo, para atualizar o nome de exibição dos computadores, execute o seguinte comando substituindo <gMSAName>
e <NewDisplayName>
com seus valores:
Set-ADServiceAccount -Identity "<gMSAName>" -DisplayName "<NewDisplayName>"
For detailed information on how to set other properties for the gMSA, see Set-ADServiceAccount.
Verificar alterações em um gMSA
Depois de fazer alterações em um gMSA, você pode verificar se o gMSA está atualizado corretamente. Essas alterações incluem adicionar, remover e desinstalar um gMSA. Você também pode executar essa etapa a qualquer momento quando forem feitas atualizações nas propriedades do gMSA.
Execute o seguinte comando substituindo <gMSAName>
pelo nome do gMSA que você criou:
Get-ADServiceAccount -Identity "<gMSAName>" | Select-Object *
Adicionar anfitriões membros a um grupo de segurança
Note
Group-centric management (
Add-ADGroupMember
/Remove-ADGroupMember
): Use these cmdlets when you want to manage the membership of a specific group. Eles são mais adequados para adicionar ou remover vários usuários, computadores ou outros objetos de ou para um único grupo de forma eficiente.Principal-centric management (
Add-ADPrincipalGroupMembership
/Remove-ADPrincipalGroupMembership
): Choose these cmdlets when your goal is to manage a specific user or computer's membership across multiple groups. Eles permitem adicionar ou remover um principal de vários grupos numa única operação, facilitando a atualização das afiliações de grupo de contas individuais.
Se você usar grupos de segurança para gerenciar hosts membros, adicione a conta de computador do novo host membro ao grupo de segurança que contém os hosts membros do gMSA. Você pode fazer isso usando um dos seguintes métodos:
Para usar o snap-in Usuários e Computadores do Ative Directory (ADUC), consulte Adicionar uma conta de computador a um grupo e Gerenciar contas de usuário em Usuários e Computadores do Ative Directory.
Se estiver a utilizar contas de computador, localize as contas existentes e, em seguida, adicione a nova conta de computador.
Remover anfitriões membros de um grupo de segurança
Para usar o snap-in ADUC, consulte Excluir uma conta de computador e Remover uma conta de usuário.
Desinstalar um gMSA do seu sistema
Embora não seja possível desinstalar gMSAs no ADUC, você pode excluir manualmente um gMSA localizando-o no contêiner Contas de Serviço Gerenciado e excluindo-o como qualquer outro objeto do AD. No entanto, lembre-se de que isso não executa as mesmas operações de limpeza que Uninstall-ADServiceAccount
executaria no PowerShell.
Para desinstalar um gMSA, abra uma janela elevada do PowerShell e siga estas etapas.
Para remover um único gMSA do seu ambiente, execute o seguinte comando substituindo
<gMSAName>
pelo seu valor:Uninstall-ADServiceAccount -Identity <gMSAName>
Para remover vários gMSAs do seu ambiente, execute o seguinte comando substituindo
<gMSA#$>
pelos seus valores:$gMSANames = @("gMSA1$", "gMSA2$", "gMSA3$") foreach ($gMSAs in $gMSANames) { Uninstall-ADServiceAccount -Identity $gMSAs }
For more information about the Uninstall-ADServiceAccount
cmdlet, see Uninstall-ADServiceAccount.