Administração de contas no domínio Active Directory. Gerenciando o Active Directory com o Windows PowerShell
Em 2002, andando pelo corredor do departamento de informática da minha universidade favorita, vi um cartaz fresquinho na porta do escritório da NT Systems. O pôster mostrava ícones de contas de usuários agrupados em grupos, dos quais, por sua vez, as setas iam para outros ícones. Tudo isso foi esquematicamente combinado em uma determinada estrutura, algo foi escrito sobre um único sistema de entrada, autorização e assim por diante. Tanto quanto eu entendo agora, aquele pôster mostrava a arquitetura dos sistemas Windows NT 4.0 Domains e Windows 2000 Active Directory. A partir desse momento, meu primeiro contato com o Active Directory começou e terminou imediatamente, porque então houve uma sessão difícil, férias divertidas, após as quais um amigo compartilhou discos FreeBSD 4 e Red Hat Linux, e nos anos seguintes mergulhei em o mundo dos sistemas tipo Unix, mas nunca esqueci o conteúdo do pôster.
Tive que voltar e me familiarizar mais com os sistemas Windows Server quando me mudei para trabalhar em uma empresa onde o gerenciamento de toda a infraestrutura de TI era baseado no Active Directory. Lembro que o administrador-chefe daquela empresa, em todas as reuniões, dizia algo sobre algum tipo de práticas recomendadas do Active Directory. Agora, após 8 anos de comunicação periódica com o Active Directory, entendo muito bem como esse sistema funciona e quais são as melhores práticas do Active Directory.
Como você provavelmente já adivinhou, falaremos sobre o Active Directory.
Quem estiver interessado neste tópico, seja bem-vindo ao cat.
Essas recomendações são válidas para sistemas clientes a partir do Windows 7 e superior, para domínios e florestas de nível Windows Server 2008/R2 e superior.
estandardização
O planejamento do Active Directory deve começar desenvolvendo seus próprios padrões para nomear objetos e sua localização no diretório. É necessário criar um documento no qual defina todos os padrões necessários. Claro, esta é uma recomendação bastante comum para profissionais de TI. O princípio “primeiro escrevemos a documentação e depois construímos um sistema com base nessa documentação” é muito bom, mas raramente é implementado na prática por vários motivos. Entre essas razões - simples preguiça humana ou falta de competência apropriada, as demais razões são derivadas das duas primeiras.
Eu recomendo - primeiro escreva a documentação, pense bem e só então prossiga com a instalação do primeiro controlador de domínio.
Por exemplo, darei uma seção do documento sobre os padrões para nomear objetos do Active Directory.
Nomenclatura de objetos.
- O nome dos grupos de usuários deve começar com o prefixo GRUS_ (GR - Group, US - Users)
- O nome dos grupos de computadores não deve começar com o prefixo GRCP_ (GR - Grupo, CP - Computadores)
- O nome dos grupos de delegação deve começar com o prefixo GRDL_ (GR - Grupo, DL - Delegação)
- O nome dos grupos de acesso a recursos deve começar com o prefixo GRRS_ (GR - Grupo, RS - recursos)
- O nome dos grupos para as políticas deve começar com os prefixos GPUS_, GPCP_ (GP - Group policy, US - Users, CP - Computers)
- O nome dos computadores clientes deve consistir em duas ou três letras do nome da organização, seguidas de um número por meio de um hífen, por exemplo, nnt-01.
- Os nomes dos servidores devem começar com apenas duas letras, seguidas por um traço seguido pela função do servidor e o número do servidor, por exemplo, nn-dc01.
Sua abordagem para escrever a documentação deve ser muito completa, isso economizará muito tempo mais tarde.
Simplifique tudo o que for possível, tente alcançar o equilíbrio
Ao construir um Active Directory, você deve seguir o princípio de alcançar um equilíbrio, optando por mecanismos simples e compreensíveis.
O princípio do equilíbrio é conseguir a funcionalidade e segurança necessárias com a máxima simplicidade da solução.
É preciso tentar construir o sistema de forma que sua estrutura fique clara para o administrador mais inexperiente ou mesmo para o usuário. Por exemplo, houve uma recomendação para criar uma estrutura de floresta de vários domínios. Além disso, foi recomendado implantar não apenas estruturas de vários domínios, mas também estruturas de várias florestas. Talvez tal recomendação existisse por causa do princípio de "dividir e conquistar", ou porque a Microsoft disse a todos que o domínio é um limite de segurança e, ao dividir a organização em domínios, obteremos estruturas separadas mais fáceis de controlar individualmente. Mas, como a prática tem mostrado, é mais fácil manter e controlar sistemas de domínio único, onde os limites de segurança são unidades organizacionais (OU), não domínios. Portanto, evite criar estruturas multidomínio complexas, é melhor agrupar objetos por OU.
Claro, você deve agir sem fanatismo - se você não pode ficar sem vários domínios, então você precisa criar vários domínios, também com florestas. O principal é que você entenda o que está fazendo e a que isso pode levar.
É importante entender que uma infraestrutura simples do Active Directory é mais fácil de administrar e controlar. Eu diria até que quanto mais simples, mais seguro.
Aplicar o princípio da simplificação. Tente alcançar o equilíbrio.
Siga o princípio - "objeto - grupo"
Comece a criar objetos do Active Directory criando um grupo para este objeto e já atribua os direitos necessários ao grupo. Vejamos um exemplo. Você precisa criar uma conta de administrador principal. Primeiro crie o grupo Head Admins e só depois crie a própria conta e adicione-a a este grupo. Atribua ao grupo Head Admins os direitos do administrador principal, por exemplo, adicionando-o ao grupo Domain Admins. Quase sempre acontece que depois de um tempo outro funcionário chega ao trabalho que precisa de direitos semelhantes e, em vez de delegar direitos a diferentes seções do Active Directory, será possível simplesmente adicioná-lo ao grupo necessário, para o qual o sistema já função definida e delegou a autoridade necessária.
Mais um exemplo. Você precisa delegar direitos à UO com usuários para o grupo de administradores do sistema. Não delegue direitos diretamente ao grupo de administradores, mas crie um grupo especial como GRDL_OUName_Operator_Accounts ao qual você atribui direitos. Em seguida, basta adicionar o grupo de administradores responsáveis ao grupo GRDL_OUName_Operator_Accounts. Definitivamente, em um futuro próximo, você precisará delegar direitos a esta UO a outro grupo de administradores. E, neste caso, você simplesmente adicionará o grupo de dados do administrador ao grupo de delegação GRDL_OUName_Operator_Accounts.
Eu proponho seguinte estrutura grupos.
- Grupos de usuários (GRUS_)
- Grupos de administradores (GRAD_)
- Grupos de delegação (GRDL_)
- Grupos de políticas (GRGP_)
- Grupos de servidores (GRSR_)
- Grupos de computadores cliente (GRCP_)
- Grupos de acesso a recursos compartilhados (GRRS_)
- Grupos de acesso à impressora (GRPR_)
Mantenha o equilíbrio, limite o número de funções para os grupos e lembre-se de que o nome do grupo deve, idealmente, descrever completamente sua função.
arquitetura OU.
A arquitetura de uma UO deve antes de tudo ser pensada do ponto de vista da segurança e da delegação de direitos a essa UO aos administradores do sistema. Não recomendo planejar a arquitetura da OU em termos de vincular políticas de grupo a elas (embora isso seja feito com mais frequência). Para alguns, minha recomendação parecerá um pouco estranha, mas não recomendo vincular políticas de grupo a uma unidade organizacional. Leia mais na seção Políticas de Grupo.
Administradores de OU
Recomendo alocar uma UO separada para contas e grupos administrativos, onde colocar as contas e grupos de todos os administradores e engenheiros de suporte técnico. O acesso a esta OU deve ser limitado a usuários comuns, e o gerenciamento dos objetos desta OU deve ser delegado apenas aos administradores principais.
OU Computadores
As OUs de computador são melhor planejadas em termos de geografia do computador e tipos de computador. Distribua computadores de diferentes localizações geográficas em diferentes OUs e, por sua vez, divida-os em computadores clientes e servidores. Os servidores podem ser divididos em Exchange, SQL e outros.
Usuários, direitos no Active Directory
As contas de usuário do Active Directory devem receber atenção especial. Conforme mencionado na seção sobre OUs, as contas de usuário devem ser agrupadas com base no princípio da delegação de autoridade a essas contas. Também é importante observar o princípio do menor privilégio - quanto menos direitos um usuário tiver no sistema, melhor. Eu recomendo que você coloque imediatamente o nível de privilégio do usuário no nome de sua conta. Uma conta para o trabalho diário deve consistir no sobrenome e nas iniciais do usuário em latim (por exemplo, IvanovIV ou IVivanov). Os campos obrigatórios são: Nome, Iniciais, Sobrenome, Nome de exibição (em russo), e-mail, celular, Cargo, Gerente.
As contas de administrador devem ser dos seguintes tipos:
- Com direitos de administrador para computadores de usuários, mas não para servidores. Deve consistir nas iniciais do proprietário seguidas pelo prefixo local (por exemplo, iivlocal)
- Com direitos para administrar servidores e Active Directory. Deve consistir apenas em iniciais (por exemplo, iiv).
Deixe-me explicar por que você deve separar as contas administrativas em administradores de servidor e administradores de computador cliente. Isso é necessário por motivos de segurança. Os administradores de computadores clientes terão o direito de instalar software nos computadores clientes. O que e por que o software será instalado, você nunca pode dizer com certeza. Portanto, não é seguro executar a instalação do programa com direitos de administrador de domínio; você pode comprometer todo o domínio. Você deve administrar os computadores clientes apenas com direitos de administrador local para esse computador. Isso impossibilitará uma série de ataques a contas de administradores de domínio, como "Pass The Hash". Além disso, os administradores de computadores cliente devem fechar a conexão dos Serviços de Terminal e a conexão de rede com o computador. Os computadores para suporte técnico e administradores devem ser colocados em uma VLAN separada para restringir o acesso a eles da rede de computadores clientes.
Concedendo direitos de administrador aos usuários
Se você precisar conceder direitos de administrador a um usuário, não coloque sua conta diária no grupo de administradores locais do computador em hipótese alguma. Uma conta para o trabalho diário deve ser sempre limitada em direitos. Crie uma conta administrativa separada do tipo namelocal para ela e adicione essa conta ao grupo de administradores locais usando a política, restringindo seu uso apenas no computador do usuário usando o direcionamento em nível de item. O usuário poderá usar esta conta usando o mecanismo Run AS.
Políticas de senha
Crie políticas de senha separadas para usuários e administradores usando uma política de senha refinada. É desejável que a senha do usuário tenha pelo menos 8 caracteres e seja alterada pelo menos trimestralmente. É desejável que os administradores alterem a senha a cada dois meses, e ela deve ter pelo menos 10 a 15 caracteres e atender aos requisitos de complexidade.
Composição de domínios e grupos locais. Mecanismo de grupos restritos
A composição de domínio e grupos locais em computadores de domínio deve ser controlada apenas no modo automático, usando o mecanismo de Grupos Restritos. Por que é necessário fazer isso apenas dessa maneira, explicarei com o exemplo a seguir. Normalmente, depois que o domínio do Active Directory é quebrado, os administradores se adicionam a grupos de domínio como administradores de domínio, administradores corporativos, adicionam engenheiros de suporte técnico aos grupos necessários e também distribuem outros usuários em grupos. No processo de administração deste domínio, o processo de emissão de direitos se repete muitas vezes e será extremamente difícil lembrar que ontem você adicionou temporariamente a contadora Nina Petrovna ao grupo de administradores 1C e que hoje precisa removê-la desse grupo. A situação será agravada se a empresa tiver vários administradores e cada um conceder de vez em quando direitos aos usuários em um estilo semelhante. Em um ano, será quase impossível descobrir quais direitos são atribuídos a quem. Portanto, a composição dos grupos deve ser controlada apenas pelas políticas de grupo, que vão colocar tudo em ordem a cada aplicação.
Composição de grupos integrados
Vale dizer que os grupos embutidos como Operadores de Conta, Operadores de Backup, Operadores de Criptografia, Convidados, Operadores de Impressão, Operadores de Servidor devem estar vazios, tanto no domínio quanto nos computadores clientes. Esses grupos são necessários principalmente para compatibilidade com versões anteriores com sistemas mais antigos, e os usuários desses grupos recebem muitos direitos no sistema, e ataques de escalonamento de privilégios tornam-se possíveis.
Contas de administrador local
Usando o mecanismo de Grupos Restritos, você deve bloquear contas de administradores locais em computadores locais, bloquear contas de convidados e limpar o grupo de administradores locais em computadores locais. Nunca use políticas de grupo para definir senhas para contas de administrador local. Este mecanismo não é seguro, a senha pode ser recuperada diretamente da política. Mas, se você decidir não bloquear contas de administrador local, use o mecanismo LAPS para definir senhas corretamente e girá-las. Infelizmente, a configuração do LAPS não é totalmente automatizada e, portanto, será necessário adicionar atributos manualmente ao esquema do Active Directory, conceder direitos a eles, atribuir grupos e assim por diante. Portanto, é mais fácil bloquear contas de administrador local.
Contas de serviço.
Para iniciar os serviços, use as contas de serviço e o mecanismo gMSA (disponível no Windows 2012 e sistemas superiores)
Políticas de grupo
Documente as políticas antes de criar/modificar.
Ao criar uma política, use o princípio "Política - grupo". Ou seja, antes de criar uma política, primeiro crie um grupo para esta política, remova o grupo Usuários autenticados do escopo da política e adicione o grupo criado. Vincule a política não a uma UO, mas à raiz do domínio e regule o escopo de sua aplicação adicionando objetos ao grupo de políticas. Considero tal mecanismo mais flexível e compreensível do que vincular uma política a uma UO. (Foi sobre isso que escrevi na seção OU Architecture).
Sempre ajuste o escopo da política. Se você criou uma política apenas para usuários, desative a estrutura do computador e vice-versa, desative a estrutura do usuário se tiver criado uma política apenas para computadores. Graças a essas configurações, as políticas serão aplicadas mais rapidamente.
Configure backups diários de políticas usando o Power Shell para que, em caso de erros de configuração, você sempre possa retornar as configurações originais.
Modelos de Loja Central (Loja Central)
A partir do Windows 2008, tornou-se possível armazenar modelos de Diretiva de Grupo ADMX em um armazenamento central, em SYSVOL. Antes disso, por padrão, todos os modelos de política eram armazenados localmente, nos clientes. Para colocar os modelos ADMX no armazenamento central, copie o conteúdo da pasta %SystemDrive%\Windows\PolicyDefinitions junto com subpastas de sistemas cliente (Windows 7/8/8.1) para %SystemDrive%\Windows\SYSVOL\domain do controlador de domínio Diretório \Policies\PolicyDefinitions com mesclagem de conteúdo, mas sem substituição. Em seguida, você deve fazer a mesma cópia com sistemas de servidor, começando pelo mais antigo. Por fim, ao copiar pastas e arquivos da versão mais recente do servidor, faça uma cópia Mesclar e SUBSTITUIR.
Copiando Modelos ADMX
Além disso, os modelos ADMX para quaisquer produtos de software, como Microsoft Office, produtos Adobe, produtos Google e outros, podem ser colocados no armazenamento central. Acesse o site do fornecedor do software, baixe o modelo ADMX da Diretiva de Grupo e extraia-o para a pasta %SystemDrive%\Windows\SYSVOL\domain\Policies\PolicyDefinitions em qualquer um dos seus controladores de domínio. Agora você pode gerenciar o produto de software necessário por meio de políticas de grupo.
Filtros WMI
Os filtros WMI não são muito rápidos, então a segmentação em nível de item é preferível. Mas se a segmentação no nível do item não puder ser usada e você decidir usar o WMI, recomendo que crie imediatamente vários dos filtros mais comuns para você: o filtro "Somente sistemas operacionais de cliente", "Somente sistemas operacionais de servidor", filtros “Windows 7”, filtros “Windows 8”, “Windows 8.1”, “Windows 10”. Se você tiver conjuntos prontos de filtros WMI, será mais fácil aplicar filtro desejadoà política desejada.
Auditoria de eventos do Active Directory
Certifique-se de habilitar a auditoria de eventos em controladores de domínio e outros servidores. Eu recomendo habilitar a auditoria dos seguintes objetos:
- Auditoria de gerenciamento de contas de computador - sucesso, falha
- Auditar outros eventos de gerenciamento de contas - sucesso, falha
- Gerenciamento de grupo de segurança de auditoria - sucesso, falha
- Gerenciamento de conta de usuário de auditoria - sucesso, falha
- Auditoria do serviço de autenticação Kerberos - Falha
- Auditar outros eventos de logon de conta - Falha
- Auditoria Alteração da Política de Auditoria - Sucesso, Falha
Configurações avançadas de auditoria
Não vou me alongar sobre as configurações de auditoria em detalhes, pois existem suficiente artigos sobre este tema. Acrescentarei apenas que, além de habilitar a auditoria, você deve configurar alertas de e-mail sobre eventos críticos de segurança. Também vale a pena considerar que em sistemas com grande número de eventos, vale a pena dedicar servidores separados para coleta e análise de arquivos de log.
Scripts de administração e limpeza
Todas as ações do mesmo tipo e frequentemente repetidas devem ser executadas usando scripts de administração. Entre essas ações: criar contas de usuário, criar contas de administrador, criar grupos, criar OUs e assim por diante. Objetos de script permitem que você honre sua lógica de nomenclatura de objetos do Active Directory criando verificações de sintaxe diretamente em seus scripts.
Também vale a pena escrever scripts de limpeza que controlarão automaticamente a composição dos grupos, identificarão usuários e computadores que não estão conectados ao domínio há muito tempo, detectarão violações de seus outros padrões e assim por diante.
Não considero uma recomendação oficial explícita o uso de scripts de administração para monitorar a conformidade com os padrões e realizar operações em segundo plano. Mas eu mesmo prefiro verificações e procedimentos no modo automático usando scripts, pois isso economiza muito tempo e elimina um grande número erros e, claro, minha abordagem levemente Unix para administração afeta aqui, quando é mais fácil digitar alguns comandos do que clicar nas janelas com o mouse.
Administração manual
Parte das operações de administração que você e seus colegas precisarão fazer manualmente. Para esses fins, recomendo usar o console mmc com snap-ins adicionados a ele.
Como será discutido mais adiante, seus controladores de domínio devem operar no modo Server Core, ou seja, a administração de todo o ambiente do AD deve ser realizada apenas de seu computador usando consoles. Para administrar o Active Directory, você precisa instalar as Ferramentas de Administração de Servidor Remoto em seu computador. Os consoles devem ser executados em seu computador como um usuário com direitos de administrador do Active Directory para quem o controle foi delegado.
A arte de gerenciar o Active Directory usando consoles requer um artigo separado e talvez até mesmo um vídeo de treinamento separado, então aqui estou apenas falando sobre o próprio princípio.
controladores de domínio
Em qualquer domínio, deve haver pelo menos dois controladores. Os controladores de domínio devem ter o mínimo de serviços possível. Você não deve criar um servidor de arquivos a partir de um controlador de domínio ou, Deus me livre, aumentar a função de um servidor de terminal nele. Execute sistemas operacionais Server Core em controladores de domínio removendo completamente o suporte WoW64, isso reduzirá significativamente o número de atualizações necessárias e aumentará sua segurança.
Anteriormente, a Microsoft desencorajava a virtualização de controladores de domínio devido ao fato de que, ao restaurar de instantâneos, eram possíveis conflitos de replicação difíceis de resolver. Pode ter havido outras razões, não posso dizer com certeza. Agora, os hipervisores aprenderam a dizer aos controladores para restaurá-los a partir de instantâneos e esse problema desapareceu. Virtualizei controladores o tempo todo, sem tirar nenhum instantâneo, porque não entendo por que pode ser necessário fazer isso em controladores de domínio. Na minha opinião, é mais fácil fazer backup de um controlador de domínio usando ferramentas padrão. Portanto, recomendo virtualizar todos os controladores de domínio possíveis. Esta configuração será mais flexível. Ao virtualizar controladores de domínio, coloque-os em diferentes hosts físicos.
Se você precisar colocar um controlador de domínio em um ambiente físico não seguro ou em uma filial de sua organização, use um RODC para essa finalidade.
Funções FSMO, controladores primários e secundários
As funções FSMO do controlador de domínio continuam a incutir medo nas mentes dos administradores novatos. Freqüentemente, os novatos estudam o Active Directory usando documentação desatualizada ou ouvem histórias de outros administradores que leram algo em algum lugar.
Para todos os cinco + 1 papéis, o seguinte deve ser dito brevemente. A partir do Windows Server 2008, não há mais controladores de domínio primário e secundário. Todas as cinco funções de controlador de domínio são portáteis, mas não podem ser hospedadas em mais de um controlador de domínio ao mesmo tempo. Se pegarmos um dos controladores, que, por exemplo, era o proprietário de 4 funções e excluí-lo, podemos transferir facilmente todas essas funções para outros controladores, e nada de terrível acontecerá no domínio, nada quebrará. Isso é possível porque todas as informações sobre o trabalho associado a uma determinada função são armazenadas por seu proprietário diretamente no Active Directory. E se transferirmos a função para outro controlador, ele primeiro solicitará as informações armazenadas no Active Directory e começará a servir. Um domínio pode existir por muito tempo sem proprietários de função. A única "função" que deve estar sempre no Active Directory, e sem a qual tudo ficará muito ruim, é a função do catálogo global (GC), ela pode ser exercida por todos os controladores do domínio. Recomendo atribuir a função GC a cada controlador no domínio, quanto mais, melhor. Claro, você pode encontrar casos em que não deve instalar a função GC em um controlador de domínio. Bem, se você não precisa, então não precisa. Siga as recomendações sem fanatismo.
serviço DNS
O serviço DNS é crítico para a operação do Active Directory e deve funcionar sem problemas. O serviço DNS é melhor colocado em cada controlador de domínio e armazena zonas DNS no próprio Active Directory. Se você usar o Active Directory para armazenar zonas DNS, deverá configurar as propriedades da conexão TCP / IP nos controladores de domínio para que cada controlador tenha qualquer outro servidor DNS como servidor DNS primário e você possa definir o servidor DNS secundário endereço 127.0.0.1. Essa configuração é necessária porque, para o início normal do serviço Active Directory, é necessário um DNS em funcionamento e, para o DNS iniciar, o serviço Active Directory deve estar em execução, pois contém a própria zona DNS.
Certifique-se de configurar zonas de pesquisa reversa para todas as suas redes e ativar a atualização segura automática dos registros PTR.
Eu recomendo que você habilite adicionalmente a limpeza automática da zona de registros DNS obsoletos (eliminação de DNS).
Eu recomendo especificar servidores Yandex seguros como DNS-Forwarders se não houver outros mais rápidos em sua localização geográfica.
Sites e replicação
Muitos administradores tendem a pensar em sites como um agrupamento geográfico de computadores. Por exemplo, o site de Moscou, o site de São Petersburgo. Essa visão surgiu devido ao fato de que a divisão original do Active Directory em sites foi feita para equilibrar e separar o tráfego de rede de replicação. Os controladores de domínio em Moscou não precisam saber que dez contas de computador já foram criadas em São Petersburgo. E, portanto, essas informações sobre mudanças podem ser transmitidas uma vez por hora de acordo com a programação. Ou até replicar as alterações uma vez por dia e apenas à noite, para economizar largura de banda.
Sobre sites, eu diria o seguinte: sites são grupos lógicos de computadores. Computadores interconectados por uma boa conexão de rede. E os próprios sites são interligados por uma conexão com baixa largura de banda, o que é uma raridade em nossa época. Portanto, divido o Active Directory em sites não para equilibrar o tráfego de replicação, mas para equilibrar a carga da rede em geral e para processar mais rapidamente as solicitações de clientes dos computadores do site. Deixe-me explicar com um exemplo. Existe uma rede local de 100 megabits da organização, que é servida por dois controladores de domínio, e existe uma nuvem onde os servidores de aplicativos desta organização estão localizados com outros dois controladores de nuvem. Dividirei essa rede em dois locais para que os controladores na rede local processem solicitações de clientes da rede local e os controladores na nuvem processem solicitações de servidores de aplicativos. Além disso, isso separará as solicitações para os serviços DFS e Exchange. E como agora raramente vejo um canal de Internet com menos de 10 megabits por segundo, vou habilitar a Replicação Baseada em Notificação, isto é, quando os dados são replicados assim que houver alterações no Active Directory.
Conclusão
Esta manhã eu estava pensando sobre por que o egoísmo humano não é bem-vindo na sociedade e em algum lugar em um nível profundo de percepção causa emoções extremamente negativas. E a única resposta que me veio à cabeça é que a raça humana não teria sobrevivido neste planeta se não tivesse aprendido a compartilhar recursos físicos e intelectuais. É por isso que estou compartilhando este artigo com você e espero que minhas recomendações o ajudem a melhorar seus sistemas e você gaste muito menos tempo solucionando problemas. Tudo isso levará à liberação de mais tempo e energia para a criatividade. É muito mais agradável viver em um mundo de pessoas criativas e livres.
É bom se você compartilhar seus conhecimentos e práticas de construção de um Active Directory nos comentários, se possível.
Paz e bem a todos!
Você pode ajudar e transferir algum dinheiro para o desenvolvimento do site
17.03.2014 Darren Mar Elia
Quando Windows PowerShell acabou de aparecer, muitas pessoas começaram a perguntar se era possível gerenciar o Active Directory (AD) usando o PowerShell. Na época, a resposta da Microsoft não foi a que a maioria dos administradores gostaria de ouvir. O PowerShell tinha um "acelerador de tipo" integrado do Active Directory Service Interfaces (ADSI) para acessar objetos do AD, mas o usuário precisava descobrir como usar o PowerShell para executar tarefas de administração do AD por conta própria. Mudanças significativas ocorreram com o lançamento do Windows Server 2008 R2, que introduziu o módulo PowerShell para Active Directory. O módulo AD inclui um conjunto de comandos para gerenciar o AD, bem como um provedor de AD que permite navegar no AD como uma unidade simbólica. Neste artigo, mostrarei como instalar o módulo AD e descrever como ele funciona em detalhes.
Quando o Windows PowerShell foi lançado, muitas pessoas começaram a perguntar se o Active Directory (AD) poderia ser gerenciado usando o PowerShell. Na época, a resposta da Microsoft não foi a que a maioria dos administradores gostaria de ouvir. O PowerShell tinha um "acelerador de tipo" integrado do Active Directory Service Interfaces (ADSI) para acessar objetos do AD, mas o usuário precisava descobrir como usar o PowerShell para executar tarefas de administração do AD por conta própria. Algum tempo depois, a Quest Software forneceu um conjunto gratuito de comandos para tarefas administrativas do AD, incluindo criar, modificar e excluir objetos do AD e procurar objetos no AD. Por um longo período, o estado do gerenciamento do PowerShell e do AD foi assim.
Mudanças significativas ocorreram com o lançamento do Windows Server 2008 R2, que introduziu o módulo PowerShell para Active Directory. O módulo AD inclui um conjunto de comandos para gerenciar o AD, bem como um provedor de AD que permite navegar no AD como uma unidade simbólica. Neste artigo, mostrarei como instalar o módulo AD e descrever como ele funciona em detalhes.
Instalando o Módulo Active Directory
Ao contrário das ferramentas anteriores que usavam o LDAP para se comunicar com o AD, o módulo AD usa os protocolos Active Directory Web Services (ADWS) para se comunicar com um controlador de domínio (DC) do AD. Esses protocolos são detalhados no blog do MSDN "Active Directory Web Services Overview", mas basta dizer que os comandos do PowerShell no módulo AD e o Active Directory Administrative Center (ADAC) usam o ADWS para se comunicar e recuperar informações do AD.
Quando você instala controladores de domínio do Windows Server 2012 ou Server 2008 R2 em um domínio AD, o protocolo ADWS é instalado e iniciado por padrão em cada um deles. Se o seu domínio consistir inteiramente em controladores de domínio Windows Server 2008 ou Windows Server 2003, você deverá instalar o ADWS separadamente. A Microsoft fornece gratuitamente o pacote Active Directory Management Gateway Service para essa finalidade. Se você instalar o pacote em pelo menos um controlador de domínio AD Server 2008 ou Server 2003, poderá usar o módulo AD para PowerShell junto com o ADAC.
O próprio módulo AD é instalado por padrão em qualquer DC executando Server 2012 ou Server 2008 R2. Em computadores com Windows 8 e Windows 7 (ou qualquer computador que não seja um controlador de domínio executando o Server 2012 ou o Server 2008 R2), você deve instalar as ferramentas de administração de servidor remoto do Centro de download da Microsoft.
Independentemente de as Ferramentas de Administração de Servidor Remoto estarem instaladas no computador antecipadamente ou separadamente, a próxima etapa é abrir a seção Adicionar/Remover Programas no Painel de Controle e selecionar Ativar ou desativar recursos do Windows no menu à esquerda. Role a caixa de diálogo Recurso do Windows até a seção Ferramentas de administração do servidor remoto. Localize a caixa de seleção Active Directory Module for Windows PowerShell na pasta \Remote Server Administration Tools\Role Administration Tools\AD DS and AD LDS Tools folder, conforme mostrado na Figura 1. Marque a caixa de seleção e clique em OK para instalar o módulo.
Você deve ver o atalho do Active Directory Module para Windows PowerShell na seção Ferramentas administrativas do menu Iniciar. Clique neste atalho para iniciar o PowerShell com o módulo AD carregado. Se você já estiver usando o PowerShell e quiser apenas carregar um módulo para que ele fique disponível para uso, você pode digitar o seguinte comando para acessar os comandos AD e AD Provider:
ActiveDirectory do módulo de importação
Agora vamos ver como navegar no AD usando o AD Provider.
Usando o Provedor do Active Directory
O PowerShell implementa o conceito de unidades PowerShell, às quais me referirei simplesmente como unidades PS. Um termo simplificado para uma unidade PS é uma representação de um recurso, como um sistema de arquivos navegável composto de pastas e folhas. Nem todos os recursos podem ser representados dessa maneira, mas muitos (incluindo o AD e o registro) se encaixam bem nesse modelo. O módulo AD contém o provedor de disco PS AD. Conseqüentemente, você pode se mover e até alterar o AD como se fosse um sistema de arquivos.
Então, como você navega no AD usando o AD Provider? Ele assume que o PowerShell está aberto e o módulo AD está carregado. Nesse caso, o primeiro passo é executar o comando Set-Location, que possui diversos aliases, incluindo sl e cd:
Definir localização AD:
Este comando altera a posição de trabalho atual da unidade PS AD. Como resultado, o prompt do PowerShell mostrará AD:\ em vez de C:\. Em seguida, para ver os itens na unidade PS AD, você pode usar o comando Get-ChildItem com o alias dir:
Get-ChildItem
A tela 2 mostra um exemplo do resultado no meu computador.
Como podemos ver, o comando retorna uma lista de todas as partições de domínio disponíveis. A mais interessante, na minha opinião, é a seção de domínio chamada cpandl, que contém nomes de usuários e computadores. Para alterar este domínio, basta digitar o comando:
Set-Location "dc=cpandl,dc=com"
Observe que o comando Set-Location está usando o nome distinto (DN) do meu domínio AD. Isso é necessário para uma navegação correta. Depois de navegar para o diretório do domínio (conforme indicado pelo prompt AD:\dc=cpandl,dc=com no PowerShell), você pode usar o comando Get-ChildItem para ver a estrutura AD de nível superior (Figura 3).
.jpg) |
| Figura 3: Visualizando o nível superior da hierarquia do AD |
Se você quiser ver os usuários em uma unidade organizacional (OU) SDM, então, para navegar até esta OU, basta digitar:
Set-Location "OU=SDM"
A linha de comando do PowerShell se parecerá com AD:\ou=SDM,dc=cpandl,dc=com. Neste ponto, você pode usar o comando Get-ChildItem para ver todos os objetos de usuário nesta UO. Se eu quiser alterar a propriedade Description no objeto de usuário que representa minha conta de usuário Darren Mar-Elia. Existe uma equipe para isso! O comando Set-ItemProperty permite alterar uma propriedade em um objeto AD. Se você quiser alterar a descrição da conta do usuário para Chief Techie, execute o comando:
Set-ItemProperty -Path ".\CN=Darren Mar-Elia" ` -Name "Description" -Value "Chief Techie"
Como podemos ver, o parâmetro -Path é usado aqui para especificar minha conta de usuário no diretório atual. Também uso o parâmetro -Name para indicar que a propriedade Description deve ser alterada e o parâmetro -Value para indicar a descrição do Chief Techie.
Observe que, se você deseja localizar todos os objetos com um valor de propriedade específico, pode usar Get-ItemProperty. Se você deseja apenas obter uma referência a um objeto AD, use Get-Item.
Como você pode ver, trabalhar com o AD dessa maneira é bastante simples. O mecanismo dificilmente é adequado para alterações em massa, mas é conveniente para trabalhar com o AD como um sistema de arquivos. No entanto, descobri que a maioria dos administradores usa comandos em vez da unidade PS AD para gerenciar o AD. Vamos ver como alguns desses comandos funcionam.
Aplicando comandos do Active Directory
O módulo para AD que acompanha o Windows 7 contém 76 comandos para gerenciamento do AD. Eles podem ser usados para praticamente qualquer finalidade, incluindo procurar objetos do AD, criar e excluir objetos do AD e manipular informações sobre as configurações do AD (como modo de floresta e política de senha refinada). Os comandos geralmente são agrupados por verbos como Add-, Remove-, Get- e Set-. Observe que nem todo comando Get tem um comando Set correspondente e vice-versa, então às vezes é preciso algum esforço para encontrar o comando certo para uma tarefa. Por exemplo, você pode definir o nível de funcionalidade da floresta do AD usando Set-ADForestMode, mas para descobrir o nível de funcionalidade da floresta atual, você deve usar o comando Get-ADForest e examinar a propriedade ForestMode no objeto retornado.
Vejamos algumas tarefas comuns que podem ser executadas usando comandos do AD. Em particular, ele mostrará como adicionar contas de usuário, gerenciar membros de grupos, redefinir senhas de contas de usuários e pesquisar objetos AD.
Adicionando contas de usuário
O comando New-ADUser fornece uma maneira fácil de adicionar contas de usuário ao AD. Se você precisar adicionar uma nova conta de usuário chamada Bill Smith à UO SDM, no caso mais simples, poderá criar uma nova conta de usuário com o comando:
New-ADUser -Name "Bill Smith" -SamAccountName "bsmith" ` -GivenName "Bill" -Surname "Smith" ` -DisplayName "Bill Smith" -Path "OU=SDM,DC=cpandl,DC=com"
Este comando insere informações básicas da conta do usuário. Em particular, o parâmetro -SamAccountName é usado para fornecer o nome da conta SAM necessária para criar o objeto de usuário. O parâmetro -Path também é usado para informar ao comando onde colocar o objeto - em este caso para o SDM OU no domínio cpandl.com. Além disso, o nome do usuário (parâmetro -GivenName), sobrenome (parâmetro -Surname) e nome de exibição (parâmetro -DisplayName) são especificados.
A execução desse comando criará uma conta de usuário, mas há dois problemas. Primeiro, a conta será desativada. Em segundo lugar, a conta não terá uma senha associada a ela, o que é obrigatório na maioria dos domínios.
Para evitar ter que ativar a conta e atribuir uma senha separadamente, você pode modificar o comando New-ADUser. New-ADUser ativará automaticamente a conta se você especificar a opção -Enabled $true no comando. A ativação requer uma senha, então você também deve especificá-la no comando.
Você pode usar o parâmetro –AccountPassword para fornecer uma senha. No entanto, você não pode inserir a senha em texto simples na linha de comando. Esta opção requer que a senha seja inserida em uma string segura (isto é, do tipo de dados SecureString). Existem duas maneiras de converter a senha em uma string segura e, em ambos os casos, uma variável é usada.
O primeiro método usa o comando ConvertTo-SecureString, que converte strings de texto simples em strings seguras. Por exemplo, se você precisar alterar a senha [e-mail protegido] a uma string segura e atribua-a à variável $pwd, execute o comando:
$pwd = ConvertTo-SecureString -string" [e-mail protegido]» ` -AsPlainText –force
Este não é o método mais seguro de atribuir uma senha, pois alguém pode olhar por cima do seu ombro enquanto você digita o comando. Mais maneira confiável se o comando New-ADUser solicitar uma senha e ocultar os caracteres digitados. Isso pode ser feito usando o comando Read-Hostcmdlet com o parâmetro -AsSecureString:
$pwd = Read-Host -AsSecureString
Depois de executar este comando, você verá o conhecido símbolo “*” na tela ao inserir a senha. Quando terminar de inserir, pressione a tecla Enter.
Depois que a senha é armazenada na variável $pwd, você pode passá-la para o comando New-ADUser:
New-ADUser -Name"Bill Smith"-SamAccountName"bsmith"` -GivenName"Bill"-Surname"Smith"` -DisplayName"Bill Smith"` -Path"OU=SDM,DC=cpandl,DC=com"` - Habilitado $true -AccountPassword $pwd
Como podemos ver, o comando contém as opções -Enabled e -AccountPassword, que habilitam a conta e atribuem uma senha a ela com segurança.
Criar contas de usuário uma de cada vez é uma maneira simples, mas às vezes você precisa criar várias contas ao mesmo tempo. O PowerShell é ótimo para essa finalidade. Por exemplo, se você precisar criar três contas de usuário, poderá preparar um arquivo de valores separados por vírgula (CSV) que contenha informações da conta e, em seguida, usar o comando Import-CSV para passar essas informações para New-ADUser.
A Figura 4 mostra um arquivo CSV denominado userlist.csv.
Observe que neste arquivo, os cabeçalhos das colunas correspondem aos nomes dos parâmetros fornecidos no comando New-ADUser anterior. É feito de propósito. Quando os dados CSV forem passados para New-ADUser, o comando selecionará esses nomes de parâmetro do pipeline do PowerShell e não precisará ser especificado no próprio comando. Aqui está o comando usado para criar três contas de usuário:
Import-CSV -Path C:\data\userlist.csv | New-ADUser -Enabled $true -AccountPassword $pwd
Como você pode ver, as linhas de saída do comando Import-CSV vão para o comando New-ADUser. O pipeline reconhece que os cabeçalhos das colunas no arquivo CSV são nomes de parâmetro e o restante das linhas contém valores, portanto, ele só precisa fornecer os parâmetros -Enabled e -AccountPassword. Esta é uma excelente capacidade de pipeline. Isso torna muito mais eficiente o uso do PowerShell para esses tipos de tarefas de automação.
Gerenciamento de membros do grupo
Adicionar contas de usuário e computador é uma tarefa comum de gerenciamento do AD. Com a ajuda do módulo AD, é relativamente fácil fazer isso. Usando o comando Add-ADGroupMember, você pode adicionar uma ou mais contas a um grupo. Por exemplo, se você deseja adicionar três novos usuários ao grupo Usuários de Marketing. A maneira mais fácil é usar o comando:
Add-ADGroupMember -Identity»Usuários de Marketing«` -Membros jadams,tthumb,mtwain
Nesse comando, o parâmetro -Identity é usado para fornecer o nome do grupo. A opção -Members também é usada para fornecer os nomes de conta SAM dos usuários. Se houver vários nomes de conta SAM, eles devem ser especificados em um arquivo delimitado por vírgula.
Você pode combinar as etapas de criação de três contas e adicioná-las ao grupo Usuários de marketing em um comando para concluir a tarefa em uma etapa. No entanto, o comando Add-ADGroupMember não oferece suporte à passagem de nomes de membros de grupos para o pipeline. Portanto, você deve usar o comando Add-ADPrincipalGroupMembership se quiser usar o pipeline. Esse comando pode usar objetos de usuário, computador ou grupo como entrada do pipeline e adicionar esses objetos ao grupo especificado.
Você pode combinar a operação de criação de usuários com a operação de adição de novos usuários ao grupo Usuários de Marketing em um comando da seguinte forma:
Import-CSV -Path C:\data\userlist.csv | New-ADUser -Enabled $true -AccountPassword $pass ` -PassThru | Add-ADPrincipalGroupMembership ` -MemberOf"Usuários de marketing"
Observe que o parâmetro -PassThru foi adicionado à parte New-ADUser do comando. Este parâmetro instrui New-ADUser a passar os objetos de usuário gerados para o pipeline. Se esse parâmetro não for especificado, o comando Add-ADPrincipalGroupMembership falhará.
Também digno de nota é que apenas o parâmetro -MemberOf é usado para especificar o nome do grupo na seção Add-ADPrincipalGroupMembership do comando. O pipeline faz o restante adicionando cada um dos três usuários ao grupo Usuários de Marketing.
Assim, com um único comando do PowerShell, três novos usuários foram criados, colocados em uma unidade organizacional, receberam senhas e foram adicionados ao grupo Usuários de marketing. Agora vamos ver algumas outras tarefas típicas de manutenção do AD que podem ser automatizadas usando o PowerShell e o módulo AD.
Redefinir senhas de contas de usuário
Às vezes, os usuários precisam redefinir a senha da conta. Você pode automatizar facilmente essa tarefa com o comando Set-ADAccountPassword alterando ou redefinindo a senha da conta. Para alterar a senha, você deve saber a senha antiga e inserir uma nova. Para redefinir sua senha, basta fornecer uma nova senha. No entanto, você precisa da permissão Redefinir senha no objeto de usuário no AD para redefinir a senha.
Assim como a opção -AccountPassword do comando New-ADUser, o comando Set-ADAccountPassword usa o tipo de dados SecureString para senhas, portanto, você deve usar um dos métodos para converter senhas de texto simples em strings seguras. Por exemplo, se você deseja redefinir a senha da conta de usuário Tom Thumb, depois de salvar a nova senha como uma string segura na variável $pass, você pode executar o comando:
Set-ADAccountPassword -Identity"tthumb"` -NewPassword $pass –Reset
Nesse comando, uso o parâmetro -Identity para atribuir um nome de conta SAM à conta de usuário Tom Thumb. Também insiro a opção -NewPassword com a variável $pass para fornecer uma nova senha. Por fim, a opção -Reset é fornecida para indicar que uma redefinição está sendo executada em vez de uma alteração de senha.
Outra tarefa opcional: alternar o sinalizador de conta de usuário de Tom Thumb para forçá-lo a alterar sua senha na próxima vez que ele fizer login. Essa é uma técnica comum quando se trata de redefinir a senha de um usuário. Esta tarefa pode ser executada usando o comando Set-ADUser definindo o parâmetro -ChangePasswordAtLogon como $true:
Set-ADUser -Identity tthumb -ChangePasswordAtLogon $true
A questão surge por que um pipeline não foi usado para canalizar a saída do comando Set-ADAccountPassword para o comando Set-ADUser para executar ambas as operações em um único comando do PowerShell. Eu tentei essa abordagem, não funciona. Provavelmente, há alguma limitação no comando Set-ADAccountPassword que impede que um único comando seja executado com êxito. Em qualquer caso, basta alternar o sinalizador usando o comando Set-ADUser, conforme mostrado acima.
Encontrando objetos do Active Directory
Outra tarefa típica do AD é encontrar objetos do AD que correspondam a determinados critérios. Por exemplo, você pode localizar todos os computadores executando uma versão específica do sistema operacional Windows em um domínio do AD. O comando Get-ADObject é o comando de pesquisa LDAP mais conveniente. Por exemplo, para encontrar computadores Server 2008 R2 no domínio cpandl.com, o comando foi usado:
Get-ADObject -LDAPFilter ` "(&(operatingSystem=Windows Server 2008 R2 Enterprise)` (objectClass=computer))"-SearchBase"dc=cpandl,dc=com"` -SearchScope Subtree
Esse comando usa três parâmetros para concluir a tarefa: -LDAPFilter, -SearchBase e -SearchScope. O parâmetro -LDAPFilter usa uma consulta LDAP padrão como entrada. Este exemplo consulta todos os objetos de computador que têm o atributo OperatingSystem definido como Windows Server 2008 R2 Enterprise. O parâmetro -SearchBase informa ao comando onde iniciar a pesquisa na hierarquia do AD. Nesse caso, a pesquisa é realizada a partir do diretório raiz do domínio AD, mas não é difícil limitar a pesquisa a uma UO específica. O parâmetro -SearchScope informa ao comando se deve rastrear todos os contêineres na base de pesquisa, localizando os objetos especificados. Nesse caso, o parâmetro Subtree é usado para que o comando verifique todos os contêineres subjacentes.
Quando você executa o comando, os objetos que correspondem aos critérios são exibidos. Ou você pode enviar os resultados para outro comando para processar os objetos encontrados.
Observe que, para pesquisas grandes, é útil usar o parâmetro -ResultPageSize para controlar a paginação dos resultados da pesquisa. Normalmente, defino esse parâmetro como 1.000 e o comando Get-ADObject retorna 1.000 objetos por vez. Caso contrário, você pode não obter o resultado esperado porque o número de objetos retornados excede o máximo permitido pela política definida para uma única solicitação de pesquisa.
Outro comando de pesquisa fornecido pela Microsoft é Search-ADAccount. Este comando é especialmente útil para pesquisar com várias condições predefinidas, como contas desabilitadas, contas com senhas expiradas e contas bloqueadas. Por exemplo, o comando a seguir localiza todas as contas de usuário com senhas expiradas na UO SDM:
Search-ADAccount -PasswordExpired -UsersOnly ` -SearchBase"OU=sdm,dc=cpandl,dc=com"` -SearchScope OneLevel Search-ADAccount -PasswordExpired -UsersOnly ` -SearchBase"OU=sdm,dc=cpandl,dc=com" ` -SearchScope OneLevel
Este comando usa o parâmetro -PasswordExpired para especificar que contas com senhas expiradas são necessárias. O parâmetro -UsersOnly especifica que somente objetos de usuário devem ser pesquisados (ou seja, excluir objetos de "computador"). Como no exemplo anterior, os parâmetros -SearchBase e –SearchScope são usados para especificar o escopo da pesquisa. Mas, neste caso, estou usando o parâmetro OneLevel para pesquisar apenas a OU mais próxima (ou seja, excluindo quaisquer OUs filhas).
Esta é apenas uma visão superficial do módulo AD, mas espero que você tenha uma ideia do que ele é capaz. Conforme observado acima, existem mais de 70 comandos no módulo. Os tópicos não abordados neste artigo incluem a exclusão de objetos usando o comando Remove-, a restauração de objetos excluídos usando o comando Restore-ADObject e a remoção de propriedades UAC em objetos de usuário usando o comando Set-ADAccountControl. Existem comandos para quase todas as tarefas administrativas do AD.
Bom dia a todos, continuamos nossas aulas de administração do sistema. Vamos continuar hoje para entender os principais objetos do Active Directory. Depois de lidarmos com o planejamento do Active Directory, a primeira coisa a criar é a estrutura das unidades organizacionais (OU). Isso é feito para que o administrador do sistema possa delegar direitos a grupos separados de objetos, combinados de acordo com alguns critérios, aplicar políticas de grupo, pelos mesmos motivos. Se você organizar uma hierarquia conveniente para si mesmo, terá tudo no AD apenas lafa, o que economizará muito tempo.
Vou criar no meu AD, uma estrutura de tal plano:
- No topo está a UO territorial. No meu caso, são cidades
- Além disso, são servidores OU, usuários e computadores
- Além disso, se necessário, você pode dividi-lo em andares, departamentos e tudo o que sua imaginação imaginar.
Bem, vamos realmente começar. Abrir Iniciar-Administração-ADUC
Digite o nome da UO, no meu caso, a cidade. Além disso, de forma semelhante, criamos o número de OUs que você precisa na hierarquia que você precisa.
Para mim parece assim. Existem várias cidades que contêm unidades organizacionais adicionais:
- Usuários
- Grupos de distribuição
- Grupos
- Contas do sistema
- Servidores
- Computadores
Se você criou repentinamente uma UO extra ou no lugar errado, pode tentar excluí-la ou movê-la, isso é feito clicando com o botão direito do mouse em excluir ou clicando na cruz na parte superior. Mas você verá que a UO está protegida contra exclusão.
Privilégios insuficientes para excluir uma unidade organizacional ou o objeto está protegido contra exclusão acidental
Para corrigir isso e ter ordem no Active Directory, vá para o menu "Exibir componentes adicionais".
Agora clique com o botão direito do mouse na OU desejada e selecione as propriedades.
Passamos para a guia "Objeto" e vemos esta marca de seleção, que protege a UO. Depois de removê-lo, você pode realizar manipulações, conselhos sobre como fazer o que precisa para marcar a caixa de volta.
Como você pode ver, a Microsoft tornou o processo de criação de objetos no Active Directory muito trivial, pois o administrador do sistema simplesmente delega muitas coisas, por exemplo, ao departamento pessoal, que cria as contas. Se você tiver alguma dúvida, escreva-a nos comentários, terei o maior prazer em conversar.
Inteligência
- **As Ferramentas de Administração de Servidor Remoto para Windows 7 SP1 APENAS podem ser instaladas em computadores que executam Windows 7 ou Windows 7 SP1 Professional, Enterprise e Ultimate.**
As Ferramentas de Administração de Servidor Remoto para Windows 7 SP1 permitem que os administradores de TI gerenciem as funções e recursos instalados em computadores remotos que executam Windows Server 2008 R2 SP1 ou Windows Server 2008 R2 (e Windows Server 2008 ou Windows Server 2003 para algumas funções e recursos), com computador remoto executando Windows 7 ou Windows 7 Service Pack 1 (SP1). Essas ferramentas fornecem suporte para gerenciamento remoto de computadores executando Windows Server 2008 R2 SP1, Windows Server 2008 R2 e Windows Server 2008 (para algumas funções e recursos) ao instalar o Server Core ou ao instalação completa esses sistemas operacionais. Usando as Ferramentas de Administração de Servidor Remoto para Windows 7 SP1, você pode gerenciar remotamente certas funções e recursos do Windows Server 2003, embora a opção de instalação Server Core não esteja disponível para este sistema operacional.
Esse recurso é comparável em funcionalidade ao Windows Server 2003 Administration Tools Pack e Remote Server Administration Tools para Windows Vista Service Pack 1 (SP1).
- As Ferramentas de Administração de Servidor Remoto para Windows 7 SP1 podem ser instaladas em computadores que executam Windows 7 ou Windows 7 SP1 Professional, Enterprise e Ultimate. Dado Programas pode ser instalado APENAS em computadores com Windows 7 ou Windows 7 SP1 Professional, Enterprise e Ultimate; ele não pode ser instalado em servidores de destino que você planeja gerenciar.
Você pode baixar as versões de 32 bits e 64 bits das Ferramentas de Administração de Servidor Remoto para Windows 7 SP1 nesta página. Baixe e instale a versão que corresponda à arquitetura do computador no qual planeja instalar as ferramentas de administração. Os usuários que não sabem se a arquitetura do computador é x86 ou x64 devem consultar a seção.
Você pode usar as Ferramentas de Administração de Servidor Remoto para Windows 7 SP1 para gerenciar as funções e os recursos executados quando você instala o Server Core ou uma instalação completa de um sistema operacional Windows Server 2008 R2 SP1 de 64 bits ou Windows. Server 2008 R2. O gerenciamento remoto também é compatível com algumas funções e recursos executados no Windows Server 2008 ou no Windows Server 2003.
As Ferramentas de Administração de Servidor Remoto para Windows 7 SP1 não devem ser instaladas em um computador que esteja executando o Windows Server 2003 ou Windows 2000 Server® Administration Tools Pack. Antes de instalar as Ferramentas de Administração de Servidor Remoto para Windows 7 SP1, desinstale todas as versões do Pacote de Ferramentas de Administração ou Ferramentas de Administração de Servidor Remoto do computador.
Apenas uma instância das Ferramentas de Administração de Servidor Remoto para Windows 7 SP1 pode ser instalada em um computador. Você deve desinstalar todas as cópias existentes das Ferramentas de Administração de Servidor Remoto para Windows 7 SP1 antes de instalar o novo pacote. Eles também incluem cópias em diferentes idiomas.
Para obter informações detalhadas sobre as Ferramentas de Administração de Servidor Remoto para Windows 7 SP1 e os sistemas operacionais com suporte para os quais você pode usar as ferramentas, consulte .
- Instalando ferramentas de administração de servidor remoto para Windows 7 SP1
Administradores no computador em que deseja instalar o Pacote de Ferramentas Administrativas ou faça logon no computador usando a conta integrada Administrador.
Atenção! Antes de instalar as Ferramentas de Administração de Servidor Remoto para Windows 7 SP1, desinstale todas as versões do Pacote de Ferramentas de Administração ou Ferramentas de Administração de Servidor Remoto do computador.
Atenção! Apenas uma instância das Ferramentas de Administração de Servidor Remoto para Windows 7 SP1 pode ser instalada em um computador. Você deve desinstalar todas as cópias existentes das Ferramentas de Administração de Servidor Remoto para Windows 7 SP1 antes de instalar o novo pacote. Eles também incluem cópias em diferentes idiomas. Para desinstalar as instâncias existentes das Ferramentas de Administração de Servidor Remoto para Windows 7 SP1, consulte nesta página.
1. Baixe o Pacote de Ferramentas de Administração de Servidor Remoto para Windows 7 SP1 em um computador executando Windows 7 ou Windows 7 SP1 no Centro de Download da Microsoft.
2. Abra a pasta onde você baixou o pacote, clique duas vezes para extraí-lo e execute o Assistente de instalação das Ferramentas de administração remota do servidor para Windows 7 SP1.
. Atenção! Para começar a instalar o Administration Tools Pack, você deve aceitar os termos da licença e a garantia limitada.
3. Siga todas as instruções do assistente e clique no botão Preparar para concluir sua operação após a conclusão da instalação.
4. Pressione o botão Começar, selecione um item Painel de controle e clique Programas.
5. Na área Programas e características selecione uma opção.
6. Se a janela Controle de conta de usuário perguntar se você deseja abrir a caixa de diálogo Componentes do Windows, clique em Continuar.
7. Na caixa de diálogo Componentes do Windows expandir elemento.
8. Selecione as ferramentas de gerenciamento remoto que deseja instalar.
9. Pressione o botão OK.
10. Personalize o menu Começar para que ele exiba o rótulo Administração(na sua ausência):
Clique no botão Começar clique com o botão direito e selecione o comando Propriedades;
na aba Menu Iniciar aperte o botão Afinação;
Na caixa de diálogo Personalização do menu Iniciar role a lista até o item Administração e marque a caixa Exibição em Todos os programas e no menu Iniciar. Clique no botão OK. Os atalhos para snap-ins instalados pelas Ferramentas de Administração de Servidor Remoto para Windows 7 SP1 foram adicionados à lista Administração cardápio Começar.
Reinstale ou remova ferramentas de administração de servidor remoto individuais para Windows 7 SP1
Se a Ferramenta de Administração Remota foi desinstalada de um computador com Windows 7 ou Windows 7 SP1, você pode reinstalá-la seguindo as etapas abaixo.
Reinstalar ferramentas individuais de administração remota
1. Pressione o botão Começar, selecione um item Painel de controle e clique Programas.
2. No campo Programas e características selecione a opção Liga ou desliga características das janelas.
3. Se a janela Controle de Conta de Usuário perguntar se você deseja abrir a caixa de diálogo Componentes do Windows, aperte o botão Continuar.
4. Na caixa de diálogo Componentes do Windows expandir elemento Ferramentas de Administração de Servidor Remoto.
5. Selecione as ferramentas de gerenciamento remoto que deseja instalar ou desmarque as caixas das ferramentas a serem removidas. Clique no botão OK.
Remoção limpa de ferramentas de administração de servidor remoto para Windows 7 SP1
Deve ser um membro de um grupo Administradores no computador onde deseja desinstalar o Pacote de Ferramentas Administrativas ou faça logon no computador usando a conta interna Administrador.
Você pode remover todo o Pacote de Ferramentas Administrativas do seu computador usando o utilitário Desinstalando um programa no painel de controle.
Desinstalando o pacote de ferramentas administrativas
1. Pressione o botão Começar, selecione um item Painel de controle, e depois na área Programas clique no elemento Desinstalando um programa.
2. Clique em um item Ver atualizações instaladas.
3. Selecione um item Atualização para Microsoft Windows (958830).
4. Pressione o botão Excluir.
- Instalando ferramentas de administração de servidor remoto para Windows 7 SP1
Windows6.1-KB958830-x64-RefreshPkg.msu
Windows6.1-KB958830-x86-RefreshPkg.msu
Data de publicação:
requisitos de sistema
Sistema operacional compatível
Janelas 7; Windows 7 Service Pack 1
instruções de instalação
Noções básicas de gerenciamento de domínio do Active Directory
Várias ferramentas nos snap-ins do Microsoft Management Console (MMC) facilitam o trabalho com o Active Directory.
cordame Usuários e computadores do Active Directory(Active Directory Users and Computers) é um MMC que você pode usar para administrar e publicar informações no diretório. É a principal ferramenta de administração do Active Directory e é usada para realizar todas as tarefas relacionadas a usuários, grupos e computadores, bem como para gerenciar unidades organizacionais. Para iniciar o snap-in Usuários e Computadores do Active Directory, selecione o comando de mesmo nome no menu Ferramentas Administrativas.
Usuários e computadores do Active Directory
Por padrão, o console Usuários e Computadores do Active Directory funciona com o domínio ao qual seu computador pertence. Você pode acessar objetos de computador e usuário neste domínio por meio da árvore do console ou conectar-se a outro domínio. As ferramentas do mesmo console permitem visualizar parâmetros adicionais de objetos e procurá-los.
Tendo obtido acesso ao domínio, você verá um conjunto padrão de pastas:
- Consultas salvas - critérios de pesquisa salvos que permitem repetir rapidamente uma pesquisa realizada anteriormente no Active Directory;
- B uiltin - lista de contas de usuário integradas;
- C omputers - contêiner padrão para contas de computador;
- Controladores de domínio - o contêiner padrão para controladores de domínio;
- ForeignSecurityPrincipals - contém informações sobre objetos de um domínio externo confiável. Normalmente, esses objetos são criados quando um objeto de um domínio externo é adicionado ao grupo de domínio atual;
- U s é o contêiner padrão para usuários.
Algumas pastas do console não são exibidas por padrão. Para exibi-los, selecione o comando Advanced Features no menu View. Essas pastas adicionais são:
- L ostAndFound - proprietário perdido, objetos de diretório;
- N TDS Quotas - dados sobre a cotação do serviço de diretório;
- Dados do programa - dados armazenados no serviço de diretório para aplicativos da Microsoft;
- S ystem - parâmetros de sistema embutidos.
Você mesmo pode adicionar pastas para unidades organizacionais à árvore do AD.
Considere um exemplo de criação de uma conta de usuário de domínio. Para criar uma conta de usuário, clique com o botão direito do mouse no contêiner no qual deseja colocar a conta de usuário, selecione Novo no menu de contexto e, em seguida, Usuário. A janela do assistente Novo Objeto – Usuário será aberta:
- Insira o nome, a inicial e o sobrenome do usuário nos campos apropriados. Essas informações serão necessárias para gerar o nome de exibição do usuário.
- Edite o nome completo. Deve ser único dentro do domínio e não pode ter mais de 64 caracteres.
- Digite seu nome de login. Use a lista suspensa para selecionar o domínio ao qual a conta será associada.
- Se necessário, altere o nome de usuário de login para sistemas executando Windows NT 4.0 ou anterior. Por padrão, os primeiros 20 caracteres do nome completo do usuário são usados como nome de login para sistemas que executam versões anteriores do Windows. Esse nome também deve ser exclusivo dentro do domínio.
- Clique em Avançar. Especifique uma senha para o usuário. Suas configurações devem corresponder à sua política de senha;
C onfirmar senha - campo utilizado para confirmar a exatidão da senha digitada;
você ser deve alterar a senha no próximo logon(Exigir alteração de senha no próximo login) - se esta caixa estiver marcada, o usuário terá que alterar a senha no próximo login;
O usuário não pode alterar a senha - se esta caixa estiver marcada, o usuário não poderá alterar a senha;
A senha nunca expira - se esta caixa estiver marcada, a senha nunca expirará para esta conta (esta configuração substitui a política de conta de domínio);
Uma conta está desativada - Se marcada, a conta está desativada (útil para impedir temporariamente que alguém use a conta).
As contas permitem que você armazene informações de contato do usuário, bem como informações sobre a participação em vários grupos de domínio, caminho do perfil, script de logon, caminho da pasta pessoal, lista de computadores a partir dos quais o usuário pode entrar no domínio, etc.
Os scripts de logon definem os comandos que são executados em cada logon. Eles permitem que você configure a hora do sistema, impressoras de rede, caminhos de unidade de rede, etc. Os scripts são usados para executar comandos uma vez e as configurações de ambiente definidas pelos scripts não são salvas para uso posterior. Os scripts de login podem ser arquivos do Windows Script Server com extensões .VBS, .JS e outros, arquivos em lote com extensão .BAT, arquivos de comando com extensão .CMD, programas com extensão .EXE.
Você pode atribuir a cada conta sua própria pasta pessoal para armazenar e restaurar os arquivos do usuário. A maioria dos aplicativos abre a pasta inicial por padrão para operações de abertura e salvamento de arquivos, facilitando a localização de dados pelos usuários. Na linha de comando, a pasta inicial é o diretório atual inicial. A pasta pessoal pode estar localizada no disco rígido local do usuário ou em uma unidade de rede compartilhada.
Para domínio contas computadores e usuários podem aplicar políticas de grupo. A Diretiva de Grupo simplifica a administração ao fornecer aos administradores controle centralizado sobre os privilégios, permissões e recursos de usuários e computadores. A Diretiva de Grupo permite:
- criar pastas especiais gerenciadas centralmente, como Meus Documentos (Meus documentos);
- gerenciar o acesso aos componentes do Windows, recursos de sistema e rede, ferramentas do painel de controle, área de trabalho e menu Iniciar;
- configurar scripts de usuário e computador para executar uma tarefa em um horário especificado;
- configurar políticas para senhas e bloqueios de contas, auditoria, atribuições de direitos de usuário e segurança.
Além de gerenciar contas e grupos de usuários, há muitas outras tarefas de gerenciamento de domínio. Existem outras ferramentas e aplicativos para isso.
cordame Domínios e relações de confiança do Active Directory(Active Directory - Domains and Trusts) é usado para trabalhar com domínios, árvores de domínio e florestas de domínio.
cordame Sites e serviços do Active Directory(Active Directory - Sites e Serviços) permite gerenciar sites e sub-redes, bem como a replicação entre sites.
Para gerenciar objetos AD, existem ferramentas de linha de comando que permitem executar uma ampla gama de tarefas administrativas:
- D sadd - Adiciona computadores, contatos, grupos, unidades organizacionais e usuários ao Active Directory. Para obter ajuda, digite dsadd /? , como dsadd computer/?
- D smod - Modifica as propriedades de computadores, contatos, grupos, unidades organizacionais, usuários e servidores registrados no Active Directory. Para obter ajuda, digite dsmod /? , por exemplo servidor dsmod /?
- D smove - Move um único objeto para um novo local dentro de um domínio ou renomeia um objeto sem movê-lo.
- D sget - Exibe as propriedades de computadores, contatos, grupos, unidades organizacionais, usuários, sites, sub-redes e servidores registrados no Active Directory. Para obter ajuda, digite dsget /? , por exemplo sub-rede dsget /?
- D squery - procura computadores, contatos, grupos, unidades organizacionais, usuários, sites, sub-redes e servidores no Active Directory de acordo com critérios especificados.