Introdução ao Group Policy Em uma rede baseada em Windows Server e Active Directory (AD), quase sempre o conjunto principal de computadores clientes também roda sistemas operacionais Microsoft Windows, e essas máquinas estão todas ingressadas no domínio. Configurar tudo dessa forma não apenas faz sentido do ponto de vista organizacional dentro do AD, mas também permite uma autenticação centralizada entre dispositivos e aplicações, como já discutimos anteriormente. Alguns exemplos que mencionei antes foram algo como: • “E quando uma empresa tem uma política de segurança em vigor que…” • “Ou certifique-se de que seus servidores não recebam aquelas políticas de segurança existentes porque…” Então, afinal, o que são essas políticas mágicas de segurança e como configurá-las? Essa é a força do Group Policy. Ele permite criar Objetos de Política de Grupo (GPOs) que contêm configurações e ajustes que você deseja aplicar a computadores ou usuários no seu domínio AD. Depois de criar e configurar um GPO com várias definições, você pode direcioná-lo para onde quiser: • Se deseja aplicar uma política a todos os sistemas desktop, basta apontá-la para a OU ou grupo de segurança que contém todos os computadores do domínio. • Se criou um GPO que deve se aplicar apenas a computadores Windows 10 em um determinado site, pode filtrá-lo para que apenas esses sistemas recebam a política. E a verdadeira mágica é que a aplicação dessas configurações acontece automaticamente, simplesmente pelo fato de os computadores estarem ingressados no domínio. Você não precisa tocar em cada máquina cliente para aplicar as configurações via GPO. Com o Group Policy, é possível ajustar ou bloquear praticamente qualquer aspecto dentro do sistema operacional Windows. Mais uma vez, olhando a lista de funções disponíveis no meu Windows Server 2025, não vejo nenhuma chamada Group Policy. Correto: ela não existe! Na verdade, se você acompanhou a configuração do laboratório neste livro, já tem o Group Policy totalmente funcional na sua rede. Tudo o que o Group Policy precisa para funcionar faz parte do AD DS. Portanto, se você tem um DC na sua rede, também tem o Group Policy nesse mesmo servidor, já que todas as informações que ele utiliza estão armazenadas dentro do diretório. Como a instalação da função AD DS é tudo o que precisamos para usar o Group Policy, e já fizemos isso no nosso DC, estamos prontos para começar a usar o Group Policy para enviar políticas e preferências aos computadores e usuários do domínio. Mas atenção: o Group Policy é um tópico grande o suficiente para merecer um capítulo próprio — e é exatamente isso que decidi fazer. Se você está interessado em centralizar administração e políticas com essa ferramenta fascinante (e deveria estar), continue lendo, pois vamos mergulhar em todos os aspectos dos GPOs no Capítulo 5: Group Policy. Política de Grupo (Group Policy) Se você estiver lendo este livro de frente para trás — de fato, uma boa e nada estranha forma de ler um livro — já terá uma ideia geral do que é a Política de Grupo e do que ela faz (porque falamos sobre isso no Capítulo 3, Active Directory). No entanto, já convivi tempo suficiente com profissionais de TI para saber que ler um livro de capa a capa é raro, e a atenção raramente permite tal jornada. Portanto, para qualquer um que esteja acessando este capítulo de forma aleatória porque as palavras “Group Policy” chamaram sua atenção ou porque você tem uma necessidade específica que espera ver respondida aqui, não se preocupe! Vamos novamente resumir o grande e glorioso poder da Política de Grupo. É fácil entender o uso geral da palavra “política”, significando algum tipo de conjunto de regras, estrutura ou padrão ao qual algo precisa se adequar. No nosso caso, estamos falando de computadores baseados em Microsoft Windows (e servidores). Aplicar políticas a computadores — como políticas de segurança, políticas de aplicativos ou políticas de impressoras — parece uma ótima ideia. Se aplicar políticas a um computador é bom, aplicar políticas a um grupo de computadores deve ser ainda melhor, daí o termo Group Policy. Em resumo, a Política de Grupo é uma forma centralizada de aplicar políticas a grupos de usuários ou computadores dentro da sua rede de domínio. A palavra-chave aqui é “domínio”, já que a Group Policy só pode identificar e manipular usuários ou computadores se eles fizerem parte do seu domínio Active Directory. Tópicos que serão abordados neste capítulo: • Objetos de Política de Grupo (Group Policy Objects – GPOs) • Construção de um GPO (alguns, na verdade!) • Escopo de um GPO • Configurações de computador e de usuário • Política versus preferência • Política de Domínio Padrão (Default Domain Policy) • Modelos administrativos (Administrative Templates) • O Central Store Objetos de Política de Grupo (Group Policy Objects) A tecnologia principal de que estamos falando aqui é chamada de Group Policy (Política de Grupo), e uma instância individual dessa tecnologia é conhecida como Group Policy Object (GPO). Um GPO é um pacote único que contém uma ou várias configurações de política e se aplica a um computador de domínio, a um usuário de domínio ou, às vezes, a muitos computadores e usuários ao mesmo tempo. Os GPOs são armazenados dentro do Active Directory e replicados entre os servidores Domain Controller (DC). Sempre que um usuário de domínio faz login em um computador associado ao domínio e conectado à rede, o computador consulta o Active Directory e pergunta: “Ei, há alguma configuração de GPO para mim?”. A partir daí, uma série de atividades acontece, enquanto o DC entrega todas as configurações de GPO que se aplicam ao computador e/ou usuário que está entrando. Esse é um ponto-chave: os GPOs são definidos com escopo no momento da criação, dando a você o poder de determinar a quem cada política será aplicada — algo extremamente poderoso. Essas configurações então se aplicam ao computador, forçando certas ações (ou impedindo outras) conforme definido pelo departamento de TI. • Você pode bloquear configurações, forçar padrões ou até configurar valores iniciais permitindo que o usuário os altere depois. • Pode aplicar certas configurações a alguns computadores e o oposto a outros. • Pode até aplicar GPOs conflitantes ao mesmo computador e observar qual prevalece no fim. Se você não entende como a Política de Grupo funciona, é muito fácil causar grandes problemas na rede, já que também é muito fácil aplicar configurações a todas as máquinas do domínio. Um único GPO mal configurado pode derrubar toda a rede. Portanto… isso é tranquilizador, certo? 😅 Confie em mim: embora a Política de Grupo venha com um “aviso de uso” e aquele famoso lema “com grandes poderes vêm grandes responsabilidades”, você vai querer usar GPOs cada vez mais depois de ver tudo o que eles podem fazer. Ciclo de atualização em segundo plano da Política de Grupo Mencionei que a Política de Grupo processa sua lista de regras e configurações nos computadores associados ao domínio sempre que um usuário faz login, e isso é verdade. Mas também é verdade que a Política de Grupo se reprocessa em intervalos ao longo do dia, mesmo enquanto o usuário continua logado. Por padrão — e quase ninguém altera isso — ocorre algo chamado atualização em segundo plano (background refresh) a cada 90 minutos. Isso significa que implementar novos GPOs durante o dia geralmente funciona bem, porque essas configurações entram em vigor sem que os usuários precisem sair ou reiniciar seus computadores. Existem exceções, pois algumas configurações de GPO não podem ser aplicadas em ciclos de atualização em segundo plano e só entram em vigor durante o processo de login. Exemplos: • Scripts de logon (executam apenas no logon ou logoff). • Mapeamento de unidades de rede. Muitas vezes, ao testar configurações de GPO, seria muito ineficiente esperar 90 minutos ou reiniciar o computador de teste a cada pequena alteração. Felizmente, existe um comando simples que força a Política de Grupo a atualizar imediatamente: Código gpupdate /force Executar esse comando no Prompt de Comando ou no PowerShell em um computador associado ao domínio faz com que ele busque imediatamente as configurações atualizadas de GPO. ⚠️ Importante: o computador precisa estar conectado a um Domain Controller para que a Política de Grupo seja processada. Isso não funcionará, por exemplo, se o laptop estiver em casa sem VPN. Mas em qualquer computador no escritório ou conectado à rede corporativa, você pode rodar gpupdate /force quantas vezes quiser para aplicar novas políticas e mudanças em tempo real. Criando um GPO Não há nada tão satisfatório quanto colocar a mão na massa, então vamos direto ao ponto e construir um novo GPO. Não se preocupe, ainda não vamos aplicar esse GPO a nada — isso ficará para a próxima seção. Como acontece com a maioria das tecnologias da Microsoft, existe um console de gerenciamento especial no Windows Server, criado especificamente para interagir com a Política de Grupo, chamado Group Policy Management Console (GPMC). Ao entrar em qualquer um dos seus servidores Domain Controller (DC), você pode abrir o GPMC de várias formas: • Pelo menu Administrative Tools. • Pelo menu Tools dentro do Server Manager. • Ou simplesmente executando GPMC.MSC a partir do Start | Run, Prompt de Comando, Terminal ou PowerShell. 👉 Em resumo: • O GPMC é a ferramenta oficial para criar e gerenciar GPOs. • Pode ser acessado facilmente em qualquer DC. • O processo de criação é separado da aplicação — primeiro você constrói, depois define o escopo e aplica. Criando um novo GPO Na Figura 5.1, você notará que já existem alguns GPOs listados. Eles são uma combinação de GPOs padrão, que sempre existem quando você instala o Active Directory (falaremos sobre a Default Domain Policy mais adiante neste capítulo), e os GPOs do IPAM, que o processo de configuração do IPAM criou para nós no Capítulo 4, DNS e DHCP. Para criar um novo GPO de forma que ele ainda não se aplique a nenhuma estação de trabalho ou usuário, siga estes passos: 1. Clique com o botão direito na pasta Group Policy Objects. 2. Selecione New. 3. Crie um nome para o seu novo GPO. 4. Clique em OK. Pronto! Você criou um Group Policy Object. Até aqui, seu novo GPO está vazio, sem configurações ou definições, e não se aplica a nada nem a ninguém — ou seja, é totalmente inútil neste momento. Mas isso vai mudar em breve… 👉 Em resumo: • Os GPOs padrão sempre existem após a instalação do AD. • O IPAM também cria GPOs automaticamente durante sua configuração. • Criar um GPO é simples, mas inicialmente ele não tem efeito até ser configurado e vinculado. Adicionando Sites Confiáveis Eu nomeei meu primeiro GPO como Trusted Sites porque vou usar esse novo GPO para fazer com que algumas URLs sejam reconhecidas como sites confiáveis no Windows, nos computadores com Windows 10 e 11. Quem reconhece o termo “Trusted Sites” pode se perguntar se, no ano de 2025, eu realmente vou seguir o caminho de aplicar configurações nas propriedades do Internet Explorer. Sim! Mesmo que o Internet Explorer esteja praticamente morto e tenha sido substituído pelo Edge para navegação, o IE foi tão profundamente integrado ao código do Windows que ainda existem muitas situações em que manipular suas configurações altera comportamentos ou habilita certas funções dentro do próprio Windows. Há poucas semanas, ajudei um engenheiro a criar exatamente esse tipo de GPO porque o aplicativo corporativo de um cliente não funcionava corretamente, a menos que algumas URLs fossem adicionadas às configurações de Trusted Sites do Internet Explorer — mesmo que a empresa não utilizasse o IE para navegação. Às vezes, esses aplicativos tentam executar JavaScript, ActiveX controls ou algo semelhante, e isso é um dos motivos pelos quais você pode se ver mexendo nas configurações de segurança do IE nos computadores clientes. Quando surge uma mudança que precisa ser aplicada em todos os computadores dos usuários, você poderia: • Ser reativo e imprimir uma página de instruções para o helpdesk, pedindo que configurem manualmente cada máquina. • Ou ser proativo e criar um GPO que aplique essas mudanças automaticamente em todas as estações de trabalho, poupando tempo e evitando inúmeros chamados. Esse é apenas um pequeno exemplo do poder da Group Policy, mas é útil porque mostra como ela pode aplicar configurações escondidas profundamente dentro das opções do sistema. Para configurar: 1. Clique com o botão direito no novo GPO e escolha Edit… 2. Navegue até: o Computer Configuration o Policies o Administrative Templates o Windows Components o Internet Explorer o Internet Control Panel o Security Page Como eu disse, essa configuração está bem enterrada lá dentro! 👉 Em resumo: • Mesmo em 2025, algumas aplicações ainda dependem das configurações de segurança do IE. • Criar um GPO para Trusted Sites é mais eficiente do que configurar manualmente cada computador. • O caminho para configurar está dentro das opções avançadas do GPO, em Internet Explorer → Security Page. Configurando Trusted Sites em um GPO Agora, dê um duplo clique em Site to Zone Assignment List e defina-o como Enabled. Isso permite que você clique no botão Show…, dentro do qual é possível inserir os sites e atribuir valores de zona para cada um deles. Cada configuração de GPO vem acompanhada de um texto descritivo, explicando exatamente para que serve aquela configuração e o que significam as opções disponíveis. No caso deste exemplo, para que meus sites sejam reconhecidos como Trusted Sites, preciso atribuir a eles o valor de zona 2. E, só para ilustrar, também adicionei um site que não quero que seja acessível pelos usuários, atribuindo a ele o valor de zona 4, de forma que badsite.contoso.com seja considerado membro da zona de sites restritos em todos os computadores da minha rede. 👉 Em resumo: • Site to Zone Assignment List → Configuração dentro do GPO para definir sites confiáveis ou restritos. • Zone value 2 → Sites confiáveis (Trusted Sites). • Zone value 4 → Sites restritos (Restricted Sites). • Permite aplicar automaticamente configurações de segurança de navegador em todos os computadores do domínio. Lista de Atribuição de Sites para Zonas (Site to Zone Assignment List) Concluindo a criação do GPO Estamos quase terminando. Assim que eu clicar no botão OK, essas configurações serão armazenadas dentro do meu GPO e estarão prontas para serem distribuídas. Como você sabe, ainda não fizemos nenhum trabalho para atribuir esse novo GPO a usuários ou computadores, então, por enquanto, o GPO está preenchido com configurações, mas ainda não tem efeito prático. Antes de aplicarmos essas configurações, vamos criar mais alguns GPOs comuns para garantir que nossos exemplos fiquem bem completos e variados. 👉 Em resumo: • O GPO já contém configurações, mas ainda não está vinculado a nada. • Só terá efeito quando for atribuído a usuários ou computadores. • O próximo passo é criar outros exemplos de GPOs para consolidar o aprendizado. Mapeando Unidades de Rede Os servidores de arquivos são alguns dos tipos mais comuns de servidores, já que todas as empresas, em qualquer setor, precisam criar e manter documentação para operar seus negócios. Este não é um capítulo sobre como construir um servidor de arquivos, configurar compartilhamentos, restringir permissões ou usar o DFS (Distributed File System) para melhorar a flexibilidade e resiliência da infraestrutura de arquivos — embora tudo isso seja importante e será abordado no Capítulo 6, File Management. Por enquanto, no meu laboratório de testes, criei algumas pastas compartilhadas simples que usaremos: • \\DC1\HR • \\DC2\Accounting • \\WEB3\Installers Nosso desafio hoje é automatizar o mapeamento desses locais em todas as estações de trabalho dos usuários. Claro, eu poderia criar uma documentação mostrando como acessar manualmente esses locais via UNC path no File Explorer, ou até ensinar os usuários a mapear manualmente unidades de rede com letras de drive. Isso funcionaria, mas traria problemas: • Sobrecarga administrativa para os usuários. • Inconsistência de letras de unidade (ex.: Grace usa “R:” para Accounting, enquanto Jackson usa “T:”). • Links baseados em letras de unidade poderiam falhar entre usuários. Essas complicações mostram que deixar os usuários mapearem drives por conta própria não é eficiente. A solução melhor é usar a Group Policy para padronizar o mapeamento de drives. • Dentro de um novo GPO, podemos definir UNC paths para os compartilhamentos e atribuir letras de unidade. • Ao aplicar esse GPO a usuários ou computadores, as unidades serão mapeadas automaticamente no login. Passo a passo no GPMC 1. Crie um novo GPO. 2. Clique com o botão direito e selecione Edit. 3. Navegue até: o User Configuration o Preferences o Windows Settings o Drive Maps 4. Clique com o botão direito em Drive Maps → New | Mapped Drive. 5. Configure: o Location (UNC path): \\DC1\HR o Drive Letter: H: 👉 Em resumo: • O GPO garante consistência e evita problemas de drive letters diferentes. • O caminho é User Configuration → Preferences → Windows Settings → Drive Maps. • Cada compartilhamento pode ser mapeado com uma letra específica, padronizada para todos os usuários. CRUD em GPOs (Create, Replace, Update, Delete) Ao configurar um mapeamento de unidade de rede via GPO, você verá no menu Action quatro opções: Create, Replace, Update e Delete. Esse conjunto é conhecido como CRUD. Significado de cada opção: • Create: o Cria o drive mapeado somente se ele não existir. o Exemplo: Se a letra H: já estiver em uso, o mapeamento será ignorado. • Replace: o Remove uma configuração existente e substitui por uma nova. o Exemplo: Se já houver algo usando H:, será substituído por \\DC1\HR. o Mais útil em outros cenários (como impressoras), já que em drives o Update cobre o mesmo caso. • Update (mais comum): o Se o drive não existir, ele será criado. o Se já existir, será atualizado com a nova definição. o É a opção padrão e a mais usada em políticas de mapeamento de drives. • Delete: o Remove o mapeamento da máquina cliente. o Útil para garantir que um compartilhamento antigo seja removido de todos os computadores. Aba Common (Configurações adicionais) Na aba Common, há cinco opções adicionais. A mais importante para mapeamento de drives é: • Run in logged-on user’s security context: o Faz com que o GPO aplique o mapeamento usando o contexto do usuário logado. o Isso é essencial para drives, pois normalmente queremos que os usuários interajam com suas unidades de rede com suas credenciais normais. o Embora não seja comum marcar essa opção em outros GPOs, para mapeamento de drives é altamente recomendado. 👉 Em resumo: • Update é a ação padrão e mais usada para drives. • Replace pode ser útil em outros tipos de preferências. • Run in logged-on user’s security context deve ser marcado para garantir que os drives funcionem corretamente no contexto do usuário. Repetindo o processo para outras unidades Repita o procedimento para quaisquer outras letras de unidade que você queira incluir no seu novo GPO, e assim você estará no caminho certo para automatizar o mapeamento de todas as unidades de rede em toda a sua infraestrutura! No meu laboratório de testes, configurei mapeamentos de letras de unidade para cada uma das minhas pastas compartilhadas e também incluí uma configuração de GPO para excluir a unidade Z: caso ela exista. Nunca houve uma unidade Z: no meu ambiente de testes, mas aqui você pode ver como uma exclusão de unidade aparece dentro da política. Em resumo: • Você pode repetir o processo para quantos compartilhamentos precisar. • É possível não apenas criar e atualizar drives, mas também remover unidades indesejadas. • Isso garante padronização e evita inconsistências entre usuários. Concluindo o GPO de Mapeamento de Drives Mais uma vez, este novo GPO agora está preenchido com configurações, mas ainda não se aplica a nenhum usuário ou computador. Não se preocupe — assim que terminarmos de criar mais alguns exemplos de GPOs, avançaremos para a etapa de definir o escopo das configurações de GPO. É nesse momento que colocaremos os novos GPOs em ação e verificaremos se as configurações e os drives mapeados aparecem automaticamente nos computadores clientes. 👉 Em resumo: • O GPO já contém configurações, mas ainda não está vinculado. • A aplicação real acontece na etapa de scoping (definição de escopo). • Essa etapa garante que os drives e políticas sejam aplicados automaticamente aos usuários/computadores corretos. Instalando Chaves de Registro Da mesma forma que unidades de rede podem ser mapeadas para os usuários via GPO, também podemos implementar chaves e valores de registro automaticamente nos computadores. Isso é extremamente poderoso, porque praticamente qualquer coisa em um ambiente Windows pode ser manipulada por meio do registro. Crie mais um novo GPO e, desta vez, navegue até: • User Configuration • Preferences • Windows Settings • Registry A criação, substituição, atualização ou exclusão de chaves de registro funciona de maneira muito semelhante ao processo de mapeamento de drives. O ponto crítico é garantir que as opções sejam especificadas corretamente, especialmente o Key Path e as informações de Value, caso contrário não funcionarão. No exemplo, vou aplicar um valor de registro que impede os usuários de alterar a imagem de fundo da área de trabalho e define um papel de parede personalizado. Na prática, a maneira mais fácil de garantir que uma configuração de registro via GPO seja feita corretamente é editar manualmente o registro primeiro, inserindo a chave/valor desejado no servidor ou computador de onde você está rodando o GPMC. Assim, ao clicar no botão de reticências (ellipsis), você pode navegar diretamente até a chave e selecioná-la, sem se preocupar em digitar a sintaxe correta para o campo Key Path. Lembre-se: o GPMC é semelhante a qualquer outro console administrativo do Windows Server, podendo ser usado diretamente em um Domain Controller, em outro servidor ou até em uma estação cliente Windows com as ferramentas RSAT instaladas. ⚠️ Tenha cuidado para não alterar manualmente demais o registro em um Domain Controller, apenas porque está usando-o para editar GPOs. É mais seguro configurar a chave necessária em uma estação cliente e rodar o GPMC a partir dela, evitando mexer diretamente no registro do DC. A informação de registro que estou aplicando é: • Key Path: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System • Value Name: Wallpaper Aqui está minha entrada preenchida dentro da Group Policy. 👉 Em resumo: • GPOs podem criar, atualizar ou excluir chaves de registro. • Sempre valide a chave manualmente antes de configurá-la no GPO. • Use o GPMC preferencialmente em uma estação cliente, não no Domain Controller. • Exemplo prático: impedir alteração do papel de parede e definir um fundo padrão via chave Wallpaper. Atualização de Chaves de Registro Como selecionei essa chave de registro para ser aplicada com a ação Update, toda vez que a Group Policy for processada neste computador, ela garantirá que a chave esteja presente, impedindo continuamente que os usuários alterem o papel de parede da área de trabalho. Escolhi esse exemplo porque é simples e porque, muitas vezes, na Política de Grupo, existem múltiplas formas de alcançar o mesmo resultado. • Em vez de usar uma chave de registro para bloquear a alteração do papel de parede, eu poderia ter criado um GPO utilizando a seguinte configuração: o User Configuration | Policies | Administrative Templates | Desktop | Desktop | Desktop Wallpaper Impedindo o desligamento do sistema É muito comum utilizar GPOs para aplicar parâmetros de segurança e restrições em computadores ou servidores. Muitas empresas usam Remote Desktop Servers (RDS) para fornecer desktops virtuais aos usuários. Nesses casos, os usuários navegam com teclado e mouse em seus computadores, mas tudo acontece dentro de um ambiente multiusuário no servidor. Se um usuário desligasse o servidor — mesmo acidentalmente — isso teria um impacto enorme em todos os outros usuários conectados. A mesma lógica se aplica a estações de uso comum (kiosks) ou computadores compartilhados por vários funcionários. Uma restrição bastante comum nesses ambientes é impedir que os usuários desliguem o computador em que estão logados. Para implementar essa restrição: 1. Crie um novo GPO (ou edite um existente). 2. Navegue até: o Computer Configuration (ou User Configuration) o Policies o Administrative Templates o Start Menu and Taskbar 3. Localize a configuração: o Remove and prevent access to the Shut Down, Restart, Sleep, and Hibernate commands 4. Dê um duplo clique e defina como Enabled. 👉 Em resumo: • Wallpaper pode ser bloqueado via chave de registro ou via configuração nativa de GPO. • Shutdown/Restart/Sleep/Hibernate podem ser desativados para ambientes RDS ou kiosks, garantindo estabilidade e segurança. Impedindo o desligamento do sistema Uma vez habilitada, essa é uma política simples de ação única que impedirá determinados usuários de desligarem computadores ou servidores dentro do seu ambiente de domínio. Ainda não definimos a quais computadores ou usuários essa política se aplica, pois não discutimos como definir o escopo de um GPO — mas não se preocupe, essa informação virá em breve! Assim que esse GPO for aplicado, se um usuário tentar desligar um computador, ele não verá mais a opção para fazê-lo. Na verdade, essa política não é apenas uma atualização gráfica para esconder o botão. Mesmo que o usuário seja experiente em TI e tente algo como pressionar Alt + F4 na área de trabalho ou iniciar um desligamento via Prompt de Comando, ele será impedido de realizar a ação. 👉 Em resumo: • O GPO remove as opções de Shutdown, Restart, Sleep e Hibernate. • A restrição é efetiva tanto na interface gráfica quanto em tentativas avançadas via teclado ou linha de comando. • O escopo (quem recebe a política) será definido na próxima etapa de configuração de GPOs. Restrições de desligamento via GPO Embora essa configuração da Group Policy seja uma ótima maneira de impedir que 99% dos usuários desliguem ou reiniciem um servidor RDS acidentalmente ou intencionalmente, tecnicamente ela é uma configuração de Start Menu and Taskbar. O que ela realmente faz é ocultar as opções gráficas que permitem ao usuário interagir com ferramentas da interface para desligar ou reiniciar. Ela não bloqueia os comandos de desligamento em si. Portanto, se um usuário avançado abrir o Prompt de Comando ou o PowerShell e executar comandos específicos, ainda poderia reiniciar um servidor RDS se realmente quisesse. Esses tipos de usuários fogem um pouco do escopo do exemplo aqui, mas se você tiver usuários problemáticos que insistem em fazer coisas que não deveriam, existem opções muito mais restritivas que podem ser aplicadas por meio de políticas locais de segurança ou GPOs mais avançados. 👉 Em resumo: • Essa configuração remove opções gráficas de desligamento/reinício. • Não impede comandos diretos via CMD ou PowerShell. • Para ambientes com usuários avançados e problemáticos, é necessário aplicar políticas de segurança adicionais para reforçar a restrição. Desabilitando Drives USB Removíveis Você já ouviu falar do Dropped Drive Experiment? Originalmente implementado por testadores de penetração, é uma forma criativa de avaliar o nível de consciência em segurança dos funcionários. A ideia é simples: carregar pen drives com software malicioso, deixá-los “esquecidos” em um estacionamento da empresa e observar o que acontece. Muitas pessoas vão encontrar esses dispositivos e, por curiosidade, conectá-los em seus computadores. Nesse momento, já é tarde demais — o atacante ganha acesso ao sistema e às informações, sem que o usuário precise sequer abrir arquivos. Portanto, se você encontrar um pen drive no chão ou receber um de um fornecedor em um evento, a única ação correta é jogar fora. Claro, você pode enviar um e-mail alertando os funcionários sobre esse risco ou pedir que nunca conectem dispositivos USB desconhecidos. Mas será que eles realmente vão seguir essa orientação? Provavelmente não. É aí que entra a Group Policy: com uma configuração simples, aplicada a todos os computadores do domínio, você protege sua empresa contra essa vulnerabilidade real. Caminho da Configuração no GPO • Computer Configuration • Policies • Administrative Templates • System • Removable Storage Access • All removable storage classes: Deny all accesses Defina essa opção como Enabled, e pronto: todos os dispositivos de armazenamento removível (como pen drives) serão bloqueados. 👉 Em resumo: • O experimento mostra como usuários podem comprometer sistemas por curiosidade. • A solução prática é bloquear o uso de dispositivos USB via GPO. • Uma única configuração garante proteção imediata contra esse vetor de ataque. Adicionando um Atalho na Área de Trabalho Vamos passar por mais um exemplo de GPO antes de seguir para a próxima seção. Um chamado bastante comum nos helpdesks é algo como: “Você poderia enviar um ícone para todos os computadores apontando para tal recurso?” Algumas empresas possuem suas próprias ferramentas de gerenciamento remoto (RMM) que permitem realizar essa tarefa de várias formas. Mas, em nosso laboratório de testes com alguns servidores Windows, podemos resolver isso com Group Policy. Caminho da configuração: • Computer Configuration ou User Configuration • Preferences • Windows Settings • Shortcuts Assim como você cria um mapeamento de unidade de rede, impressora ou chave de registro, aqui você cria um novo atalho e define suas propriedades. No exemplo da Figura 5.10, o novo ícone é um atalho para uma URL, levando os usuários diretamente ao site da intranet da empresa. Depois de configurar esse GPO e definir o escopo para que se aplique a todos os computadores ingressados no domínio, você garante que o link para a intranet estará presente em todos os computadores — inclusive em novos dispositivos que forem implantados no futuro. 👉 Em resumo: • O GPO pode distribuir atalhos automaticamente para todos os usuários. • O caminho é Preferences → Windows Settings → Shortcuts. • Pode apontar para URLs, pastas ou aplicativos. • Garante consistência e evita que o helpdesk precise configurar manualmente cada máquina. “Distribuindo um atalho na área de trabalho para todos os computadores” Distribuindo Atalhos na Área de Trabalho Hoje, enviamos um atalho de URL para a área de trabalho de todos os usuários, mas você poderia, da mesma forma, enviar um atalho apontando para um executável de aplicação e armazenar esse ícone em outros locais, como na barra de Inicialização Rápida (Quick Launch) ou até dentro da pasta All Users Startup. A capacidade de controlar atalhos de forma centralizada pode ser extremamente poderosa. 👉 Em resumo: • O GPO não se limita a atalhos de sites, pode também distribuir atalhos de aplicativos ou pastas. • É possível definir a localização do atalho (Desktop, Quick Launch, Startup). • Isso garante consistência e reduz chamados de suporte relacionados a ícones e acessos. Definindo o Escopo de um GPO Mencionei brevemente a capacidade de definir o escopo dos GPOs, que é a possibilidade de determinar quais configurações de GPO precisam ser aplicadas a quais computadores ou usuários em seu ambiente. Essa é provavelmente a parte mais importante do quebra-cabeça da Group Policy para entender e memorizar. Você já viu alguns exemplos de como inserir configurações em GPOs, e há uma abundância de informações na internet com políticas úteis e exatas, além de instruções de como configurá-las. Se houver alguma tarefa específica que você esteja tentando realizar em larga escala, basta recorrer a mecanismos de busca e incluir a palavra GPO junto ao item desejado, e rapidamente encontrará informações sobre como configurar seu novo GPO para executar essa ação. O que esses artigos, documentos da Microsoft e posts em blogs não vão definir para você é até que ponto você deve aplicar essas configurações em sua rede, e como garantir que seu novo GPO não seja abrangente demais. Essa decisão cabe somente a você. Nesta seção, discutiremos as diferentes opções disponíveis em cada GPO que permitem apontar detalhes muito específicos sobre quem deve ou não receber essas configurações. 👉 Em resumo: • Scoping é decidir quem recebe o GPO (usuários, grupos, computadores). • É a parte mais crítica para evitar que políticas sejam aplicadas de forma excessiva ou incorreta. • • Scoping significa definir o escopo de aplicação de uma política de grupo. • • É o processo de escolher quais usuários, grupos ou computadores terão aquela configuração aplicada. • A configuração correta garante que apenas os alvos desejados recebam as políticas. Links Um link de GPO é, sem dúvida, a ferramenta mais importante dentro do seu arsenal de Group Policy. Um link simplesmente pega um GPO e o associa a um local dentro do Active Directory. O GPO que você vinculou começará a aplicar suas configurações aos usuários e dispositivos que estão dentro daquele local. Até agora, criamos vários GPOs dentro da Group Policy, mas ainda não os aplicamos a nada. Isso significa que ainda não vinculamos esses GPOs a nenhum local e, quando o fizermos, é nesse momento que eles serão liberados e começarão a funcionar. Antes de vincular um dos nossos novos GPOs, vamos verificar quais GPOs atualmente se aplicam ao meu computador com Windows 10. Assim, poderemos conferir novamente depois de criar o link e provar para nós mesmos que o novo GPO está realmente fazendo algo. Gpresult Até agora, não falamos sobre como verificar máquinas individuais para descobrir quais políticas podem ou não estar sendo aplicadas a elas. Vamos fazer isso agora. Ao entrar no meu cliente Windows 10, posso abrir o Command Prompt, PowerShell ou Terminal e executar o seguinte comando: Código Gpresult /r Esse comando gera uma quantidade considerável de informações interessantes, mas o que mais nos interessa aqui é a seção chamada Applied Group Policy Objects. Na verdade, você pode notar que existem duas seções nessa saída, cada uma com uma instância de Applied Group Policy Objects: • Uma listada em COMPUTER SETTINGS • Outra em USER SETTINGS Em breve, vamos descrever as diferenças entre configurações de computador e de usuário dentro de um GPO. Mas, para o nosso exemplo agora, quero destacar que a saída no meu cliente de teste mostra que nenhum GPO está sendo aplicado no nível de User Settings, como pode ser visto na Figura 5.11. 👉 Em resumo: • Linkar um GPO significa associá-lo a um local no Active Directory. • Sem o link, o GPO existe mas não tem efeito. • O comando Gpresult /r mostra quais GPOs estão aplicados em um computador, tanto no nível de Computer Settings quanto de User Settings Gpresult com escopo e vinculação de GPOs: Usando Gpresult com Escopo Depois de se familiarizar mais com a Group Policy, você pode querer executar o comando Gpresult e restringir os resultados apenas às configurações de computador ou de usuário. Isso pode ser feito adicionando um parâmetro ao comando: Código Gpresult /r /scope computer Gpresult /r /scope user Continuando com o Link De volta ao GPMC, localize o ponto em que deseja vincular seu novo GPO. No exemplo, vou vincular meu Drive Mappings GPO e mostrar que todas as minhas unidades de rede mapeadas são criadas automaticamente na próxima vez que eu fizer login em uma estação de trabalho. A conta de usuário com a qual estou entrando está dentro de uma OU chamada Accounting Users. Ao localizar a OU Accounting Users, clico com o botão direito e escolho a opção Link an Existing GPO…. Na tela seguinte, encontro o GPO recém-criado e o seleciono. Agora você vinculou o GPO a essa OU específica, e essa alteração entra em vigor imediatamente na sua rede. Na Figura 5.12, é possível ver que o link do GPO aparece listado sob a OU Accounting Users. 👉 Em resumo: • O comando Gpresult pode ser filtrado por escopo (computador ou usuário). • Vincular um GPO significa associá-lo a uma OU no Active Directory. • Após o link, o GPO passa a ser aplicado imediatamente aos objetos daquela OU. Aplicação do GPO após o Link Na próxima vez que os usuários dentro dessa OU fizerem login em um computador ingressado no domínio, suas unidades de rede deverão ser mapeadas automaticamente durante o processo de login. Ao entrar na minha estação de trabalho com Windows 10, constatei que isso realmente aconteceu. Executando novamente o comando: Código gpresult /r fica comprovado que meu GPO foi aplicado com sucesso! 👉 Em resumo: • Depois de vincular o GPO a uma OU, ele passa a ser aplicado imediatamente. • Os usuários daquela OU recebem as configurações na próxima vez que fizerem login. • O comando gpresult /r é a forma prática de verificar se o GPO foi realmente aplicado. Vincular GPOs a múltiplas OUs: Links em múltiplas OUs Você pode vincular um GPO a mais de uma OU. Basta seguir o mesmo processo novamente, desta vez escolhendo uma OU diferente para criar o link. Assim, esse GPO passará a ser aplicado a todas as OUs que tiverem links ativos. Você pode remover links clicando com o botão direito sobre eles e escolhendo Delete. Não se preocupe: excluir um link de GPO não exclui o GPO em si. Outra forma é clicar diretamente no objeto de Group Policy para visualizar e modificar suas propriedades de link. 👉 Em resumo: • Um mesmo GPO pode ser vinculado a várias OUs. • Remover o link não apaga o GPO, apenas interrompe sua aplicação naquela OU. • As propriedades de link podem ser gerenciadas diretamente no objeto de GPO. Ordem de Processamento da Group Policy No exemplo de vinculação de GPO que acabamos de concluir, vinculamos um GPO a uma OU específica. Você provavelmente percebeu em algumas capturas de tela que também existem GPOs vinculados em outros níveis, como na raiz do domínio contoso.local. O que isso significa? Na verdade, quando um computador faz login, existem quatro níveis diferentes de processamento da Group Policy. A localização dos seus links pode fazer uma grande diferença no efeito correto que o GPO terá sobre seus computadores e usuários. Vamos discutir esses quatro níveis de processamento de GPO. Política Local (Local Policy) Se você já trabalhou em TI por algum tempo, é bem provável que tenha seguido algum blog ou fórum que levou a uma modificação via gpedit.msc. Executar gpedit.msc em qualquer sistema Windows abre o Editor de Política de Grupo Local. Esse é o conjunto de objetos e configurações de política que existem em uma máquina individual. Eles podem ser manipulados manualmente via gpedit.msc ou podem ser modificados e sobrescritos por GPOs. O ponto principal é: • Quando o computador Windows inicializa e faz login, a primeira coisa que acontece é o processamento das configurações dentro do Local Group Policy Editor. • Como a Política Local é aplicada primeiro, isso significa que qualquer nível de Group Policy do Active Directory (que vamos discutir em seguida) terá prioridade sobre ela. Em outras palavras: • Seu computador pode ter configurações locais aplicadas. • Mas, milissegundos depois, durante o processo de inicialização, essas configurações locais podem ser sobrescritas pelas políticas do AD. 👉 Em resumo: • O Local Policy é o primeiro nível de processamento. • Configurações locais podem ser substituídas por GPOs vinculados no Active Directory. • A ordem de aplicação é fundamental para entender qual configuração prevalece. políticas em nível de site no Active Directory: Políticas em Nível de Site Lembra-se do Capítulo 3, Active Directory, quando discutimos sobre sites e serviços do AD? Eles entram em cena aqui. Se o seu ambiente for grande o suficiente para conter múltiplos sites, é possível vincular GPOs em nível de site, permitindo que a Group Policy aplique configurações a computadores ou usuários com base no site em que eles estão localizados. Na minha experiência, ter GPOs vinculados a sites é algo relativamente raro, mas é importante manter isso em mente ao solucionar problemas de aplicação de GPOs. Computadores e usuários só receberão políticas de nível de site quando residirem fisicamente dentro desses sites, de acordo com o esquema de endereçamento IP e sub-redes que você definiu dentro de AD Sites and Services. Se um computador receber configurações de GPO baseadas em um link de site, e essas configurações entrarem em conflito com a Política Local, as políticas de nível de site irão sobrescrever a Política Local, tornando-se as novas configurações durante o processo de login. 👉 Em resumo: • Site-level GPOs aplicam políticas com base na localização física (IP/sub-rede). • São raros, mas úteis em ambientes grandes e distribuídos. • Site-level policies têm prioridade sobre Local Policy. Políticas em Nível de Domínio Algumas políticas e configurações são coisas que você deseja aplicar a todas as máquinas ou usuários em um domínio inteiro, e o local apropriado para essas configurações são os GPOs em nível de domínio. Ao falarmos sobre esses diferentes níveis de política, é importante destacar que os GPOs em si não são diferentes. Um GPO é um GPO. O que muda é o nível em que o GPO é vinculado, e é isso que estamos discutindo em relação à hierarquia. Os links criados na raiz, ou nível superior, de um domínio dentro do Group Policy Management vão, por padrão, tentar se aplicar a qualquer usuário ou computador que faça parte do domínio. Existem vários fatores que podem filtrar os GPOs vinculados ao domínio, mas, em geral, se você vincular um GPO ao nome do domínio, precisa estar ciente de que as configurações dentro desse GPO podem se aplicar a todas as estações de trabalho, todos os servidores e todos os usuários. Se você observar algumas páginas anteriores com capturas de tela do GPMC, verá que meus GPOs de IPAM estão todos vinculados diretamente ao contoso.local. Esses são conhecidos como links em nível de domínio. Seguindo o fluxo de exemplo de um processo de login em computador, as políticas em nível de domínio são aplicadas depois das políticas em nível de site. Assim, quaisquer configurações recebidas via políticas de site agora são adicionadas ou, em caso de conflito, sobrescritas pelas políticas de domínio. 👉 Em resumo: • Domain-level GPOs aplicam configurações a todo o domínio. • O GPO é o mesmo; o que muda é o nível de vinculação. • Vincular ao domínio significa que todos os usuários e computadores podem ser afetados. • Ordem de aplicação: Local → Site → Domain → OU. Quadro hierárquico completo mostrando a ordem de aplicação (Local, Site, Domain, OU) com exemplos práticos de cada nível. Políticas em Nível de Domínio Algumas configurações e políticas são do tipo que você deseja aplicar a todos os computadores ou usuários de um domínio inteiro. O local apropriado para essas configurações são os GPOs em nível de domínio. Ao falarmos sobre esses diferentes níveis de políticas, é importante destacar que os GPOs em si não são diferentes. Um GPO é sempre um GPO. O que muda é o nível em que ele é vinculado, dentro da hierarquia do Active Directory. Como funciona • Links criados na raiz do domínio (ou seja, no nível superior dentro do Group Policy Management) vão, por padrão, tentar se aplicar a todos os usuários e computadores que fazem parte do domínio. • Existem filtros e outras formas de limitar a aplicação, mas, em geral, se você vincular um GPO ao nome do domínio, precisa estar ciente de que as configurações dentro dele podem se aplicar a todas as estações de trabalho, servidores e usuários. • Por exemplo, no ambiente contoso.local, os GPOs de IPAM estão vinculados diretamente à raiz do domínio. Esses são chamados de links em nível de domínio. Ordem de processamento Seguindo o fluxo de login de um computador: • Primeiro são aplicadas as políticas locais (Local Policy). • Depois, as políticas em nível de site (Site-level Policy). • Em seguida, entram as políticas em nível de domínio (Domain-level Policy). Isso significa que qualquer configuração recebida via políticas de site pode ser adicionada ou sobrescrita pelas políticas de domínio, caso haja conflito. 👉 Em resumo: • Domain-level GPOs são aplicados a todo o domínio. • São poderosos, mas precisam ser usados com cautela para não impactar indevidamente todos os usuários e máquinas. • Na hierarquia de processamento, eles vêm depois das políticas de site e podem sobrescrevê-las. Vamos organizar a hierarquia completa de ordem de processamento da Group Policy em um quadro bem claro, mostrando quem prevalece em caso de conflito: 🗂 Ordem de Processamento da Group Policy Nível Descrição Prioridade Exemplo de Aplicação Local Policy Configurações feitas diretamente no computador via gpedit.msc. Mais fraca (pode ser sobrescrita por qualquer nível superior). Ajustes manuais em uma estação de trabalho. Site-level Policy GPOs vinculados a Sites do Active Directory, baseados em IP/sub-redes. Sobrescreve Local Policy. Configurações específicas para filiais ou localidades. Domain-level Policy GPOs vinculados à raiz do domínio. Afetam todos os usuários e computadores do domínio. Sobrescreve Site-level e Local Policy. Políticas globais de senha, bloqueio de tela, restrições gerais. OU-level Policy GPOs vinculados a Organizational Units (OUs). Mais forte (sobrescreve todos os níveis anteriores). Configurações específicas para departamentos, como Financeiro ou RH. 🔑 Regras importantes • Último nível processado prevalece: OU-level tem mais força que Domain-level, que tem mais força que Site-level, que tem mais força que Local Policy. • Conflitos são resolvidos pela hierarquia: se duas políticas definem valores diferentes, vence a que está mais abaixo na ordem (mais próxima do objeto). • Filtros e permissões: mesmo em níveis altos (como domínio), você pode usar Security Filtering ou WMI Filtering para restringir a aplicação. 👉 Em resumo: • Local → Site → Domain → OU é a ordem. • OU-level é o mais específico e, portanto, o mais forte. • Entender essa hierarquia é essencial para evitar que um GPO seja aplicado de forma incorreta ou abrangente demais. Políticas em Nível de OU (OU-level policies) Começamos nossa jornada de login com as configurações de Política de Grupo Local (Local Group Policy), que foram então adicionadas ou sobrescritas pelas políticas em nível de site (Site-level GPOs). Essas, por sua vez, foram novamente adicionadas (ou sobrescritas, em caso de conflito) pelas políticas em nível de domínio (Domain-level GPOs). Você já deve imaginar para onde isso está indo: agora entram em cena as políticas em nível de OU (Organizational Unit), aplicadas sobre as políticas de domínio. As OUs, como você sabe, são pastas de contenção para contas de computador e de usuário que estão ingressadas no domínio. A maioria das empresas aproveita o uso de múltiplas OUs dentro do Active Directory para diferenciar tipos de máquinas e usuários. Por exemplo: • Servidores são separados de estações de trabalho. • Usuários de contabilidade são diferentes dos usuários de RH. O aninhamento de OUs também é uma prática comum. Assim como criar pastas dentro de outras pastas no File Explorer, você pode usar o AD Users and Computers para criar OUs dentro de outras OUs. Isso é importante tanto para a organização dos objetos do domínio quanto para a Group Policy. Vincular GPOs a OUs específicas nos dá flexibilidade para aplicar diferentes configurações a diferentes grupos de pessoas ou máquinas. • Quando um GPO é vinculado a uma única OU, apenas os computadores ou usuários dentro dessa OU (ou em OUs descendentes dela) serão afetados pelo GPO. • É possível ter múltiplos GPOs vinculados à mesma OU. • OUs aninhadas fornecem uma camada adicional nesse fluxo de GPOs. Lembre-se: a regra geral é que a Group Policy é processada de cima para baixo. Portanto, GPOs vinculados a uma OU aninhada normalmente terão maior peso do que GPOs vinculados a uma OU em nível superior. 👉 Em resumo: • OU-level policies são o nível mais granular e flexível de aplicação. • Permitem personalizar políticas para grupos específicos de usuários ou computadores. • OUs aninhadas criam hierarquia, e as políticas mais próximas do objeto (usuário/computador) tendem a prevalecer. Security Filtering Agora que você criou um GPO e o vinculou a uma OU específica, já tem informação suficiente para começar a usar a Group Policy em seu ambiente. Usar links para determinar quais máquinas ou usuários recebem quais políticas é o método mais comum que vejo administradores utilizarem. Mas existem muitas circunstâncias em que você pode querer levar o filtragem um passo além. Imagine que você criou um novo GPO e o vinculou a uma OU que contém todos os computadores desktop. Depois, você decide que apenas alguns desses computadores precisam da política e outros não. Seria trabalhoso ter que dividir essas máquinas em duas OUs diferentes apenas por causa dessa política. É aí que entra o Security Filtering. O Security Filtering permite filtrar um GPO para objetos específicos do Active Directory. Em qualquer GPO do diretório, você pode definir filtros para que ele se aplique apenas a determinados usuários, computadores ou até grupos de usuários e computadores. Na prática, usar grupos é especialmente útil. Por exemplo, no caso do Drive Mappings GPO, ele está atualmente vinculado à OU Accounting Users. Mas e se eu quisesse filtrar esse GPO de outra forma? Em vez de limitar o escopo a uma única OU, eu poderia vinculá-lo ao domínio inteiro (contoso.local). Isso faria com que o GPO fosse aplicado a tudo — a menos que eu utilizasse o Security Filtering para definir quais contas ou grupos realmente devem recebê-lo. Boas práticas • Eu sempre tomo minhas decisões de Security Filtering antes de criar o link. • Isso porque os links entram em vigor imediatamente, e configurar o filtro primeiro garante a distribuição correta desde o início. Ao clicar em qualquer GPO dentro do GPMC, você verá informações sobre ele. Na aba Scope, aparecem tanto os links existentes quanto as informações de Security Filtering. Todos os novos GPOs vêm com Authenticated Users definido no Security Filtering. Isso significa, essencialmente, “todos os usuários e computadores do domínio”. Lembre-se: significa ambos! No exemplo, o Drive Mappings GPO está vinculado à OU Accounting Users e tem Authenticated Users listado no Security Filtering. Se eu simplesmente removesse o link da OU e criasse um novo link em nível de domínio, esse GPO começaria imediatamente a se aplicar a todas as contas de usuário do domínio inteiro. 👉 Em resumo: • Security Filtering permite restringir um GPO a usuários, computadores ou grupos específicos. • É mais flexível do que depender apenas de OUs. • Por padrão, todo GPO novo aplica-se a Authenticated Users (todos os usuários e computadores). • A melhor prática é definir o filtro antes de criar o link, para evitar impacto indesejado. Ajustando o Security Filtering Em vez de simplesmente criar o link em nível de domínio, vou primeiro ajustar minhas configurações de Security Filtering. Todos os usuários de contabilidade fazem parte de um grupo de segurança chamado Acct Group (fui bem criativo nesse nome!). Ao adicionar o Acct Group ao Security Filtering deste GPO e REMOVER Authenticated Users, significa que agora, não importa onde eu vincule esse GPO, apenas os membros do grupo Acct Group irão receber as configurações do GPO. Depois de adicionar o Acct Group ao Security Filtering, posso com segurança vincular o GPO ao nível superior do meu domínio e permanecer confiante de que somente os membros do Acct Group receberão as configurações desse GPO. 👉 Em resumo: • Authenticated Users = todos os usuários e computadores do domínio. • Substituir por um grupo específico (como Acct Group) garante que apenas os membros desse grupo recebam a política. • Isso permite vincular o GPO até mesmo ao nível de domínio sem risco de impactar todos os objetos. Aba Settings Outro recurso interessante, acessível com apenas um clique, é a aba Settings na mesma tela do GPMC. Ao clicar nessa aba, são exibidas todas as configurações atualmente definidas dentro do seu GPO. Isso é muito útil para revisar GPOs criados por outra pessoa e verificar quais configurações estão presentes na política. WMI Filtering Usando uma combinação de links bem planejados e Security Filtering para restringir o escopo dos seus GPOs, você provavelmente conseguirá planejar e aplicar configurações de política de forma perfeita em cerca de 90% dos casos. Os próximos subtópicos abordam os 10% restantes, cobrindo técnicas avançadas de filtragem que permitem ser ainda mais granular na aplicação de GPOs. O WMI Filtering é uma ferramenta genial — embora um pouco confusa — para definir de forma ainda mais precisa a aplicação de GPOs. • Os filtros WMI aproveitam as informações do Windows Management Instrumentation (WMI), presentes em todo computador Windows, e usam esses dados para filtrar configurações de GPO. • É possível criar filtros que verificam: o Versão do sistema operacional o Tipo de CPU o Quantidade de RAM o Espaço disponível em disco o Até mesmo informações como firmware da BIOS Uma vez definido um filtro WMI, você pode selecioná-lo para cada GPO na seção WMI Filtering, localizada logo abaixo de Security Filtering dentro do GPMC. Exemplos práticos • “Instalar este software pesado apenas se houver pelo menos 5 GB de espaço livre em disco.” • “Aplicar estas configurações de firewall apenas em máquinas que executam Windows Server.” • Identificar se uma máquina está rodando hardware móvel (laptops/tablets) e aplicar o GPO apenas nesses dispositivos, excluindo desktops. Considerações • O WMI Filtering coleta informações de outros componentes do sistema operacional. • Isso faz com que o processamento da Group Policy leve mais tempo e consuma mais CPU. • Pode causar aumento no uso de recursos e logins mais lentos, já que o processamento ocorre em segundo plano. Criar filtros WMI é entrar em um nível mais profundo da Group Policy. Para instruções detalhadas, o autor recomenda consultar a seção Summary no final do capítulo, onde há referência a uma publicação dedicada inteiramente à Group Policy. 👉 Em resumo: • Settings tab mostra todas as configurações de um GPO. • WMI Filtering permite aplicar GPOs com base em características técnicas da máquina. • É poderoso, mas pode impactar desempenho e tempo de login. Item-level Targeting Links, Security Filtering e WMI Filtering são ótimas formas de determinar quais GPOs se aplicam a quais computadores e usuários. Mas e se você precisar ir além? Imagine que você tem um único GPO que contém múltiplas configurações, e deseja que apenas algumas dessas configurações se apliquem a certos usuários ou computadores, enquanto outras configurações dentro da mesma política se apliquem a diferentes usuários e computadores. Um exemplo clássico disso é um Drive Mappings GPO. É comum colocar todas as unidades de rede mapeadas em um único GPO no domínio e chamá-lo de Mapped Drives ou algo parecido. Também é comum que nem todos os usuários precisem de todas as unidades mapeadas. Como resolver? Uma forma seria dividir esse GPO em vários GPOs menores, criando um GPO separado para cada letra de unidade e, então, usar links e filtros para determinar quais usuários recebem quais unidades. Mas isso resultaria em uma quantidade enorme de GPOs para gerenciar. É aí que entra o Item-level targeting. Onde encontrar Você talvez se lembre que existe uma aba especial chamada Common dentro de muitas configurações de GPO. Um dos cinco recursos dentro dessa aba é justamente o Item-level targeting, que é exatamente o que precisamos para tornar nosso GPO de mapeamento de drives mais eficiente. Exemplo prático No mesmo Drive Mappings GPO que temos usado como exemplo, sabemos que ele contém múltiplas letras de unidade. Atualmente, os usuários do grupo Acct Group recebem todas essas unidades mapeadas. Mas vamos supor que eu queira que o Acct Group receba apenas uma dessas unidades (por exemplo, a unidade P:) e não as demais. • Editando o GPO, eu dou um duplo clique no mapeamento da unidade P:. • Vou até a aba Common. • Marco a opção Item-level targeting e clico no botão Targeting…. • Dentro do Targeting Editor, escolho New Item e encontro uma lista extensa de critérios que podem ser usados para definir parâmetros adicionais de direcionamento. 👉 Em resumo: • Item-level targeting permite aplicar configurações específicas dentro de um mesmo GPO apenas a determinados usuários, grupos ou computadores. • Evita a necessidade de criar vários GPOs separados para cada configuração. • É especialmente útil em cenários como mapeamento de drives, onde diferentes usuários precisam de diferentes unidades. Item-level Targeting com grupos de segurança Quero instruir este GPO para que a unidade P: seja mapeada apenas para usuários que fazem parte do grupo de segurança Acct Group. Ao escolher adicionar um novo grupo de segurança ao meu Item-level targeting (ILT), defino o Acct Group. Assim, como mostrado na Figura 5.17, as configurações de ILT da unidade P: foram atualizadas para que somente se o usuário for membro do grupo de segurança CONTOSO\Acct Group, ele receberá o mapeamento da unidade P: ao fazer login. 👉 Em resumo: • O Item-level targeting permite aplicar configurações específicas dentro de um GPO apenas a determinados grupos ou usuários. • No exemplo, apenas membros do grupo Acct Group recebem o mapeamento da unidade P:. • Isso garante granularidade sem precisar criar vários GPOs separados Consolidando o GPO com ILT Repita esse processo para o restante das letras de unidade dentro do seu GPO, e você terá agora um único GPO contendo todos os mapeamentos de unidades de rede para toda a organização. Você pode vincular esse GPO ao domínio e deixá-lo security-filtered para Authenticated Users (como é por padrão). Ainda assim, com base no Item-level targeting (ILT), apenas as letras de unidade que correspondem aos grupos apropriados serão mapeadas para cada usuário que fizer login. ILT é incrível! (Uau, mal posso acreditar que acabei de escrever isso…). 👉 Em resumo: • Com ILT, você pode manter um único GPO centralizado para todos os mapeamentos de drives. • O Security Filtering garante que apenas usuários autenticados sejam considerados. • O ILT dentro de cada configuração decide qual grupo recebe qual unidade. • Resultado: menos GPOs para gerenciar e mais granularidade na aplicação. Delegation Considere este cenário: a liderança executiva da sua empresa pediu para você aplicar restrições de segurança em todos os computadores do domínio. Isso parece um trabalho perfeito para a Group Policy! Exceto que, como eles são a liderança e não querem que seus próprios sistemas limitem a navegação no Instagram ou a configuração de planos de fundo com gatinhos sorridentes, exigiram que essas configurações de bloqueio se apliquem a todos exceto aos membros do grupo Leadership no Active Directory. Nós já conhecemos várias formas de filtrar GPOs para determinados usuários ou grupos, mas como filtrar para todos, exceto um grupo específico? Para isso, acessamos o GPMC, clicamos no GPO em questão e visitamos a aba chamada Delegation. Se o seu GPO tiver Security Filtering personalizado, você verá os nomes desses usuários ou grupos também na tela de Delegation. Na prática, quando configuramos Security Filtering, o GPMC está realmente ajustando permissões de delegação no GPO em segundo plano. Exemplo prático No meu Drive Mappings GPO, que ainda está filtrado para o grupo Acct Group, naveguei até a aba Delegation. Clicando no botão Advanced… no canto inferior esquerdo, entro nos detalhes avançados de segurança por trás da delegação e das permissões desse GPO. Na Figura 5.18, é possível ver que o grupo Acct Group atualmente possui as permissões Read e Apply group policy configuradas como Allow. Isso foi exatamente o que aconteceu quando adicionei o Acct Group ao Security Filtering. Esse conjunto de permissões é o que faz a mágica acontecer: sempre que alguém faz login em um computador do domínio, ele tem permissão para ler as configurações desse GPO e também para aplicar as configurações. 👉 Em resumo: • A aba Delegation mostra como as permissões de leitura e aplicação são configuradas nos bastidores. • O Security Filtering nada mais é do que uma forma simplificada de manipular essas permissões. • É possível usar Delegation para criar exceções, como “aplicar a todos, exceto ao grupo Leadership”. Delegation – Negação de Permissões Voltando ao ponto principal: no mundo Microsoft, uma negação de permissão sempre tem prioridade sobre uma permissão concedida. Se você precisa negar que um usuário, computador ou grupo receba as configurações de um determinado GPO, basta adicioná-los às permissões de Delegation e marcar a opção Deny para Apply group policy. Mesmo que esse usuário ou grupo tenha permissão para aplicar a Group Policy por outra entrada de permissão na lista, ao marcar Deny, eles serão impedidos de receber esse GPO. Exemplo prático Na captura de tela da Figura 5.18, vemos que o grupo Leadership foi configurado com Deny para aplicar o Desktop Wallpaper GPO. Isso significa que, quando qualquer membro do grupo Leadership fizer login, não receberá as restrições de papel de parede que estão em vigor para o restante dos usuários. 👉 Em resumo: • Deny sempre vence Allow. • Usar Delegation com Deny é a forma de excluir grupos específicos da aplicação de um GPO. • No exemplo, o grupo Leadership fica livre das restrições de papel de parede, enquanto todos os demais usuários continuam recebendo-as. Delegation – Use with Caution ⚠️ Delegação – Use com cautela Criar negações de GPO dentro da aba Delegation funciona muito bem, mas deve ser usado com bastante cuidado. É muito fácil esquecer ou deixar passar essas configurações no futuro. Já auxiliei diversos administradores em troubleshooting de GPOs que pareciam não estar sendo aplicados corretamente, e no fim descobrimos que o problema vinha justamente de uma permissão negada dentro da Delegation. Esse detalhe pode causar bastante dor de cabeça, já que a negação sempre prevalece sobre qualquer permissão concedida. 👉 Em resumo: • Delegation com Deny é útil para excluir grupos específicos da aplicação de um GPO. • Mas é fácil perder o controle dessas configurações, especialmente em ambientes grandes. • Sempre documente e revise suas negações, para evitar problemas futuros de aplicação de políticas. - Configurações do computador e configurações do usuário Diferença entre Computer Configuration e User Configuration no GPO Depois de explorar os GPOs por alguns minutos, você provavelmente percebeu que o Group Policy Management Editor é dividido em duas seções principais. Ao navegar dentro de um GPO para encontrar a configuração que deseja aplicar, a primeira decisão que você precisa tomar é se está trabalhando em Computer Configuration ou em User Configuration. Computer Configuration • Aplica-se a máquinas (independentemente de quem faça login). • Configurações típicas incluem: o Políticas de segurança do sistema o Instalação de software em nível de máquina o Configurações de rede o Scripts de inicialização • Exemplo: definir que todos os computadores do domínio usem um firewall específico. User Configuration • Aplica-se a usuários (independentemente do computador em que façam login). • Configurações típicas incluem: o Preferências de desktop o Mapeamento de drives de rede o Scripts de logon/logoff o Restrições de interface (menu iniciar, painel de controle etc.) • Exemplo: mapear automaticamente a unidade P: para todos os usuários do grupo Acct Group. Importância da distinção • Entender essa diferença é essencial não apenas para encontrar a configuração correta, mas também para garantir que o GPO esteja vinculado ao local certo e se aplique ao tipo de objeto adequado. • Se você criar uma configuração de User Policy mas vinculá-la a uma OU que contém apenas computadores, ela não terá efeito. • Da mesma forma, uma configuração de Computer Policy não afetará usuários se vinculada a uma OU que contém apenas contas de usuário. 👉 Em resumo: • Computer Configuration = políticas aplicadas ao dispositivo. • User Configuration = políticas aplicadas ao usuário. • Sempre verifique se o GPO está vinculado ao tipo de objeto correto (computador ou usuário) para que funcione como esperado. Vamos analisar brevemente essas opções. Configuração de Computadores Configurações de GPO – Computer vs. User Todas as configurações de GPO listadas sob Computer Configuration são, naturalmente, configurações que podem ser aplicadas aos computadores ingressados no domínio. Mas atenção: nem todas as configurações de GPO são aplicadas a computadores. • Muitas configurações realmente se aplicam ao objeto computador no Active Directory, e todas elas ficam dentro de Computer Configuration. • Algumas configurações podem ser definidas tanto em nível de computador quanto em nível de usuário. • Em outros casos, você pode encontrar opções semelhantes em Computer Configuration e em User Configuration, mas que realizam a tarefa de formas ligeiramente diferentes. Exemplo prático – Bloqueio de tela por inatividade Um exemplo clássico é a política de idle screen lockout (bloqueio automático da tela). É comum que empresas exijam que as telas dos computadores se bloqueiem após alguns minutos de inatividade. Assim, se um usuário se afastar e esquecer de bloquear manualmente, o sistema se encarrega de fazê-lo. Se você for responsável por criar essa política, precisa decidir se ela será aplicada em nível de computador ou de usuário. • Computer-level: a tela bloqueia após 15 minutos, não importa quem esteja logado. • User-level: a tela bloqueia após 15 minutos, mas a configuração acompanha o usuário, independentemente do computador em que ele faça login. Configuração em nível de computador Se você decidir que o melhor método é aplicar em nível de computador, a configuração correta dentro do GPO será: Código Computer Configuration | Policies | Windows Settings | Security Settings | Local Policies | Security Options Interactive logon: Machine inactivity limit = Enabled (900 segundos = 15 minutos) 👉 Em resumo: • Nem todas as configurações de GPO são para computadores; algumas são para usuários. • Algumas existem em ambos os níveis, mas com diferenças sutis. • O exemplo do idle screen lockout mostra como escolher entre aplicar a política em nível de máquina ou de usuário, dependendo da necessidade da organização. User Configuration – Configurações aplicadas ao usuário Por outro lado, muitas configurações de GPO não se aplicam ao objeto computador, mas sim ao usuário de domínio que está fazendo login. As configurações de User Configuration acompanham a conta do usuário e se aplicam a qualquer estação de trabalho em que ele faça login. Exemplo prático – Drive Mappings GPO No caso do Drive Mappings GPO, todas as configurações de unidades de rede mapeadas que criamos estão sob User Configuration. Isso significa que esses mapeamentos de drives vão tentar se aplicar em qualquer computador em que o usuário fizer login. 👉 Importante: não é possível criar mapeamentos de drives de rede como configuração nativa dentro de Computer Configuration. Exemplo prático – Bloqueio de tela por inatividade Revisitando o exemplo do idle screen lockout, suponha que você queira que o bloqueio de tela aconteça para um determinado tipo de usuário (ou até para todos), independentemente do computador em que façam login. Nesse caso, não existe uma configuração específica de “screen-lock” dentro de User Configuration, mas a recomendação é ser criativo com as configurações de protetor de tela, que pertencem ao escopo de usuário. Se você configurar as seguintes quatro opções de GPO, terá o mesmo comportamento do Machine inactivity limit em nível de computador, mas aplicado ao usuário: Código User Configuration | Policies | Administrative Templates | Control Panel | Personalization Enable screen saver = Enabled Force specific screen saver = Definir qual protetor de tela será usado Screen saver timeout = Enabled (900 segundos = 15 minutos) Password protect the screen saver = Enabled 👉 Em resumo: • User Configuration aplica-se ao usuário, independentemente do computador. • É ideal para cenários em que a configuração precisa “seguir” o usuário. • Exemplo: mapeamento de drives de rede ou bloqueio de tela via protetor de tela. Vinculando GPOs de acordo Ao procurar configurações de GPO para aplicar em seu ambiente, às vezes você não terá escolha entre Computer Configuration ou User Configuration, já que algumas opções só existem em um dos dois locais. Outras vezes, você encontrará configurações que podem ser aplicadas em ambos os níveis, e a decisão dependerá de onde você deseja que a política seja aplicada. Essa decisão está diretamente ligada ao local onde você vai vincular o GPO: Regras de vinculação • Se o GPO contém configurações de Computer Configuration o Ele só pode ser aplicado a objetos de computador. o Portanto, deve ser vinculado a OUs que contenham computadores, ou ao nível de domínio (que cobre todas as OUs). • Se o GPO contém configurações de User Configuration o Ele só pode ser aplicado a objetos de usuário. o Assim, qualquer link criado deve ser para OUs que contenham usuários. Boas práticas • É geralmente considerado melhor prática criar GPOs como computer-based ou user-based, evitando misturar os dois tipos de configuração em um único GPO. • Um GPO pode conter muitas configurações diferentes, e se for vinculado em um nível alto, até poderia aplicar tanto configurações de usuário quanto de computador. • Porém, isso aumenta a complexidade administrativa e dificulta o gerenciamento. • Por isso, recomenda-se que cada GPO contenha apenas configurações de computador ou apenas configurações de usuário. 👉 Em resumo: não misture os dois tipos em um único GPO. Loopback Policy Processing Processamento de loopback da Política de Grupo Existe uma função especial dentro dos GPOs que essencialmente mistura configurações de computador e de usuário, usada em casos específicos. Ela é chamada de Loopback Policy Processing. Quando usar Imagine que você precise aplicar configurações de User Configuration a determinados computadores, mas deseja que esses computadores tratem essas configurações como se fossem de Computer Configuration. Isso significa que qualquer usuário que fizer login nesses computadores receberá as mesmas políticas, independentemente de suas próprias configurações de usuário. Exemplo prático – Kiosk workstation • Laura, do RH, tem um conjunto de políticas aplicadas em sua estação de trabalho diária. • Mas, ocasionalmente, ela faz login em um kiosk workstation público no saguão da empresa. • Normalmente, ao logar nesse kiosk, o GPO aplicaria todas as políticas de usuário que Laura já recebe em sua máquina pessoal. • Com o Loopback Policy Processing habilitado, você pode criar um GPO de User Configuration e vinculá-lo ao computador kiosk. • Assim, Laura receberá as configurações especiais de restrição do kiosk, mesmo que não as receba em sua estação de trabalho normal. Isso evita que ela tenha acesso a documentos sensíveis ou permissões indevidas quando estiver usando o computador público. Outro cenário comum O Loopback Processing também é bastante utilizado em Remote Desktop Servers (RDSH). Nesses casos, você aplica GPOs para que todos os usuários que fizerem login no servidor de RDS recebam configurações específicas, independentemente de suas políticas pessoais. 👉 Em resumo: • Loopback Policy Processing força configurações de usuário a se comportarem como configurações de computador. • É útil em cenários de kiosks públicos ou servidores de Remote Desktop. • Permite maior controle sobre ambientes compartilhados ou críticos. Policy versus Preference Política versus Preferência Existe uma distinção importante que todo administrador de Group Policy precisa entender sobre as configurações de GPO. Dentro de um GPO, existem dois tipos diferentes de configurações: Policies e Preferences. Esses dois tipos se comportam de maneiras bem diferentes. Agora que já entendemos a diferença entre Computer Configuration e User Configuration, o próximo nível que você vai notar dentro do Group Policy Management Editor são as subpastas chamadas Policies e Preferences. Policies • São configurações obrigatórias. • Quando aplicadas, o sistema força o comportamento definido. • Exemplo: definir que a tela bloqueie após 15 minutos de inatividade. • O usuário não consegue alterar ou remover essa configuração, pois ela é imposta pelo GPO. Preferences • São configurações recomendadas ou sugeridas. • O GPO aplica a configuração, mas o usuário pode alterá-la depois. • Exemplo: definir um atalho no desktop ou configurar uma impressora padrão. • Se o usuário mudar manualmente, o GPO não força a reversão (a menos que seja configurado para atualizar sempre). 👉 Em resumo: • Policies = obrigatórias, imutáveis. • Preferences = opcionais, flexíveis. • Saber a diferença é essencial para aplicar GPOs corretamente e evitar frustrações, tanto para administradores quanto para usuários. Policies – Comportamento e Remoção As managed policies, listadas na seção Policies tanto em Computer Configuration quanto em User Configuration, geralmente se comportam como verdadeiras regras obrigatórias. Essas são configurações que você aplica esperando resultados consistentes: elas forçam o comportamento definido e nada que o usuário tente fazer pode alterá-las. Quando você remove um GPO de um sistema, essas políticas também se comportam de forma previsível: elas se removem ativamente. Como funciona na prática • Ao aplicar configurações de Policy em um GPO e vinculá-lo a um local, você espera que essas configurações sejam impostas aos computadores ou usuários filtrados. • Isso funciona tanto para Policies quanto para Preferences enquanto o GPO está ativo. • Mas quando o GPO deixa de se aplicar (por exemplo, se o link for removido ou o Security Filtering for ajustado), surge a diferença: 👉 Policy items: • São monitorados pelo Group Policy em quatro áreas especiais do Windows Registry. • Durante os ciclos de atualização da Group Policy, essas áreas são reprocessadas. • Isso garante que, se o GPO não se aplicar mais, as configurações sejam removidas automaticamente. 👉 Preferences (que veremos em seguida): • Não se removem automaticamente. • Podem permanecer no sistema mesmo após o GPO deixar de ser aplicado. Observação importante Nem todas as configurações listadas sob a pasta Policies são totalmente gerenciadas. Existem managed policies e unmanaged policies: • As managed policies se removem corretamente quando o GPO é desativado. • Algumas unmanaged policies, mesmo dentro da pasta Policies, podem falhar em remover suas configurações ao desvincular o GPO. • Isso depende do tipo de configuração e de como ela manipula o cliente. 👉 Em resumo: • Policies = obrigatórias, imutáveis e geralmente se removem quando o GPO deixa de se aplicar. • Preferences = opcionais, flexíveis e não se removem automaticamente. • Saber distinguir entre managed e unmanaged policies é essencial para evitar surpresas no comportamento do GPO. Preferences – Comportamento e Persistência Enquanto as Policies forçam configurações e se removem automaticamente quando o GPO deixa de se aplicar, as Preferences funcionam de forma diferente: • Preferences são reversíveis pelo usuário. O GPO aplica a configuração, mas o usuário pode alterá-la manualmente depois. • São ideais para ajustes que facilitam a vida do usuário, mas que não precisam ser obrigatórios. Exemplo: criar atalhos no desktop, definir impressoras padrão ou mapear drives de rede. Diferença fundamental em relação às Policies • Policies: o Forçam o comportamento. o Se o GPO deixar de se aplicar, a configuração é removida automaticamente. • Preferences: o Aplicam a configuração, mas permitem alteração manual. o Não se removem automaticamente quando o GPO é desvinculado ou excluído. o Permanecem “grudadas” (sticky) no sistema até que sejam alteradas manualmente pelo usuário ou substituídas por outro GPO. Exemplo prático Se você configurar uma Preference para adicionar um atalho no desktop: • O usuário pode apagar esse atalho se quiser. • Se o GPO for removido, o atalho continuará existindo. • Para reverter ao estado original, será necessário que o usuário remova manualmente ou que você crie outro GPO para desfazer a configuração. 👉 Em resumo: • Policies = obrigatórias, auto-removíveis. • Preferences = opcionais, persistentes (“sticky”). • Saber essa diferença é essencial para evitar surpresas quando GPOs são removidos ou alterados. Default Domain Policy Dentro do Group Policy Management Console (GPMC), você já deve ter notado um GPO especial vinculado à raiz do domínio chamado Default Domain Policy. Esse GPO vem pré-instalado em qualquer ambiente Active Directory — a menos que um administrador o tenha excluído (o que não é recomendado). Características principais • O Default Domain Policy aplica-se a todos os usuários e computadores do domínio. • Ele já vem habilitado por padrão e, portanto, qualquer configuração adicionada nele será aplicada globalmente. • É comum que empresas editem esse GPO para impor políticas globais de senha ou regras de segurança universais. Problema comum Muitos administradores menos experientes acabam colocando diversas configurações dentro do Default Domain Policy, por não se sentirem confortáveis em criar e vincular novos GPOs. Isso funciona, mas cria riscos: • Todas as configurações aplicam-se a todos os usuários e máquinas, incluindo servidores. • Com o tempo, isso gera complexidade administrativa e pode causar problemas sérios. Regra de ouro Minha recomendação geral é: • Nunca edite o Default Domain Policy, exceto para configurar políticas globais de senha (expiração, complexidade, histórico). • Para qualquer outra configuração, crie um novo GPO e vincule-o ao local apropriado. Exemplo – Configuração de senha global Se você realmente precisar configurar uma política de senha única para todo o domínio, edite o Default Domain Policy e navegue até: Código Computer Configuration | Policies | Windows Settings | Security Settings | Account Policies | Password Policy Aqui você pode definir: • Expiração de senha • Complexidade mínima • Histórico de senhas 👉 Em resumo: • O Default Domain Policy é especial e deve ser usado com extrema cautela. • Melhor prática: somente políticas globais de senha. • Para qualquer outra configuração, crie um GPO separado. Default Domain Policy – Password Settings Dentro do Default Domain Policy, você encontra a lista de configurações que compõem a Password Policy do seu domínio. Essas configurações são o comportamento padrão de um ambiente Windows Server recém-instalado e já estão ativas, mesmo sem nenhuma ação intencional do administrador. Como funciona • Ao dar duplo clique em qualquer configuração, você pode modificá-la. • Essa alteração passa a valer imediatamente para todos os computadores ingressados no domínio. • Exemplo: o comprimento mínimo de senha vem definido por padrão em 7 caracteres. o Se você alterar para 14 caracteres, todos os usuários terão que atender a esse requisito na próxima vez que redefinirem suas senhas. Atenção ao editar Embora o Default Domain Policy seja uma forma rápida e fácil de configurar ajustes globais, é preciso cautela: • Qualquer mudança feita aqui afeta todos os usuários e computadores do domínio, inclusive servidores e administradores. • Muitas vezes, você criará políticas que não precisam se aplicar a todos. • Nesses casos, é altamente recomendado não usar o Default Domain Policy. • Em vez disso, crie um novo GPO específico para a tarefa desejada e vincule-o ao local apropriado. 👉 Em resumo: • O Default Domain Policy já vem com configurações de senha padrão. • Alterações feitas nele têm efeito imediato e universal. • Melhor prática: use-o apenas para políticas globais de senha. • Para qualquer outra configuração, crie um GPO separado. Administrative Templates Modelos Administrativos Quando você edita um GPO e abre o Group Policy Management Editor, ao expandir a pasta Policies em Computer Configuration ou User Configuration, encontrará uma subpasta chamada Administrative Templates. Muitos administradores pensam que ela é apenas mais uma coleção de configurações, mas na verdade ela é personalizável e mostra a flexibilidade do Group Policy. O que são Administrative Templates? • Cada configuração dentro de Administrative Templates é carregada a partir de arquivos de modelo chamados ADMX. • Esses arquivos ficam armazenados nos domain controllers e contêm todas as informações necessárias para exibir as opções no editor de GPO: o Campos de seleção o Caixas de drop-down o Textos de descrição • Junto com cada ADMX existe um arquivo ADML, que define o idioma das configurações. 👉 Em versões antigas do Windows (XP e anteriores), usava-se ADM files em vez de ADMX/ADML. Hoje, ambientes modernos (Windows 7 em diante) trabalham apenas com ADMX/ADML. Implementando ADMX/ADML Existem dois cenários principais em que você pode precisar mexer com ADMX/ADML: 1. Atualização de versão do Windows Server o Cada nova versão (2012, 2016, 2019, 2022, 2025) traz novos e atualizados GPOs. o Ao instalar um novo domain controller, o processo ADPrep atualiza o schema e popula os novos templates. o Mas se o novo servidor não for um DC, você pode precisar copiar manualmente os arquivos ADMX/ADML para disponibilizar as novas configurações. 2. Instalação de ADMX personalizados de fornecedores o Muitos softwares (inclusive da Microsoft) oferecem ADMX próprios. o Exemplo: Google Chrome possui ADMX que permitem configurar políticas centralizadas para o navegador. o Ao instalar esses arquivos no Active Directory, você passa a ter novas opções dentro do GPMC para controlar o Chrome. Exemplo prático – Google Chrome 1. Baixe os arquivos de template: policy_templates.zip (ou pesquise “download chrome admx files” caso o link mude). 2. Extraia os arquivos e localize: o ADMX → pasta admx o ADML → pastas separadas por idioma 3. Copie-os para o servidor, no diretório: Código %systemroot%\PolicyDefinitions (normalmente C:\Windows\PolicyDefinitions) 4. Após isso, ao abrir o GPMC, você verá novas configurações dentro de Administrative Templates, específicas para o Chrome. 👉 Em resumo: • Administrative Templates são alimentados por arquivos ADMX/ADML. • Eles permitem que o Group Policy seja expandido e personalizado. • Você pode atualizar templates com novas versões do Windows ou instalar templates de fornecedores como Google ou Microsoft. Instalando ADMX/ADML personalizados (exemplo: Google Chrome) O processo para adicionar novos modelos ao Administrative Templates é bem direto: 1. Copiar os arquivos ADMX o Pegue os arquivos .admx do pacote baixado (ex.: do Chrome) e copie-os para: Código %systemroot%\PolicyDefinitions (normalmente C:\Windows\PolicyDefinitions) 2. Copiar os arquivos ADML de idioma o Dentro do pacote, os arquivos .adml ficam organizados por pastas de idioma (ex.: en-US, pt-BR). o Copie apenas os arquivos da pasta correspondente ao idioma do seu servidor para dentro da pasta equivalente já existente em PolicyDefinitions. o Exemplo: se o servidor usa US English, copie os arquivos da pasta en-US para C:\Windows\PolicyDefinitions\en-US. 3. Reabrir o GPMC o Feche e abra novamente o Group Policy Management Console. o Agora, dentro de Administrative Templates, você verá novas configurações específicas do Chrome. Resultado Esses novos itens aparecem como se fossem nativos do Windows, mas na verdade vêm dos arquivos ADMX/ADML que você adicionou. No caso do Chrome, você terá acesso a dezenas de configurações, como: • Definir página inicial padrão. • Bloquear ou permitir extensões. • Configurar atualizações automáticas. • Controlar permissões de cookies e segurança. 👉 Em resumo: • ADMX = arquivos de definição de políticas. • ADML = arquivos de idioma. • Copie ambos para PolicyDefinitions e o GPMC exibirá novas opções em Administrative Templates. Central Store – Simplificando o uso de ADMX/ADML No exemplo anterior, assumimos que você tinha apenas um único Domain Controller. Nesse caso, bastava copiar os arquivos ADMX/ADML para a pasta local C:\Windows\PolicyDefinitions. Mas em ambientes com múltiplos DCs, isso se torna trabalhoso, já que seria necessário replicar manualmente os arquivos em cada servidor. O que é o Central Store? O Central Store é um recurso do Active Directory que permite centralizar os arquivos ADMX/ADML dentro da pasta SYSVOL, garantindo que todos os Domain Controllers e máquinas com RSAT busquem os modelos a partir desse local. Assim, qualquer atualização ou inclusão de novos templates passa a ser replicada automaticamente para todo o domínio. Como habilitar o Central Store 1. Acesse um Domain Controller e crie a seguinte pasta: Código %systemroot%\SYSVOL\sysvol\<seu-dominio>\Policies\PolicyDefinitions 2. Dentro dela, crie uma subpasta para os arquivos de idioma (exemplo em inglês): Código %systemroot%\SYSVOL\sysvol\<seu-dominio>\Policies\PolicyDefinitions\en-US (Substitua <seu-dominio> por algo como contoso.local ou o nome real do seu domínio.) 3. Copie os arquivos ADMX para PolicyDefinitions e os ADML para a pasta de idioma correspondente. Resultado • Ao abrir novamente o GPMC, você verá que a pasta Administrative Templates agora aparece como: Administrative Templates: Policy definitions (ADMX files) retrieved from the central store. • Isso significa que o editor está buscando os arquivos diretamente do Central Store. • Se você ainda não populou a pasta com os ADMX/ADML, verá a pasta vazia — por isso é essencial copiar os arquivos padrão do Windows e quaisquer adicionais (como Chrome, Office, Edge etc.) para lá. 👉 Em resumo: • O Central Store elimina a necessidade de copiar ADMX/ADML manualmente em cada DC. • Ele garante consistência e replicação automática via SYSVOL. • Sempre que precisar adicionar novos templates, basta copiá-los para o Central Store. Recuperando suas configurações no Central Store Quando você habilita o Central Store, o GPMC passa a buscar os arquivos de modelo (ADMX/ADML) diretamente de lá. Se você ainda não populou o Central Store com os arquivos padrão, a pasta Administrative Templates pode aparecer vazia. Como resolver Os arquivos originais ainda estão no disco do seu Domain Controller, no mesmo local onde você adicionou os ADMX do Chrome. Basta copiá-los para o Central Store: 1. Copie todos os arquivos ADMX da pasta local: Código %systemroot%\PolicyDefinitions para: Código %systemroot%\SYSVOL\sysvol\<seu-dominio>\Policies\PolicyDefinitions 2. Copie também os arquivos de idioma (ADML), por exemplo: Código %systemroot%\PolicyDefinitions\en-US para: Código %systemroot%\SYSVOL\sysvol\<seu-dominio>\Policies\PolicyDefinitions\en-US (Ajuste conforme o idioma usado no seu servidor, como pt-BR, en-GB etc.) Resultado • Após copiar, feche e reabra o GPMC. • Agora, a pasta Administrative Templates estará novamente populada com todas as configurações padrão do Windows, além de qualquer ADMX adicional que você tenha incluído (como Chrome, Edge, Office etc.). • A partir de agora, qualquer novo ADMX/ADML que você adicionar ao Central Store será replicado automaticamente para todos os Domain Controllers e ficará disponível em qualquer console de gerenciamento. 👉 Em resumo: • O Central Store centraliza os ADMX/ADML e elimina a necessidade de cópia manual em cada DC. • Se a pasta aparecer vazia, basta copiar os arquivos locais de PolicyDefinitions para o Central Store. • Depois disso, todas as configurações voltam a aparecer no GPMC. ✅ Central Store populado e replicado Agora que você copiou os arquivos ADMX/ADML para o Central Store, o GPMC continua puxando as configurações a partir desse local — mas desta vez, com o repositório devidamente populado. O que acontece a partir daqui • O Central Store está disponível para todos os Domain Controllers do seu ambiente. • Isso ocorre porque o SYSVOL é uma pasta especial do Active Directory que é automaticamente replicada entre todos os DCs. • Ou seja, qualquer novo ADMX/ADML que você adicionar ao Central Store será replicado e ficará disponível em todos os consoles de gerenciamento (GPMC) usados no domínio. Benefícios práticos • Consistência: todos os administradores veem as mesmas configurações. • Escalabilidade: basta adicionar novos templates uma única vez. • Flexibilidade: você pode incluir ADMX de fornecedores (Chrome, Office, Edge, OneDrive etc.) e eles ficam disponíveis para todos. • Manutenção simplificada: não há necessidade de copiar manualmente arquivos para cada DC ou máquina com RSAT. 👉 Em resumo: você agora tem um Central Store ativo e replicado, garantindo que qualquer configuração de Administrative Templates seja uniforme em todo o domínio. 📝 Summary – Group Policy Recap Group Policy é uma das ferramentas mais poderosas em ambientes de domínio Windows. Ela permite que administradores centralizem e imponham configurações em usuários e computadores, garantindo segurança, consistência e produtividade. Pontos-chave que vimos • Default Domain Policy o Existe por padrão em todo domínio. o Melhor prática: usar apenas para políticas globais de senha. o Para qualquer outra configuração, crie GPOs separados. • Computer vs. User Configuration o Computer Configuration → aplica-se ao objeto computador. o User Configuration → acompanha o usuário em qualquer máquina do domínio. • Policies vs. Preferences o Policies → obrigatórias, imutáveis, auto-removíveis quando o GPO deixa de se aplicar. o Preferences → opcionais, reversíveis pelo usuário, persistem mesmo após a remoção do GPO. • Loopback Policy Processing o Permite aplicar configurações de usuário como se fossem de computador. o Útil em kiosks e Remote Desktop Servers. • Administrative Templates (ADMX/ADML) o Arquivos que definem as opções exibidas no GPMC. o Podem ser atualizados com novas versões do Windows ou adicionados de fornecedores (Chrome, Office, Edge, OneDrive etc.). • Central Store o Centraliza os ADMX/ADML dentro do SYSVOL. o Garante replicação automática entre todos os Domain Controllers. o Simplifica manutenção e garante consistência. Exemplos práticos de uso do Group Policy • Mapeamento automático de drives de rede. • Instalação de impressoras. • Personalização de desktop. • Padrões centralizados de segurança. • Políticas de senha. • Lockdown de kiosks públicos. • Políticas de segurança em servidores RDS. • Instalação automática de aplicativos. • Administração centralizada de OneDrive em migrações para nuvem. 📌 Perguntas – Teste seus conhecimentos (tradução) Aqui estão as questões traduzidas para o português, para você praticar: 1. As configurações de protetor de tela (screensaver) são de Computer Configuration ou User Configuration? 2. Os links em nível de domínio ou em nível de OU são processados primeiro? 3. Qual é a configuração especial de GPO que força as configurações de usuário a se aplicarem a qualquer usuário em um determinado computador? 4. Que tipo de filtragem de GPO você configura dentro do próprio GPO, como em uma política de drives de rede mapeados? 5. Verdadeiro ou Falso? É possível que um usuário substitua uma preferência de Group Policy. 6. Qual é o tempo padrão entre os ciclos de atualização em segundo plano do Group Policy? 7. Que tipo de filtragem de GPO poderia ser utilizada para aplicar configurações apenas a computadores portáteis (laptops)? 8. Se você encontrar um pen drive no chão com o rótulo “CEO financials”, o que deve fazer com ele? 9. Pergunta bônus: Qual é o nome da tecnologia baseada em nuvem da Microsoft que fornece parte da mesma funcionalidade do Group Policy, mas especificamente para computadores ingressados no Entra? ✅ Respostas 1. User Configuration – protetor de tela segue o usuário, não o computador. 2. Links em nível de domínio processam primeiro, depois os de OU, seguindo a hierarquia. 3. Loopback Policy Processing – força configurações de usuário a se aplicarem em qualquer usuário que faça logon no computador. 4. Item-level targeting (filtragem de preferências dentro do GPO). 5. Verdadeiro – o usuário pode alterar manualmente uma preferência. 6. 90 minutos, com um deslocamento aleatório de até 30 minutos. 7. WMI filtering – por exemplo, filtrando por presença de bateria ou classe de hardware. 8. Não conectar o pen drive. Tratar como ameaça de segurança e reportar ao time de TI/segurança. 9. Microsoft Intune – parte do Microsoft Endpoint Manager, integrado ao Entra ID.

Manoel Maciel PST