Arquivo

Archive for the ‘Active Directory’ Category

Criação e adequação em contas de parceiros externos via PowerShell

6 de março de 2017 Deixe um comentário

Saudações,

Neste primeiro post de 2017 vou compartilhar com vocês um trabalho feito a uns dias atrás na empresa onde trabalho.

Cenário – Uma consultoria foi contratada para dar suporte a uma aplicação on-premisses da empresa. O contrato tem duração da data de hoje até 31 de dezembro de 2017. Como se trata de uma solução de ERP instalada em um de nossos servidores, ficou acertado que 4 pessoas desta consultoria deveriam ter acesso como Administrator neste servidor para as devidas manutenções, migrações, etc. Entretanto, não posso simplesmente criar 4 novas contas no domínio e coloca-las como administrator de um servidor. Alguns critérios tiveram que ser seguidos para que as normas de segurança definidas pelo nosso time de Cyber Security não fossem quebradas.

Vou neste post mostrar como fiz, usando alguns exemplos em meu ambiente de laboratório.

Descrição do ambiente:

Domínio: uilson.net

Nome da empresa que vai alocar consultores: 123 Consultoria SA

Passos a serem seguidos na tarefa:

1. Criar uma OU específica para provedores externos

New-ADOrganizationalUnit -Name "ExternalProviders" -Path "DC=uilson,DC=net" -Description "OU para contas de usuários externos"

Acima criei a OU “ExternalProviders” que irá abrigar as OU´s de todos os meu parceiros externos que alocam pessoas em minha organização

2. Criar uma OU dentro daquela criada no item 1 descrevendo o nome da empresa

New-ADOrganizationalUnit -Name "123Consultoria" -Path "OU=ExternalProviders,DC=uilson,DC=net" -Description "OU para contas da 123 consultoria SA"

Acima criei a OU “123Consultoria” que vai ficar dentro da OU “ExternalProviders”.

3. Criar as contas de usuário já dentro dessa nova OU, definindo a senha provisória, solicitando alteração de senha no log on do usuário e seguindo as melhores práticas de segurança definir que cada conta será desabilitada em 31/12/2017

New-ADUser -Name "José da Silva 123 Consultoria" -SamAccountName jose.silva -UserPrincipalName jose.silva.ext@uilson.net -DisplayName "Jose da Silva – consultor externo" -Description "Usuário Consultor da 123 Consultoria" -Title "Jose da Silva – 123 Consultoria" -Enable $true -ChangePasswordAtLogon $true -AccountPassword (ConvertTo-SecureString "!!!zaq12wsx" -AsPlainText -force) -PassThru -Path "OU=123Consultoria,OU=ExternalProviders,DC=uilson,DC=net" | Set-ADAccountExpiration -DateTime "12/31/2017"

O comando acima cria o usuário “jose.silva” com uma senha pré-definida que deverá ser alterada no momento do primeiro log on do usuário, a localização da conta (dentro das OU´s que criamos anteriormente) e para casos como este de usuários externos, definição da data de expiração da conta, ou seja, o projeto ao que este usuário está alocado deverá se encerrar até 31/12/2017, data qual a conta será desabilitada.

O mesmo poderá ser repetido com outros usuários desta mesma empresa que vierem a integrar o quadro de consultores externos.

Agora vamos supor que o gestor do contrato com a “123 Consultoria” lhe peça pra listar a data de expiração da conta do consultor “José da Silva”, apenas para ter certeza de que a configuração de expiração da conta bate com a data final do contrato:

get-aduser jose.silva -Properties * | Select-Object Name,SamAccountName,AccountExpirationDate

No comando acima você receberá o seguinte resultado:

image

Vimos na imagem acima que a criação do usuário foi feita de forma a respeitar os processos de segurança da informação da empresa e também certifica que, em 31/12/2017 a conta do usuário listado não mais funcionará a partir da meia noite do dia citado.

Agora seu gerente quer saber quais são os recursos da “123 Consultoria” alocados na empresa. Sabendo qual a OU em que esses usuários estão criados você já pode fazer uma linha de comando mais elaborada:

Get-ADUser –Filter * –SearchBase “OU=123Consultoria,OU=ExternalProviders,DC=uilson,DC=net” | Select-Object Name,SamAccountName

Executando o comando acima você tem o resultado abaixo

image

Você pode mandar essas informações para seu gerente no corpo do email ou simplesmente  envie para um arquivo TXT e trate depois em um excel, basta incluir “> arquivo.txt” no fim da linha de comando exemplificada acima.

Depois de alguns dias, você recebe uma notificação de sua gestão dizendo que, pela complexidade do projeto no qual a 123 Consultoria está atuando, o tempo de contrato foi extendido, ou seja, não mais acabará em 31/12/2017 e sim em 31/12/2018. Dessa forma, os acessos da equipe alocada precisa continuar em funcionamento após a primeira data estipulada.

Neste caso você não precisa efetuar a alteração conta por conta. Simplesmente aplique o update para toda a OU “123Consultoria”:

O primeiro comando fará com que todos os usuários da 123 Consultoria tenham sua data de expiração alterada para 31/12/2018:

Get-ADUser -Filter * -SearchBase "OU=123Consultoria,OU=ExternalProviders,DC=uilson,DC=net" | Set-ADAccountExpiration -DateTime "12/31/2018"

Agora você pode tirar a prova para se certificar que a alteração foi feita usando o comando abaixo:

Get-ADUser -Filter * -SearchBase "OU=123Consultoria,OU=ExternalProviders,DC=uilson,DC=net" -Properties * | Select-Object Name,SamAccountName,AccountExpirationDate

Os comandos acima trazem o resultado na figura abaixo:

image

Com base na imagem acima, e tendo em mente os usuários externos da empresa, vamos para nosso último laboratório deste post. Depois de alguns meses de trabalho, o gerente da equipe de desenvolvimento entendeu que a consultora Hele de Jesus (userid – helena.jesus) desempenha um excelente trabalho no suporte ao produto ERP da empresa e lhe faz uma proposta de contratação como funcionária efetiva. A mesma aceita e agora vai fazer parte do quadro de funcionários.

Com todas as formalidades em dia, você da área de infra estrutura recebe uma solicitação para adequar o usuário de Helena ao padrão da empresa, ou seja, tem que mover a conta para a OU “DevTeam” que fica dentro de “ITDept”, mudar as descrições da conta e remover a data de expiração da conta, afinal, Helena agora é funcionária nossa!

Dessa vez vamos usar o editor de script´s PowerShell ISE, lembrando que para abrir este editor você apenas precisa digitar “ise” no prompt de comando do PowerShell. Como vamos rodar vários comandos, resolvi definir uma varíavel para o usuário “helena.jesus”. Veja como ficou abaixo:

$conta = "helena.jesus"
Get-ADUser $conta | Clear-ADAccountExpiration
Get-ADUser $conta |  Move-ADObject -TargetPath "OU=DevTeam,OU=ITDept,DC=uilson,DC=net"
Set-ADUser $conta -DisplayName "Helena de Jesus" -Description "Desenvolvedora ITDept" -Department "IT Department" -UserPrincipalName "helena.jesus@uilson.net" -Title "Helena de Jesus"

O script acima fica assim no ISE:

image

Após execução do Script, ainda vemos que um atributo permanece inalterado, conforme image abaixo:

image

O campo “Name” não foi alterado, permanece como “Helena de Jesus 123 Consultoria”. Isso ocorre porque este campo fica na propriedade DistinguishedName do usuário “helena.jesus”. Para que este campo seja renomeado corretamente, é preciso alterar o objeto “CN” do DistinguishedName. Abaixo mostro dois comandos, sendo o primeiro para listar o DistinguishedName do usuário e o segundo mostro como fazer a alteração necessária:

get-aduser helena.jesus | Select-Object distinguishedname

Rename-ADObject -Identity "CN=Helena de Jesus 123 Consultoria,OU=DevTeam,OU=ITDept,DC=uilson,DC=net" -NewName "Helena de Jesus"

image

Na tela acima você vê os resultados da aplicação dos comandos.

Agora o objeto aparece corretamente no AD:

image

Além disso, vemos que os procedimentos adotados removeram a data de expiração da conta:

image

Neste post vimos como configurar acessos no Active Directory para consultores externos seguindo as melhores práticas de segurança e todos os

Espero que possa ser útil no dia a dia de vocês.

Quero pedir desculpas pela demora em postar neste ano. Estou estudando para as provas da CompTIA. Vou começar com Cloud Essentials (o livro vc pode comprar no link no lado superior direito). Depois vou estudar Security+, depois vem Cloud+ e CSA (Cyber Security Analyst) – você pode ter uma visão geral de todas essas certificações em https://certification.comptia.org/pt/certificações

Seguiremos este ano com posts voltados a todo tipo de otimização de tarefas com PowerShell, Web Application Proxy e Azure AD Application Proxy.

Abraços

Uilson

Otimizando tarefas com PowerShell–Administração DNS Server

16 de novembro de 2016 Deixe um comentário

Saudações,

Chegamos hoje ao quinto artigo da série “Otimizando tarefas com PowerShell”. Dessa vez vamos falar sobre administração do DNS.

Para quem ainda não viu, abaixo os 4 primeiros posts publicados:

1. Otimizando tarefas com PowerShell – Administrando Active Directory Users and Computers

2. Otimizando tarefas com PowerShell – Implementação e administração Web Application Proxy

3. Otimizando tarefas com PowerShell – Implementando e administrando AD Federation Services

4. Otimizando tarefas com PowerShell – Implementando e administrando Internet Information Services – IIS

Publiquei tb um artigo no TechNet Wiki sobre Administração do AD Directory Services via PowerShell com coneitos mais avançados que o primeiro desta série.

Podemos levar em consideração o ambiente fictício dos últimos 4 posts:

Domínio – uilson.net

Vamos considerar um ambiente básico onde o DNS está junto com o AD e também considerar a instalação de um novo servidor de resolução de nomes com as configurações básicas, criação de zones, hosts, etc.

1. Instalando e configurando a Role via Powershell:

A principio, todo domain controller já vem com o DNS Server instalado. Neste caso vamos simular um segundo DNS Server sendo instalado e que será integrado ao nosso Active Directory.

Como já mostrado em outros artigos desta série vamos usar o cmdlet “Add-WindowsFeature” ou “Install-WindowsFeature”:

Install-WindowsFeature DNS –IncludeManagementTools

No comando acima eu pedi a inclusão da console de gerenciamento, mas, vamos mostrar aqui como administrar seu DNS sem usa-la.

2. Configurando forward, reverse e stub zones (primárias)

Sabemos que podemos ter dois tipos de forward zone no DNS – Com integração no AD (que é o tipo mais comum para redes internas, tanto que um servidor promovido a Domain Controller já instala a role do DNS junto) e sem integração, ou seja, aquele DNS Server que poderá ser usado para resolução de nomes externos

Para criar uma Forward Lookup Zone integrada ao AD – Add-DnsServerPrimaryZone -Name "uilson.net" -ReplicationScope "Forest" –PassThru 

O comando acima vai criar um forward zone primária integrada ao AD, ou seja, todas as informações que forem criadas nesta zona serão armazenadas no base do AD.

Para criar uma Forward Lookup Zone sem integração com o AD – Add-DnsServerPrimaryZone -Name "uilson.net" -ZoneFile "uilson.net"

O Zone File armazena todas as configurações e registros criados neste forward lookup zone, uma vez que não há integração com o AD. Esse arquivo fica na pasta c:\windows\system32\dns do seu servidor DNS. De forma que, para zonas sem integração com o AD é interessante manter um backup destes arquivos para imediato restore em caso de necessidade.

Agora vamos ver como criar as zonas reversas, ou seja, aquelas que fazem a resolução IP-Nome. Abaixo os comandos que você deve usar para esta finalidade:

Para criar uma Reverse Lookup Zone integrada a seu AD – Add-DnsServerPrimaryZone -NetworkID "10.1.1.0/24" -ReplicationScope "Forest"

Para criar uma zona reversa sem integração com o AD – Add-DnsServerPrimaryZone -NetworkID 10.1.1.0/24 -ZoneFile "0.1.10.in-addr.arpa.dns"

Outra tipo de zone que você pode criar no DNS Server é a Stub Zone. Ela facilita a resolução de nomes em ambientes complexos. Os endereços da filial A serão mais rapidamente resolvidos pela filial C que se conectam via WAN em distâncias grandes.

Como os exemplos acima, você poderá criar uma stub zone de forma integrada, não integrada e também uma reverse stub zone.

Para criar uma stub zone não integrada com o AD – Add-DnsServerStubZone -Name "filialrj.uilson.net "192.168.1.1" -PassThru -ZoneFile "filialrj_uilsonnet.dns"

No exemplo acima criei uma stub zone não integrada ao AD para uma filial no Rio de Janeiro dentro da arvore uilson.net.

Com base no cenário do exemplo acima, segue o comando para criar uma stub zone integrada ao AD:

Add-DnsServerStubZone -Name "filialrj.uilson.net" -MasterServers 192.168.1.1 -PassThru -ReplicationScope "Forest"

Você também pode criar uma reverse stub zone – Add-DnsServerStubZone -NetworkId 10.10.1.0/24 -MasterServers 192.168.1.1 -PassThru -ReplicationScope Forest – neste exemplo, integrada ao AD.

3. Criando Zonas Secundárias

Para criação de uma Reserve Lookup Zone integrada ao AD em um DNS Secundário, ou seja, uma zona secundária que irá receber informações de uma zona primária criada conforme mostramos no item 2 deste post, você deve usar o comando abaixo:

Integrada ao AD – Add-DnsServerSecondaryZone –Name “uilson.net” –ReplicationScope “Forest” –MasterServers 10.10.1.1

Associada a um Zone File – Add-DnsServerSecondaryZone -Name "uilson.net" -ZoneFile "uilson.net" -MasterServers 10.10.1.1

4. Configurando propriedades dos zones

DNS Forwarder e DNS Conditional Forwarder

Um dos pontos a serem configurados em uma zona de encaminhamento no DNS Server é o serviço de Forwarder.

O servidor DNS que você configura como Forwarder irá receber as requisições de resolução de nomes externas encaminhadas do seu DNS Interno.

Neste caso, temos duas maneiras de configurar a lista de Forwarders:

1. Set-DnsServerForwarder – Este comando irá começar a lista de IP´s externos do zero, ou seja, usado em situações em que você acabou de instalar e configurar seu DNS Server.

2. Add-DnsServerForwarder – Este comando irá adicionar IP´s a uma lista de forwarders já existente.

OBS: Se você usar o comando Set-DnsServerForwarder em uma lista de forwarders já existente, você vai “zerar” a lista e usar aquele IP que o comando definir no momento em que for executado, portanto, cuidado!

Para criar um nova lista de forwarders – Set-DnsServerForwarder -IPAddress "192.168.0.1" –PassThru

Para adicionar um IP a uma lista de forwarders – Add-DnsServerForwarder -IPAddress 192.168.0.1 –PassThru

Outra configuração interessante a ser feita é a do Conditional Forwarder, funcionalidade que foi introduzida a partir do Windows Server 2003. Um Conditional Forwarder permite a resolver nomes de um rede privada ou externa, ajudando a acelerar a resolução. Quando o DNS recebe a requisição de um cliente para resolver o nome de um host que não está em sua zona autoritativa, o processo começa a partir do root name do servidor e continua até a resolução do nome. Quando você configura um Conditional Forwarder, o DNS local encaminhará a requisição para a zona autoritativa do domínio de destino.

De igual forma aos exemplos mostrados neste post, você pode criar uma zona Conditional Forwarder de forma integrada a seu AD Loal ou não.

O link abaixo fala de Zonas Conditional Forwarder para Windows Server 2003, mas, o conceito explicado pode ser usado em qualquer situação a frente, ou seja, Windows Server 2008, 2012, 2016, etc:

https://support.microsoft.com/en-us/kb/304491 – Conditional Forwarding in Windows Server 2003

Agora vamos a prática:

Para criar uma Conditional Forwarder Zone integrada a seu AD: Add-DnsServerConditionalForwarderZone -Name "contoso.com" -ReplicationScope "Forest" -MasterServers 172.16.10.1

Para criar uma Conditional Forwarder Zone sem integração com seu AD: Add-DnsServerConditionalForwarderZone -Name "contoso.com" -MasterServers 172.16.10.1 –PassThru

Root Hints

Para adicionar um endereço a minha lista de root hints – Add-DnsServerRootHint -NameServer "root.contoso.com" -IPAddress 172.23.90.128

Zone Transfers

Quando você configura uma zona secundária, precisa habilitar a transferência dos dados da primária.

Para habilitar o zone transfer – Start-DnsServerZoneTransfer -Name "uilson.net"

DNS Policy

Ao invés de deixar um ou outro exemplo sobre DNS Policy, vou colocar o link pra um artigo que escrevi em 24/06/2015 – Nele mostrei um cenário completo onde você pode configurar o DNS Policy. Essa feature vem a partir do Windows Server 2016. Clique aqui para ler o post.

Tem muito mais

Os exemplos citados acima são apenas alguns daqueles que podem ser usados para configurar e administrar seu DNS Server via PowerShell. Muitos outros existem e vou deixar um link aqui com todos os cmdlets do DNS Server com exemplos práticos.

5. Criação de Registros

A criação de registros em uma zona é feita de forma automática. Entretanto, imagine a situação em que você precise registrar um host que aponte a um web server, um application server ou back-end server.

Vamos ver abaixo como criar um registro A que venha de encontro a esse propósito.

Cenário: Temos um web server no domínio uilson.net. O mesmo tem uma aplicação que deverá ser publicada e usada internamente ou externamente. No IIS eu configurei esta aplicação com o host header sistemas.uilson.net. O IP deste servidor é 10.10.1.50. Veja abaixo como este registro é criado:

Add-DnsServerResourceRecord -ZoneName "uilson.net" -A -Name "sistemas" -IPv4Address "10.10.1.50"

Nesse link você encontra exemplos práticos de como criar os demais tipos de registro (AAAA, CNAME, etc) – https://technet.microsoft.com/en-us/library/jj649925.aspx

6. Consultas

Neste ponto em que nosso laboratório já está totalmente configurado. Vamos ver os comandos que você pode usar para verificar as configurações de seu DNS Server:

Get-DnsServer

Este comando traz todas as configurações de seu DNS Server. Voce pode usar também o parâmetro –computername para pegar informações remotamente.

image

Get-DnsServerZone

Este comando traz todas as Zones criadas no seu DNS Server. Voce pode usar também o parâmetro –computername para pegar informações remotamente.

image

Get-DnsServerResourceRecord -ZoneName uilson.net

O comando acima lista todos os registros na zone uilson.net:

image

Estas são apenas algumas das muitas consultas que podem ser feitas. No item abaixo você encontra o link que poderá ver exemplos práticos de todas elas.

7. Referências para estudo

Neste link você encontra todos, exatamente todos os comandos DNS para PowerShell com exemplos práticos – https://technet.microsoft.com/en-us/library/jj649850.aspx

8. Conclusão

Neste post mostrei para você exemplos práticos de instalação, configuração e administração do DNS Server via PowerShell.

Espero que o conteúdo possa ser útil e lhe ajudar em suas tarefas diárias.

Abraços

Uilson

Automatizando tarefas com PowerShell–Administrando Active Directory Users and Computers

22 de fevereiro de 2016 2 comentários

Saudações,

Depois do nosso último post, resolvi investir um pouco mais de tempo em entender bem o PowerShell e, medindo o tempo que usava para entregar determinadas tarefas usando click de mouse e o tempo que levei para executar as mesmas tarefas via cmdlets, fiquei mais interessado ainda em me aprofundar no tema.

Para tanto, recomendo que você acesse o Microsoft Virtual Academy e procure pelos treinamentos de PowerShell disponíveis. Tente também baixar pelo Microsoft Press, os livros disponíveis. Além disso, procure também no TechNet todo conteúdo disponível sobre PowerShell. Realmente, você vai gostar e, como disse no meu último post, vai enteder que, o futuro do ITPro passa e fica pelo Powershell.

A idéia é mostrar como o Powershell pode facilitar seu dia a dia nas mais variadas ferramentas Microsoft, portanto, começo hoje uma série de posts onde mostro os principais comandos de PowerShell para AD, ADFS, Web Application Proxy, AD CS, IIS,  DNS e DHCP. Lembrando que não sou expert em PowerShell, portanto, o espaço está aberto aos especialistas para que nos aprofundemos no tema.

Neste primeiro post, trago para vocês uma lista de comandos úteis para administração do AD e que vai automatizar algumas tarefas no seu dia a dia. Então, vamos lá! Vamos pensar num domínio fictício chamado uilson.net e uma conta com nome Uilson Souza e username uilson.souza:

Você começa pelo import do módulo de comandos do Active Directory, digitando o cmdlet abaixo:

Import-Module ActiveDirectory

1. Criando/removendo uma nova conta de usuário

O exemplo abaixo mostra a criação de um usuário no seu domínio. O comando mostra como criar o usuário definindo nome, username, display name, diz que a conta está habilitada, define a senha inicial, força alteração de senha no primeiro logon e diz em que OU a mesma ficará:

New-ADUser -Name "Uilson Souza" -SamAccountName uilson.souza -DisplayName "Uilson Souza" -Title "Uilson Souza" -Enable $true -ChangePasswordAtLogon $true -AccountPassword (ConvertTo-SecureString "P@ssw0rd" -AsPlainText -force) -PassThru -Path "OU=Users,DC=uilson,DC=net"

Para remover uma conta de usuário use o seguinte parâmetro:

Remove-ADUser –Identity “uilson.souza” – remove a conta de usuário mas antes é exibida uma mensagem de confirmação

Remove-ADUser –Identity “uilson.souza” –confirm:$false – remove a conta direto sem nenhuma mensagem de confirmação

2. Desbloqueando uma conta de usuário:

Aquele momento em que um usuário reclama que sua conta está bloqueada. Ele não é um usuário comum…trata-se de um diretor ou o presidente da sua corporação. Você (esperto como é) não vai fazer um usuário VIP entrar na fila dos chamados. Nesse caso o comando abaixo ajuda bastante:

Unlock-ADAccount -Identity uilson.souza

3. Listando contas com opção "password never expires":

Contas de serviço ou aquelas usadas em tarefas específicas que não podem entrar na política de alteração de senha da empresa. Nesse caso, ela é criada com a opção “Password never expires”. Para saber quais contas têm essa opção habilitada você pode usar a linha abaixo:

Search-ADAccount -PasswordNeverExpires | Select-Object Name,ObjectClass,PasswordNeverExpires | Export-Csv arquivo.csv

A parte “| Export-Csv arquivo.csv” significa que o resultado desta linha irá ser armazenado em um arquivo csv que, posteriormente poderá ser tratado no Excel.

4. Listando usuários de um determinado grupo:

Quem são os usuários que estão em um determinado grupo? Você não precisa mais abrir o snap-shot AD Users and Computers para isso e ainda poderá exportar a listagem para um arquivo:

Get-ADGroupMember -Identity "Nome_do_Grupo" | Select-Object Name,samAccountName | Export-Csv C:\TEMP\arquivo.csv

5. Criando um grupo dentro de uma OU:

Não basta simplesmente criar um grupo…ele precisa estar na OU certa para que seus membros recebam as políticas pré-definidas:

New-ADGroup -Name Marketing -GroupCategory Security -GroupScope Global -DisplayName Marketing -Path "OU=Users,DC=uilson,DC=net"

6. Adicionando usuário em um grupo:

Após criar o grupo, você precisa adicionar os membros nele:

Add-ADGroupMember NomedoGrupo uilson.souza – exemplo de inserção de um único 1 usuário

Add-ADGroupMember NomedoGrupo uilson.souza,jose.santos,paulo.oliveira – exemplo de inserção de vários usuários

7. Removendo usuário de um grupo:

Remove-ADPrincipalGroupMembership -Identity "uilson.souza" -MemberOf "NomedoGrupo" -Path "OU=Users,DC=uilson,DC=net"

8. Lista usuários com a conta desabilitada:

Você precisa saber quais contas estão desabilitadas. Para tal, a linha abaixo traz a informação desejada com as informações de Nome e Username:

Get-ADUser -Filter * -SearchBase "OU=Users,DC=uilson,DC=net" | where { $_.enabled -eq $False} | Select-Object Name,SamAccountName

9. Lista contas que não logam a mais de 30 dias

Nesse pequeno script você define que quer saber as contas que não efetuam logon a mais de 30 dias:

$timespan = New-TimeSpan -Days 30

Search-ADAccount -UsersOnly -AccountInactive -TimeSpan $timespan

Você ainda pode incrementar a linha 2 do script dizendo que as contas que não logam a mais de 30 dias já serão desativadas:

Search-ADAccount -UsersOnly -AccountInctive -TimeSpan $timespan | Disable-ADAccount

Essa opção de comando pode ser executada também a partir do PowerShell ISE (digitar ISE na linha de comando do PS – vou mostrar um exemplo abaixo).

10. Desabilitando uma conta em particular:

Comando para desabilitar uma conta. Imagine que um gerente de um setor qualquer te avisa de um funcionário está sendo desligado e que já quer o bloqueio da conta dele. Na linha abaixo vc já tem como atende-lo no mesmo instante:

Disable-ADAccount – Identity "uilson.souza"

OBS: Espero que o usuário de nenhum de vocês esteja entre as aspas duplas do comando acima…rs..rs..rs.rs

11. Habilitando uma conta em particular:

Em algumas empresas, os usuários em férias têm suas contas desabilitadas. Dessa forma o próprio não vai poder usa-la remotamente por uma série de questões trabalhistas envolvidas. No retorno do mesmo ao trabalho, o comando abaixo pode ser usado para reativar a conta:

Enable-ADAccount –Identity “uilson.souza”

12. Lista usuários de uma OU:

Você tem diversas OU´s separadas por departamento. Um belo dia alguém diz que precisa saber quem são os usuários do setor financeiro. O comando abaixo traz a informação que pode, posteriormente ser exportada para um arquivo:

Get-ADUser -Filter * -SearchBase "OU=Financeiro,OU=Users,DC=uilson,DC=net" | Select-Object Name,SamAccountName

13. Lista os dados de um usuário pelo nome:

Na linha abaixo eu listo todos os “Uilson´s” que existem em meu domínio trazendo informações de Nome e Username:

Get-ADUser -Filter ‘Name -like "uilson*"’ | FT Name,SamAccountName –A

OBS: No meu caso, Uilson com “U” raramente irá haver mais de 1…rs..rs..rs

14. Gerando uma lista de usernames e já inserindo em um grupo a partir de uma lista em TXT:

Agora, vamos sair um pouco do shell de comandos do PowerShell e vamos usar o PowerShell ISE para o pequeno script abaixo. Imagine que você precisa inserir uma quantidade alta de usuários em um determinado grupo, sendo que esses usuários já possuem conta de domínio. Você teria que seguir os passos da dica número 6 deste post, digitando um por um? Não!!!! Um script PowerShell resolve esse problema. Tudo que você precisa é ter a lista de nomes em um TXT, pedir que o PowerShell consulte no AD o username destes usuários a partir dos nomes da lista e já os adicione no grupo que você precisa que eles estejam:

Import-Module ActiveDirectory
ForEach ($Item in (Get-Content C:\UserList.txt)){
    Get-ADUser -Filter ‘Name -eq $Item’ | Add-ADPrincipalGroupMembership -MemberOf NomedoGrupo

}

Conforme falado anteriormente, ao digitar ISE na linha de comandos do PowerShell, você abre o PowerShell ISE:

image

image

O PowerShell ISE é fantástico! Note que, você tem a parte em que pode escrever o script, abaixo a tela azul onde vê a execução e ao lado direito você pode consultar todos os comandos PowerShell com explicação detalhada.

15. Lista todos os DC´s de seu domínio:

Para saber quais os domain controllers do seu ambiente:

Get-ADDomainController -Filter { name -like "*" }

Essa foi uma lista básica de comandos que vão ajudar e automatizar suas tarefas no dia a dia. Fiz um métrica de tempo entre as atividades feitas a partir de interface gráfica e as mesmas feitas em PowerShell. O tempo cai para algo em torno de 80 a 90% a menos. Então, ao menos para este que vos escreve, não há mais dúvidas…vamos mudar o foco e usar PowerShell.

Reitero que não sou especialista no tema e convido os experts a agregarem conhecimento e assim vamos nos ajudando mutuamente. Existem muitos outros comandos e parâmetros que podem ser usados juntamente com o conteúdo deste post para que possamos administrar e facilitar o dia dia no Active Directory. Aqui deixo os mais usados, mas, você pode ir além e aprender mais.

Queria agradecer o Anderson Thiago. que me ajudou muito em um fórum no TechNet elucidando alguns pontos de Power Shell – https://social.technet.microsoft.com/Forums/pt-BR/8249c2f2-af4e-417f-982c-8a8f5db05b5a/gerando-lista-de-usurios-via-powershell?forum=winsrv2008pt

No próximo artigo vamos falar sobre comandos PowerShell para agilizar a implementação e administração de um ambiente de proxy reverso com Web Application Proxy e AD Federation Services.

Espero que o conteúdo seja útil!

Abraços

Uilson

Resumo da minha palestra sobre Web Application Proxy no MVP ShowCast 2014

24 de setembro de 2014 3 comentários

Saudações,

Na última segunda (22/09/2014) entreguei a palestra “Proxy Reverso com Web Application Proxy no Windows Server 2012 R2”. Tivemos uma audiência de 10 pessoas que conseguiram me aguentar até o final e aprender um pouco sobre como proteger suas aplicações que precisam ser acessadas externamente.

Falei sobre o conceito do produto – Uma função agregada à role Remote Access do Windows Server 2012 R2 – e finalidade dentro da corporação, possibilitando acessar aplicações corporativas de qualquer lugar com qualquer dispositivo (notebook, tablets, smart phones).

Mostrei sua integração ao Active Directory Federation Services 3.0 (o usando como base de dados e para autorização e pré-autenticação).

Mostrei também que é possível fazer a pré-autenticação usando Claims-based identity, MSFBA, OAuth, KCD e Client Certificate Authentication (via ADFS) e passthrough (acesso direto do WAP Server ao BackEnd Server). É possível também (via Power Shell) fazer a autenticação via certificado a partir do próprio WAP.

Mostrei também a topologia mais adequada ao produto:

image

Mantenha sempre o WAP em uma DMZ com um back-firewall protegendo sua rede interna e assim as requisições que chegam ao proxy reverso e não são autorizadas e pré-autenticadas pelo ADFS interno, não são passadas ao rede local.

Falei que o WAP também atua como um AD FS Proxy – lembrando que a partir do Windows Server 2012 R2, o AD FS Proxy não existe mais, cabendo ao WAP este papel.

Foi falado da atenção que se deve ter na questão do deployment do WAP. Você precisa conecta-lo a um ADFS pré-definido para pré-autenticação, autorização e para base de dados do produto. Mostramos que, para que essa parte seja bem sucedida vc precisa ter instalado no WAP o certificado do seu ADFS interno e também apontar para ele através do ADFS Name (e não com o hostname da máquina…erro esse que até eu cometi). Além disso é necessário que o WAP Server e o ADFS interno se comuniquem a partir das portas 80, 443 e 49443 (para client certificate autentication).

Mostrei o passo a passo da instalação do WAP e as configurações iniciais que devem ser feitas. Além disso, mostrei algumas limitações do produto que deverão ser corrigidas na próxima versão.

Os contratempos

Como em todas as áreas da vida, a lei de Murphy também afeta os evangelistas técnicos, os MVP´s e MTAC´s como eu. No momento da Palestra meu note não se conectava a sala de transmissão, visto estarmos usando o LiveMeeting e, por muito pouco não tivemos que cancelar a apresentação.

Para evitar esse desastre, e para minha sorte, tinha outro notebook com o client do LiveMeeting instalado e aí foi possível entregar a palestra, porém, não tive tempo de migrar minhas VM´s de um lado para o outro….dessa forma, não foi possível fazer a demo que preparei. Só espero que meu amigo MVP Alberto Oliveira não me estrangule…rs..rs..rs…

Brincadeiras a parte, consegui demonstrar o processo de publicação de aplicações via passthrough a partir de screen shots. Não foi como eu queria, mas, deu pra mostrar algo.

O que me esqueci de falar nesse desespero todo:

1 – Cuidado com a parte de certificados digitais que fazem o trust entre ADFS e WAP. Apesar de ter dito que é necessário ter a chave privada exportável, eu me esqueci de dizer que, qualquer alteração de certificado no ADFS afeta o WAP, visto que, o Federation Services só valida as alterações de certificado no http.sys após uma série de comandos power shell (problema este que será resolvido na próxima versão do produto).

2 – Me esqueci de falar que o WAP não deve ser inserido no domínio, a menos que você vá autenticar na aplicação a partir de KCD (Kerberos Constrained Delegation)…nesse caso é imprescindível que o WAP seja inserido em seu domínio.

Continuando

Fiz um pequeno overview do Azure AD Application Proxy. A ferramenta de proxy reverso do Microsoft Azure que faz o mesmo papel do WAP, porém, totalmente voltado para núvem.

Após a palestra, eu e o Luciano Lima (moderador) falamos sobre os programas Microsoft para disseminação de conteúdo, tais como o Programa MVP, o MVP Mentoring, o Microsoft Curah e o Microsoft Virtual Academy.

Diferente das outras palestras que entreguei, nesta eu só mostrei os links de referência para estudo no final. E para agilizar o Luciano Lima criou um curah com todos os links da minha apresentação e neles você terá um vasto material para aprendizado do WAP, podendo inclusive ver videos e montar seu laboratório de testes.

Para acessar curah criado pelo Luciano Lima, clique no link http://curah.microsoft.com/210943/mvp-showcast-2014-proxy-reverso-com-web-application-proxy-no-windows-server-2012-r2

Para assistir o video da palestra, basta acessar o mesmo link no qual foi feito a inscrição. Ao entrar na página, você deverá clicar no botão “exibir online” na parte direita da tela e será direcionado a área de download.

Como falei posteriormente, o aprendizado do WAP requer um conhecimento no AD Federation Services. Dessa forma disponibilizei uma página no Curah da Microsoft onde você encontra dois links com vasto conteúdo sobre a ferramenta e também o passo a passo para deployment. Clique no link abaixo:

http://curah.microsoft.com/211422/windows-server-2012-r2-passo-a-passo-instalando-o-active-directory-federation-services-30

Para os próximos dias estarei trabalhando numa série de posts sobre WAP e ADFS que serão publicados não só aqui, mas também nos canais que escrevo (TechNet Wiki e CooperaTI).

Finalizando, queria agradecer ao amigo Alberto Oliveira pela nova oportunidade (espero contribuir em outros eventos) e ao Luciano Lima pela imensa ajuda na moderação da palestra!

Espero que o conteúdo ajude e até a próxima!

Abraços

Uilson

Considerações sobre o uso da feature Account Lockout do Forefront TMG

8 de outubro de 2013 3 comentários

Saudações,

No dia 29/08/2013, postei aqui sobre uma investigação que fiz juntamente com alguns colegas especialistas em Exchange Server em um cliente que usa o Forefront TMG para publicar o Outlook Web Access (OWA). Você poderá ler o artigo clicando aqui.

A aplicação do Account Lockout no Forefront TMG ocorreu depois que constatamos diversas tentativas de acesso ao ambiente vindas de um dispositivo Android, cuja conexão foi “hackeada” através de um acesso feito usando uma WIFI pública.

Entretanto, mesmo após habilitar o Account Lockout o administrador ainda pode vivenciar casos de bloqueio de contas.

A questão é, como implementar o Account Lockout de forma a torna-lo efetivamente útil e não ser mais um problema em meu ambiente?

É fundamental um envolvimento de todos os profissionais que administram o ambiente para que se habilite a feature da melhor forma possível, ou seja, o administrador do TMG deve trabalhar lado a lado com o responsável pelo AD e suas políticas.

Se o Active Directory bloqueia o usuário após a terceira ou quarta tentativa de logon com senha errada, o Account Lockout do TMG deverá entrar em ação em um threshold menor que isso.

Exemplo: A política de senhas da corporação rege que a conta seja bloqueada após a 3a. tentativa de acesso ao ambiente com password errado. Neste caso o Account lockout deverá estar configurado para bloquear um acesso na segunda tentativa errada, evitando assim que o AD contabilize a terceira tentativa e bloqueie a conta do usuário.

Tudo certo? NÃO!!!

Existem outros fatores que podem fazer uma conta ser bloqueada no AD, mesmo que todos esses cuidados sejam tomados e os pré requisitos sejam seguidos.

Vamos tomar como exemplo o desenho abaixo:

image

Levando em consideração o desenho exposto, temos um ambiente em que o usuário tem um notebook para uso na empresa e fora dela. Pela rede interna, o acesso sai do notebook e vai diretamente para o Exchange, sem intermédio do Forefront TMG.

No momento em que este usuário está fora da empresa, ele pode acessar seus emails a partir de um tablet, celular e até mesmo pelo próprio notebook.

O usuário tem seu perfil de email cadastrado no tablet e no celular com a senha gravada em ambos. Desta forma, o acesso ocorre sem necessidade de fornecimento das credenciais.

Levemos em consideração que, antes de sair da empresa, o usuário alterou sua senha de rede.

Ao sair da empresa o usuário para em um cyber-café. Enquanto saboreia um capuccino, acessa a internet pelo WIFI e resolve ler seus emails corporativos.

Na primeira tentativa dá erro, a segunda também…ele se lembra que alterou a senha antes de sair do escritório e faz o mesmo no perfil de emails cadastrado no tablet. Pronto! Tudo resolvido! Acessa seus emails e vai embora.

Entretanto, para sua surpresa, ao chegar no escritório, dia seguinte, vê que sua conta está bloqueada…porque?

Vamos agora entrar na parte técnica da nossa aventura, explorando o desenho acima.

Imaginem que a politica de senhas da corporação vai bloquear uma conta após 5 tentativas de acesso com senha errada.

No Forefront TMG, o admnistrador habilitou a feature de Account Lockout para bloquear o acesso na quarta tentativa de acesso externo com senha errada.

Aí o leitor deste blog me pergunta: “Uilson, se o usuário digitou a senha errada “só” duas vezes e o limite do AD é 5 e do TMG 4, porque isso ocorreu?”

Neste caso eu volto a nossa história para lembrar que o acesso externo do usuário não se resume somente ao tablet…existe um perfil dele cadastrado também no celular.

OK, mas, o que isso tem a ver com o bloqueio da conta? Imaginem que o celular dele ficou com a secretária ou com um assistente que gerencia seus compromissos e também emails.

No momento e que o usuário alterou sua senha no AD (enquanto acessando internamente), ele não comunicou seu assistente/secretária deste fato. O tablet enviou duas requisições erradas para o AD através de uma WIFI, vindo de uma determinada range de IP.

O assistente tentou por 3 vezes acessar os emails do usuário sem sucesso, afinal ainda constava no dispositivo a senha antiga. O acesso deste celular veio de uma rede 3G/4G usando outra range de IP. Vale ressaltar que os acessos do celular ocorreram 5 minutos depois que o usuário corrigiu a senha errada no tablet.

Observe no desenho que, o acesso via Tablet é representado pela seta maior e o acesso via celular, pela seta menor.

Vamos supor que o acesso pela seta maior (tablet) entra com um IP, passa pelo proxy reverso do node 1 do TMG e autentica no AD pelo node 1. OK? Certo!!!

Agora vamos supor que o acesso pela seta menor (celular) entra com outro IP, passa pelo proxy reverso do node 2 do TMG e autentica no AD pelo node 2. OK? Certo de novo!!!

O que irá acontecer no próximo acesso do nosso usuário?

Exato! Irá bloquear! E aí, o desbloqueio ocorrerá após um período definido na própria política do AD, ou através de um administrador do ambiente.

Vejam bem, o usuário digitou sua senha errada 2 vezes pelo tablet, o assistente digitou a senha errada pelo celular 3 vezes. Ambos entraram na rede com IP’s distintos e por nodes diferentes.

A configuração do Account Lockout é feita em um único node do TMG e replica para o outro, porém, o processo de contabilização das tentativas é feita por cada node em separado.

Dessa forma, o Account Lockout não bloqueia o acesso, tanto do tablet como do celular, mas, as tentativas erradas ficam registradas no AD. Dessa forma o bloqueio da conta ocorre.

Como fazer para evitar isso? De certa forma a solução foge de qualquer ação a ser tomada no AD ou no Forefront TMG. É necessário avaliar a necessidade de vários dispositivos sendo usados para uma mesma conta e, além disso, o usuário ter a ciência de que, se alterar sua senha em um dispositivo (notebook, tablet ou celular) terá que alterar em todos os que usa para acessar seu perfil.

Esta explanação foi apresentada em um de nossos clientes a uns dias atrás e achei que seria muito interessante compartilhar aqui.

Espero que possa ser útil e, em caso de dúvidas, deixe seu comentário que terei o maior prazer em responder.

Abraços

Uilson

Investigando bloqueio de contas de usuário a partir do Forefront TMG

20 de agosto de 2013 1 comentário

Saudações,

Na semana passada fui chamado a atuar em um dos nossos clientes onde buscavam entender o porque dos constantes bloqueios de conta de um determinado usuário.

Os scripts que os administradores do AD usaram mostravam que a origem dos bloqueios vinha de uma infra de servidores Forefront TMG.

O fluxo do ambiente corre conforme abaixo:

image

Esta infra foi implementada por mim no fim de 2012. Conforme desenho acima, os acessos ao OWA (Outlook Web Access) são publicados em uma infra de 2 servidores Forefront TMG em NLB para os acessos externos.

Os acessos ao webmail vindos da rede interna vão direto para os servidores Exchange.

Durante o período de análise do problema verifiquei que algumas contas estava bloqueando, mas, logo foi identificado que, realmente se tratava de tentativas de logon com senha errada e foram descartadas.

Apenas um usuário sofria com constantes bloqueios em sua conta e, com base no user name específico focamos nele as análises.

A primeira verificação foi determinar se a feature Local Account Lockout do TMG estava habilitada. Após alguns comandos em Power Shell recebi o retorno abaixo:

imagem3

De acordo com a imagem acima a feature encontrava-se desabilitada. Mesmo sabendo que os bloqueios estavam vindo diretamente de servidores AD, fiz questão de verificar isso pois, a configuração desse feature pode influenciar no acesso ao domínio como um todo.

Para saber como configurar e verificar o status da feature você pode ler o artigo que escrevi para o TechNet Wiki sobre como Configurar o Local Account Lockout no Forefront TMG usando Power Shell.

O próximo passo foi verificar o tráfego que o usuário gerava para verificar o que ocorria. Após algumas queries no Live Logging recebi as informações abaixo:

Failed Connection Attempt TMGServer 8/14/2013 12:20:23 PM

Log type: Web Proxy (Reverse)

Status: 1909 The referenced account is currently locked out and may not be logged on to.

Rule: Publish EAS 2010

Source: 189.106.176.29:40794

Destination: xx.xxx.xx.xx:443

Request: OPTIONS http://webmail.dominio.com.br/Microsoft-Server-ActiveSync?Cmd=OPTIONS&User=domain%5Cuserid&DeviceId=androidc95837483&DeviceType=Android

Filter information: Req ID: 155b8170; Compression: client=No, server=No, compress rate=0% decompress rate=0% ; FBA cookie: exists=no, valid=no, updated=no, logged off=no, client type=unknown, user activity=yes

Protocol: https

Essas tentativas de acesso ocorriam noite a dentro e madrugada.

Como o TMG não faz cache de usuário e senha e tampouco armazena essas informações, precisamos conversar diretamente com o usuário para tentar mapear o comportamento.

Na log exibida acima é possivel determinar o device ID e o modelo do celular usado (DeviceId=androidc95837483&DeviceType=Android) e após verificação pelo pessoal responsável pela administração dos aparelho corporativos, não existe nenhum aparelho com esses dados na companhia.

Segundo ponto importante, o IP de origem da conexão (189.106.176.29), quando verificado, me mostrou a seguinte origem:

image

O domínio veloxzone.com.br pertence a uma empresa que fornece acesso WIFI público em shoppings, tendo como parceiros provedores como o UOL por exemplo. Ou seja, o acesso estava vindo de fora do cliente através de uma WIFI pública. O usuário usou essa rede para acesso por uma vez.

Terceiro ponto – As tentativas de acesso feitas noite a dentro e madrugada, vinham de uma conexão 3G da empresa VIVO.

Detalhe: O uso do aparelho pelo usuário se limitava a ligações telefônicas e acessos ao webmail durante horário comercial.

Quarto e decisivo ponto – Fizemos um teste de conexão usando o aparelho do usuário (um Samsung Galaxy S3) e os dados do DeviceID e modelo coletados pelo log do TMG eram completamente diferentes dos exibidos aqui.

Conclusão:

1. Com base em todas as informações acima citadas e o fato de os bloqueios continuarem ocorrendo mesmo com o aparelho desligado, nos deram a certeza de que, durante o acesso do usuário na WIFI pública, seus dados foram hackeados e usados por terceiros.

2. Os servidores do TMG apareciam como os pontos de bloqueio da conta porque são o primeiro ponto em que a conexão chega antes de ser encaminhada aos servidores do Outlook Web Access. A identificação do DeviceID e origem da conexão, além da própria interação com o usuário foram importantes para entender o caso.

3. Fizemos uma regra bloqueando o acesso vindo o IP da rede VeloxZone para evitar novos bloqueios, visto que os acessos via 3G não mais ocorreram. Além disso, os responsáveis pelo Exchange bloquearam o acesso do usuáro via Active Sync em caráter temporário.

Espero que o case apresentado possa ser útil!

Abraços

Uilson

Perda da relação de confiança em uma infra estrutura de servidores Forefront TMG

24 de abril de 2013 Deixe um comentário

Saudações,

Essa semana a operação nos acionou para verificação de uma infra estrutura TMG em um de nossos clientes.

Temos um servidor EMS e dois nodes TMG em NLB servindo uma média de 7.000 usuários.

Ao tentar acesso no servidor TMG o administrador recebia a seguinte mensagem de erro:

 

image

Ao analisar o event viewer nos deparávamos com os seguintes erros:

Error      4/22/2013 10:05:33 AM GroupPolicy       1053      None
The processing of Group Policy failed. Windows could not resolve the user name. This could be caused by one of more of the following:
a) Name Resolution failure on the current domain controller.
b) Active Directory Replication Latency (an account created on another domain controller has not replicated to the current domain controller).

Log Name:      System
Source:        Microsoft-Windows-Security-Kerberos
Date:          4/22/2013 10:05:28 AM
Event ID:      5
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:     
Description:
The kerberos client received a KRB_AP_ERR_TKT_NYV error from the server host/oesp0001.grpoesp.com.br. This indicates that the ticket used against that server is

not yet valid (in relationship to that server time).  Contact your system administrator to make sure the client and server times are in sync, and that the KDC in realm GRPOESP.COM.BR is in sync with the KDC in the client realm.

Podemos aqui verificar problemas de acesso do node TMG ao Domain Controller.

Para entender bem a importância do acesso do TMG no Domain Controller, vc pode usar como referência o artigo escrito a algum tempo pelo Yuri Diógenes clicando aqui.

Depois de um certo tempo ficou inviável o acesso ao servidor por uma perda de relação de confiança entre TMG Server e o Domain Controller, conforme mensagem abaixo:

 

image

Para resolver este problema você pode seguir um dos métodos abaixo usando uma conta local com direitos administrativos:

1. Remover a estação do domínio e recoloca-la:

Em uma infra estrutura pequena com apenas um node o processo é simples:

Remover do domínio / Reboot / Inserir novamente no domínio

Para infras com mais de um node em array (via EMS ou Stand Alone Array) vc precisa remover a máquina afetada do array, usando a opção “disjoin server from array” no painel Tasks conforme abaixo:

image

Feito o disjoin, você remove o servidor do domínio / reboot / insere novamente / reboot / logon com conta de domínio e faz o join do servidor no array conforme abaixo:

image

Clicando na opção “Join Array”, você vai inserir o node em um stand alone array ou em um EMS.

2. Corrigir a relação de confiança usando o utilitário netdom:

Em um command prompt com elevação de permissão digite o seguinte comando:

netdom.exe resetpwd /s:<server> /ud:<user> /pd:*

Reinicie o servidor e faça novo logon com sua conta de domínio.

Para informações sobre sintaxes do comando netdom vá no link abaixo:

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

A opção 2 é a mais recomendada para que você tenha menos trabalho e consiga restaurar seu ambiente em menos tempo, mas, em algumas situações, a opção 1 é a mais indicada.

Espero que o artigo seja útil e possa ajudar.

Abraços

Uilson

%d blogueiros gostam disto: