Serialização e de-serialização genéricas de classes em C#

Olá pessoas!

Depois de alguns meses sem postar nada (envolvido com o Projeto Ingrid), estou de volta com um post bem diferente do habitual: programação em C#.

Nesses últimos meses estive estudando a linguagem e já aprendi (e ainda estou aprendendo) muita coisa interessante. Quis compartilhar um pouco deste aprendizado trazendo um recurso prático para quem desenvolve em .NET e trabalha com serialização de classe.

Para quem já desenvolve em .NET sabe que serialização de classe nada mais é do que salvar uma instância de uma classe em um arquivo físico para que, posteriormente, a classe possa ser recarregada e continuar de onde parou (de-serialização).

O processo de serialização é super tranquilo, pois já trabalha com um código genérico. Veja um método de exemplo:

using System.IO;
using System.Serialization.Formatters.Binary;

public static bool SaveClass(object obj, string fileName)
{
   try
   {
      using (Stream output = File.Create(fileName))
      {
         BinaryFormatter formatter = new BinaryFormatter();
         formatter.Serialize(output, obj);
      }
      return true;
   }
   catch
   {
      return false;
   }
}

No exemplo acima, qualquer classe pode usar este método para a serialização. Basta informar a classe no parâmetro obj. Outro detalhe é que criei o método como estático. Dessa forma, eu posso colocá-lo dentro de uma classe estática de funções e evitar ficar instanciando-a toda vez que precisar serializar.

A sintaxe para utilizá-lo é:

SaveClass(myClassInstance, "c:\myClassInstance.dat");


Já o processo de de-serialização é que a coisa pega.... Veja o exemplo:

using System.IO;
using System.Serialization.Formatters.Binary;

public static myClass LoadClass(string fileName)
{
   try
   {
      using (Stream input = File.OpenRead(fileName))
      {
         myClass obj;
         BinaryFormatter formatter = new BinaryFormatter();
         obj = (myClass)formatter.Deserialize(input);
         return obj;

      }
   }
   catch
   {
      return null;
   }
}

Como podem ver, a de-serialização exige o tipo da classe (myClass) em seu código. Por causa disso, o método de de-serialização precisaria ser criado para cada classe que utilizar este recurso, mudando o tipo da classe na declaração. O código, além de ficar muito repetitivo, seria muito trabalhoso de se manter.

Se houvesse uma forma de passar o tipo da classe como parâmetro, poderíamos utilizar um método mais genérico, assim como na serialização......... Mas calma... Olhem o título do post... Esta forma existe:

using System.IO;
using System.Serialization.Formatters.Binary;

public static T LoadClass< T >(string fileName)
      where T : class
{
   try
   {
      using (Stream input = File.OpenRead(fileName)
      {
         T obj;
         BinaryFormatter formatter = new BinaryFormatter();
         obj = (T)formatter.Deserialize(input);
         return obj;
      }
   }
   catch
   {
      return null;
   }
}

Agora sim, podemos utilizar o método com qualquer classe serializada.

A sintaxe para utilizá-lo é:

myClassInstance = LoadClass< myClass >("c:\myClassInstalce.dat");



Espero que tenham gostado do meu primeiro post de Dev.
Até a próxima!

Atendimento técnico sem precisar fazer logoff

Cenário: O funcionário de um setor X faz uma ligação para o HelpDesk solictando uma manutenção local no seu computador. Um Técnico de TI é enviado ao local para verificar o equipamento e, para realizar o atendimento, precisa efetuar logoff do usuário atual para entrar com o seu usuário, pois o mesmo possui privilégios administrativos. Ocorre que o Técnico precisa fechar todos os programas que estão abertos, verificar junto ao funcionário se todos os arquivos foram salvos (senão salvar), para só então realizar o logoff. E se o funcionário disser: "-Não posso fechar esse programa agora". Você adia o atendimento?

Esse cenário é um caso de ficção científica ou você se identificou com ele? Creio que a grande maioria ainda utiliza esse procedimento. Alguns já utilizam o recurso do botão direito e "Executar como...", mas ainda sim existem algumas limitações. O que vou motrar a seguir é como realizar um atendimento local sem precisar "interromper" o que o usuário estava fazendo:

Prompt em modo elevado
Esse é o ponto de partida do atendimento local. Iremos abrir um Prompt de Comando com privilégios adminitrativos e a partir dele, podemos realizar toda e qualquer atividade do atendimento. Recurso muito poderoso e prático. Abra a janela executar o digite o seguinte comando:
runas /u:[domínio\usuário] cmd.exe
Onde [domínio\usuário] é o usuário de rede com privilégios administrativos. Ao teclar ENTER, uma janela será aberta solicitando a senha da conta informada. Após validar a senha, uma janela do Prompt de Comando será aberta. Verifique o título da janela. Será algo parecido com "cmd (sendo executado como [domínio\usuário])". A partir daqui, podemos realizar o atendimento.

- Caso queira acertar a hora e/ou a data do computador, basta digitar: control timedate.cpl
- Caso queira desinstalar um programa, basta digitar: control appwiz.cpl
- Caso queira abrir o Windows Explorer, basta digitar: explorer
- Caso queira abrir o Windows Explorer na pasta atual, basta digitar start..

... E por aí vai.

Após encerrar o atendimento, basta fechar a janela do Prompt de Comando e deixar o funcionário trabalhar normalmente.

Espero que tenham gostado da dica.

Abrindo o Prompt de Comando em uma pasta selecionada no Windows Explorer

Recurso muito útil para quem trabalha com o Prompt de Comando e acha um pé no saco ficar digitando nomes extensos de pastas do Windows (apesar de já existir o recurso "auto-completar" com o TAB). Não seria muito mais simples navegar pelo Windows Explorer até a pasta desejada, clicar com o botão direito do mouse, escolher a opção "Prompt de Comando", e abrir o prompt já naquela pasta? Mas se você prefere digitar coisas como:
cd \Arquivos de Programas\Microsoft SQL Server\100\MSSQL10_50.SQLEXPRESS\Backup...
bem...é o gosto da pessoa...

Existem várias formas de se implementar este recurso: Manualmente ou através de utilitários. Vou mostrar uma das formas manuais, que acho a mais simples e direta.

1 - Abra o registro e navegue até a chave HKEY_LOCAL_MACHINE\Software\Classes\Folder\Shell

2 - Crie uma nova chave com o nome "Prompt de Comando" sem as aspas.

3 - Crie uma sub-chave com o nome "command", novamente sem as aspas.

4 - Defina o valor padrão da chave command como cmd.exe /k pushd %1.

A alteração é imediata e não requer reinicialização do Windows. Abra o Windows Explorer e divirta-se.

Ajuste Fino do Active Directory - Parte 5

No post de hoje veremos sobre o Catálogo Global (Global Catalog ou GC) e, de quebra, uma palhinha sobre sua relação com  o Infrastructure Master que, dependendo da estrutura da rede, não é das melhores.

O Catálogo Global armazena algumas informações (ditas as mais comuns) de todos os domínios de uma floresta. Em um ambiente com mais de 1 domínio, seu uso é fundamental, pois agiliza o tempo de resposta de uma query de um domínio para o outro.

Por exemplo: um usuário do Domínio A está procurando por objetos no Domínio B. Como o Domínio A não contém nenhuma informação do Domínio B, o Domínio A repassa a query (forward) para o Domínio B. O Domínio B faz a pesquisa em sua base de dados e retorna a resposta ao Domínio A.

Este processo de ida e volta consome tempo e tráfego. E é exatamente aí que entra o Catálogo Global: Como ele armazena certas informações, tanto do Domínio A, quanto do Domínio B, na maioria dos casos a query não precisaria ser repassada e a resposta seria muito mais rápida.

Na prática, toda e qualquer pesquisa por objetos (usuários, computadores, etc.) no Active Directory é feita, primeiro, no Catálogo Global. É importante garantir a redundância deste serviço, ou seja, ter, pelo menos, 2 Controladores de Domínio atuando como Catálogos Globais.

Uma forma rápida de saber quais são os Catálogos Globais de um domínio é através da console do DNS. Expanda a Forward Lookup Zone do domínio e selecione o nodo _tcp. Os registros de nome _gc são seus Catálogos Globais.

Se seu domínio possuir 2 ou mais Controladores de Domínio e apenas 1 for o Catálogo Global, a adição de um Controlador de Domínio como Catálogo Global é feita através do Active Directory Sites and Services. Expanda o nodo do Site onde o Controlador de Domínio se encontra. Em sequida, expanda o nodo com o nome do Controlador de Domínio que será "promovido", clique com o botão direito sobre o nodo NTDS Settings e abra as propriedades. Marque a caixa "Global Catalog", confirme a alteração e aguarde a próxima replicação do Active Directory.

Temos agora 2 Catálogos Globais servindo ao domínio e garantimos maior disponibilidade do serviço. Se preferir, todos os Controladores de Domínio da rede podem ser Catálogos Globais. Vai do gosto do cliente e da estrutura da rede.

Parênteses para uma dica/experiência: Encontrei um caso em que ao pesquisar o nodo _tcp na console do DNS, dei falta de alguns registros não só _gc, mas também _ldap, _kpasswd e _kerberos. Para ser mais exato, um Controlador de Domínio não havia publicado seus serviços no DNS (por isso a ausência de seus registros). Confirmei que o referido Controlador de Domínio estava funcionando normalmente. Agora a pergunta: Como fazer para publicar os registros novamente?... Reiniciando o servidor?... Eh, resolveria, mas seria mais prático apenas reiniciar o serviço Netlogon do Controlador de Domínio:
net stop netlogon
net start netlogon
Para os mais curiosos, isso aconteceu porque o "Aging/Scavenging" do DNS estava configurado com um período que era inferior ao período que o Controlador de Domínio leva para atualizar seus registros junto ao DNS (Registration Refresh Interval), que por padrão é de 24 horas.

No início do post eu disse que falaria um pouco da relação entre o Catálogo Global e o Infrastructure Master. Mas o post vai ficar meio grande e, por isso, vou deixar esse assunto para um próximo.

Até lá.

Diário de um TI: Re-adicionando um computador no Domínio

Essa semana resolvemos ligar um computador que fica reservado para Eventos e Visitas que acontecem aqui na Empresa. Só que esse computador estava desligado já fazia um bom tempo e, ao tentar logar, apareceu a mensagem dizendo que a relação de confiança entre o Controlador de Domínio e aquele computador havia falhado.

Lembro-me de ter lido em um livro que isso ocorre quando um computador fica muito tempo sem se comunicar com o Controlador de Domínio (dããããã...). Mais precisamente, 30 dias, pois é o tempo padrão que cada computador leva para atualizar a senha de sua conta de rede. Lembro-me, também, que este mesmo livro dizia que em situações como esta, bastaria apenas resetar a conta do computador para reestabelecer a relação de confiança.

Abri o Active Directory Users and Computers no Controlador de Domínio, localizei a conta do computador, cliquei com o botão direito e selecionei a opção "Reset Account". Voltei no computador e tentei logar na rede.... Mesma mensagem de erro (como assim?!). Reiniciei o computador e tentei logar... mesma mensagem de erro (uadarréu?!).

Lembrei-me de ter lido em um site com questões técnicas, que há um comando que, também, reestabelece a relação de confiança. Ele está localizado nas ferramentas de suporte no CD de instalação do Windows. Instalei o pacote, fui para o prompt de comando e digitei o comando:

netdom trust nome_do_computador /domain:nome_do_domínio 

/usero:admin_local /passwordo:senha_local

Teclei [ENTER] e sabe qual foi o resultado?... A mesma mensagem de erro!!!

...
...
...

Depois de um cafezinho e uma conversa jogada fora no intervalo, voltei ao computador e contei até 10 antes de começar o próximo capítulo da novela. Tentei ao máximo não partir para o "método gambiarra", pois os procedimentos acima são "procedimentos oficiais". Mas não teve jeito, abri as propriedades do computador, fui até o campo onde estava o FQDN do domínio e modifiquei deixando apenas o nome Netbios. O computador solicitou uma conta de usuário que pudesse ingressar um computador na rede, coloquei minhas credenciais, o computador reiniciou e...... consegui logar!!!

Eh... Eu tive que reingressar o computador na rede. Os "procedimentos oficiais" não funcionaram. Pesquisei em vários sites e todos reclamavam do mesmo problema (ufa, não fui o único). Felizmente resolveu.

Mas que é feio, é!

Removendo Vírus Remotamente

Ter uma solução antivírus implantada e, principalmente, atualizada em um ambiente corporativo ajuda na proteção dos computadores conectados na rede. Mas, como nem tudo são flores, mesmo nestes cenários podem ocorrer casos de infecção, se um vírus recém saído do forno chegar na rede antes de sua vacina (é raro, mas acontece) e causar muita dor de cabeça (e horas extras noite afora...). Ter um antivírus desatualizado é a mesma coisa que não ter antivírus instalado.

Alguns vírus, uma vez infectado em um computador, conseguem inibir a ação do antivírus, chegando até a desativá-lo. Em outros casos, computadores infectados não permitem nem a instalação de uma solução antivírus caso o mesmo não possua uma.

Soluções antivírus corporativas utilizam um recurso comumente chamado de "Instalação Remota", onde através de uma Console Central de Gerenciamento, o Técnico de TI consegue disparar a instalação do antivírus em todos os computadores da rede sem precisar ir a cada um deles. Caso um computador se enquadre na situação de infecção descrita acima, o antivírus não será instalado.

Geralmente, é enviado um Técnico ao local e na grande maioria dos casos, o procedimento é: tirar o computador da rede (quando eu digo tirar o computador da rede é, literalmente, tirar o cabo de rede); executar a limpeza do computador com algum utilitário de limpeza específico; e só então voltar com o computador para a rede e tentar a instalação do antivírus novamente. Convenhamos que, além de trabalhoso, não é dinâmico. E dinamismo é o que mais se exige da TI nos dias de hoje. Nessas situações, entra em cena o lado Batman do Técnico de TI (por favor, quando digo Batman não quero que pensem no lado "morcego" do Técnico de TI. Técnico de TI não morcega... ¬¬). Quando digo o lado Batman, me refiro ao Cinto de Utilidades.

Todo Técnico de TI que se preze tem o seu kit de ferramentas e softwares que são indispensáveis em qualquer situação. Para o caso apresentado, vou utilizar 3 softwares: um software de varredura e limpeza, um log viewer e um software de acesso remoto.

1 - O Microsoft Windows Malicious Software Removal Tool ou MRT é um software de varredura e limpeza que reconhece e elimina os vírus mais comuns. Ele é o que chamamos de Standalone Sweeper, ou seja, um "varredor autônomo". Ele não precisa ser instalado, basta copiar para o computador e executar. O MRT pode ser encontrado em qualquer computador Windows que esteja configurado para receber atualizações automáticas e seu executável (mrt.exe) está localizado na pasta %WinDir%\System32. Toda segunda terça-feira do mês, a Microsoft libera uma atualização desta ferramenta. Caso não a possua, o download pode ser feito neste endereço: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=16

2 - O SMS Trace ou Trace32 é um log viewer muito conhecido entre os usuários do Configuration Manager. Ele permite a visualização de logs em tempo real, ou seja, assim que são feitos novos registros no arquivo de log, o SMS Trace os exibe automaticamente, sem que o usuário precise ficar fechando e abrindo o arquivo, como acontece com quem usa o Bloco de Notas, por exemplo. O SMS Trace é parte do System Center Configuration Manager 2007 Toolkit e pode ser encontrado neste endereço: http://www.microsoft.com/downloads/en/details.aspx?familyid=5A47B972-95D2-46B1-AB14-5D0CBCE54EB8&displaylang=en. Após a instalação, execute-o pelo menos uma vez para que os arquivos de log sejam associados a ele.

3 - O PsExec é um prompt de comando remoto muito simples é fácil de usar. Com ele é possível executar comandos e softwares remotamente em qualquer computador que você consiga se conectar. O PsExec não precisa ser instalado, basta executar. Ele pode ser encontrado no endereço: http://technet.microsoft.com/en-us/sysinternals/bb897553.

De posse dos softwares, vamos aos preparativos: Tenha o MRT mais recente em seu computador de trabalho. Instale o SMS Trace e associe-o aos arquivos .log. Copie o PsExec para a pasta %WinDir%\System32 do seu computador de trabalho.

(Hora de mostrar que você é o cara!!!) Abra um Prompt de Comando no seu computador de trabalho e dispare a execução do MRT no computador infectado através do comando:

psexec \\nome_do_computador -c mrt.exe /Q

- O parâmetro -c do PsExec faz com que o MRT seja copiado para o computador remoto antes de ser executado.

- O parâmetro /Q do MRT faz com que ele seja executado em modo silencioso, ou seja, o usuário que estiver trabalhando no computador no momento não será interrompido.

Abra a janela Executar e acesse a raiz da unidade C do computador remoto através do comando:

\\nome_do_computador\c$

Acesse a pasta do Windows e em seguida, acesse a pasta Debug. Procure pelo arquivo mrt.log e dê um duplo-clique para que ele seja aberto no SMS Trace e acompanhe toda a atividade do MRT em tempo real. Ao término, se o MRT pedir para reiniciar o computador para terminar a limpeza do sistema, você pode fazer isso, também remotamente, e informar ao usuário que estiver trabalhando no computador no momento sobre a reinicialização, através do comando:

shutdown -r -t 30 -m \\nome_do_computador -c "Foi encontrado um vírus em seu computador e será necessário reiniciá-lo para completar a remoção. Por favor, salve todos os seus documentos em aberto para evitar perda de dados. Seu computador será reiniciado em 30 segundos."

- O parâmetro -c do comando shutdown exibe uma mensagem customizada ao usuário conectado no computador remoto e pode ser definida ao seu gosto.

Após completar a limpeza, dispare novamente a Instalação Remota de sua solução antivírus e tudo deve ocorrer como deveria ter sido desde o início.

Para finalizar, algumas considerações: Não levantei questões como privilégios administrativos ou configuração de firewall, pois não eram o foco do Post. É óbvio que para executar estes procedimentos, o usuário precise ter privilégios administrativos e acessar remotamente o computador infectado. No meu entendimento, tais "requisitos" são básicos a qualquer Técnico de TI que trabalhe nesta área.

Espero que tenham gostado do Post. Até a próxima.

Encontrando o Conficker na rede

De vez em quando o "gente boa" do Conficker resolve fazer uma visitinha na rede da minha empresa. Felizmente, nossa solução antivírus consegue conter sua disseminação, mas às vezes (eu disse às vezes), aparece uma Estação de Trabalho sem o anvitírus instalado (ainda estou tentando entender isso).

E basta uma única máquina infectada com o Conficker na rede para começar o caos. Como disse anteriormente, a disseminação não ocorre porque o antivírus impede, mas a Estação de Trabalho infectada começa a tentar quebrar a senha dos usuários de rede por Força Bruta e, devido a política de senha, acaba travando as contas de usuário, o que gera um aumento nas ligações à Equipe de TI solicitando o destravamento das contas. Em resumo, não chega a ser uma m*rda completa, mas já é algo que enche o raio da paciência.

A grande dificuldade seria encontrar a máquina infectada, certo? Errado! Essa tarefa é bem simples: Basta acessar o log Security no Event Viewer de algum Controlador de Domínio, procurar nas "Failure Audit" (Event ID 680) qual é a Source Workstation que está forçando os logins.

No próximo post, vou dar uma dica de como remover o Conficker ou algum outro vírus de forma remota, ou seja, sem precisar ir até a Estação de Trabalho infectada.

Até lá.

Ajuste Fino do Active Directory - Parte 4

Nesta quarta parte iremos ajustar alguns detalhes do Domain Naming System ou DNS..... Mas peraí?! O título é sobre o Active Directory e não o DNS, o que um tem haver com o outro? Vejamos:

1 - Desde que o Serviço de Diretório da Microsoft passou a se chamar Active Directory, a tecnologia utilizada para localizar outros computadores ou recursos da rede, como: localização de Controladores de Domínio para autenticação ou Controladores de Domínio procurando por seus parceiros de replicação; é o DNS;

2 - A certificação MCTS 70-640 que é sobre Configuração do Active Directory exige conhecimento em DNS (Motivo mais que necessário para mim :P).

Pois bem, dúvidas esclarecidas, vamos ao que interessa. Quando utilizamos o DNS em modo integrado ao AD (Active Directory-Integrated Zones), temos um recurso chamado "Atualização Dinâmica" (Dynamic Update), que permite que o computador cliente registre e atualize seu endereço IP junto ao servidor de DNS. Acontece que caso este mesmo computador seja desativado, o seu registro permanecerá no Servidor de DNS por tempo indeterminado. Se ampliarmos essa situação para 100 computadores clientes, serão 100 registros desatualizados no Servidor de DNS.

Isso ocorre, porquê, por padrão, o Servidor de DNS não está configurado para "varrer e eliminar" registros antigos. E configurar este recurso é muito simples:

- Abra a console do DNS, clique com o botão direito do mouse sobre o nome do servidor e selecione a opção "Set Aging/Scavenging for All Zones..."

- Marque a opção "Scavenge stale resource records" e defina o período da varredura ou deixe os valores padrões.

- Clique no botão OK para salvar as alterações e é isto! Simples assim.

Se sua rede trabalha com muitas zonas e você não quer configurar este recurso para todas elas, basta, ao invés de clicar com o botão direito no nome do servidor, selecionar a zona deseja, clicar com o botão direito nela, selecionar a opção "Properties", clicar no botão "Aging" e configurar a varredura exclusivamente para a zona selecionada.

Por hoje é só. Espero que o post tenha lhe ajudado.

Ajuste Fino do Active Directory - Parte 3

Yo!

 Nesta terceira parte da série Ajuste Fino do Active Directory vou falar sobre a replicação do SYSVOL através do DFS-R.

Até o Windows Server 2003, a replicação do SYSVOL era realizada pelo File Replication Service ou FRS. A partir do Windows Server 2008, o Distributed File System Replication ou DFS-R passou a ser a nova tecnologia de replicação do SYSVOL.

Uma das grandes vantagens dessa tecnologia está no fato do DFS-R replicar apenas a parte de um determinado arquivo que fora alterado (delta) enquanto que o FRS replica o arquivo inteiro.

Quando realizamos a migração dos Controladores de Domínio do 2003 para o 2008, a replicação do SYSVOL não é automaticamente migrada do FRS para o DFS-R. Alguém sabe dizer o por quê? (Perguntinha de certificação Microsoft ^^)

Para que o SYSVOL possa ser replicado pelo DFS-R é necessário que o Nível Funcional do Domínio (Domain Functional Level) seja Windows Server 2008. Após essa alteração, o domínio estará pronto para iniciar o processo de migração.

A migração ocorre em 4 etapas e o tempo gasto varia de acordo com a quantidade de Controladores de Domínio presentes na rede e a distância entre eles (intra-sites e inter-sites). Vamos chamar essas "etapas" de "estados", ou seja, todos os Controladores de Domínio precisarão passar por 4 "estados" para concluir o processo de migração. Os estados vão de 0 (zero) a 3 (três) e são os seguintes:

• 0 = 'START'
• 1 = 'PREPARED'
• 2 = 'REDIRECTED'
• 3 = 'ELIMINATED'

Quando se sai de um estado para o outro, é necessário aguardar que todos os Controladores de Domínio estejam no mesmo estado. Entre os estados 0 e 2 é possível regressar ao estado anterior (do estado 2 voltar para o estado 0, por exemplo). Após a definição do estado 3, o processo não poderá mais ser desfeito.

A mudança do estado e o acompanhamento do processo é realizado via prompt de comando utilizando um único comando, o dfsrmig.exe. Abra o prompt de comando em modo elevado, de preferência no Controlador de Domínio que detém a FSMO de PDC Emulator e digite os seguintes comandos:

dfsrmig /setglobalstate [0-3]

dfsrmig /getglobalstate

O primeiro comando é responsável pela mudança do estado e o segundo mostra como anda a mudança do estado:

Após obter sucesso em um estado, basta partir para o próximo:

E o próximo:

E para finalizar:

That's it! A replicação do SYSVOL está agora sendo realizada pelo DFS-R.

Adeus FRS... foi bom (ou não) enquanto durou...

Ajuste Fino do Active Directory - Parte 2

Nesta segunda parte da série Ajuste Fino do Active Directory, vou falar um pouco sobre contas. Mais precisamente, sobre as Contas de Computador...

Normalmente, quando um novo funcionário é contratado por uma empresa, é procedimento padrão, criar sua Conta de Usuário para que o mesmo possa utilizar a rede. Mas, e quando um novo computador é comprado pela empresa, esse mesmo procedimento de "pré-criar" a sua conta é realizado? Na maioria dos casos a resposta é NÃO!

Geralmente, o cadastro da conta do novo computador é feita durante a etapa de instalação do sistema operacional, quando chegamos na janela onde selecionamos "Grupo de Trabalho" ou "Domínio". Essa prática pode deixar brechas na segurança da empresa, dependendo de como o Active Directory estiver estruturado. Calma lá... deixa eu explicar isso:

Na maioria das empresas, são criadas uma ou mais Unidades Organizacionais (OUs) e as Contas de Computadores são distribuídas ou organizadas entre elas. A essas OUs, são aplicadas Políticas de Grupo (GPOs) para restringir o que o usuário pode ou não fazer no computador. Quando a Conta do Computador é criada durante a instalação do sistema operacional, por padrão, ela é criada dentro do Contâiner Computadores (Computers), ou seja, FORA do escopo da GPO. Cabe então a alguém, responsável pela manutenção do Active Directory, mover a Conta do Computador para a respectiva OU e reiniciar o novo computador para que a GPO possa ser aplicada. Mas se levarmos em conta que o cara não vai ficar lá o dia inteiro no Contâiner Computadores apertando F5 na esperança de que surja um novo computador para ser movido, pode levar um tempo (horas ou dias) até que o novo computador receba a GPO. E esse tempinho é suficiente para os famosos "usuários espertos" detonarem a máquina que acabou de ser instalada. Para a alegria da Equipe de TI que adora formatar um computador... ¬¬

Mas então, como resolver esse impasse? Bom... existe mais de uma forma de resolver isso. Depende de como a empresa trabalha. Vou apresentar algumas alternativas:

- Ao invés de "linkar" a GPO na OU personalizada, "linke-a" na raiz do Domínio. Isso fará com que o escopo da GPO alcance todos os computadores do Domínio e não só aqueles dentro da OU. Empresas que possuem poucas GPOs podem utilizar essa alternativa, pois é a que gera menos trabalho. É igual Baterias Tudor: Você instala e esquece! (Piadinha tosca)

- Já empresas que possuem muitas GPOs podem ter um certo "desconforto" tendo inúmeras delas "linkadas" na raiz do Domínio, pois dá um pouco mais de trabalho à administração do Active Directory, como utilização de Filtragem de Segurança (Security Filtering) e a questão da Precedência das GPOs (mas isso é assunto para outro post). Nesses casos, o mais interessante seria mover (ou "redirecionar") o local padrão de armazenamento das Contas de Computador (Contâiner Computadores) para a OU personalizada. Ahm?! Tem como?! Claro que tem!!! Mas antes, um pequeno aviso: É preciso que o Nível Funcional do Domínio (Domain Functional Level) seja, pelo menos, Windows Server 2003 (creio que isso não seja um problema nos dias de hoje... ou é?! 0.o). Para fazer o redirecionamento, precisamos acessar o Prompt de Comando em modo elevado e utilizar o comando redircmp.exe. A sintaxe é bem simples:

redircmp <DN da OU personalizada>

Não entendeu? Deixa eu colocar mais açúcar no mamão então: Digamos que o domínio da sua empresa seja ABC.NET e que a OU personalizada seja "MeusComputadores". O comando ficaria assim:

redircmp ou=MeusComputadores,dc=ABC,dc=NET

Pronto! As novas Contas de Computador criadas durante a etapa de instalação do sistema operacional serão criadas automaticamente dentro dessa OU.

- A última alternativa, e a melhor de todas, dentro das "Boas Práticas do Grande Administrator do Active Directory" seria.... tcham tcham tcham tchaaaaaammmmm.... Pré-criar a Conta do Computador antes mesmo de iniciar a instalação do sistema operacional! A segunda alternativa, apesar de interessante, pode deixar falhas se a empresa utilizar mais de uma OU para organizar suas Contas de Computador, pois ainda sim, a Conta de Computador precisará ser movida (mas isso dentro de uma estrutura mais organizada de OUs e GPOs). Então, já que em todo caso a Conta de Computador precisará ser movida, porque não já criá-la na OU em que deverá ficar? Pelo menos, assim, o computador já ingressa na rede recebendo as GPOs que deveria. É menos dor de cabeça para você e menos falação do seu Gerente de TI (sacanagem).

Bom... deixa eu ir ali porque apareceram novos computadores no Contâiner Computadores. ^^

Partição de Aplicação do Active Directory

Quando a Microsoft lançou o Windows 2000 Server e seu novo serviço de diretório, o Active Directory, uma das grandes novidades foi a possibilidade de integrar o serviço de DNS ao serviço do Active Directory. Essa integração ficou conhecida como Active Directory-Integrated Zone.

Essa foi uma grande sacada pois:

• As informações de Zonas que antes eram armazenadas em arquivos, passaram a ser armazenadas dentro do Active Directory (mais especificamente, na partição de Domínio), o que garantiu maior segurança, pois não haviam mais arquivos físicos .dns;
• Todo Controlador de Domínio passou a ter uma cópia da Zona, utilizando o recurso de replicação do Active Directory (multimaster replication), o que garantiu maior redundância das informações;
• A estrutura Master/Slave onde apenas um servidor DNS podia gravar e os demais apenas lerem deixou de existir, pois todo Controlador de Domínio que tinha o serviço de DNS instalado podia gravar dados na Zona, o que garantiu a alta disponibilidade do serviço.

Mas como nem tudo são flores, essa integração trouxe um "pequeno" problema...

Em determinadas empresas, nem todo Controlador de Domínio é, também, um servidor DNS. Digamos, por exemplo, que uma empresa possui 5 Controladores de Domínio, mas apenas 2 são servidores DNS. O que será que vai acontecer???...

Todos os 5 Controladores de Domínio irão receber uma cópia das informações de DNS. Agora eu lhes pergunto, por quê? (Perguntinha de Certificação Microsoft ^^)

Como dito acima, o Active Directory-Integrated Zone era armazenado na partição de Domínio do Active Directory (Domain Naming Context). Por definição, o escopo de replicação desta partição é: para todos os Controladores de Domínio do domínio. Tem como alterar isso? Não! Os outros 3 Controladores de Domínio que não são servidores DNS recebem "lixo". É um tráfego desnecessário.

Vamos levar este mesmo exemplo para um ambiente maior: uma multinacional com 100 Controladores de Domínio espalhados pelo mundo inteiro, mas apenas 20 deles são servidores DNS. São 80 servidores trafegando "lixo" pelo mundo inteiro.

Com a vinda do Windows Server 2003, surgiu um novo tipo de partição para o Active Directory: a Partição de Aplicação (Application Partition). A grande vantagem dessa partição foi a possibilidade de se definir, justamente, o escopo da replicação. Com isso foi possível eliminar o "lixo" que trafegava na rede e a replicação de informações de DNS passou a ser feita apenas entre Controladores de Domínio com o serviço de DNS instalado.

Mas atenção!!! Se você migrou sua rede do 2000 para o 2003 e se enquadra no exemplo deste post. Terá que fazer a movimentação do DNS para a Partição de Aplicação manualmente. Se sua rede começou do 2003, seu DNS já está configurado na Partição de Aplicação.

'Til next time!

Ajuste Fino do Active Directory - Parte 1

Back from the ashes para uma série de posts contendo dicas para ajustar algumas configurações do Active Directory e tapar alguns buracos negros. E para abrir com chave de ouro vamos começar tapando um buraco negro chamado ms-DS-MachineAccountQuota.

Vocês sabiam que, POR PADRÃO, o Active Directory permite que QUALQUER usuário ingresse até 10 computadores em um domínio? Pode arregalar mesmo os olhos e se perguntar: "Pra que isso?". Onde fica a segurança da empresa quando um usuário, que não é da área de TI, consegue ingressar o seu notebook na rede da empresa sem prévia notificação ou autorização? Ah... e isso existe desde o Windows 2000 Server.

Agora você, meu amigo Administrador de Rede, sabia disso? Não, então vamos tapar o buraco!

Precisaremos do ADSI Edit para realizar a alteração.

Para quem ainda utiliza o Windows Server 2003, o ADSI Edit está nas Ferramentas de Suporte (Support Tools) no CD de instalação do Windows Server 2003. Após a instalação, abra o menu Iniciar->Executar e digite adsiedit.msc. No Windows Server 2008, o ADSI Edit se encontra nas Ferramentas Administrativas.

• Conecte-se na partição do domínio (well known Naming Context -> Domain).
• Expanda a partição e selecione a pasta "dc=seudominio,dc=com".
• Clique com o botão direito e vá nas Propriedades da pasta.
• Na guia Editor de Atributos (Attribute Editor) localize a opção ms-DS-MachineAccountQuota e mude o valor de 10 para 0.
• Confirme as alterações e tcharam!!!... buraco tapado.

Até a próxima!