Permissões e Windows 2008 Failover Clusters

Por Fernando Cardoso.

Ainda estes dias trabalhei em um caso onde a solução acabou sendo uma variação de uma solução relativamente conhecida. Por acreditar que este problema pode eventualmente ser enfrentando em outros ambientes, resolvi por escrever este artigo. Neste artigo vamos abordar o que é a conta CSA no Failover Cluster 2003, como ela foi eliminada no Failover Cluster 2008, cuidados que temos que tomar com permissões e, finalmente, uma novidade na resolução de problemas relacionados.

Desde o Failover Cluster do Windows 2008 deixamos de ter a CSA (Cluster Service Account). No Windows 2003, que ainda utiliza a CSA, o Cluster Service é iniciado sob o contexto de segurança desta conta. As credenciais para esta conta são informadas nas propriedades do Cluster Service. O Service Control Manager por sua vez utiliza estas credencias para iniciar o serviço. Esta conta tem que ser previamente criada no AD a fim de que se possa indicá-la durante a criação de um novo cluster. Durante a configuração inicial do cluster, essa conta é então adicionada como membro do grupo Local Administrators de cada um dos nodes do cluster. São ajustadas também uma séria de permissões adicionais, como por exemplo “Act as part of the operating system”, “Logon as a Service”, etc. Temos ainda que nos assegurar de que o próprio grupo Local Administrators tenha alguns direitos específicos. Tudo isso em todos os nodes do cluster. Detalhes estão descritos na kb269229. Esta KB descreve o processo de configuração da CSA, para casos onde se tenha que trocar esta conta. Sem o auxílio que wizard presta na configuração inicial do cluster.

O problema que se resolve com a configuração manual da conta, conforme a kb acima referenciada, é justamente um dos motivos pelos quais se alterou este modelo a partir dos Failover Clusters baseados em Windows 2008. A partir do Windows 2008 não temos mais a CSA. Adicionalmente, a partir do Windows 2008, o Cluster Service roda sob o contexto de segurança de uma conta local.

Isso pode ser verificado via comand “sc qc clussvc”. Abaixo temos o retorno do comando em um cluster 2003 e um 2008. (Essa configuração é também verificável pelo Services.msc, coluna Log On As)

Windows 2003:

SERVICE_START_NAME: Contoso.com\Cluster2003ServiceAccount ß referencia uma conta no AD

Windows 2008:

SERVICE_START_NAME: LocalSystem

No Windows 2008 o contexto de segurança de um cluster 2008 não é mais a conta CSA mas sim o computer object que é criado no AD durante a criação do cluster (Create Cluster Wizard). Em outras palavras, o computer object que leva o mesmo nome do cluster passa a ser o security context do cluster no AD. À este objeto se dá o nome de Computer Name Object (CNO).

O processo de configuração das permissões necessárias à conta que está sendo utilizada para a configuração inicial de um Failover Cluster Windows 2008, para o CNO bem como para computer objects para Serviços e Aplicações (VCOs), estão bem descritos na documentação:

Failover Cluster Step-by-Step Guide: Configuring Accounts in Active Directory

Ai temos como ajustar permissões como, por exemplo, permissões full controll para a conta que será utilizada para a configuração inicial do cluster. Ou permissões para o CNO de criar computer objects. Pois é com o contexto CNO que o cluster vai criar outros computer objects (VCOs). Esta documentação é geralmente o ponto de partida quando estamos trabalhando com troubleshooting de permissões em um Cluster 2008. E geralmente é a solução.

Por exemplo, em casos onde não estamos conseguindo trazer um Network Name para online, e temos uma mensagem como esta no system log:

Event ID 1194

Cluster network name resource '<CNO>' failed to create its associated computer object in domain '<dominio>' for the following reason: Unable to obtain access to Computer Object in DS.

The text for the associated error code is: Access is denied.

Please work with your domain administrator to ensure that:

- The cluster identity '<CNO>$' can create computer objects. By default all computer objects are created in the 'Computers' container; consult the domain administrator if this location has been changed.

- The quota for computer objects has not been reached.

- If there is an existing computer object, verify the Cluster Identity <CNO>$' has 'Full Control' permission to that computer object using the Active Directory Users and Computers tool.

Na grande maioria das vezes é resolvido com os ajustes de permissões descritos na documentação acima.

Se estas configurações, que são fundamentais, não resolverem, assegura-se de o grupo default “Authenticated Users” é membro do grupo local Users. Em todos os nodes do cluster. Se não for, adicione. Isso já foi solução em um caso que tivemos tem algumas semanas.

Em um caso ainda um pouco mais especial, todos os dois nodes de um cluster eram Domain Controllers. Apesar de ser best practice que nodes de um cluster não sejam DCs, em alguns casos raros (nodes do cluster são os únicos servers em um site) isso pode ser fazer necessário. Estávamos enfrentando problema com permissões (justamente a mensagem acima, event id 1194). Não há como adicionar Authenticated Users no grupo local pois, sendo as máquinas DCs, não temos grupos locais. Neste caso adicionamos o Authenticated Users no grupo Users no domínio. O que resolveu o problema da mesma forma.