Technical Focus Group

Active Directory Domain Services and Identity
About

About




Blogue desenvolvido e disponibilizado por um grupo de trabalho com foco específico em serviços de diretoria e identidade. O grupo de trabalho é constituído por elementos da área de serviços e suporte da Microsoft.

Para além do blogue, os conteúdos podem também ser consultados, de um modo mais prático e direto, através de uma aplicação disponibilizada na Windows Store. A aplicação tem o nome de "TechNet RSS Reader" e pode ser encontrada diretamente a partir do seguinte localização http://apps.microsoft.com/webpdp/app/technet-rss-reader/dc85c3ba-2e0d-4641-abea-b443281ae832.

  • [English] ADFS Token-Signing and Token-Decrypt Certificates Expiration Process and Dates

    [English] - Content Developed by the Shared Services Support Team.



    By default, Token-Signing and Token-Decrypting Certificates will expire one year after your ADFS was setup. Near to the expiration period you will get the following notification on your Portal Admin Page.
    This notification do not apply to SSL Certificate, also known as Service Communications Certificate.


    W14



     W15


     



    The number of days represents the day where the service will stop. Due to certificate change.


    How to calculate the effective day:


    The new Certificate will be generated 20 days before the certificate expirations date:
    1) Go to Powershell
    2) Connect-MsolService
    3) Get-MsolFederationProperty
    4) Check [CertificateGenerationThreshold: 20]


    The new certificate will be promoted to Primary after 5 days:
    1) Go to Powershell
    2) Connect-MsolService
    3) Get-MsolFederationProperty
    4) Check [CertificatePromotionThreshold: 5]


    Knowing that AD FS Service only uses the primary certificate, as we will switch the certificates 15 days before the current primary certificates expires the service will stop 15 days before the current certificate expiration.


    This is not true if the Relying party has been updated on the 5 days that exist between the new certificate creation and the promotion.


    Example:
    Certificate expires on 30-01-2014.
    New certificate will be created on 10-01-1014 and will be marked as Secondary [20 days before expiration].
    On the 15-01-2014 the Secondary Certificate is promoted to Primary [5 days after new certificate generation].
    If we see the message on the portal on the day 05-01-2014 this should be informing that the service will stop in 10 days, if federation metadata information is not updated.



    ADFS default configuration:

    Default configuration on AD FS regarding Token Signing and Token Decrypting certificates includes an auto-renewal process, [AutoCertificateRollover].

    If you did not change this value from “True” to “False”, no renewal operation regarding token certificates is needed, this will happen automatically based on triggers explained below.



    Default values of ADFS - [see details below for default values]:

    The Rollover interval is checked by the AD FS service every 720 minutes (12 hours).
    If the existing primary certificate (Token Signing or Token Decryption) expiration time is within the window of the CertificateGenerationThreshold value (20 days), then a new certificate is generated and configured as the secondary certificate.
    Noted by event ID 385 in the event logs: It will remain as the secondary certificate until the CertificatePromotionThreshold value is observed (5 days). So, 5 days after creation of the certificate, it will be promoted and the existing primary will be configured as the secondary until the next CertificateGenerationThreshold window is observed.

    Once the Promotion event has occurred, the Token Service will sign/encrypt all issued tokens with the new primary certificate.

    This does not cause a service outage of AD FS 2.0, but an application issue when the token is received and signed with something other than the expected certificate. This is true for O365 or any other application.

    With AutoCertificateRollover enabled, AD FS 2.0 will continue to function as expected.



    Validate your ADFS configuration:

    To validate your configuration, connect to your primary ADFS Server and follow these PowerShell instructions:

    Open the Windows PowerShell
    Add-PSSnapin Microsoft.ADFS.PowerShell
    Get-ADFSProperties

    CertificateCriticalThreshold: 2 - Days prior to expiry of the certificate before a new certificate is generated and promoted if AutoCertificateRollover has not performed naturally.

    CertificateDuration: 365 - Validity period of the auto-generated Certificate.

    CertificateGenerationThreshold: 20 - Days before expiration of current primary a new certificate will be generated.

    CertficatePromotionThreshold: 5 - Days the newly generated certificate will exist before being promoted from secondary to primary.

    CertificateRolloverInterval: 720 - Interval in minutes at which we check to see if a new certificate needs to be generated.

    CertificateThresholdMulitplier: 1440 - Number of minutes used in calculation of other threshold counters (default value is 1440 minutes or 24 hrs. X 60 minutes, which makes threshold values equal to full days).



    To have single sign on with ADFS the federation certificates need to be updated with the online platform. O365 is now automatically pulling the certificates from the AD FS server via the public metadata endpoint on a regular basis.


    You may need to manually update the federation metadata using the PowerShell in complement to the Microsoft pull mechanism, as this will not pull the certificates on all scenarios.


    To setup this to run automatically on your infrastructure implement the following script:
    http://gallery.technet.microsoft.com/scriptcenter/Office-365-Federation-27410bdc.

  • [English] What do I have to do if I received the alert on the Office 365 portal or an E-mail informing that one of the federation services certificates is expiring

    [English] - Content Developed by the Shared Services Support Team.





    This information is normally related to the Token-Signing and Token-Decrypting Certificates.


    To overcome the current situation, most of the times you do not need to do anything. By default, your ADFS server is configured for “AutoCertificateRollover”. This means that the new certificates will be automatically generated and promoted to primary. You simply need to confirm that your on-premises AD FS infrastructure is configured as displayed:

    1) Go to Powershell
    2) Get-ADFSProperties |fl AutoCertificateRollover




    If the output is “AutoCertificateRollover: True”, you do not need to do anything, your Token-Signing and Token-Decrypting Certificates will update automatically. You can also check that "NextTokenSigningCertificate" contains the information of the next certificate to be used:

    1) Go to Powershell
    2) Connect-MsolService
    3) Get-MsolFederationProperty
    4) Check "NextTokenSigningCertificate" information for both "ADFS Server" and "Microsoft Office 365".


    On rare occasions, after the automatic switch to the new Certificates, you might need to update the O365 federation information:

    Option a)
    Check if you previously have installed the automatic update federation tool:




    If not, install it using the following script - Microsoft Office 365 Federation Metadata Update Automation Installation Tool - http://gallery.technet.microsoft.com/scriptcenter/Office-365-Federation-27410bdc.


    Option b)
    Manually update federation information (only needed once after the Certificates renewal)
    1) Connect-MsolService
    2) Insert O365 Admin Credentials
    3) Update-MsolFederatedDomain -DomainName yourdomain.name -SupportMultipleDomain


    And that’s it.


    If for some reason the “AutoCertificateRollover: false”, please find guidance on the following article http://social.technet.microsoft.com/wiki/contents/articles/2554.ad-fs-2-0-how-to-replace-the-ssl-service-communications-token-signing-and-token-decrypting-certificates.aspx.


    Additional Notes:
    To now more about Certificates on ADFS, please go to the following article http://social.technet.microsoft.com/wiki/contents/articles/2554.ad-fs-2-0-how-to-replace-the-ssl-service-communications-token-signing-and-token-decrypting-certificates.aspx

    To understand the difference in the date displayed on the alert message, and the date of expire of the certificate on the ADFS, a new article is available on this blog http://blogs.technet.com/b/tfg/archive/2014/04/21/token-signing-and-token-decrypt-certificates-expiration-process-and-dates.aspx.

  • [Português] Associar Subscrição do Azure ao Directório do Office 365 / [English] Link Azure Subscription with Office 365 Directory

    [Português]
    > Aceder a https://manage.windowsazure.com/.

    > Efetuar o login com a Microsoft account (live.com, hotmail.com, outlook.com, etc.).
    > Ir para Active Directory > Directory > ADD.
    > Selecionar "Use existing directory".
    > Selecionar a opção "I am ready to be signed out now" e Continuar (redireccionamento para o login do Office 365).
    > Login com a conta de global admin do Office 365 e Continuar.
    > [Atualização - Não é necessário introduzir manualmente o URL] Depois do redireccionamento para o login do Azure novamente, não continue, em vez disso deve inserir manualmente o URL https://manage.windowsazure.com/.
    > Efectue o login novamente no Azure with com a Microsoft Account e verifique a existência de dois diretórios na opção de Active Directory, uma correspondente ao Azure default, e a outra referente ao Office 365.
    > Para permitir que os users do diretório do Office 365 possam ser adicionados como Co-Administrators da subscrição do Azure > Selecione Settings (Azure) > Subscriptions.
    > Selecione a Azure Subscription > Edit Directory > Escolha o Diretório do Office 365 e termine o processo.
    > A partir deste momento os users da default Azure Directory não poderão ser adicionados como Co-Administrators do Azure, apenas os users do Diretório do Office 365.


    [English]
    > Go to https://manage.windowsazure.com/.
    > Login with the Microsoft account (live.com, hotmail.com, outlook.com, etc.).
    > Go to Active directory > Directory > ADD.
    > Select "Use existing directory".
    > Select the box "I am ready to be signed out now" and Continue (redirection to Office 365 Login).
    > Login with Office 365 Global Admin account and Continue with the Wizard.
    > [Update - No longer needed to insert the URL manually] After redirection to the Azure login page, do not continue, instead, manually insert the URL on the address bar https://manage.windowsazure.com/.
    > Login again into Azure with the Microsoft Account and Check Active Directory for the two Directories, one, the Azure default, and the other, with the Office 365 users.
    > To enable the users from the Office 365 directory to be added as co-administrators for the Azure subscription, go to Settings (on Azure) > Subscriptions.
    > Select the Azure Subscription > Edit Directory > Choose Office 365 Directory and Finish.
    > From this time on, users from the default Azure Directory, cannot be used as Co-Administrators, only users from Office 365 Organizational Directory.

  • DFS Replication – Introdução e criação de Replication Group.

    DFS Replication – Introdução e criação de Replication Group.

    Distributed File System é o sistema de replicação de files que substitui o FRS a partir de 2003. Um sistema de replicação de ficheiros permite manter duas ou mais pastas sincronizadas com o mesmo conteúdo entre servidores diferentes. Este tipo de tecnologia é utilizada para os propósitos mais diversos, desde a sincronização de conteúdo entre “branch offices” para minimizar a carga de comunicação em links mais lentos, ou mesmo como sistema de Disaster Recovery ou Backup de recuperação rápida, já que os dados entre os servidores são replicados de forma muito veloz. Outra das utilizações, mas mais intrínseca ao sistema, é a replicação da pasta Sysvol e Netlogon (que contem as politicas e scripts de logon), entre Domain Controllers. Na maioria dos sistemas esta ainda é feita utilizando FRS (default quando promovemos Domain Controllers), mas pode ser migrada para DFSR. Por agora, poucos sistemas optaram por esta migração, dado que uma das principais diferenças entre o FRS e DFSR é o volume de dados que suportam em termos de replicação. A replicação de Sysvol ou Netlogon, em geral, não contem dados suficientes para justificar uma migração para DFSR e dado que FRS pode coexistir numa infraestrutura de domínio com DFSR, normalmente não se procede á migração para DFSR. (http://technet.microsoft.com/en-us/library/dd640019(v=ws.10).aspx), porém, por uma questão de melhoria de performance bem como de suporte futuro, aconselhamos os nossos clientes a considerar a migração

    Neste primeiro artigo da minha série de DFS Replication vamos focar-nos na utilização do DFSR para a replicação de files disponibilizados ao utilizador.

    Um sistema DFSR é composto por:

    - Replication Group: o objeto que descreve e mantem os elementos participantes na replicação. É o que devemos criar para começar.

    - Replication Partner: os servers que estão incluídos num determinado Replication Group.

    - Replicated folders: as pastas de um Replication Partner, que estão a ser replicadas.

    No vídeo vamos ver como criar um Replication Group. No próximo post vamos entrar mais em detalhe sobre como gerir a replicação e que parâmetros teremos de configurar para que a replicação corra sem problemas.

    Preview - http://blogs.technet.com/cfs-filesystemfile.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-94-04/4760.DFSR1.png

     

  • Monitorização de objetos Lost&Found

    Objetos Lost&Found são objetos que aquando a replicação entre controladores de domínio, a Active Directory não entende qual o destino do objeto pelo simples fato deste já não existir. Assim coloca-os dentro de um container Lost&Found.

    Exemplo: 

    Quando um utilizador é criado na Organization Unit Utilizadores no Controlador de Domínio A e antes da replicação deste a Organization Unit é apagada no Controlador de Domínio B, quando se dá inicio à replicação o Controlador de Domínio B não sabe onde colocar o utilizador, visto que a Organization Unit onde ele pertence originalmente já não existe. Nestas condições os objetos são colocados num Container chamado Lost&Found.

    Comando:

    dsquery * cn=LostAndFound,<DOMAIN-DN> -scope onelevel - attr cn

    dsquery * cn=LostAndFound,DC=contoso,DC=com -scope onelevel - attr cn

  • Software de Virtualização que suporta VM-GenerationID

    Recentemente, a Microsoft introduziu o atributo VM-GenerationID no Windows Server 2012, desta forma permitirá que a máquinas virtuais estejam cientes de quando são alvo de "snapshot", recuperação e até de clonagem.

    Este método previne situações de USN Rollback quando executadas qualquer uma das alternativas mencionadas.

    VM-GenerationID é suportado por:

    • Windows Server 2012 Standard Edition (Hyper-V)
    • Windows Server 2012 Enterprise Edition (Hyper-V)
    • Hyper-V Server 2012  (Hyper-V)
    • Windows 8 Professional (Hyper-V)
    • Windows 8 Enterprise (Hyper-V)
    • VMware Workstation 9.0
    • VMware vSphere 5.0 with Update 4 (Build 821926, 9/27/2012)
    • VMware vSphere 5.1 (Build 799733, 9/10/2012)

     

  • Despromoção de um controlador de domínio com o Windows Server 2012, usando o PowerShell

    Procedimentos a executar com o objectivo de despromover um controlador de domínio com o Windows Server 2012, usando o PowerShell:

    > Abrir PowerShell
    > Uninstall-ADDSDomainController –Credential (Get-Credential) –RemoveApplicationPartitions –Confirm

    Preview - http://blogs.technet.com/cfs-filesystemfile.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-95-87/7288.Demote_5F00_DC_5F00_WS2012_5F00_PowerShell.png

    > Informação Adicional > http://technet.microsoft.com/en-us/library/hh974714.aspx

  • Configurar o cliente Windows 8 para utilizar queries DnsSec

    Para configurar o cliente Windows 8 para utilizar queries DnsSec podemos utilizar Group Policies onde configuramos a tabela NRPT (Name Resolution Policy Table) ou então localmente com o seguinte comando Powershell:

    PS C:\> Add-DnsClientNrptRule -Namespace corp.contoso.com -DnsSecEnable -NameServers 10.0.0.1

     

    De seguida podemos validar essa mesma configuração com:

    PS C:\> Get-DnsClientNrptPolicy

     

    Ao obter a listagem da policy table podemos então usar um dos servidores DNS com zonas protegidas por DnsSec e fazer um query para validar a resolução de nomes:

    PS C:\> Resolve-DnsName dc1.corp.contoso.com -Server 10.0.0.1 -DnssecOk

    Preview - http://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-94-04/7610.dnsssecpreview.png

     

  • Configurar o serviço de sincronização do tempo no PDCE do domínio raiz da floresta

    Os seguintes procedimentos mostram um dos métodos possíveis para configurar adequadamente e de acordo com as melhores práticas, o serviço de sincronização do tempo, do controlador de domínio que é simultaneamente o proprietário do FSMO role PDCE do domínio de raiz da floresta. Os comandos seguintes devem ser executados no PDCE do domínio raiz da floresta. Para descobrir qual o controlador de domínio que atualmente é também o PDCE, deve ser utilizado o comando "netdom query fsmo".

    > Abrir o PowerShell
    > w32tm.exe /config /syncfromflags:manual /manualpeerlist:"GoodKnownNTP1 GoodKnownNTP2" (GoodKnownNTP1 e GoodKnownNTP2 devem ser substituídos por servidores NTP reais, corretos e adequados)
    > w32tm.exe /config /update
    > Restart-Service w32time
    > Get-Service w32time

    Preview - http://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-95-87/0576.Configure_5F00_PDC_5F00_Time_5F00_Service.png

  • Listar, Transferir e efetuar o "Seize" dos FSMO Role Holders através do PowerShell

    Comandos de PowerShell que devem ser executados de modo a listar, transferir ou efectuar o "Seize" dos FSMO Role Holders (Exemplo para o domínio contoso.com).

     Listar:

    > Get-ADForest contoso.com | Format-Table SchemaMaster,DomainNamingMaster
    > Get-ADDomain contoso.com | Format-Table RIDMaster,InfrastructureMaster,PDCEmulator

    Transferir:

    > Move-ADDirectoryServerOperationMasterRole -Identity ADRESLAB3 -OperationMasterRole SchemaMaster,DomainNamingMaster,RIDMaster,InfrastructureMaster,PDCEmulator (Neste exemplo o DC de destino é o ADRESLAB3)

    "Seize":

    > Move-ADDirectoryServerOperationMasterRole -Identity ADRESLAB3 -OperationMasterRole SchemaMaster,DomainNamingMaster,RIDMaster,InfrastructureMaster,PDCEmulator -Force

    Preview - http://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-95-87/1512.PowerShell_5F00_FSMO_5F00_Roles_5F00_Setup.png

  • Utilização do modulo de Powershell para Active Directory - Add-ADGroupMember

    Como adicionar utilizadores a grupos da Active Directory a partir de um ficheiro CSV, utilizando o Powershell.

    > Import-Module ActiveDirectory
    > $tabela = Import-Csv .\Users.csv
    > $tabela | foreach {Add-ADGroupMember -Identity $_.group -Members $_.user -v}

    Picture Preview - http://blogs.technet.com/cfs-filesystemfile.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-94-04/4834.Add_2D00_ADGroupMember.png

     

  • Como promover o primeiro controlador de domínio numa nova floresta

    Movie Preview: http://blogs.technet.com/cfs-filesystemfile.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-94-04/7723.PromoteDC.PNG

     

     

  • Testes gerais ao ambiente de Active Directory em 2 minutos

    Procedimento para a execução, em apenas 2 minutos, de testes ao ambiente de Active Directory de modo a obter uma ideia geral do estado actual do sistema:

    > net share
    > repadmin /viewlist *
    > repadmin /replsum
    > repadmin /failcache *
    > repadmin /showbackup
    > dcdiag /test:dns

    Preview - http://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-95-87/4718.2Minutes_5F00_DC_5F00_Tests.png

  • Consultar o FFL / DFL

    Procedimento para consultar o FFL (Forest Functional Level - Nível Funcional da Floresta) e o DFL (Domain Functional Level - Nível Funcional do Domínio), através do snap-in "Active Directory Domains and Trusts":

    > Run > Domain.msc

    Preview - http://blogs.technet.com/cfs-filesystemfile.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-95-87/3034.Display_5F00_FFL_5F00_DFL.png

  • Consultar os FSMO Role Owners

    Procedimento para consultar os controladores de domínio que são FSMO Role Owners do Domínio/Floresta, através da ferramenta "netdom":

    > cmd > netdom query fsmo

    Preview - http://blogs.technet.com/cfs-filesystemfile.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-95-87/5635.Display_5F00_FSMO_5F00_Role_5F00_Holders.png

  • Promover um Controlador de Domínio no Windows Server 2012 através de PowerShell

    Utilizar o PowerShell, no Windows server 2012, para promover um Controlador de Domínio numa nova floresta (neste exemplo o domínio raiz da floresta é "contoso.com"):

    > Install-WindowsFeature AD-Domain-Services
    > Install-WindowsFeature RSAT-AD-PowerShell
    > Install-WindowsFeature RSAT-ADDS
    > Import-Module ADDSDeployment
    > Install-ADDSForest -DatabasePath "C:\Windows\NTDS" -DomainMode "Win2012" -DomainName "contoso.com" -DomainNetbiosName "CONTOSO" -ForestMode "Win2012" -InstallDns -LogPath "C:\Windows\NTDS" -NoRebootOnCompletion -SysvolPath "C:\Windows\SYSVOL" -Force

    Nota: Através deste processo, a password atribuída ao administrador de domínio é a mesma que a do administrador local da máquina, antes de ela ser promovida a Controlador de Domínio na nova floresta.

    Preview - http://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-95-87/7851.ADDS_5F00_PowerShell_5F00_Deploy.png