Estender o Schema - Validação da Consistência

Alguns softwares de mercado ou da própria Microsoft alteram o schema do AD, estas alterações podem levar a quebra do schema (parada total do AD) durante um processo de atualização. Por esta razão temos a necessidade de validar os possíveis problemas que podem ocorrer antes de estender o schema.

Apesar deste procedimento mitigar alguns riscos para a alteração do schema, este procedimento não tira a importância da validação do procedimento em ambiente de teste (laboratótio) antes da execução do procedimento em ambiente de produção.

1. Verificar a versão do schema do AD, para isso instale o support tools e acesse o adsiedit.msc, abra o caminho LDAP “CN=Schema,CN=Configuration,DC=contoso,DC=com”, localize o objeto “CN=Schema-Version” e clique em propriedades, localize o atributo “objectVersion” e verifique o valor deste atributo. Em nosso exemplo, o valor é 31. Outra forma de verificar este valor é através do comando:

dsquery * cn=schema,cn=configuration,dc=contoso,dc=com -scope base -attr objectVersion

2. Realizar um dump do schema que pertence a floresta que será realizado a modificação do schema, para isso, execute o comando (digite na mão, pois alguns casos copiar+colar não funciona):

ldifde –d “CN=schema,CN=configuration,DC=contoso,DC=com” –f schema.ldf

3. Sabendo o valor do atributo e tendo o dump do schema da floresta, iremos verificar a consistência desta versão com todos ldfs seguintes até a versão que irá ser implementada. Por exemplo, a floresta em modo 2003 Nativo possui o valor 31, já o valor em modo 2008 Nativo é 44, neste caso iremos comparar o dump realizado que está na versão 31 com o ldf 32, 31 com o ldf 33 e assim por diante até a versão 44.

Localize todos os ldfs que serão comparados, eles se encontram na mídia de instalação do sistema operacional. Copie estes arquivos para um diretório local no servidor onde será realizado a comparação e onde se enconta o dump do schema que foi realizado. Execute o comando: cscript schchk.vbs schema.ldf sch33.ldf Repita o procedimento para cada ldf, sch34.ldf, sch35.ldf, etc.

4. Verifique se há algum erro no log gerado pelos procedimentos realizados, normalmente erros encontrados terão a descrição “mismatch”. O log gerado será o schchk.log. Caso encontre algum erro, será necessário entrar em contato com o fornecedor da aplicação que alterou o schema. Se a atualização do schema proceder sem a resolução do problema, poderá ocorrer desde a indisponibilidade da aplicação até a quebra do schema.

O problema dos objetos "printqueue" no AD

Os objetos printqueue, são criados quando temos alguma impressora instalada com a opção para publicação no Active Directory. Para cada impressora com esta configuração ativa irá gerar um objeto no Active Directory, além disso, caso o Active Directory não consiga entrar em contato com estes objetos depois depois de 8 horas, o objeto será excluído.

Se imaginarmos um cenário onde temos um parque de 500 desktops com 2 impressoras instaladas e a opção de publicação no Active Directory ativa, teremos a publicação de 1000 objetos, quando estes desktops forem desligado e o Active Directory não conseguir comunicação com estes objetos depois de 8h todos serão deletados, indo para tombstoned, porém ainda armazenados na base do AD. No dia seguinte os desktops voltam a ser ligados, criando novamente 1000 objetos printqueue, com isso a base já teria 2000 destes objetos (1000 ativos / 1000 tombstoned). Seguindo esta lógica no terceiro dia teremos 3000 objetos (1000 ativos / 2000 tombstoned), e assim por diante. O crescimento seria de 1000 objetos diariamente até a quantidade de dias estipulado para a limpeza dos objetos em tombstoned, que limpa os objetos mais antigos a 60 ou 180 dias dependendo da versão do schema.

Em nosso exemplo, vimos que podemos chegar a um incrível número de quase 200.000 objetos printqueue, isto causaria um aumento da base do Active Directory, maior número de replicação entre os Domain Controller do Domínio, etc. Para que estes objetos não sejam criados, basta implementar uma GPO nos computadores para que não seja permitido a publicação das impressoras no Active Directory.

A linguagem VBScript não suporta a consulta de objetos tombstoned através de seus métodos de consulta no AD (ADSI ou ADO), a melhor forma de consultar estes objetos é através do uso do utilitário Adfind.exe, que em apenas um utilitário fornece as funcionalidades do ldapsearch, search.vbs, ldp, dsquery e dsget. Este utilitário pode ser baixado através do endereço http://www.joeware.net/freetools/tools/adfind/index.htm.

Comando para contar os objetos printqueue do domínio. Retire a opção “-c” para obter os detalhes de cada objeto.

AdFind.exe -default -f "objectclass=printqueue" -c 

Comando para contar os objetos printqueue que estão em tombstone do domínio. Retire a opção “-c” para obter os detalhes de cada objeto.

AdFind.exe -default -rb "CN=Deleted Objects" -f "objectclass=printqueue" -showdel -c

 
Para que este problema seja resolvido, defina quais serão os computadores que devem evitar a publicação de impressoras no Active Directory. Na GPO, habilite a opção de “Disable” do template Computer Configuration > Administrative Templates > Printers > Allow printers to be published.

Como Localizar e Obter Informações sobre o Administrador do Domínio

Alguns administradores de rede, tem como prática renomear o usuário Administrador do domínio com o intuito de aumentar a segurança contra ataques. Porém é uma falsa impressão de segurança já que é possível localizar o Administrador do domínio mesmo que ele tenha sido renomeado ou movido entre as OUs do domínio. Como isto é possível? veremos a seguir.

Quando um objeto é criado no Active Directory é atribuído a este objeto um identificador único chamado de SID (Security Identifier), mesmo renomeado ou movendo o objeto o SID é preservado. Como o usuário Administrador do domínio é o primeiro usuário a ser criado no momento em que o servidor é promovido a Domain Controller, ele sempre irá ter o SID terminando em 500. Há um artigo da Microsoft descrito abaixo com maiores detalhes sobre a atribuição do SID.

Customizamos um script VBScript capaz de consultar os SIDs dos usuários do domínio e identificar o usuário que possui o SID terminando com 500 (o Administrador do domínio), retornando informações como seu nome, logon, caminho LDAP e se a conta está habilitada ou não. Como estamos trabalhando apenas com consulta LDAP não é necessário ser membro de um grupo com permissões de segurança especificas para obter o retorno, basta ter uma conta com o acesso mais simples no domínio (Domain Users).

Well-known security identifiers in Windows operating systems

http://support.microsoft.com/kb/243330

Salve o script abaixo como AD_GetAdmin.vbs e execute.

'******************************************************

'* Autor: Maikon Demacq

'* Versão: 1.0
'* Última Modificação: 14/09/2010
'*
'* Este script contempla:
'* Localiza o Administrador do Dominio e retorna
'* informações da conta
'*
'* Sintaxe:
'* Cscript AD_GetAdmin.vbs Parâmetros
'******************************************************
On Error Resume Next

Main

Sub Main
Const ADS_UF_ACCOUNTDISABLE = 2
Set objRootDSE = GetObject("LDAP://RootDSE")
strDNSDomain = objRootDSE.Get("defaultNamingContext")
Set adoCommand = CreateObject("ADODB.Command")
Set adoConnection = CreateObject("ADODB.Connection")
adoConnection.Provider = "ADsDSOObject"
adoConnection.Open "Active Directory Provider"
adoCommand.ActiveConnection = adoConnection
strBase = "<LDAP://" & strDNSDomain & ">"
strFilter = "(objectCategory=user)"
strAttributes = "distinguishedName,cn,sAMAccountName,userAccountControl,objectSID"
strQuery = strBase & ";" & strFilter & ";" & strAttributes & ";subtree"
adoCommand.CommandText = strQuery
adoCommand.Properties("Page Size") = 100
adoCommand.Properties("Timeout") = 30
adoCommand.Properties("Cache Results") = False
Set adoRecordset = adoCommand.Execute
Do Until adoRecordset.EOF
  strHexSid = OctetToHexStr(adoRecordset.Fields("objectSid").Value)
  strDecSid = HexStrToDecStr(strHexSid)
  If Right(strDecSid,4) = "-500" Then
    strUAC = adoRecordset.Fields("userAccountControl").Value
    If strUAC AND ADS_UF_ACCOUNTDISABLE Then
      strACC = "Disable"
    Else
      strACC = "Enable"
    End If
    strCN = adoRecordset.Fields("cn").Value
    strSAM = adoRecordset.Fields("sAMAccountName").Value
    strDN = adoRecordset.Fields("distinguishedName").value
    Wscript.Echo "User Account: " & strCN & vbcrlf & "Logon Account: " & strSAM & vbcrlf & "Account Status: " & strACC & vbcrlf & "DN: " & strDN & vbcrlf & "SID: " & strDecSid
    strFlag = 1
  End If
  If strFlag = 1 Then
    Wscript.Quit(0)
  End If
  adoRecordset.MoveNext
Loop
adoRecordset.Close
adoConnection.Close
End Sub

Function OctetToHexStr(arrbytOctet)
  Dim k
  OctetToHexStr = ""
  For k = 1 To Lenb(arrbytOctet)
    OctetToHexStr = OctetToHexStr & Right("0" & Hex(Ascb(Midb(arrbytOctet, k, 1))), 2)
  Next
End Function

Function HexStrToDecStr(strSid)
  Dim arrbytSid, lngTemp, j
  ReDim arrbytSid(Len(strSid)/2 - 1)
  For j = 0 To UBound(arrbytSid)
    arrbytSid(j) = CInt("&H" & Mid(strSid, 2*j + 1, 2))
  Next
  HexStrToDecStr = "S-" & arrbytSid(0) & "-" & arrbytSid(1) & "-" & arrbytSid(8)
  lngTemp = arrbytSid(15)
  lngTemp = lngTemp * 256 + arrbytSid(14)
  lngTemp = lngTemp * 256 + arrbytSid(13)
  lngTemp = lngTemp * 256 + arrbytSid(12)
  HexStrToDecStr = HexStrToDecStr & "-" & CStr(lngTemp)
  lngTemp = arrbytSid(19)
  lngTemp = lngTemp * 256 + arrbytSid(18)
  lngTemp = lngTemp * 256 + arrbytSid(17)
  lngTemp = lngTemp * 256 + arrbytSid(16)
  HexStrToDecStr = HexStrToDecStr & "-" & CStr(lngTemp)
  lngTemp = arrbytSid(23)
  lngTemp = lngTemp * 256 + arrbytSid(22)
  lngTemp = lngTemp * 256 + arrbytSid(21)
  lngTemp = lngTemp * 256 + arrbytSid(20)
  HexStrToDecStr = HexStrToDecStr & "-" & CStr(lngTemp)
  lngTemp = arrbytSid(25)
  lngTemp = lngTemp * 256 + arrbytSid(24)
  HexStrToDecStr = HexStrToDecStr & "-" & CStr(lngTemp)
End Function

Usando o Terminal Service para acessar o DC em DSRM

Nos Domain Controller que utilizam o Windows 2000 ou 2003 o AD é iniciado junto ao Sistema Operacional, por este motivo algumas tarefas administrativas necessitam ser executadas em um modo que o AD não tenha iniciado junto ao SO, este modo se chama Directory Service Restore Mode (DSRM), que pode ser acessado quando o servidor está sendo iniciado pressionando F8, em seguida selecionando a opção DSRM.

O Problema neste caso ocorre quando não se tem acesso a console do servidor, ou seja, o administrador tem acesso apenas pelo Remote Desktop ou outra ferramenta de acesso remota que só é inicializada junto ao SO, não permitindo o acesso ao menu para seleção do DSRM.

O Terminal Service pode ser utilizado para acessar o Domain Controller em Directory Service Restore Mode (DSRM), desta forma algumas tarefas de manutenção poderão ser efetuada remotamente.

1. Configure o Terminal Service para permitir o acesso remoto, em System Properties > Remote (aba) > Enable Remote Desktop on this computer.

2. Edite o arquivo do Boot.ini, criando uma nova string na primeira linha após "[operating systems]" igual a linha já existente e acrescentando no final o parâmetro "/SAFEBOOT:DSREPAIR", conforme exemplo abaixo:

[boot loader]

timeout=30

default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS

[operating systems]

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003 Standard Edition" /fastdetect /SAFEBOOT:DSREPAIR

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003 Standard Edition" /fastdetect

3. Reinicie o Domain Controller para acessar o DSRM.

4. Ao termino da manutenção para voltar a acessar o modo normal, remova a linha inserida no arquivo de Boot.ini e reinicie o Servidor.

Referência: http://support.microsoft.com/kb/256588