Erro ao configurar o ADFS no Windows Server 2012 R2

Sintoma:

Depois de instalar a Role de Active Directory Feredation Services (ADFS) no Windows Server 2012 R2 é necessário executar as tarefas de configuração pós-deployment.

Durante a configuração é necessário especificar um usuário com membro do grupo “Domain Admins” para configurar o ADFS e outro usuário de serviço para iniciar o serviço do ADFS.

Depois de especificar as credencias corretamente o seguinte erro é apresentado:

“You do not have sufficient privileges to create another container in Active Directory at location CN=<cn-id-code>,CN=ADFS,Microsoft,CN=Program Data,DC=domain,DC=my for use with shared ceritifcates. Verify that you are logged on as a Domain Admin or have sufficient privileges to create this container, and try again.

 

Diagnóstico:

Conecte-se no Active Directory Users and Computers (ADUC) e certifique-se que a opção “Advanced Features” está habilitada no menu “View“.

Certifique-se que a pasta “Program Datanão está criada.

 

Resolução

Inicie o ADSIEdit e conecte-se no domínio no contexto de “Default Naming Context

Navegue em “Default Naming Context” > “DC=my,DC=domain

Clique com o botão direito sobre “DC=my,DC=domain“, aponte para “new” e selecione “Object

Selecione container, clique em Next e digite “Program Data” no campo value:

Finalize o wizard com o padrão.

Confirme que o grupo “Domain Admins” tem acesso Full Control neste container

Tente configurar o ADFS novamente.

 

Anúncios

Microsoft Certification Authority apresentando Erro “Win32: 13” ao iniciar o serviço

Após a renovação do certificado do Root CA o seguinte erro pode ocorrer ao iniciar o serviço do Microsoft AD CA:

No Event Viewer ocorrem os erros Application Event ID 100 e System Event ID 7023:


A Microsoft disponibiliza um artigo com a solução para esse tipo de problema: https://support.microsoft.com/en-us/help/969302/certificate-server-service-does-not-start-and-you-receive-the-error-th

Para corrigir esse problema abra o mmc.exe e adicione a console de certificados. Navegue no painel à esquerda em Certificates > Personal > Certificates. Localize os certificados que são referentes à root CA.

Dica: procure pelo certificado cujo o valor de “Intendend Purposes” é “All” ou verifique o Certificate Template:

Para cada um dos certificados relacionados, clique duplo sobre eles e anote dois valores: “Thumprint” e “Previous CA Certificate Hash“.


O “Previous Certificate Hash” é o “Thumbprint” do certificado anterior. Deste modo, se o certificado foi renovado 3 vezes, você terá uma cadeia de certificados similar ao exemplo abaixo:

Anote o thumbprint do certificado mais recente.

Inicie o regedit.exe e naveguem em: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\CertSvc\Configuration\<root-ca-name>\CACertHash

Faça um backup dessa chave, just in case, e edite a entrada CACertHash

Cada linha no valor equivale a 1 certificado e a última linha deve conter o thumbprint do certificado atual (o mais novo). Insira “-” para cada certificado anterior gerado.

Por exemplo, se houveram 3 renovações de certificado CA, o valor de CACertHash será:

2e db 30 24 cd 2b 50 55 b7 42 54 aa a8 e0 8b 30 3f 43 d4 db

 

Depois disso deve ser possível iniciar o serviço do Certification Authority

Tela azul no Windows 10 com Cisco AnyConnect

Problemas ocorrendo com o Windows 10 (build 1511) e o Cisco AnyConnect , que causam BSoD durante a reconexão com a VPN.

Segundo esse artigo da Microsoft  esse erro pode ocorrer devido a conflito entre o Cisco AnyConnect e o Credential Guard: https://docs.microsoft.com/pt-br/windows/access-protection/credential-guard/credential-guard-known-issues

Neste artigo a Cisco indica que o problema não ocorre com o Windows 10 em versões mais novas: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvc66692/?referring_site=bugquickviewclick

No meu caso atualizar a build do Windows 10 não era uma opção então contornei o problema desabitando o Credential Guard. Para isso executei o “Passo 1” desse procedimento da VMWare: https://kb.vmware.com/s/article/2146361.

Não cheguei a executar os demais passos do procedimento, mas avalie se isso é necessário em seu ambiente.

Reproduzo abaixo os passos descritos no procedimento da VMWare:

To disable Device Guard or Credential Guard:

1. Disable the group policy setting that was used to enable Credential Guard.

   a. On the host operating system, click Start > Run, type gpedit.msc, and click Ok. The Local group Policy Editor opens.
   b. Go to Local Computer Policy > Computer Configuration > Administrative Templates > System > Device Guard > Turn on Virtualization Based Security.
   c. Select Disabled.

2. Go to Control Panel > Uninstall a Program > Turn Windows features on or off to turn off Hyper-V.
3. Select Do not restart.
4. Delete the related EFI variables by launching a command prompt on the host machine using an Administrator account and run these commands:

  mountvol X: /s
  copy %WINDIR%\System32\SecConfig.efi X:\EFI\Microsoft\Boot\SecConfig.efi /Y
  bcdedit /create {0cb3b571-2f2e-4343-a879-d86a476d7215} /d "DebugTool" /application osloader
  bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} path "\EFI\Microsoft\Boot\SecConfig.efi"
  bcdedit /set {bootmgr} bootsequence {0cb3b571-2f2e-4343-a879-d86a476d7215}
  bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions DISABLE-LSA-ISO,DISABLE-VBS
  bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} device partition= mountvol X: /d

Note: Ensure X is an unused drive, else change to another drive.

5. Restart the host.
6. Accept the prompt on the boot screen to disable Device Guard or Credential Guard.

 

Ativando KMS Host Server

Instalar o Volume Licensing Activation Services
Ativar o chave de Host KMS
Aguardar a replicação do DNS

Para configurar novos clients Windows não é necessário fazer nada!

Para converter clients de MAK para KMS:

REM Este comando remove chaves instaladas. Com ele vamos remover a chave MAK
cscript slmgr.vbs /upk
REM Este comando instala uma nova chave. Utilize uma das GVLK disponibilizadas pela Microsoft no link abaixo.
cscript slmgr.vbs /ipk:XXXX-XXXX-XXXX-XXXX-XXXX

GVLK para Windows: https://technet.microsoft.com/en-us/library/jj612867(v=ws.11).aspx

Habilitar o KMS Host para ativar instalações de Microsoft Office 2016

Para habilitar o KMS Host para ativar instalações do Office 2016 é necessário rodar o script de configuração do KMS Host para Office.

Para isso, acesse o Microsoft Volume Licensing Service Center (VLSC), em “Downloads e Chaves” localize e faça download do aplicativo “Office Professional Plus 2016 Key Management Service Host”.

KMS_IMG_1.PNG

Ele é uma ISO com pouco mais de 1MB que você deve copiar e montar no seu KMS Server. Ao fazer isso, você deve enxergar os seguintes arquivos:

KMS_IMG_2.PNG

Depois abra um prompt de comando com permissões elevadas e execute o seguinte comando:

wscript.exe kms_host.vbs

O script irá configurar o Volume Activation Services instalado no servidor e abrirá a janela de administração.  Insira a chave de KMS Host para Office Professional Plus 2016 nesse servidor e finalize o Wizard.

KMS_IMG_3.PNG

Nota: se você precisar habilitar o KMS Host para ativar instalações de Project ou Visio, basta repetir este processo, inserindo as chaves KMS correspondentes.

Configurando os Clients para utilizar o novo KMS Host

Assim como para ativações do Windows, no caso de novas instalações do Office 2016 o computador buscará por padrão um servidor KMS na rede e o ativará.

No entanto, caso precise converter uma instalação existente que ja esteja ativada com chave MAK utilize o seguinte procedimento:

No computador cliente abra um prompt de comando com permissões elevadas.

Execute o seguintes comandos:

cd "C:\Program Files\Microsoft Office\Office16"
REM Este comando instala uma nova chave. Utilize uma das GVLK disponibilizadas pela Microsoft no link abaixo.
cscript ospp.vbs /inpkey:xxxxx-xxxxx-xxxxx-xxxxx-xxxxx

GVLK para Office: https://technet.microsoft.com/en-us/library/dn385360(v=office.16).aspx

Validando a configuração

Para validar que tudo funcionou execute no prompt de comando com permissões elevadas os seguintes comandos:

cscript OSPP.VBS /dcmid

O resultado desse comando deve indicar que o Office foi ativado utilizando  o KMS Host

DON’T REJOIN TO FIX: The trust relationship between this workstation and the primary domain failed

If you Google “the trust relationship between this workstation and the primary domain failed”, you get plenty of information from support blogs and Microsoft articles; however, most of them ask you to rejoin your machine to the domain. That’s not always possible.

##TL;DR You got this error and you can’t simply unjoin and rejoin because the machine is a Certificate Authority. Run this command from PowerShell:

Reset-ComputerMachinePassword [-Credential ] [-Server ]

##What’s the problem and how did I get here?

The underlying problem when you see this error is that the machine you are trying to access can no longer communicate securely with the Active Directory domain to which it is joined. The machine’s private secret is not set to the same value store in the domain controller. You can think of this secret as a password but really it’s some bits of cryptographic data called a Kerberos keytab stored in the local security authority. When you try to access this machine using a domain account, it fails to verify the Kerberos ticket you receive from Active Directory against the private secret that it stores locally. I think you can also come across this error if for some reason the system time on the machine is out of sync with the system time on the domain controller. This solution also fixes that problem.

##The standard fix This problem can be caused by various circumstances, but I most commonly run into it when I reset a virtual machine to a system snapshot that I made months or even years before. When the machine is reset, it is missing all of the automatic password changes that it executed against the domain controller during the intervening months. The password changes are required to maintain the security integrity of the domain.

 

Fonte: DON’T REJOIN TO FIX: The trust relationship between this workstation and the primary domain failed

Como publicar uma aplicação Web no Citrix XenApp

Existem algumas formas de publicar uma aplicação Web no Citrix XenApp.

A mais simples, talvez, é utilizar o modo “Kyosk” do Internet Explorer. Para isso basta utiilizar o parâmetro “-k” ao chamar o aplicativo. A configuração da aplicação no Citrix Studio deveria ficar mais ou menos assim:

Internet Explorer modo Kyosk
Internet Explorer modo Kyosk

O problema do modo Kyosk é que o IE é iniciado em tela cheia e sem o botão “Fechar”. Isso pode confundir o usuário e prejudicar a sua experiência de uso.

Outra forma de fazer isso é utilizar um script que instancia o Internet Explorer desabilitando alguns componentes (tais como a barra de endereços, botões de navegação, complementos e etc). Aqui nesse post, há um exemplo de um VB Script bem simples que dá conta do recado, e que reproduzo abaixo:

Set oIE1 = WScript.CreateObject ("InternetExplorer.Application")

oIE1.Navigate "http://www.yahoo.com"
oIE1.Visible = 1
oIE1.AddressBar = 0
oIE1.StatusBar = 0
oIE1.ToolBar = 0
oIE1.MenuBar = 0

No entanto, a minha solução preferida foi a desse outro Blog. O VB Script publicado aqui é bem mais robusto e reutilizável. Nesse caso, basta chamar o script e passar como parâmetro a URL da aplicação Web.

Set objArgs = WScript.Arguments 
If objArgs.Count = 0 Then 
 WScript.Echo "No URL provided, please supply a URL to open" & VbCrLf & VbCrLf & "e.g. CScript OpenURL.vbs http://www.google.com" 
 wscript.quit
End If

Set objIE = CreateObject("InternetExplorer.Application")

With CreateObject("internetexplorer.application") 
 .navigate "about:blank" 
 With .document.parentWindow.screen 
 iHeight = .height 
 iWidth = .width 
 End With 
End With

objIE.StatusBar = False 
objIE.Visible = True 
objIE.AddressBar = False 
objIE.MenuBar = False 
objIE.ToolBar = False 
objIE.Top = 0 
objIE.Left = 0 + 8 'Move to the side just a bit to show the desktop
objIE.Width = iWidth - 16 'Shrink to let a bit of the desktop show on the sides
objIE.Height = iHeight - 28 'Shrink a bit to see the taskbar
objIE.Navigate (objArgs(0))

A publicação de uma aplicação Web no XenDesktop utilizando essa ferramenta ficaria mais ou menos assim:

Internet Explorer chamado através do VBScrit
Internet Explorer chamado através do VBScript

Fontes: JasonSamuel.com, Citrix Discussions

 

Microsoft encerra suporte ao Windows 8 nesta terça-feira

Utilizado por menos de 3% dos computadores, sistema não vai mais receber atualizações de segurança a partir desta terça

A partir desta terça-feira, 12/01, a Microsoft vai encerrar o suporte ao sistema operacional Windows 8. Deste modo, ele deixará de receber atualizações de segurança, de desempenho e de suporte para novos dispositivos.

A maioria dos sistemas operacionais da Microsoft tem um ciclo de vida de dez anos. Contudo, o Windows 8, lançado em 2012, foge a essa regra: segundo a própria Microsoft, o Windows 8.1, que continua a receber atualizações, substituiu a versão 8 em 2013. A empresa garante que a versão 8.1 terá suporte até 2023.

Por essa razão a empresa recomenda que os usuários atualizem o sistema para a versão 8.1 ou mais recente, o que pode ser feito gratuitamente, para não deixar o computador vulnerável a ataques cibernéticos.

Conforme foi divulgado no blog Link do Estadão, uma pesquisa realizada pela Statista constatou que menos de 3% dos computadores no mundo ainda utilizam o Windows 8. Segundo a mesma pesquisa, o Windows 7 ainda é o sistema operacional mais popular da Microsoft, presente mais de 43% de PCs e notebooks.

Fonte: Microsoft encerra suporte ao Windows 8 nesta terça-feira – Link Estadão – Notícias de Tecnologia – Estadao.com.br

Alterar Windows Server 2012 R2 de Core para interface gráfica de usuário (GUI)

Desde a versão Windows Server 2008 R2 é possível optar pela instalação do Sistema Operacional com a interface gráfica (with GUI) ou sem ela (server core installation).

No entanto, no Windows Server 2012 e 2012 R2 a instalação da interface gráfica é um componente que pode ser instalado ou removido a qualquer momento.

Se você instalou o Windows Server 2012 R2 sem a interface gráfica (Server Core) e precisa – ou deseja – alterar essa característica, será necessário um repositório que contenha todos os arquivos de instalação. Normalmente esses arquivos estão armazenados em <%WINDIR%>\WinSxS\. Caso eles não estejam mais disponíveis é possível utilizar também a imagem padrão disponível no DVD de instalação do Sistema Operacional. Para isso, localize na mídia o arquivo “Install.wim” dentro do diretório D:\sources\ (supondo que “D:\” seja o seu drive de CD).

No prompt de comando execute o PowerShell para identificar as imagens do Windows disponíveis no arquivo. Verifique o Index das imagens que não se referem a Server Core e que correspondam ao seu tipo de licença (Standard ou Datacenter).

Get-WindowsImage -ImagePath:D:\Sources\Install.Wim

Get-WindowsImage
Index das Imagens disponíveis na mídia

Para identificar as funcionalidades que precisam ser habilitadas execute no PowerShell o seguinte cmdlet:

Get-WindowsFeature

Como resultado, esse cmdlet listará todas as features disponíveis para o Sistema Operacional e identificará as instaladas com o [X]. Os componentes de Interface Gráfica estão aninhados em “User Interfaces and Infrastructure“:

Get-WindowsFeature
Resultados do cmdlet Get-WindowsFeature

Portanto, para instalar a interface gráfica do Windows Server execute o cmdlet Install-WindowsFeature no PowerShell conforme abaixo:

Install-WindowsFeature -Name server-gui-shell,server-gui-mgmt-infra -source: D:\sources\install.wim:2 -restart

O parâmetro “:2” refere-se ao número do Index da imagem. Neste caso, indica que a imagem utilizada é a “Windows Server 2012 R2 SERVERSTANDARD”.

Após o término da execução será necessário reiniciar o servidor.

Habilitar o Gerenciamento Remoto do Windows Server 2012 R2 em servidores com Windows Server 2008 R2

As ferramentas de gerenciamento remoto do Windows Server 2012 R2 são uma mão na roda para administrar servidores no ambiente.

Elas proporcionam fácil acesso a uma série de recursos administrativos e possibilitam criar um ponto único de contato, tornando rápido identificar e solucionar problemas em servidores.

Entretanto, essas ferramentas só estão disponíveis de forma nativa no Windows Server 2012 em diante.

Embora seja possível adicionar um servidor com Windows Server 2008 R2 ao grupo de gerenciamento, o painel exibirá um erro e, ao tentar gerencia-lo, recebemos a mensagem:

Online - Verify WinRM 3.0 service is installed, running and required firewall ports are open
Console de gerenciamento remoto do Windows Server 2012 R2
Console de gerenciamento remoto do Windows Server 2012 R2

Para habilitar o gerenciamento remoto em servidores Windows Server 2008 R2 é necessário instalar:

Depois de instalado os dois pacotes, será necessário configurar o WinRM para “escutar” solicitações de gerenciamento remoto. A forma mais rápida de se fazer isso é executar o comando a seguir com permissões elevadas:

winrm quickconfig

Aceite a criação do listener sugerido e verifique que a configuração ocorreu sem erros.

Configuração do WinRM 3.0
Configuração do WinRM 3.0

Depois disso, atualize a console de gerenciamento remoto no servidor e verifique que o gerenciamento está ocorrendo.

Windows Server 2012 – ADFS 2.1 – Erro MSIS7613:The signing certificate of the relying party trust is not unique across all relying party trusts in AD FS 2.0 configuration

Ao tentar utilizar um mesmo certifcado para entradas diferentes utilizando o ADFS 2.0, aparece a mensagem:

MSIS7613: The signing certificate of the relying party trust is not unique across all relying party trusts in AD FS 2.0 configuration”

O Rollup 3 disponibilizado pela Microsoft permite corrigir este erro facilmente, conforme pode ser visto neste excelente post do Paul Williams, ou em outros tantos pela internet. Entretanto, este Rollup só pode ser aplicado no Windows Server 2008 r2.

No Windows Server 2012, o ADFS 2.1 é instalado como uma Role, e esperava-se que este problema não ocorresse mais, porém não foi o que observei. Ao tentar encontrar a solução para este problema,  deparei-me com a inexistência (até o momento) de atualizações para o ADFS 2.1.

Deste modo, encontrei uma alternativa para solucionar isso:

  • Separe uma maquina de testes com Windows Windows Server 2008 R2 e instale o ADFS 2.0 e o Rollup 3.
  • Após a instalação abra a pasta “C:\Program Files\Active Directory Federation Services 2.0\SQL” e copie os seguintes arquivos:
    • IdentityServerAttestation.cer
    • IdentityServerAttestation.dll
    • IdentityServerAttestation.sql
    • PostReleaseSchemaChanges.ps1
Copiar os arquivos do ADFS 2.0
Copiar os arquivos do ADFS 2.0
  • Cole os arquivos no seu servidor Windows Server 2012, em “C:\Windows\Adfs\SQL\”;
  • No servidor Windows Server 2012, clique com o botão direito sobre PostReleaseSchemaChanges.ps1 e selecione editar;
  • Altere a linha 6, 8 e 9 do script, substituindo a variável “$env:ProgramFiles\Active Directory Federation Services 2.0\” por “$env:windir\ADFS\“:
Alterando o Script
Alterando o Script
Script Alterado
Script Alterado
  • Salve as alterações e feche o arquivo;
  • Execute o PowerShell como Administrador e execute o script;