Share via

Novidades nos Serviços de Federação do Active Directory (AD FS)

  • Artigo

Novidades nos Serviços de Federação do Active Directory (AD FS) para Windows Server 2019

Este artigo descreve as novas alterações feitas no AD FS (Serviços de Federação do Active Directory).

Entradas protegidas

Os seguintes pontos são um breve resumo das atualizações para entradas protegidas disponíveis no AD FS (Serviços de Federação do Active Directory) 2019:

  • Provedores de Autenticação Externos como Primários. Os clientes agora podem usar produtos de autenticação de terceiros como o primeiro fator e não expor senhas como o primeiro fator. Nos casos em que um provedor de autenticação externo pode provar dois fatores, ele pode declarar a MFA.
  • Autenticação por senha como autenticação extra. Os clientes têm uma opção de caixa de entrada com suporte total para usar senhas apenas como um fator extra depois que uma opção sem senha é usada como o primeiro fator. Essa opção aprimora a experiência do cliente com relação ao AD FS 2016, em que os clientes precisavam baixar um adaptador do GitHub que fosse compatível com o respectivo estado.
  • Módulo de Avaliação de Risco Conectável. Os clientes agora podem criar módulos de plug-in próprios para bloquear determinados tipos de solicitações durante a fase de pré-autenticação. Esse recurso facilita para os clientes usar a inteligência de nuvem, como a proteção de identidade, para bloquear a entrada de usuários ou transações suspeitos. Para mais informações, confira Criar plug-ins com o Modelo de Avaliação de Risco do AD FS 2019.
  • Aprimoramentos do ESL. Aprimora o QFE (engenharia de correção rápida) do ESL na versão 2016 adicionando as seguintes funcionalidades:
    • Permite que os clientes estejam no modo de auditoria enquanto são protegidos pela funcionalidade "clássica" de bloqueio da extranet, disponível desde o AD FS 2012R2. Atualmente, os clientes 2016 não têm proteção no modo de auditoria.
    • Habilita o limite de bloqueio independente para locais familiares. Esse recurso possibilita que várias instâncias de aplicativos em execução com uma conta de serviço comum sobreponham senhas com o menor impacto possível.

Outros aprimoramentos de segurança

Os seguintes aprimoramentos de segurança estão disponíveis no AD FS 2019:

  • PowerShell remoto usando a entrada com SmartCard. Os clientes agora podem usar SmartCards para se conectar de modo remoto ao AD FS por meio do PowerShell e usar isso para gerenciar todas as funções do PowerShell, incluindo cmdlets de vários nós.
  • Personalização de cabeçalho HTTP. Os clientes agora podem personalizar cabeçalhos HTTP emitidos durante as respostas do AD FS, incluindo os seguintes cabeçalhos:
    • HSTS: esse cabeçalho significa que os pontos de extremidade AD FS podem ser usados somente em pontos de extremidade HTTPS para impor um navegador compatível.
    • x-frame-options: possibilita que administradores do AD FS permitam que partes confiáveis específicas insiram iFrames nas páginas interativas de entrada do AD FS. Este cabeçalho deve ser usado com cuidado e somente em hosts HTTPS.
    • Cabeçalho futuro: outros cabeçalhos futuros também podem ser configurados.

Para obter mais informações, confira Personalizar cabeçalhos de resposta de segurança HTTP com o AD FS 2019.

Funcionalidades de autenticação/política

As seguintes funcionalidades de autenticação/política estão inclusas no AD FS 2019:

  • Especifique o método de autenticação para outra autenticação por RP. Os clientes agora podem usar regras de declarações para decidir qual outro provedor de autenticação invocar para realizar a autenticação adicional deles. Esse recurso é útil para dois casos de uso:
    • Os clientes estão fazendo a transição de um provedor de autenticação adicional para outro. Dessa forma, à medida que eles integram usuários a um provedor de autenticação mais recente, eles podem usar grupos para controlar qual provedor de autenticação adicional é chamado.
    • Os clientes precisam de um provedor de autenticação adicional específico (por exemplo, certificado) para determinados aplicativos.
  • Restrinja a autenticação de dispositivo baseada em TLS (Transport Layer Security) somente a aplicativos que façam essa exigência. Os clientes agora podem restringir as autenticações de dispositivo baseadas em TLS de cliente somente a aplicativos que executam acesso condicional com base no dispositivo. Essa opção impede prompts indesejados na autenticação do dispositivo (ou falhas, caso o aplicativo cliente não possa tratar) para aplicativos que não exigem a autenticação de dispositivo baseada em TLS.
  • Suporte à atualização de MFA (autenticação multifator). O AD FS agora dá suporte à capacidade de refazer a credencial de segundo fator com base na atualização dela. Esse recurso permite que os clientes façam uma transação inicial com dois fatores e que o segundo fator seja solicitado apenas periodicamente. Esse recurso está disponível somente para aplicativos que podem fornecer um parâmetro adicional na solicitação e não é uma definição configurável no AD FS. O Azure AD dá suporte a esse parâmetro quando você configura "Lembrar minha MFA por X dias" e define o sinalizador "supportsMFA" como true nas configurações de confiança de domínio federada do Azure AD.

Melhorias de logon único

Os seguintes aprimoramentos de SSO (logon único) foram feitos no AD FS 2019:

  • Experiência de usuário paginada com tema centralizado. O AD FS agora migrou para um fluxo de experiência de usuário paginada, permitindo que o AD FS valide e forneça uma experiência de entrada mais tranquila. O AD FS agora usa uma interface do usuário centralizada (em vez do lado direito da tela). Você pode precisar de imagens de logotipo e de tela de fundo mais recentes para se alinhar com essa experiência. Essa mudança também espelha a funcionalidade oferecida no Azure AD.
  • Correção de bug: estado de SSO persistente para dispositivos Win10 ao fazer a autenticação de PRT (Token de Atualização Principal). Essa alteração resolve um problema em que o estado de MFA não era persistente ao usar a autenticação de PRT para dispositivos Windows 10. O resultado do problema era que os usuários finais eram solicitados a inserir a credencial de segundo fator (MFA) com frequência. A correção também torna a experiência consistente quando a autenticação do dispositivo é executada com êxito via TLS do cliente e por meio do mecanismo de PRT.

Suporte para criar aplicativos de linha de negócios modernos

O seguinte suporte para a criação de aplicativos LOB (aplicativos de linha de negócios) modernos foi adicionado ao AD FS 2019:

  • Fluxo/perfil do dispositivo Oauth. O AD FS agora é compatível com o perfil de fluxo de dispositivo OAuth para entrar em dispositivos que não têm uma superfície da interface do usuário para dar suporte a experiências de entrada avançadas. Esse recurso permite que o usuário conclua a experiência de entrada em outro dispositivo. Essa funcionalidade é necessária para a experiência da CLI do Azure no Azure Stack e pode ser usada em outros casos.
  • Remoção do parâmetro "Resource". O AD FS agora removeu o requisito de especificar um parâmetro de recurso, que está em linha com as especificações OAuth atuais. Agora, os clientes podem fornecer o identificador do objeto de confiança de terceira parte confiável como o parâmetro de escopo, além das permissões solicitadas.
  • Cabeçalhos CORS (compartilhamento de recursos entre origens) em respostas do AD FS. Agora, os clientes podem criar aplicativos de página única que permitem que bibliotecas JavaScript do lado do cliente validem a assinatura do id_token consultando as chaves de assinatura do documento de descoberta OIDC (OpenID Connect) no AD FS.
  • Suporte à PKCE (Chave de Prova para Troca de Código). O AD FS adiciona suporte à PKCE para fornecer um fluxo de código de autenticação seguro dentro do OAuth. Esse recurso adiciona uma camada extra de segurança a esse fluxo para evitar o sequestro do código e a reprodução dele por meio de outro cliente.
  • Correção de bug: enviar declaração x5t e kid. Essa alteração é uma correção de bug secundária. Agora, o AD FS também envia a declaração “kid” para indicar a dica de ID de chave para verificar a assinatura. Anteriormente, o AD FS enviava apenas a declaração “x5t”.

Aprimoramentos de capacidade de suporte

Os seguintes aprimoramentos à capacidade de suporte agora fazem parte do AD FS 2019:

  • Enviar detalhes do erro aos administradores do AD FS. Permite aos administradores configurar os usuários finais para enviar logs de depuração relacionados a uma falha na autenticação do usuário final a ser armazenada como um arquivo compactado para facilitar o consumo. Os administradores também podem configurar uma conexão SMTP para enviar por email automaticamente o arquivo compactado para uma conta de email de triagem ou para criar automaticamente um tíquete com base no email.

Atualizações de implantação

As seguintes atualizações de implantação foram incluídas no AD FS 2019:

  • Nível de Comportamento do Farm 2019. Como no AD FS 2016, há uma nova versão de nível de comportamento do farm necessária para habilitar a nova funcionalidade discutida mais adiante neste artigo. Essa atualização permite ir de:
    • AD FS no Windows Server 2012 R2 para o AD FS no Windows Server 2016.
    • AD FS no Windows Server 2016 para o AD FS no Windows Server 2019.

Atualizações SAML

A seguinte atualização da SAML (Security Assertion Markup Language) está no AD FS 2019:

  • Correção de bug: corrigidos bugs na federação agregada. Foram feitas inúmeras correções de bugs em relação ao suporte à federação agregada (por exemplo, InCommon). As seguintes áreas receberam correções:
    • Colocação em escala aprimorada para uma grande quantidade de entidades no documento de metadados de federação agregada. Anteriormente, a colocação em escala falharia e retornaria o erro "ADMIN0017".
    • Consulta usando o parâmetro "ScopeGroupID" por meio do cmdlet do PowerShell Get-AdfsRelyingPartyTrustsGroup.
    • Manipulação de condições de erro em relação à entityID duplicada.

Especificação de recurso de estilo do Azure AD no parâmetro de escopo

Anteriormente, o AD FS exigia que o recurso e o escopo desejados estivessem em um parâmetro separado em qualquer solicitação de autenticação. Por exemplo, a seguinte solicitação OAuth pode parecer que você normalmente enviaria:

https://fs.contoso.com/adfs/oauth2/authorize?response_type=code&client_id=claimsxrayclient&resource=urn:microsoft:adfs:claimsxray&scope=oauth&redirect_uri=https://adfshelp.microsoft.com/
ClaimsXray/TokenResponse&prompt=login

Com o AD FS no Server 2019, agora você pode transmitir o valor do recurso inserido no parâmetro de escopo. Essa alteração também é consistente com a maneira como alguém pode fazer a autenticação no Azure AD.

O parâmetro de escopo agora pode ser organizado como uma lista separada por espaço, em que cada entrada é estruturada como recurso/escopo.

Observação

Somente um recurso pode ser especificado na solicitação de autenticação. Se mais de um recurso é incluído na solicitação, o AD FS retorna um erro e a autenticação não tem êxito.

Suporte de PKCE (Chave de Prova para Troca de Código) para OAuth

Clientes públicos OAuth que usam a concessão de código de autorização são suscetíveis a ataques de interceptação de código de autorização. O ataque é bem descrito na RFC 7636. Para mitigar esse risco, o AD FS no Server 2019 é compatível com a PKCE (Chave de Prova para Troca de Código) para o fluxo de concessão de código de autorização OAuth.

Para usar o suporte da PKCE, essa especificação adiciona mais parâmetros à Autorização do OAuth 2.0 e às solicitações de token de acesso.

Diagrama do relacionamento da PKCE entre o cliente e o AD FS 2019.

A. O cliente cria e registra um segredo chamado "code_verifier" e deriva uma versão transformada "t (code_verifier)" (conhecida como "code_challenge"). O segredo é enviado na Solicitação de Autorização do OAuth 2.0, juntamente com o método de transformação "t_m".

B. O ponto de extremidade da autorização responde como de costume, mas registra "t(code_verifier)" e o método de transformação.

C. Em seguida, o cliente envia o código de autorização na solicitação do token de acesso como de costume, mas inclui o segredo "code_verifier" gerado em (A).

D. O AD FS transforma o "code_verifier" e compara-o com "t (code_verifier)" de (B). O acesso é negado se eles não são iguais.

Como escolher provedores de autenticação adicionais na versão 2019

O AD FS já é compatível com um disparo de autenticação adicional baseado na política de regra de declaração. Essas políticas podem ser definidas em um determinado RP ou a nível global. É possível definir uma política de autenticação adicional para um RP específico usando o cmdlet Set-AdfsRelyingPartyTrust (AD FS) | Microsoft Docs passando os parâmetros AdditionalAuthenticationRules ou AdditionalAuthenticationRulesFile. Para defini-lo de modo global, um administrador pode usar o cmdlet Set-AdfsAdditionalAuthenticationRule (AD FS) | Microsoft Docs.

Por exemplo, o administrador da versão 2012 R2 em diante já pode escrever a regra a seguir para solicitar autenticação adicional se a solicitação vier da extranet.

Set-AdfsAdditionalAuthenticationRule -AdditionalAuthenticationRules 'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", value = "http://schemas.microsoft.com/claims/multipleauthn" );'

Na versão 2019, os clientes agora podem usar regras de declarações para decidir qual outro provedor de autenticação invocar para realizar uma autenticação adicional. Esse recurso é útil para dois cenários:

Os clientes estão fazendo a transição de um provedor de autenticação adicional para outro. Dessa forma, à medida que eles integram usuários a um provedor de autenticação mais recente, eles podem usar grupos para controlar qual provedor de autenticação adicional é chamado.

Os clientes têm a necessidade de um provedor de autenticação adicional específico (por exemplo, um certificado) para determinados aplicativos, mas método diferente (MFA do Azure AD) para outros aplicativos.

Essa configuração poderia ter sido alcançada pela emissão da declaração http://schemas.microsoft.com/claims/authnmethodsproviders por meio de outras políticas de autenticação. O valor dessa declaração deve ser o Nome do provedor de autenticação.

Agora, na versão 2019, os clientes podem modificar a regra de declaração acima para escolher provedores de autenticação com base em seus cenários.

Transição de um provedor de autenticação para outro: você pode modificar a regra mencionada anteriormente para escolher a Autenticação multifator do Azure AD para usuários que estão no grupo SID S-1-5-21-608905689-872870963-3921916988-12345. Por exemplo, você pode usar essa modificação para um grupo gerenciado por empresa, que rastreia os usuários que se registraram para a Autenticação Multifator do Azure AD. Essa modificação também funciona para o restante dos usuários com que um administrador deseja usar a autenticação de certificado.

'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn" ); 

 c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "S-1-5-21-608905689-872870963-3921916988-12345"] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "AzureMfaAuthentication"); 

not exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value=="S-1-5-21-608905689-872870963-3921916988-12345"]) => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "CertificateAuthentication");’

O seguinte exemplo mostra como definir dois provedores de autenticação diferentes para dois aplicativos distintos:

Defina o Aplicativo A para usar a Autenticação Multifator do Azure AD como provedor de autenticação adicional:

Set-AdfsRelyingPartyTrust -TargetName AppA -AdditionalAuthenticationRules 'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn" ); 

c:[] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "AzureMfaAuthentication");'

Defina o Aplicativo B para usar o Certificado como provedor de autenticação adicional:

Set-AdfsRelyingPartyTrust -TargetName AppB -AdditionalAuthenticationRules 'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn" ); 

c:[] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "CertificateAuthentication");'

Os administradores também podem fazer regras para permitir mais de um provedor de autenticação adicional. Nesse caso, o AD FS mostra os provedores de métodos de autenticação emitidos e o usuário pode escolher qualquer um deles. Para permitir vários provedores de autenticação adicionais, eles devem emitir várias declarações http://schemas.microsoft.com/claims/authnmethodsproviders.

Se a avaliação da declaração não retornar nenhum dos provedores de autenticação, o AD FS retornará para mostrar todos os provedores de autenticação adicionais configurados pelo administrador no AD FS. O usuário precisa selecionar o provedor de autenticação apropriado.

Para obter todos os outros provedores de autenticação permitidos, o administrador pode usar o cmdlet (Get-AdfsGlobalAuthenticationPolicy).AdditionalAuthenticationProvider. O valor da declaração http://schemas.microsoft.com/claims/authnmethodsproviders deve ser um dos nomes de provedor retornados pelo cmdlet mencionado anteriormente.

Não há suporte para disparar um provedor de autenticação adicional específico se o RP estiver usando Políticas de Controle de Acesso no Windows Server 2016 do AD FS | Microsoft Docs. Ao migrar um aplicativo para fora da política de controle de acesso, o AD FS copiará a política correspondente para AdditionalAuthenticationRules e IssuanceAuthorizationRules. Então, se um administrador quiser usar um provedor de autenticação específico, ele poderá passar a usar a política de controle de acesso e modificar AdditionalAuthenticationRules para acionar um provedor de autenticação específico.

Perguntas frequentes

Como fazer para resolver o erro do log de eventos de Administrador do AD FS que diz "Solicitação Oauth inválida recebida. O 'NOME' do cliente é proibido de acessar o recurso com o escopo 'ugs'"?

Siga estas etapas para corrigir o problema:

  1. Inicie o console de gerenciamento do AD FS. Acesse Serviços > Descrições de Escopo.
  2. Selecione mais opções em "Descrições de Escopo e escolha Adicionar Descrição do Escopo.
  3. Em nome, digite "ugs" e selecione Aplicar> OK.
  4. Inicie o PowerShell como Administrador.
  5. Execute o comando Get-AdfsApplicationPermission. Procure pelo ScopeNames :{openid, aza} que tem o ClientRoleIdentifier. Anote ObjectIdentifier.
  6. Execute o comando Set-AdfsApplicationPermission -TargetIdentifier <ObjectIdentifier from step 5> -AddScope 'ugs'.
  7. Reinicie o serviço do AD FS.
  8. Do lado do cliente, reinicie o cliente. Você deve ser solicitado a configurar o WHFB (Windows Hello para Empresas).
  9. Se a janela de configuração não for exibida, você precisará coletar logs de rastreamento e se aprofundar na solução do problema.

Posso transmitir o valor de um recurso como parte do valor do escopo assim como as solicitações são feitas no Azure AD?

Com o AD FS no Server 2019, agora você pode transmitir o valor do recurso inserido no parâmetro de escopo. O parâmetro de escopo agora pode ser organizado como uma lista separada por espaço, em que cada entrada é estruturada como recurso/escopo. Por exemplo: <create a valid sample request>

O AD FS dá suporte à extensão da PKCE?

O AD FS no Server 2019 dá suporte à PKCE (Chave de Prova para Troca de Código) para o fluxo de concessão de código de autorização do OAuth.

Novidades nos Serviços de Federação do Active Directory (AD FS) para Windows Server 2016

Caso esteja procurando informações sobre as versões anteriores do AD FS, confira os seguintes artigos: AD FS no Windows Server 2012 ou 2012 R2 e AD FS 2.0.

O AD FS fornece controle de acesso e logon único para uma ampla variedade de aplicativos, incluindo Office 365, aplicativos SaaS baseados em nuvem e aplicativos da rede corporativa.

  • Para a organização de TI, ele permite que você forneça logon e controle de acesso para os aplicativos modernos e herdados em qualquer computador, com base no mesmo conjunto de credenciais e políticas.
  • Para o usuário, ele fornece logon sem interrupções usando as mesmas credenciais de conta já conhecidas.
  • Para o desenvolvedor, ele fornece uma maneira fácil de autenticar usuários cujas identidades residem no diretório organizacional para que você possa concentrar seus esforços em seu aplicativo, não na autenticação ou na identidade.

Eliminar as senhas da extranet

O AD FS 2016 oferece três novas opções de logon sem senhas, permitindo que as organizações evitem o risco de comprometimento da rede em virtude de roubo, vazamento ou venda de senhas.

Entrar com a autenticação multifator do Azure Active Directory

O AD FS 2016 se baseia nas funcionalidades da MFA (autenticação multifator) do AD FS no Windows Server 2012 R2. Agora você pode permitir o logon usando apenas um código de Autenticação Multifator, sem precisar inserir primeiro um nome de usuário e uma senha.

  • Com a Autenticação Multifator do Azure AD como método de autenticação primário, será solicitado ao usuário que forneça o nome de usuário e o código OTP do aplicativo Microsoft Authenticator.
  • Com Autenticação Multifator do Azure AD como método de autenticação secundário ou adicional, o usuário fornece credenciais de autenticação primárias. Eles podem entrar usando a Autenticação Integrada do Windows, com seu nome de usuário e senha, cartão inteligente ou um certificado de usuário ou de dispositivo. Em seguida, eles veem um prompt para entrada de texto, voz ou Autenticação Multifator do Azure AD baseada em OTP.
  • Com o novo adaptador interno de Autenticação Multifator do Azure AD, a instalação e a configuração da Autenticação Multifator do Azure AD com o AD FS nunca foi tão simples.
  • As organizações podem aproveitar a Autenticação Multifator do Azure AD sem a necessidade de contar com um servidor local de Autenticação Multifator do Azure AD.
  • A Autenticação Multifator do Azure AD pode ser configurada para a intranet, a extranet ou como parte de uma política de controle de acesso.

Para obter mais informações sobre a Autenticação Multifator do Azure AD com o AD FS, confira Configurar o AD FS 2016 e a Autenticação Multifator do Azure AD.

Acesso sem senha por meio de dispositivos compatíveis

O AD FS 2016 baseia-se nas funcionalidades anteriores de registro do dispositivo para habilitar o logon e o controle de acesso com base no status de conformidade do dispositivo. Os usuários podem fazer logon usando as credenciais do dispositivo e a conformidade é reavaliada quando os atributos do dispositivo são alterados, para que você sempre possa garantir que as políticas estejam sendo cumpridas. Esse recurso permite políticas como:

  • Habilitar o acesso somente por meio de dispositivos gerenciados e/ou compatíveis.
  • Habilitar o acesso à Extranet somente por meio de dispositivos gerenciados e/ou compatíveis.
  • Exigir autenticação multifator para computadores que não são gerenciados ou que não são compatíveis.

O AD FS fornece o componente local das políticas de acesso condicional em um cenário híbrido. Quando você registra dispositivos com o Azure AD para acesso condicional a recursos de nuvem, a identidade do dispositivo também pode ser usada para políticas do AD FS.

Diagrama de uma solução híbrida e os relacionamentos entre os usuários e o Active Directory local.

Para obter mais informações sobre como usar o acesso condicional baseado em dispositivo na nuvem, confira Acesso Condicional no Azure Active Directory.

Para obter mais informações sobre como usar o acesso condicional baseado em dispositivo com o AD FS

Entrada com o Windows Hello para Empresas

Observação

Atualmente, navegadores do projeto de software livre, como o Google Chrome e o novo Microsoft Edge criado no Chromium, não são compatíveis com SSO (logon único) baseado em navegador com o Microsoft Windows Hello para Negócios. Use o Internet Explorer ou uma versão mais antiga do Microsoft Edge.

Os dispositivos Windows 10 usam o Windows Hello e o Windows Hello para Empresas, substituindo senhas de usuário por credenciais de usuário vinculadas a dispositivos fortes protegidas pelo gesto de um usuário (um PIN, um gesto biométrico como impressão digital ou reconhecimento do rosto). O AD FS 2016 é compatível com essas novas funcionalidades do Windows 10 para que os usuários possam entrar nos aplicativos do AD FS por meio da intranet ou da extranet, sem fornecer senha.

Para obter mais informações sobre como usar o Windows Hello para Empresas na sua organização, confira Habilitar o Windows Hello para Empresas na sua organização.

Acesso seguro a aplicativos

As alterações a seguir afetam o acesso seguro a aplicativos no AD FS.

Autenticação moderna

O AD FS 2016 dá suporte aos mais recentes protocolos modernos que fornecem uma experiência aprimorada de usuário para o Windows 10 e para os dispositivos e aplicativos iOS e Android mais recentes.

Para obter mais informações, confira Cenários do AD FS para desenvolvedores.

Configurar políticas de controle de acesso sem a necessidade de conhecer a linguagem das regras de declaração

Anteriormente, os administradores do AD FS tinham que configurar políticas usando a linguagem de regra de declaração do AD FS, dificultando a configuração e a manutenção de políticas. Com as políticas de controle de acesso, os administradores podem usar modelos internos para aplicar políticas comuns, como

  • Permitir acesso somente à intranet.
  • Permitir acesso a todos e exigir MFA na Extranet.
  • Permitir acesso a todos e exigir MFA de um grupo específico.

Os modelos são fáceis de personalizar usando um processo controlado por assistente para adicionar exceções ou regras de política adicionais e podem ser aplicados a um ou vários aplicativos para imposição consistente da política.

Para obter mais informações, confira Políticas de controle de acesso no AD FS.

Habilitar logon com diretórios LDAP não AD

Muitas organizações têm uma combinação de Active Directory e diretórios de terceiros. Com a adição do suporte do AD FS para autenticação de usuários armazenados em diretórios compatíveis com a v3 do protocolo LDAP, agora o AD FS pode ser usado para:

  • Usuários em diretórios de terceiros compatíveis com a v3 do LDAP.
  • Usuários em florestas do Active Directory com as quais não há configurada uma relação de confiança bidirecional do Active Directory.
  • Usuários do AD LDS (Active Directory Lightweight Directory Services).

Para obter mais informações, consulte Configure AD FS to authenticate users stored in LDAP directories.

Experiência de entrada aprimorada

As alterações a seguir melhoram a experiência de entrada do AD FS.

Personalizar a experiência de entrada para aplicativos AD FS

Anteriormente, os AD FS no Windows Server 2012 R2 forneciam uma experiência comum de logon para todos os aplicativos de terceira parte confiável, com a capacidade de personalizar um subconjunto de conteúdo baseado em texto por aplicativo. Com o Windows Server 2016, você pode personalizar não apenas as mensagens, mas as imagens, o logotipo e o tema da Web por aplicativo. Além disso, você pode criar temas da Web personalizados e aplicá-los de acordo com a terceira parte confiável.

Para obter mais informações, confira Personalização de entrada do usuário do AD FS.

Aprimoramentos operacionais e da capacidade de gerenciamento

A seção a seguir descreve os cenários operacionais aprimorados que são introduzidos com o AD FS (Serviços de Federação do Active Directory) no Windows Server 2016.

Auditoria simplificada para facilitar o gerenciamento administrativo

No AD FS para Windows Server 2012 R2, havia vários eventos de auditoria gerados para uma só solicitação e as informações relevantes sobre uma atividade de emissão de credenciais ou de token estão ausentes ou espalhadas por vários eventos de auditoria. Por padrão, os eventos de auditoria do AD FS são desativados devido à sua natureza detalhada. Com o lançamento do AD FS 2016, a auditoria tornou-se mais simplificada e menos detalhada.

Para mais informações, confira Como auditar aprimoramentos ao AD FS no Windows Server 2016.

Interoperabilidade aprimorada com SAML 2.0 para participação em confederações

O AD FS 2016 contém suporte adicional ao protocolo SAML, incluindo suporte para importar relações de confiança com base em metadados que contêm várias entidades. Essa alteração permite que você configure o AD FS para participar de confederações, como a Federação InCommon, bem como de outras implementações em conformidade com o padrão eGov 2.0.

Para obter mais informações, confira Interoperabilidade aprimorada com o SAML 2.0.

Gerenciamento simplificado de senhas para usuários federados do Microsoft 365

Você pode configurar o AD FS (Serviços de Federação do Active Directory) para enviar declarações de expiração de senha para os aplicativos de confiança de terceira parte confiável que são protegidos pelo AD FS. A forma como essas declarações são usadas depende do aplicativo. Por exemplo, com o Office 365 como sua terceira parte confiável, as atualizações foram implementadas no Exchange e no Outlook para notificar os usuários federados sobre suas senhas que expirarão em breve.

Para mais informações, confira Configurar o AD FS para enviar declarações de expiração de senha.

É mais fácil mover do AD FS no Windows Server 2012 R2 para o AD FS no Windows Server 2016

Anteriormente, a migração para uma nova versão do AD FS exigia a exportação da configuração do antigo farm e a importação para um farm novo e paralelo.

Agora, migrar do AD FS no Windows Server 2012 R2 para o AD FS no Windows Server 2016 tornou-se mais fácil. Adicione um novo servidor Windows Server 2016 a um farm do Windows Server 2012 R2 e o farm atua no nível de comportamento do farm do Windows Server 2012 R2. Seu servidor agora tem aparência e se comporta como um farm do Windows Server 2012 R2.

Em seguida, adicione novos servidores do Windows Server 2016 ao farm, verifique a funcionalidade e remova os servidores mais antigos do balanceador de carga. Depois que todos os nós do farm estiverem executando o Windows Server 2016, você estará pronto para atualizar o nível de comportamento do farm para 2016 e começar a usar os novos recursos.

Para obter mais informações, confira Como atualizar para o AD FS no Windows Server 2016.