Archive

Archive for the ‘Power Shell’ Category

Sobre DNS Policies–Windows Server 2016–volume 04–Split-Brain DNS e Selective Recursion Control

29 de maio de 2017 Deixe um comentário

Saudações,

Peço desculpas pela demora na publicação do quarto volume desta série. Estive em dias de muito trabalho e alguns percalços pessoais. Mas de qualquer forma vamos ao conteúdo de hoje – Split-Brain DNS.

A quem está chegando agora, abaixo os links para os outros 3 posts da série:

Sobre DNS Policies – Windows Server 2016 – volume 01 – Teoria

Sobre DNS Policies – Windows Server 2016 – volume 02 – Balanceamento de Carga

Sobre DNS Policies – Windows Server 2016 – volume 03 – Gerenciamento de Tráfego de Rede baseado em Geo-Localização

De acordo com a teoria que coloquei no volume 1 desta série, com o recurso de Split-Brain DNS os registros são divididos em diferentes escopos de zona no mesmo servidor DNS. Os clientes DNS recebem uma resposta baseado onde de fato estes clientes estão – internos ou externos. Este recurso pode ser configurado em zonas integradas ao AD ou para DNS Standalone Servers.

Também iremos criar políticas de seletive recursion para mitigação e vulnerabilidades em ambientes como este.

Em tempo – Este laboratório foi criado em meu ambiente tendo como base o laboratório do artigo Split-Brain DNS Deployment Using Windows DNS Server Policies do pessoal do Networking Blog da Microsoft. Como não tinha montado nada semelhante, me espelhei no conteúdo deles para criar o meu. Para aqueles que notarem a semelhança do meu lab com o deles, fica aqui registrado que a idéia inicial é do link citado e deixo a eles o devido crédito.

Vamos então a parte prática!

Imaginemos que tenho um site que deverá ser acessado tanto por usuários internos quanto externos. Esse possui informações de produtos da minha empresa que a equipe compartilha com parceiros externos.

Meu DNS posui duas interfaces, uma interna e outra externa

Interna – IP 10.10.1.100

Externa – IP 200.185.0.55

Meu servidor de aplicação interno responde pelo IP 10.10.1.10 e meu servidor de aplicação externo responde pelo IP 66.56.40.10 (lembrando que estes são IP´s fictícios, os IP´s que usei no laboratório do meu ambiente são outros e aqui fica só para ilustração)

Objetivo – Usuários na minha rede interna, irão acessar o site produtos.uilson.net do back-end Server interno e usuários externos irão acessar o back-end server externo, conforme o desenho abaixo:

 

image

Com o cenário definido, vamos ao procedimento que torna tudo isso real:

Vamos começar criando um zone scope para o acesso interno, ou seja, os acessos que virão pela interface 10.10.1.100:

Add-DnsServerZoneScope –ZoneName “uilson.net” –Name “InternalAccess”

Iremos criar o zone scope somente para o acesso interno, ficando o acesso externo direto no zone uilson.net no escopo padrão.

Agora vamos criar criar os registros para os acessos interno e externo, sendo que, para o acesso interno, iremos cria-lo já dentro do zone scope que acabamos de criar:

Registro de acesso externo – Add-DnsServerResourceRecord –ZoneName “uilson.net” –A –Name “produtos” –IPv4Address “66.56.40.10”

Registro de acesso interno – Add-DnsServerResourceRecord –ZoneName “uilson.net” –A –Name “produtos” –IPv4Address “10.10.1.10” –ZoneScope “InternalAccess”

Agora que temos o zone scope e os registros criados, vamos à política que irá diferenciar acessos internos e externos:

Add-DnsServerQueryResolutionPolicy –Name “SplitBrainPolicy” –Action Allow –ServerInterface “eq,10.10.1.100” –ZoneScope “InternalAccess,1” –ZoneName uilson.net

Feito!!!! Temos agora nosso ambiente direcionando as requisições internas ao site produtos.uilson.net para o back-end server interno e os acessos externos indo diretamente para o servidor externo, conforme definido no escopo inicial.

Poderiamos dizer que temos o trabalho finalizado, certo? Errado! Deixar o ambiente simplesmente como está pode, em alguns casos, criar uma vulnerabilidade que precisa ser mitigada.

Lembre-se que neste exemplo temos um DNS Server resolvendo nomes para recursos internos e externos. O que pode ocorrer aqui é que requisições internas e externas passem fazer queries por endereços de internet, podendo expor o ambiente a um Reflection Attack ou DNS Amplification Attack – um DDoS.

Neste caso, as resoluções recursivas para nomes externos precisa ser bloqueada e para isso criaremos outra política que vem a ajudar na mitigação desta vulneravbilidade:

image

Desenho original do link: https://blogs.technet.microsoft.com/networking/2015/05/12/split-brain-dns-deployment-using-windows-dns-server-policies/

O link que postei sobre DDoS DNS Amplification Attack pede que a funcionalidade da recursiva seja desasbilitada no servidor DNS. Neste caso, vamos desabilitar este recurso que será usado somente para requisições internas.

Desabilitando a recursiva: Set-DnsServerRecursionScope –Name . –EnableRecursion $False

No comando acima, a recursiva está sendo desabilitada para o escope default (tudo que está em uilson.net).

Agora vamos habilitar a recursiva somente para um escopo de clientes internos:

Add-DnsServerRecursionScope –Name “RecursionInternalClients” –EnableRecursion $True

Agora vamos criar a política que irá permitir a recursiva somente para clientes internos;

Add-DnsServerQueryResolutionPolicy –Name “SplitBrainRecursionInternal”-Action ALLOW –ApplyOnRecursion –RecursionScope “RecursionInternalClients” –ServerInterfaceIP “EQ,10.10.1.100”

Agora temos nosso ambiente executando dentro de uma melhor prática para o recurso do Split-Brain DNS.

Espero mais uma vez que o conteúdo possa ser útil e não perca o volume 5 desta série. Iremos falar sobre Filtering com DNS Policies.

Abraços

Uilson

Usando PowerShell para corrigir vulnerabilidades via chave de registro

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

Saudações,

O post de hoje visa ajudar os administradores de rede e analistas de segurança no momento em que precisam planejar a mitigação e correção de alguns tipos de vulnerabilidades em estações de trabalho via chave de registro.

Normalmente, a empresa dispõe de uma ferramenta que faz o scan, encontra, classifica e exibe em relatório quais vulnerabilidades uma ou mais estações têm e como corrigir.

Agora, imaginem uma determinada vulnerabilidade a ser corrigida em diversas estações? Como fazer?

Uma forma é usar o comando PSEXEC do SysInternals para executar este trabalho. A partir de um arquivo de lote eu uma simples variável (%1), o problema pode ser resolvido. Entretanto, como nosso foco é disseminar todas as formas de otimização de tarefas com PowerShell, queria mostrar como o usei para resolver um problema num case real.

Recebemos a notificação de que uma determinada área da empresa precisava ter todas as estações com o parâmetro de SMB Signing habilitado. Este parâmetro criptografa todo fluxo de informações entre a estação e um file server, num processo semelhante ao do SMB Encryption, feito no Windows Server 2012 R2, entretanto, o processo aqui visa proteger estações com Windows 7 Professional.

Não existe uma console administrativa ou um processo via GUI para tal, portanto, como falei, ou você o faz via PSEXEC do SysInternals ou, no nosso caso, usando PowerShell.

O processo consiste na criação de uma chave de registry que vai habilitar o SMB Signing na estação:

Chave a ser criada – EnableSecuritySignature

Tipo – DWORD

Valor – 1

Endereço – HKLM\System\currentcontrolset\services\lanmanworkstation\parameters

Comando PowerShell a ser usado:

Invoke-Command -cn computername {New-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\LanManWorkstation\Parameters" -Name EnableSecuritySignature -Value "1" -PropertyType DWORD -Force | Out-Null}

No comando acima, criamos a chave de registry remotamente em uma estação. Estou considerando aqui que o administrador tem amplo acesso ao equipamento remoto. Entretanto você pode se deparar com um ambiente em que seu usuário não tenha acesso àquela estação (ou grupo de estações) e precise declarar seu usuário. Neste caso você pode entrar com o seguinte comando:

$Auth = Get-Credential dominio\usuario
Invoke-Command -cn computername -Cred $Auth {New-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\LanManWorkstation\Parameters" -Name EnableSecuritySignature -Value "1" -PropertyType DWORD -Force | Out-Null}

Ao executar este comando, você será solicitado a entrar com o usuário e senha com permissão de acesso na estação:

image

Ao entrar com as credenciais necessárias, o script faz criação da chave com o valor conforme citado acima.

Você pode conferir se a chave foi mesmo criada usando comando abaixo:

Invoke-Command -cn computername {Get-Item -Path "HKLM:\System\CurrentControlSet\Services\LanManWorkstation\Parameters"}

Abaixo o resultado:

image

Agora vamos considerar o fato de termos uma lista de estações a serem corrigidas. Como fazer? Você pode usar o PowerShell ISE e criar um script para isso, usando laços do comando For EACH:

ForEach ($WKS in (Get-Content C:\ComputerList.txt)){
    Invoke-Command -cn $WKS {New-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\LanManWorkstation\Parameters" -Name EnableSecuritySignature -Value "1" -PropertyType DWORD -Force | Out-Null}
    }

Antes de executar o script acima, você precisa preencher o TXT citado na primeira linha e preencher com os nomes das estações. O processo será realizado em cada uma delas.

Espero que o conteúdo seja útil e ajude no seu dia a dia.

Abraços

Uilson

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

DNS Server–Configurando a Global Query Block List via PowerShell

28 de novembro de 2016 Deixe um comentário

Saudações,

Aos que estão acompanhando a nossa série de artigos sobre otimização de tarefas com PowerShell, hoje vou fazer um “adendo” ao 5o. post – Otimização de tarefas com PowerShell – DNS Server.

Um dos pontos de atenção nas empresas nos últimos anos é a configuração do acesso ao proxy usando o registro wpad do DNS Server. O mesmo pode ser configurado via DHCP também, mas, deixarei isso para um próximo post.

Por questões de segurança, desde o Windows Server 2008, o registro WPAD e ISATAP (registro que auxilia na comunicação de dipsositivos IPv4 e IPv6), estão bloqueados para uso. Entretanto, o administrador do ambiente pode escolher entre:

1. Ativar um desses registros – via PowerShell com via linha de comando DNSCMD

2. Desativar a Global Query Global List

Um exemplo de como configurar essa funcionalidade via linha de comando foi dada no meu artigo de 16/07/2013 onde citei a configuração do WPAD via DNS usando o DNSCMD.

No nosso caso em que estamos destrinchando o PowerShell para nosso dia a dia, estou deixando aqui um exemplo prático de como usar o comando Get-DnsServerGlobalQueryBlockList e Set-DnsServerGlobalQueryBlockList

No primeiro exemplo vamos listar os hosts que estão bloqueados pelo Global Query Block List:

Get-DnsServerGlobalQueryBlockList

Em seguinda vamos liberar o uso do registro WPAD:

Set-DnsServerGlobalQueryBlockList –List “isatap” –Passthru

O comando acima vai reconstruir a Global Query Block List deixando bloqueado somente o registro “ISATAP”.

Agora vamos reconstruir a Global Query Block List inclindo, além do ISATAP, o WPAD também;

Set-DnsServerGlobalQueryBlockList –List “wpad, isatap” –Passthru

Se você quiser, também pode desabilitar a Global Query Block List (o que não recomendo):

Set-DnsServerGlobalQueryBlockList –Enable $False

E para habilitar de novo:

Set-DnsServerGlobalQueryBlockList –Enable $True

Abaixo um exemplo prático de como você visualiza todos os comandos citados:

image

No próximo post quero voltar ao Web Application Proxy, mostrando como configurar seu ambiente para aplicações com autenticação Kerberos.

Fique ligado aqui no blog e na fan page – facebook.com/usouzajr.

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

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

28 de julho de 2016 Deixe um comentário

Saudações,

Hoje vamos entrar no quarto post da série “Otimizando Tarefas com PowerShell”. Pra quem está chegando agora e não conhecia o blog Microsoft Space, estou trabalhando em uma série de artigos relacionados a PowerShell, conforme abaixo:

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

Vamos continuar usando o ambiente fictício criado nos posts anteriores.

Imagine que você precisa instalar o IIS em uma farm de servidores que vão estar balanceando a carga. Vc teria habilitar a feature em um por um, mesmo usando o Server Manager de um único servidor para isso. Vamos mostrar a seguir como fazer de forma otimizada e mais rápidamente. Ou então você vai analisar um ambiente em que o IIS esteja em um Server Core ou até mesmo Nano Server.

Algo importante que esqueci de mencionar no segundo e terceiro artigos da série é que os comandos de instalação de roles e features estão armazenados no módulo ServerManager do PowerShell, portanto, se ao tentarem fazer o teste com os comandos citados nos artigos anteriores vocês receberem alguma mensagem de erro, façam o carregamento do módulo conforme abaixo:

Import-Module ServerManager

1. Instalando o IIS:

Como vocês já devem saber, o IIS pode ser instalado em sua totalidade, ou seja, com todas as features ou somente aquelas que você precisar para o proposito da sua infra.

Com o comando abaixo você instala o IIS com todas as features do role:

add-windowsfeature web-server –includeallsubfeature

Recomendo fortemente aquilo que sempre falo em post´s neste blog e em outros espaços, além das palestras e webcasts que entreguei; faça um planejamento prévio, converse com sua área de desenvolvimento para entender o que você vai precisar do seu IIS, qual o tipo de aplicação que irá hospedar e as features exatas que você vai precisar.

Para sabermos quais as features do IIS disponíveis, podemos usar o comando get-windowsfeature parametrizando pelas funções do IIS:

get-windowsfeature | Where-Object {$_.Name –like “Web*”}

image

Na coluna “Name” da figura acima, você tem a listagem de todas as features do IIS. Tomando como exemplo a sessão “Application Development”, eu posso instalar todos os itens da mesma, declarando todos os parâmetros, ou posso escolher uma ou mais funcionalidades tais como ASP, ASP.NET 3.5, etc, usando os parâmetros separadamente. Lembrando que as funcionalidades vitais de cada feature são instaladas automaticamente, mesmo que eu não as declare na minha linha de comando (exemplo – se eu declarar somente a feature Web-Security, a funcionalidade Web-Filtering será habilitada automaticamente).

Em nosso laboratório vamos instalar o IIS pensando em autenticação básica, autenticação integrada, protocolos http e https. Além desses, vamos usar o serviço de armazenamento de certificados digitais, o CCS (Centralized Certificate Store – sobre o qual escrevi um post detalhado com um passo a passo bem completo). Veja abaixo como fica o comando para instalação:

add-windowsfeature web-server, web-webserver, web-default-doc, web-http-errors, web-static-content, web-http-redirect, web-health, web-security, web-basic-auth, web-certprovider, web-cert-auth, web-ip-security, web-windows-auth, web-app-dev

A imagem abaixo mostra o progresso da instalação:

image

Veja agora através do comando get-feature, as funcionalidades do IIS que foram instaladas com o comando usado acima:

image

OBS: Não instalei aqui a console de gerenciamento do IIS que você encontra em Start/Administrative Tools. Vamos focar na implementação e administração do IIS somente via powershell. Se você prefere gerenciar a partir da console, basta adicionar o parâmetro –IncludeManagementTools no fim do comando, ou na figura acima, você tem a sessão Management Tools com o parâmetro Web-Mgmt-Tools.

Agora que temos o IIS instalado, vamos aos métodos para administra-lo através do Powershell.

2. Criando um web-site

Vamos criar um site com os dados abaixo:

Nome – PortalUilson.net

Biding – https://www.uilson.net

Path – c:\webapp

Autenticação – Windows Integrated

Documento Default – iisstart.htm

Vai pegar o certificado através do Centralized Certificate Store.

1. Criando WebSite:

É importante que você já carregue o módulo do IIS com o comando: import-module WebAdministration

No prompt de comando, você já poderá ver como está configurado o Default Web Site conforme figura abaixo:

image

Com o comando “dir iis:” você visualiza três “pastas” do IIS disponíveis: 1. AppPools (Os application pools criados), 2. Sites (Seus WebSites, applications e virtual directories), 3. SSLBindings (Todos os bindings criados com certificado digital – porta 443).

Para listar os sites criados use o comando dir iis:\Sites para ter o resultado abaixo:

image

Acima você que o Default Web Site tem o ID 1 (importante na hora de determinar e configurar a parte de log do IIS), está em status “Started”, mostra o Physical Path e a parte do Binding rodando em http na porta padrão (80).

Para simplificar, você pode entrar no IIS pelo PowerShell digitando “IIS:” e teclando ENTER:

image

Viram como facilita?

Agora vamos criar nosso novo Web Site conforme descrevi:

Vamos criar a pasta onde vai ficar a aplicação web:

new-item c:\webapp –type directory

Com esse comando criamos a pasta webapp. Copiei os arquivos do site inicial do IIS para podermos efetuar o teste de acesso a página.

Comando para criar o site:

iis:

New-Item Sites\PortalUilson.net –bindings @{protocol=”http”;BindingInformation=”:80:www.uilson.net”} –physicalPath c:\webapp

image

O ID ficou meio estranho pra visualisar mas, é 1949349561. É com esse ID que ele vai criar a pasta de log da aplicação.

Na imagem acima você pode ver que eu já criei o site com o acesso a porta 80 no host header http://www.uilson.net . Eu poderia ter usado o comando acima sem o host header e poderia deixar um binding para porta 80 do localhost e poderia criar outro binding na mesma porta definindo a URL com o comando abaixo:

New-WebBinding -Name PortalUilson.net -IPAddress "*" -Port 80 -HostHeader www.uilson.net

Veja também que nosso site está em estado “Started”, ou seja, está escutando requisições na porta 80 a partir da URL que definimos. Caso houvesse algum conflito de porta, ele estaria em status “Stoped”, ou caso fosse necessário poderiamos para-lo com o comando abaixo:

Stop-WebSite PortalUilson.net

Para colocar o site no ar novamente, basta executar o comando abaixo:

Start-WebSite PortalUilson.net 

image

Agora que já temos nosso ambiente pronto, vamos começar a ver outros detalhes tais como log e documento default.

Em nosso laboratório criei um site simples sem nenhum application ou virtual directory. Nesse caso temos que definir o documento default que irá iniciar a pagina default do site. Caso contrário teremos erro no acesso.

Vamos verificar quais são os documentos que constam da lista de Default Document e qual documento está no topo da mesma. Para isso você vai usar o comando abaixo:

Get-WebConfigurationProperty -Filter //defaultDocument/files/add -PSPath ‘IIS:\Sites\PortalUilson.net’ -Name value | select value

image

Veja que no nosso site (PortalUilson.net) já temos Default.htm, Default.asp, index.htm, index.html e issstart.htm. Precisamos configurar o iisstart.htm no topo da lista, pois ele é o arquivo a ser chamado pela URL definida anteriormente.

Durante o período de estudos para confecção deste post, não encontrei uma linha de comando que fizesse a alteação da ordem dos arquivos, colocando ele no topo. Caso tentasse adiciona-lo como parâmetro para coloca-lo no topo, recebia uma msg de erro. Resolvi esse problema removendo o iisstart.htm da lista com o comando abaixo:

Remove-WebConfigurationProperty //defaultdocument/files "IIS:\sites\PortalUilson.net" -name collection -AtElement @{value="iisstart.htm"}

Depois verifiquei com o Get-WebConfigurationProperty para me certificar de que ele não constava mais na lista:

image

Agora vamos configurar o iisstart.htm como defult document do nosso site. Abaixo vou executar um comando que irá coloca-lo no topo da lista de arquivos do default document:

Add-WebConfiguration //defaultDocument/files "IIS:\sites\PortalUilson.net" -atIndex 0 -Value @{value="iisstart.htm"}

image

Você pode ver na imagem acima que o arquivo iisstart.htm aparece no fim do documento, entretanto, o parâmetro “atIndex 0” do comando aplicado acima o coloca no topo da ordem do default document.

3. Application Pool e métodos de autenticação

Já temos nosso site criado e configurado. Agora vamos verificar a parte do application pool dele:

Abaixo mostro como visualisar os application pools criados no IIS

image

Na imagem acima vemos que o Default Web Site já tem seu Application Pool definido, porém, o site do nosso laboratório ainda não.

Abaixo o comando para criação de um application pool:

image

OBS: O comando New-Item criou uma nova application pool no IIS. Como você pode ver na figura acima, estamos posicionados na pasta de Application Pools do IIS. Poderiamos executar esse comando mesmo em outra pasta ou na raiz do IIS da seguinte forma:  New-Item IIS:\AppPools\PortalUilson.AppPool

Agora vamos associar nosso Applicaton Pool com o site PortalUilson.net com o comando: Set-ItemProperty ‘IIS:\Sites\PortalUilson.net’ -Name applicationPool -Value PortalUilson.AppPool

Com a execução do comando acima, você verá agora que o site criado em nosso laboratório agora tem um application pool para ele:

image

Vamos definir uma conta para gerenciar essa application pool:

Set-ItemProperty iis:\AppPools\PortalUilson.AppPool -name processModel -value @{userName="appuser";password="WebAppPool@2016";identitytype=3}

No comando acima defini uma conta local (username = appuser e senha = AppPool@2016) classificando com IdentityType 3 – o Identity type se refere ao tipo de conta que você vai usar em sua Application Pool. O número do identity mudaria caso você fosse usar outro tipo de autenticação, exemplo: Network Service.

No link abaixo, você tem uma explanação detalhada da parte de Itentity Type:

http://www.iis.net/configreference/system.applicationhost/applicationpools/add/processmodel

Agora vamos ver as propriedades de nosso application pool com o comando get-item PortalUilson.AppPool | Select-Object *

image

Para ver os dados de usuário usamos o comando Get-ItemProperty PortalUilson.AppPool -name "processmodel.username"

image

Veja na figura acima que a penultima linha (Value) traz o nome da conta que configuramos nos passos acima.

Podemos ver também que nosso Application Pool está configurado para usar a versão 4.0 do .NET Framework:

image

Caso sua aplicação peça outra versão, você deverá tê-la instalada no servidor. A instalação de outras versões do .NET pode ser feita nas features do IIS conforme descrito no começo deste post.

Se você tiver um Application Pool rodando o .NET Framework na versão 2.0 e quiser mudar para a 4.0, use o comando abaixo:

Set-ItemProperty PortalUilson.AppPool managedRuntimeVersion v4.0

Com o conceito de Web Application Pool definido, vamos agora vamos falar sobre autenticação.

Lembre-se do começo deste post em que instalamos o IIS com diversos métodos de autenticação (basic, integrada, etc). Quero que o site site tenha autenticação integrada, entretanto, o IIS vem com autenticação anônima (por default) habilitada.

Nos comandos abaixo vamos desabilitar a autenticação anônima e habilitar autenticação integrada (lembrando que, para este fim a aplicação já deve estar preparada para tal):

Desabilitando Anonymous: Set-WebConfiguration system.webserver/security/authentication/anonymousAuthentication -PSPath IIS:\sites\PortalUilson.net -Value @{enabled="False"}

Habilitando Windows Integrated: Set-WebConfiguration system.webserver/security/authentication/WindowsAuthentication -PSPath IIS:\sites\PortalUilson.net -Value @{enabled="True"}

4. Logging e Backup

Depois de instalar e configurar o IIS, criar e configurar o novo site, iremos agora definir onde gravar os log´s do mesmo. Por default o IIS coloca os log´s de acesso na pasta padrão da role: c:\inetpub\logs\LogFiles\WebisteID#:

image

No nosso caso vamos configurar o log para que seja gravado numa pasta diferente. Vou configurar para gravar em C:\weblogs\PortalUilson.net. Para tanto vamos usar os comandos abaixo:

Alteração do log para a pasta citada acima:

Set-ItemProperty IIS:\sites\PortalUilson.net -name logFile -value @{format=’W3C’;directory=’C:\weblogs\PortalUilson.net’}

Listando as propriedades de logging do nosso siteget-ItemProperty IIS:\sites\PortalUilson.net -name logFile:

image

No link a seguir, você encontra diversas formas de interagir com logging do IIS via PowerShell, inclusive alterando os campos do arquivo:

https://gallery.technet.microsoft.com/office/Set-IIS-Log-Fields-via-ee9c19b3

Com tudo pronto no nosso laboratório, vamos demonstrar agora como fazer o backup das configurações do IIS. A melhor forme de garantir seu ambiente é um backup do servidor usando a ferramenta da sua empresa, mas, para situações em que você precisa de um restore rápido é interessante ter um backup das configurações do IIS feito no próprio web server.

Para efetuar um backup rápido de suas configurações do IIS use o comando abaixo:

Backup-WebConfiguration –Name IISLab

image

Nesse comando eu fiz um backup das configurações do meu servidor IIS com o nome de “IISLab”.

Para verificar um ou mais backup´s feitos em seu ambiente use o comando Get-WebConfigurationBackup:

image

Como você pode ver na figura acima, posicionei na pasta c:\windows\system32\inetsrv\backup, onde o IIS grava os arquivos de backup gerados pelo comando que usamos a pouco:

image

5. SSL Settings – Agora é a sua vez de por a mão na massa!

Agora é com você!

Se leu todo post com atenção, testou em seu ambiente pessoal e ficou entusiasmado com a possibilidade de administrar seu IIS sem a Console de Gerenciamento, leia o conteúdo dos links abaixo e configure a parte SSL do IIS 8.5. Não foge dos conceitos que coloquei aqui e tudo pode ser encontrado no site iis.net da Microsoft.

Criando SSL Bindings no IIS – http://www.iis.net/learn/manage/powershell/powershell-snap-in-configuring-ssl-with-the-iis-powershell-snap-in

Na instalação do IIS você viu que coloquei também o recurso do CCS – Centralized Certificate Store. No começo deste post eu deixei um link com um artigo que escrevi sobre esse tema mostrando todo conceito e todos os passos (um lab completo) para habilitar o CCS. Para fazer o mesmo procedimento via PowerShell, clique no link abaixo:

https://technet.microsoft.com/en-us/magazine/jj937171.aspx

Além de ensinar a configurar o CCS, o link acima traz um exemplo de como instalar o IIS com as mesmas configurações em vários servidores, caso sua aplicação esteja definida para rodar numa farm.

E assim concluímos mais um post da série “Otimizando tarefas com PowerShell”. Cobrimos todos os passos para a instalação e administração do IIS 8.5 do Windows Server 2012 R2 via cmdlet.

Espero que o conteúdo tenha sido útil e caso tenha dúvidas ou críticas, por favor, deixe seu comentário ou me deixe uma msg em minha pag pessoal em http://facebook.com/usouzajr

Abraços

Uilson

Otimizando tarefas com PowerShell–Implementando e Administrando AD Federation Services

9 de junho de 2016 Deixe um comentário

Saudações,

Peço desculpas pela demora na continuidade desta série de posts. Estive envolvido em alguns projetos que me tomaram muito tempo.

Hoje vamos ao terceiro post da série “Otimizando tarefas com PowerShell”. Irei mostrar os passos para implementação, configuração e administração do Active Directory Federation Services.

Apenas relembrando, e para quem ainda não leu, os dois posts anteriores falaram sobre otimização de tarefas no  AD DS e Web Application Proxy.

Importante ressaltar que numa infra estrutura de proxy reverso com Web Application Proxy é premissa que o AD FS já esteja pronto, nesse caso, o certo seria ter escrito este post antes do anterior, entretanto, como já tinha o material e o expertise no assunto, resolvi inverter um pouco a ordem, mas, reitero que, o AD FS precisa estar pronto, OK?

Vamos lá! Como no post anterior, estamos em um ambiente fictício:

Domínio – uilson.net

AD FS Server – IP 10.10.1.3

Você precisa instalar a role do AD FS.

Lembrando que é necessário um certificado digital para o mesmo. Em se tratando de um servidor que fica em sua rede interna, você pode optar por um certificado gerado em sua própria entidade certificadora (AD CS – Certificate Services – sobre o qual iremos mostrar os princiais comandos PS futuramente). O certificado para o servidor AD FS, deverá estar instalado antes de efetuar a configuração do mesmo. Você pode importar o PFX do certificado via snap-in Certificates ou, como estamos querendo otimizar tarefas, vamos usar o cmdlet para isso:

Import-PfxCertificate –FilePath C:\ADFSCert.pfx cert:\localMachine\my -Password adfscert*

No comando acima, o arquivo PFX do certificado está na raiz do drive C:\. Seria interessante para casos em que você tem 2 ou mais servidores AD FS em uma farm, que os coloque em uma OU específica e crie uma política que envie para eles o certificado. Assim você poupa um passo no processo de deploy.

Ainda sobre o certificado, gere o mesmo de acordo com o AD FS Service Name que você vai definir na instalação. Por exemplo, no nosso laboratório aqui: “adfs.uilson.net”

Agora que o certificado do ADFS já está instalado, crie um host em seu DNS para qual você deverá apontar o IP do seu servidor AD FS – exemplo: “adfs.uilson.net – IP 10.10.1.3”.

Você precisa ter em mente se vai usar o Windows Internal Database (WID) ou se vai usar um servidor SQL. Isso vai depender do tamanho da sua infra, tipo e quantidade de acessos na sua aplicação, entre outros.

1. Instalando a role do AD Federation Services:

Install-windowsfeature adfs-federation -IncludeManagementTools

2. Configurando o servidor AD FS:

Estamos configurando um ambiente AD FS do zero. Portanto,  vou dar alguns exemplos de cenários em que você poderá configurar um AD Federation Services. Recomendo que use o ISE do PowerShell (ao executar o PowerShell, digite ISE):

2.1 – Configurando a farm AD FS:

Teremos que ter um usuário que irá executar o serviço do AD FS no servidor. Este usuário precisa de direitos de domain admin. Para tanto, vamos usar uma variável que iremos chamar de “$fscredential”. Essa variável irá chamar a função “Get-Credential” do PowerShell que deverá solicitar o usuário e a senha.

Como recomendei o uso do ISE para aplicar o comando todo, podemos fazer com que a variável solicite a conta do usuário de serviço e password e já prossiga com a instalação da farm:

$fscredential = Get-Credential

Install-AdfsFarm -CertificateThumbprint 8d8aa70358c538c7de50f5723571b9979696b5b2 -FederationServiceName adfs.uilson.net -ServiceAccountCredential $fscredential

No script acima, você irá primeiramente receber uma telinha pedindo user e a senha que será usado como conta de serviço e posteriormente, com os dados digitados, será feito a instalação da farm AD FS:

image

O parâmetro “-CertificateThumbprint” irá definir o certificado de common name “adfs.uilson.net” para o AD FS. Para descobrir o ThumbPrint de seu certificado, utilize o comando abaixo:

image

O parâmetro “-FederationServicesName”, define o nome do seu serviço de AD FS. É por ele, pelo certificado e pelo host criado no seu DNS (conforme falamos anteriormente) que a requisição chegará até o seu portal.

E por fim o parâmetro “-ServiceAccountCredential” irá usar a variável que falamos acima. Caso você não defina esta variável e nem declare esse parâmetro no comando, o AD FS usará o usuário logado como service account. Se você não usar os parâmetros citados, tenha certeza de que o usuário logado tem direitos de domain admin. Caso contrário a instalação não prosseguirá.

Conforme também falado neste post, o AD FS usa uma base de dados, seja ela o Windows Internal Database (WID) ou um SQL Server. No exemplo que acabei de mostrar, não declaramos nenhum SQL Server. Dessa forma o AD FS irá usar o WID.

Para instalar o AD FS apontando a base de dados para um SQL Server, use o comando abaixo:

$fscredential = Get-Credential

Install-AdfsFarm -CertificateThumbprint 8d8aa70358c538c7de50f5723571b9979696b5b2 -FederationServiceName adfs.uilson.net -ServiceAccountCredential $fscredential -SQLConnectionString "Data Source=SQLServerName\Instancia01;Integrated Security=True"

No comando acima vemos após a declaração das credenciais, o string de conexão com seu SQL Server.

2.2 – Criando uma farm AD FS com conta GMSA

Se você planeja criar uma farm AD FS com 2 ou mais servidores, é interessante usar um conta de domínio GMSA (Group Managed Service Account).

Para quem não está familiarizado com o GMSA no Windows Server 2012 pra frente, imagine que você tem uma infra de servidores AD FS ou até mesmo IIS em Load Balance com uma ou mais aplicações que usem autenticação Kerberos. Todas as instâncias dos serviços teriam que usar a mesma identidade.

Hoje configuramos, na maioria dos casos,  uma conta de serviços criada no AD a qual colocamos em cada servidor da farm. Entretanto, se você precisa alterar a senha desta conta. Precisará ir em todos os servidores da infra balanceada para alterar a senha. Caso contrário, o servidor no qual a senha não foi alterada, não conseguirá subir o serviço.

O serviço GMSA coordena essas contas de serviço com gerenciamento em um único ponto, agilizando o trabalho do administrador. No link abaixo você encontra um tutorial completo com os pré-requisitos para uso do GMSA e como criar as contas, usando inclusive, o powershell:

https://technet.microsoft.com/en-us/library/jj128431(v=ws.11).aspx

No nosso caso, podemos instalar o AD FS criando uma farm de servidores usando uma conta de serviços GMSA. Veja como no comando abaixo:

Install-AdfsFarm -CertificateThumbprint <certificate_thumbprint> -FederationServiceName <federation_service_name> -GroupServiceAccountIdentifier <domain>\<GMSA_Name>$

Trazendo para um exemplo em nosso laboratório:

Install-AdfsFarm -CertificateThumbprint 8d8aa70358c538c7de50f5723571b9979696b5b2 -FederationServiceName adfs.uilson.net -GroupServiceAccountIdentifier uilson\adfs_farm_user$

Lembrando que o parâmetro “$” ao fim do username é obrigatório.

O exemplo acima cria uma farm de servidores ADFS com uma conta de serviços GMSA, usando o WID (Windows Internal Database) como base de dados. Para criar uma farm conectada a um SQL Server, basta inserir no mesmo comando a string de conexão SQL usada no exemplo do item 2.1 deste post. Segue exemplo abaixo:

Install-AdfsFarm -CertificateThumbprint 8d8aa70358c538c7de50f5723571b9979696b5b2 -FederationServiceName adfs.uilson.net -GroupServiceAccountIdentifier uilson\adfs_farm_user$ -SQLConnectionString "Data Source=SQLServerName\Instancia01;Integrated Security=True"

Vale também ressaltar que a conta de serviços da farm não precisa obrigatoriamente ser uma conta GMSA.

2.3 – Adicionandos servidores a uma farm AD FS

Com a farm criada, conforme item 2.2 deste post, você poderá incluir mais servidores nela. Isso obviamente depois de uma análise de performance da aplicação para que você tenha o exato Sizing do seu ambiente AD FS.

Antes de adicionar o servidor na farm, tenha certeza de qual tipo de base de dados vc está trabalhando – WID (Windows Internal Database) ou um SQL Server. Copie tb o arquivo PFX do certificado anteriormente instalado no servidor primário da farm.

Abaixo o comando para inserir um servidor a farm AD FS com base WID, usando como conta de serviço um usuário de domínio:

Add-AdfsFarmNode -ServiceAccountCredential $fscred -PrimaryComputerName <first_federation_server_hostname> -CertificateThumbprint <certificate_thumbprint>

Trazendo para um exemplo em nosso laboratório:

$fscredential = Get-Credential
Add-AdfsFarmNode -ServiceAccountCredential $fscredential -PrimaryComputerName adfs_primary.uilson.net -CertificateThumbprint 8d8aa70358c538c7de50f5723571b9979696b5b2

Aqui declaramos a variável usada anteriormente para definição da conta de serviço (domain user) e o nome do servidor que foi instalado como primário, além do ThumbPrint do certificado.

Para quem usa o SQL Server como base para a farm AD FS, veja abaixo o comando para inserir nodes:

$fscredential = Get-Credential
Add-AdfsFarmNode -ServiceAccountCredential $fscredential -PrimaryComputerName adfs_primary.uilson.net -CertificateThumbprint 8d8aa70358c538c7de50f5723571b9979696b5b2 -SQLConnectionString "Data Source=SQLServerName\Instancia01;Integrated Security=True"

Abaixo o comando para inserir um servidor em uma farm AD FS existente usando uma conta GMSA em base WID:

Add-AdfsFarmNode -GroupServiceAccountIdentifier uilson\adfs_farm_user$ -PrimaryComputerName adfs_primary.uilson.net -CertificateThumbprint 8d8aa70358c538c7de50f5723571b9979696b5b2

E para finalizar a lista de scripts de configuração do AD FS, mostro abaixo o comando para inserir um novo servidor a uma farm existente com uma conta de serviço GMSA em base SQL Server:

Add-AdfsFarmNode -GroupServiceAccountIdentifier uilson\adfs_farm_user$ -PrimaryComputerName adfs_primary.uilson.net -CertificateThumbprint 8d8aa70358c538c7de50f5723571b9979696b5b2 -SQLConnectionString "Data Source=SQLServerName\Instancia01;Integrated Security=True"

Com o seu ambiente do AD Federation Services instalado, basta você verificar se o portal inicial está acessível. Seguindo as configurações citadas ao longo deste post, não tem o que dar errado. Basta acessar o endereço criado (no nosso exemplo: https://adfs.uilson.net):

PortalADFS_Uilson

Após se autenticar, você irá visualizar os acessos as aplicações que estão sendo autenticadas pelo AD FS via Relying Part Trust.

3. Administrando o AD FS

Um exemplo básico no AD FS é a criação de Relying Part Trusts – onde você define o caminho das aplicações a serem federadas. Abaixo um comando para criação de um relying part trust com base no script mostrado no último artigo do Web Application Proxy:

Add-AdfsNonClaimsAwareRelyingPartyTrust -Name ‘My App Extranet Publishing’ -Identifier ‘https://appserver.uilson.net/’ -IssuanceAuthorizationRules ‘=>issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");’

Podemos usar uma série de comandos para configurar o AD FS. Existem uma quantidade enorme deles que podemos usar no PowerShell para criação e configuração de relying part trusts e demais regras de autenticação no AD Federation Services, além dos comandos para alteração do certificado. Falar de um ou outro ficaria pouco, entretanto, falar em todos, deixaria o post muito extenso.

Estou colocando abaixo um link com uma lista vasta de comandos powershell para AD Federation Services. Para todos os comandos há um link com exemplos. Além do que, você pode gerar uma lista de exemplos no seu próprio powershell usando o comando get-help, conforme exemplo abaixo:

Get-Help Add-AdfsNonClaimsAwareRelyingPartyTrust –Examples

O link para o artigo com os comandos – https://technet.microsoft.com/en-us/%5Clibrary/Dn479343(v=WPS.630).aspx

Espero que o conteúdo seja útil e lhe ajude no dia a dia.

Abraços

Uilson

%d blogueiros gostam disto: