Arquivo

Archive for the ‘Scripts’ Category

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

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

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

Tips and Tricks–certificados digitais wildcard ou SAN no IIS Windows Server 2003, Windows Server 2008 e Windows Server 2012 R2

24 de novembro de 2015 Deixe um comentário

Saudações,

Depois de alguns meses carregados de palestras que entreguei e a série de posts sobre migração do TMG para plataformas distintas, comecei um trabalho de migração de aplicações WEB. A principio o processo pedia somente migração do IIS 6.0 para IIS 7.5 e 8.5.

Em alguns casos foi preciso manter a aplicação em ambiente legado (2003) por questões de compatibilidade e falta de tempo da equipe de DEV para migração.

Além disso, para as aplicações em ambiente legado e também as que foram migradas, era necessário uso de certificado digital wildcard. Como eram aplicações que não seriam acessadas externamente, pudemos usar o template Web Server da própria entidade certificadora interna (AD CS).

Nesse ponto encontramos alguns pontos que devem ser observados em aplicações WEB legadas em IIS 6.0. O padrão da empresa era manter diversos sites no IIS, cada um com sua aplicação e para cada uma delas seria necessário certificado. Pensei em gerar um wildcard mas, um certificado SAN contendo todos os comon names dos hosts já havia sido criado.

Em tese no IIS 6.0, você não pode ter diversos sites apontando para um único certicado, nem tampouco usar a porta 443 para mais de um certificado no mesmo IP. Tinha dua opções:

A) Adiconar IP´s associando a cada uma das aplicações

B) Usar uma linha de comando do ADSUTIL para fazer a criação de secure binds que possibilitarão o uso do mesmo certificado para as diversas aplicações associadas a um único IP

Bom, devido as condições e a urgência, optamos pela opção B. Para tal, você precisa executar o seguinte comando do ADSUTIL (lembrando que o ADSUTIL fica na pasta inetpub\adminscripts):

cscript.exe adsutil.vbs set /w3svc/<site identifier> /SecureBindings “:443<host header>”

No comando acima:

<site identifier> – identificação do site no IIS

<host header> – endereço ao qual o site irá responder – ex: app.uilson.net ou www.uilson.net

Antes de colocar o exemplo prático do comando para IIS 6.0, veja como verificar o ID do site nos IIS´s 6.0 e também no 8.5 do 2012 R2:

IIS 6.0 – Windows Server 2003

image

IIS 7.5 e 8.5 – Windows Server 2008 R2 e Windows Server 2012 R2:

image

Agora que você já sabe, ou se lembrou como identificar o ID# do site, vamos ao comando de forma prática. Apenas relembrando que o procedimento abaixo se aplica ao IIS 6.0:

cscript.exe adsutil.vbs set /w3svc/856101042/SecureBindings ":443:www.uilson.net"
cscript.exe adsutil.vbs set /w3svc/620385459/SecureBindings ":443:aplication.uilson.net"
cscript.exe adsutil.vbs set /w3svc/1953820003/SecureBindings ":443:webapp.uilson.net"

Importante frisar que:

. Os sites devem estar parados para que os comandos sejam executados

. Se houver qualquer alteração nas configurações de SSL do site, o comando acima deverá ser aplicado novamente

Dessa forma o problema foi resolvido e temos mais um tempo até a equipe de dev migrar a aplicação.

Para quem usa IIS no Windows Server 2008 e 2012, as coisas são um pouco menos trabalhosas. Uma vez que um site usa o certificado SAN (com mais deu common name criado ou wildcard), assim que vc assinala o certificado em um site, você receberá uma mensagem ao assinalar o mesmo certificado para o próximo, dizendo que o certicado já está sendo usado e que, todos os demais sites, se forem habilitados a porta 443, irão usar o mesmo que foi assinalado para os anteriores. Dessa forma ficou mais rápido e simples de resolver.

O redirect para https poderá ser feito por sua infra de proxy reverso, entretanto você também poderá faze-lo pelo próprio IIS de forma simples:

IIS 6.0 – Windows Server 2003 – Propriedades do site / custom errors / edit no erro 403.1 e inserir a URL https conforme abaixo:

image

IIS 7.5 e 8.5 – Windows Server 2008 e Windows Server 2012 R2 –

image

Estas foram alguns tips and tricks que estou compartilhando com vcs acerca de configuração de certificados digitais no IIS. Recomendo que, por questões de segurança, procure migrar suas aplicações legadas para o IIS 8.5, pois além de toda uma linha de features que você tem a disposição na versão atual, você ainda pode trabalhar com certificados de encriptação maior SHA2 em 256 bits.

Além disso, o IIS 8.5 tem suporte a SNI (Server Name indication), uma extensão TLS a qual possibilita saber o host e o domínio da página onde a requisição está sendo feita. Está disponível a partir do IIS 8.0 do Windows Server 2012 e é suportado em browser a partir do IE 7. Para saber mais detalhes, clique no link abaixo:

https://www.networking4all.com/en/ssl+certificates/faq/server+name+indication/

Outro benefício é o CCS (Centralized Certificate Store), onde você pode armazenar seu certificado em um arquivo PFX dentro de um file server ou onde você quiser, para que seja compartilhado por 1 ou mais web servers com IIS 8.5 do Windows Server 2012 R2.

Para saber detalhes e como implementar, leia o artigo que escrevi sobre esta funcionalidade no link abaixo:

https://uilson76.wordpress.com/2014/03/24/configurando-o-centralized-certificate-store-no-iis-8-5-do-windows-server-2012-r2/

Espero que as dicas e os links possam ajudar. Qualquer outra dúvida sobre certificados digitais no IIS que não foram cobertas neste post, podem deixar seus coments ou me contatar pela minha página no facebook.

Abraços

Uilson

Habilitando a execução de scripts no Power Shell

14 de outubro de 2013 4 comentários

Saudações,

A dica de hoje é simples, mas, válida para pessoas que, como eu, não têm muito expertise no Power Shell.

Nos últimos dias atuei na implementação de servidores TMG como proxy reverso e implementei a feature do Account Lockout.

Quando tive outra demanda para implementar essa feature, tentei pesquisar um script que pudesse executar sem ficar digitando várias linhas de comando.

Como não sou expert no Power Shell tive dificuldades logo de cara, pois, não sabia que a execução de script’s vem desabilitada:

image

É necessário alterar o default policy no método “ExecutionPolicy”.

Para verificar o status da execução de script’s usar a sintaxe abaixo:

image

Repare na figura acima que o comando “get-ExecutionPolicy” mostra que o status da execução de script’s é “Restricted”

Para habilitar a execução de script’s, use a sintaxe abaixo:

image

Após executar o comando exibido na tela acima, apenas digite S (Sim) ou Y (Yes) para confirmar.

Repare que utilizei o parâmetro “Unrestricted” para liberar  a execução de script’s no Power Shell, desabilitando a policy por completo. Entretanto, você poderá fazê-lo de uma forma mais segura no seu ambiente corporativo ou em seu cliente usando os parâmetros abaixo:

AllSigned: Requer que todos os scripts e inclusive arquivos de configuração sejam assinados por um autor de confiança

RemoteSigned: Requer que todos os scripts baixados da internet sejam assinados por um autor de confiança.

Mesmo habilitando a execução com o parâmetro “Unrestricted”, se você rodar um script baixado da internet não assinado, será questionado a respeito de querer ou não rodar o mesmo.

A base de pesquisa para executar o script no meu cliente e montar este post foi pesquisada no blog Rolf’s Zone que tem um excelente conteudo de infra estrutura:

http://rolfboard.wordpress.com/2009/02/04/como-habilitar-powershell-scripts/

Pra finalizar, desde a chegada do Windows Server 2008, o power shell tem tomado grande iimportância no dia a dia no ITPRO. Do Windows Server 2012 pra frente, se torna indispensável o conhecimento nesta ferramenta.

Você que quer aprender mais sobre Power Shell (assim como eu) pode baixar o ebook do amigo Daniel Donda em:

http://www.mcsesolution.com/Livros/e-book-powershell-para-it-pro.html

Espero que o post possa ajudar.

Abraços

Uilson

%d blogueiros gostam disto: