Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Estes são os vários requisitos aos quais você deve estar em conformidade ao implantar o AD FS:
Requisitos de certificado
Os certificados desempenham o papel mais crítico na proteção de comunicações entre servidores de federação, Proxies de Aplicativo Web, aplicativos com reconhecimento de declarações e clientes Web. Os requisitos para certificados variam, dependendo se você está configurando um servidor de federação ou um computador proxy, conforme descrito nesta seção.
Certificados do servidor de federação
| Tipo de certificado | Requisitos, suporte e itens a serem conhecidos |
|---|---|
| Certificado SSL (Secure Sockets Layer): Esse é um certificado SSL padrão que é usado para proteger as comunicações entre servidores de federação e clientes. | - Esse certificado deve ser um certificado X509 v3 publicamente confiável. – Todos os clientes que acessam qualquer ponto de extremidade do AD FS devem confiar nesse certificado. É altamente recomendável usar certificados emitidos por uma AC (autoridade de certificação) pública (de terceiros). Você pode usar um certificado SSL autoassinado com êxito em servidores de federação em um ambiente de laboratório de teste. No entanto, para um ambiente de produção, recomendamos que você obtenha o certificado de uma CA pública. – Dá suporte a qualquer tamanho de chave compatível com o Windows Server 2012 R2 para certificados SSL. - Não dá suporte a certificados que usam chaves CNG. - Quando usado junto com o Workplace Join/Device Registration Service, o nome alternativo do assunto do certificado SSL para o serviço AD FS deve conter o valor enterpriseregistration, seguido pelo sufixo UPN (Nome Principal de Usuário) da sua organização, por exemplo, enterpriseregistration.contoso.com. – Há suporte para certificados curinga. Ao criar seu farm do AD FS, você será solicitado a fornecer o nome do serviço do AD FS (por exemplo, adfs.contoso.com. - É altamente recomendável usar o mesmo certificado SSL para o Proxy de Aplicativo Web. No entanto, é necessário que isso seja o mesmo ao dar suporte aos endpoints de Autenticação Integrada do Windows por meio do Proxy de Aplicativos Web e quando a Autenticação de Proteção Estendida está ativada (configuração padrão). – O Nome da entidade desse certificado é usado para representar o nome do Serviço de Federação de cada instância do AD FS que você implantar. Por esse motivo, convém considerar a escolha de um nome de Sujeito em todos os novos certificados que forem emitidos pela AC que melhor represente o nome da sua empresa ou organização para seus parceiros. A identidade do certificado deve corresponder ao nome do serviço de federação (por exemplo, fs.contoso.com). A identidade é uma extensão de nome alternativo da entidade do tipo dNSName ou, se não houver entradas de nome alternativo da entidade, o nome da entidade especificado como um nome comum. Várias entradas de nome alternativo da entidade podem estar presentes no certificado, desde que uma delas coincide com o nome do serviço de federação. - Importante: é altamente recomendável usar o mesmo certificado SSL em todos os nós da sua estrutura do AD FS, assim como em todos os proxies de aplicação web na sua estrutura do AD FS. |
| Certificado de comunicação de serviço: Esse certificado permite a segurança de mensagens do WCF para proteger as comunicações entre servidores de federação. | - Por padrão, o certificado SSL é usado como o certificado de comunicação de serviço. Mas você também tem a opção de configurar outro certificado como o certificado de comunicação de serviço. - Importante: se você estiver usando o certificado SSL como o certificado de comunicação de serviço, quando o certificado SSL expirar, configure o certificado SSL renovado como seu certificado de comunicação de serviço. Isso não acontece automaticamente. - Esse certificado deve ser confiável para clientes do AD FS que usam o WCF Message Security. – Recomendamos que você use um certificado de autenticação de servidor emitido por uma AC (autoridade de certificação) pública (de terceiros). - O certificado de comunicação de serviço não pode ser um certificado que usa chaves CNG. - Esse certificado pode ser gerenciado usando o console de Gerenciamento do AD FS. |
| Certificado de assinatura de token: Esse é um certificado X509 padrão que é usado para assinar com segurança todos os tokens que o servidor de federação emite. | - Por padrão, o AD FS cria um certificado autoassinado com chaves de 2048 bits. - Certificados emitidos pela Autoridade Certificadora também são suportados e podem ser alterados usando o Console de Gerenciamento do AD FS. - Os certificados emitidos pela AC devem ser armazenados e acessados por meio de um Provedor de Criptografia CSP. - O certificado de autenticação de token não pode ser um certificado que usa chaves CNG. - O AD FS não requer certificados registrados externamente para assinatura de token. O AD FS renova automaticamente esses certificados autoassinados antes de expirarem, primeiro configurando os novos certificados como certificados secundários para permitir que os parceiros os consumam e, em seguida, invertendo para primário em um processo chamado substituição automática de certificado. Recomendamos que você use os certificados padrão gerados automaticamente para assinatura de token. Se sua organização tiver políticas que exijam diferentes certificados a serem configurados para assinatura de token, você poderá especificar os certificados no momento da instalação usando o PowerShell (use o parâmetro –SigningCertificateThumbprint do cmdlet Install-AdfsFarm). Após a instalação, você pode exibir e gerenciar certificados de assinatura de token usando o console de Gerenciamento do AD FS ou cmdlets do PowerShell Set-AdfsCertificate e Get-AdfsCertificate. Quando certificados registrados externamente são usados para assinatura de token, o AD FS não executa a renovação ou substituição automática de certificado. Esse processo deve ser executado por um administrador. Para permitir a substituição de certificado quando um certificado está perto de expirar, um certificado de autenticação de token secundário pode ser configurado no AD FS. Por padrão, todos os certificados de assinatura de token são publicados em metadados de federação, mas apenas o certificado de assinatura de token primário é usado pelo AD FS para realmente assinar tokens. |
| Certificado de descriptografia/criptografia de token: Este é um certificado X509 padrão utilizado para descriptografar/criptografar qualquer token de entrada. Ele também é publicado nos metadados de federação. | - Por padrão, o AD FS cria um certificado autoassinado com chaves de 2048 bits. - Certificados emitidos pela Autoridade Certificadora também são suportados e podem ser alterados usando o Console de Gerenciamento do AD FS. - Os certificados emitidos pela AC devem ser armazenados e acessados por meio de um Provedor de Criptografia CSP. - O certificado de criptografia/descriptografia de token não pode ser um certificado que usa chaves CNG. - Por padrão, o AD FS gera e usa seus próprios certificados gerados internamente e autoassinados para descriptografia de token. O AD FS não requer certificados registrados externamente para essa finalidade. Além disso, o AD FS renova automaticamente esses certificados autoassinados antes de expirarem. Recomendamos que você use os certificados padrão gerados automaticamente para descriptografia de token. Se sua organização tiver políticas que exijam que certificados diferentes sejam configurados para descriptografia de token, você poderá especificar os certificados no momento da instalação usando o PowerShell (use o parâmetro –DecryptionCertificateThumbprint do cmdlet Install-AdfsFarm). Após a instalação, você poderá exibir e gerenciar certificados de descriptografia de token usando o console de Gerenciamento do AD FS ou cmdlets do PowerShell Set-AdfsCertificate e Get-AdfsCertificate. Quando certificados registrados externamente são usados para descriptografia de token, o AD FS não executa a renovação automática do certificado. Esse processo deve ser executado por um administrador. - A conta de serviço do AD FS precisa ter acesso à chave privada do certificado de assinatura de token no repositório pessoal do computador local. Isso é feito pela Instalação. Você também pode usar o complemento de gerenciamento do AD FS para garantir esse acesso se alterar posteriormente o certificado de assinatura de token. |
Cuidado
Os certificados utilizados para assinatura de token e descriptografia/criptografia de token são essenciais para a estabilidade do Serviço de Federação. Os clientes que gerenciam seus próprios certificados de assinatura de token e descriptografia/criptografia de token devem garantir que esses certificados sejam armazenados em backup e estejam disponíveis independentemente durante um evento de recuperação.
Observação
No AD FS, você pode alterar o nível sha (algoritmo de hash seguro) usado para assinaturas digitais para SHA-1 ou SHA-256 (mais seguro). O AD FS não dá suporte ao uso de certificados com outros métodos de hash, como MD5 (o algoritmo de hash padrão usado com a ferramenta de linha de comando Makecert.exe). Como prática recomendada de segurança, recomendamos que você use SHA-256 (que é definido por padrão) para todas as assinaturas. O SHA-1 é recomendado para uso somente em cenários em que você deve interoperar com um produto que não dá suporte a comunicações usando SHA-256, como um produto não Microsoft ou versões herdadas do AD FS.
Observação
Depois de receber um certificado de uma AC, verifique se todos os certificados são importados para o repositório de certificados pessoal do computador local. Você pode importar certificados para o repositório pessoal com o snap-in MMC de certificados.
Requisitos de hardware
Os seguintes requisitos mínimos e recomendados de hardware se aplicam aos servidores de federação do AD FS no Windows Server 2012 R2:
| Requisito de hardware | Requisito mínimo | Requisito recomendado |
|---|---|---|
| velocidade da CPU | Processador de 1,4 GHz e 64 bits | Quad-core, 2 GHz |
| RAM | 512 MB | 4 GB |
| Espaço em disco | 32 GB | 100 GB |
Requisitos de software
Os seguintes requisitos do AD FS são para a funcionalidade de servidor incorporada ao sistema operacional Windows Server® 2012 R2:
Para acesso à extranet, você deve implantar o serviço de função proxy de aplicativo Web – parte da função de servidor de Acesso Remoto do Windows Server® 2012 R2. Não há suporte para versões anteriores de um proxy de servidor de federação com o AD FS no Windows Server® 2012 R2.
Um servidor de federação e o serviço de função proxy de aplicativo Web não podem ser instalados no mesmo computador.
Requisitos do AD DS
Requisitos do controlador de domínio
Os controladores de domínio em todos os domínios de usuário e o domínio ao qual os servidores do AD FS estão ingressados devem estar executando o Windows Server 2008 ou posterior.
Observação
Todo o suporte para ambientes com controladores de domínio do Windows Server 2003 terminará após a Data de Término do Suporte Estendido para Windows Server 2003. Os clientes são altamente recomendados para atualizar seus controladores de domínio o mais rápido possível. Visite esta página para obter informações adicionais sobre o Ciclo de Vida de Suporte da Microsoft. Para problemas descobertos que são específicos para ambientes do controlador de domínio do Windows Server 2003, as correções serão emitidas somente para problemas de segurança e se uma correção puder ser emitida antes da expiração do Suporte Estendido para Windows Server 2003.
Observação
O AD FS exige um Controlador de Domínio gravável completo para funcionar, em vez de um Controlador de Domínio Somente Leitura. Se uma topologia planejada incluir um controlador de domínio somente leitura, o controlador de domínio somente leitura poderá ser usado para autenticação, mas o processamento de declarações LDAP exigirá uma conexão com o controlador de domínio gravável.
Requisitos de nível funcional de domínio
Todos os domínios de conta de usuário e o domínio ao qual os servidores do AD FS estão ingressados devem estar operando no nível funcional do domínio do Windows Server 2003 ou superior.
A maioria dos recursos do AD FS não exige modificações no nível funcional do AD DS para operar com êxito. No entanto, o nível funcional de domínio do Windows Server 2008 ou superior é necessário para que a autenticação de certificado do cliente opere com êxito se o certificado for explicitamente mapeado para a conta de um usuário no AD DS.
Requisitos de esquema
O AD FS não requer alterações de esquema nem modificações de nível funcional no AD DS.
Para usar a funcionalidade de Associação ao Local de Trabalho, o esquema da floresta na qual os servidores AD FS estão associados deve estar configurado para Windows Server 2012 R2.
Requisitos da conta de serviço
Qualquer conta de serviço padrão pode ser usada como uma conta de serviço para o AD FS. Também há suporte para contas de serviço gerenciado de grupo. Isso requer pelo menos um controlador de domínio (é recomendável que você implante dois ou mais) que esteja executando o Windows Server 2012 ou superior.
Para que a autenticação Kerberos funcione entre clientes ingressados no domínio e o AD FS, o 'HOST/<adfs_service_name>' precisa ser registrado como um SPN na conta de serviço. Por padrão, o AD FS configurará isso ao criar um novo farm do AD FS se ele tiver permissões suficientes para executar essa operação.
A conta de serviço do AD FS deve ser confiável em todos os domínios de usuário que contêm usuários autenticados no serviço do AD FS.
Requisitos de domínio
Todos os servidores do AD FS devem ser associados a um domínio do AD DS.
Todos os servidores do AD FS em um farm devem ser implantados em um único domínio.
O domínio ao qual os servidores do AD FS estão unidos deve confiar em cada domínio de conta de usuário que contém usuários autenticando no serviço do AD FS.
Requisitos de várias florestas
O domínio ao qual os servidores do AD FS estão unidos deve confiar em cada domínio de conta de usuário ou floresta que contenha usuários autenticando no serviço do AD FS.
A conta de serviço do AD FS deve ser confiável em todos os domínios de usuário que contêm usuários autenticados no serviço do AD FS.
Requisitos de banco de dados de configuração
Veja a seguir os requisitos e restrições que se aplicam com base no tipo de repositório de configuração:
WID
Um farm WID terá um limite de 30 servidores de federação se você tiver 100 ou menos objetos de confiança de terceira parte confiável.
Não há suporte para o perfil de resolução de artefatos no SAML 2.0 no banco de dados de configuração do WID. Não há suporte para a Detecção de Reprodução de Token no banco de dados de configuração de WID. Essa funcionalidade só é usada em cenários em que o AD FS está agindo como o provedor de federação e consumindo tokens de segurança de provedores de declarações externas.
Há suporte para a implantação de servidores do AD FS em data centers distintos para failover ou balanceamento de carga geográfico, desde que o número de servidores não exceda 30.
A tabela a seguir fornece um resumo sobre a utilização de uma fazenda WID. Use-o para planejar sua implementação.
| 1 a 100 relações de confiança de RP | Mais de 100 RP Trusts |
|---|---|
| 1 a 30 nós do AD FS: Suporte ao WID | 1 a 30 Nodos do AD FS: Não há suporte para usar WID – SQL Obrigatório |
| Mais de 30 nós do AD FS: Não é suportado com WID – SQL é necessário | Mais de 30 nós do AD FS: Não é suportado com WID – SQL é necessário |
SQL Server
Para o AD FS no Windows Server 2012 R2, você pode usar o SQL Server 2008 e superior
Requisitos de navegador
Quando a autenticação do AD FS é executada por meio de um navegador ou controle de navegador, seu navegador precisa atender aos seguintes requisitos:
O JavaScript deve estar habilitado
Os cookies devem ser ativados
A SNI (Indicação de Nome do Servidor) deve ter suporte
Para a autenticação de certificado do usuário e de certificado do dispositivo (funcionalidade de ingresso no local de trabalho), o navegador deve suportar a autenticação de certificado de cliente SSL.
Vários navegadores e plataformas de chave passaram por validação para renderização e funcionalidade dos quais os detalhes estão listados abaixo. Ainda há suporte para navegadores e dispositivos que não estão cobertos nesta tabela se atenderem aos requisitos listados acima:
| Navegadores | Plataformas |
|---|---|
| IE 10.0 | Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2 |
| IE 11.0 | Windows7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2 |
| Agente de Autenticação da Web do Windows | Windows 8.1 |
| Firefox [v21] | Windows 7, Windows 8.1 |
| Safari [v7] | iOS 6, Mac OS-X 10.7 |
| Chrome [v27] | Windows 7, Windows 8.1, Windows Server 2012, Windows Server 2012 R2, Mac OS-X 10.7 |
Importante
Problema conhecido – Firefox: a funcionalidade de Ingresso no Local de Trabalho que identifica o dispositivo usando o certificado do dispositivo não está funcional nas plataformas Windows. No momento, o Firefox não dá suporte à execução da autenticação de certificado do cliente SSL usando certificados provisionados no repositório de certificados do usuário em clientes Windows.
Cookies
O AD FS cria cookies baseados em sessão e persistentes que devem ser armazenados em computadores cliente para fornecer entrada, saída, SSO (logon único) e outras funcionalidades. Portanto, o navegador do cliente deve ser configurado para aceitar cookies. Os cookies usados para autenticação são sempre cookies de sessão HTTPS (Secure Hypertext Transfer Protocol) que são gravados para o servidor de origem. Se o navegador do cliente não estiver configurado para permitir esses cookies, o AD FS não poderá funcionar corretamente. Cookies persistentes são usados para preservar a seleção do usuário do provedor de declarações. Você pode desabilitá-los usando uma configuração no arquivo de configuração para as páginas de entrada do AD FS. O suporte para TLS/SSL é necessário por motivos de segurança.
Requisitos de extranet
Para fornecer acesso extranet ao serviço do AD FS, você deve implantar o serviço de função Proxy de Aplicativo Web como a função voltada para extranet que faz o proxy das solicitações de autenticação de maneira segura para o serviço do AD FS. Isso fornece isolamento dos pontos de extremidade de serviço do AD FS, bem como o isolamento de todas as chaves de segurança (como certificados de assinatura de token) das solicitações originadas da Internet. Além disso, recursos como o Bloqueio de Conta do Soft Extranet exigem o uso do Proxy de Aplicativo Web. Para obter mais informações sobre o Proxy de Aplicativo Web, consulte o Proxy de Aplicativo Web. `
Requisitos de rede
Configurar os seguintes serviços de rede adequadamente é fundamental para a implantação bem-sucedida do AD FS em sua organização:
Configurando o Firewall Corporativo
Tanto o firewall localizado entre o Proxy de Aplicativo Web quanto o farm de servidores de federação e o firewall entre os clientes e o Proxy de Aplicativo Web devem ter a porta TCP 443 habilitada para entrada.
Além disso, se a autenticação de certificado do usuário cliente (autenticação clientTLS usando certificados de usuário X509) for necessária, o AD FS no Windows Server 2012 R2 exigirá que a porta TCP 49443 seja habilitada para entrada no firewall entre os clientes e o Proxy de Aplicativo Web. Isso não é necessário no firewall entre o Proxy de Aplicativo Web e os servidores de federação).
Observação
Verifique também se a porta 49443 não é usada por nenhum outro serviço no AD FS e no servidor proxy de aplicativo Web.
Configurando o DNS
Para acesso à intranet, todos os clientes que acessam o serviço do AD FS na rede corporativa interna (intranet) devem ser capazes de resolver o nome do serviço do AD FS (nome fornecido pelo certificado SSL) para o balanceador de carga para os servidores do AD FS ou o servidor AD FS.
Para acesso à extranet, todos os clientes que acessam o serviço do AD FS de fora da rede corporativa (extranet/Internet) devem ser capazes de resolver o nome do serviço do AD FS (nome fornecido pelo certificado SSL) para o balanceador de carga para os servidores proxy de aplicativo Web ou o servidor Proxy de Aplicativo Web.
Para que o acesso à extranet funcione corretamente, cada servidor proxy de aplicativo Web no DMZ deve ser capaz de resolver o nome do serviço do AD FS (nome fornecido pelo certificado SSL) para o balanceador de carga para os servidores do AD FS ou o servidor AD FS. Isso pode ser feito usando um servidor DNS alternativo na rede DMZ ou alterando a resolução do servidor local usando o arquivo HOSTS.
Para que a autenticação integrada do Windows funcione dentro da rede e fora da rede para um subconjunto de pontos de extremidade expostos por meio do Proxy de Aplicativo Web, você precisa usar um registro A (não CNAME) para apontar para os balanceadores de carga.
Para obter informações sobre como configurar o DNS corporativo para o serviço de federação e o Serviço de Registro de Dispositivo, consulte Configurar o DNS Corporativo para o Serviço de Federação e DRS.
Para obter informações sobre como configurar o DNS corporativo para proxies de aplicativo Web, consulte a seção "Configurar DNS" na Etapa 1: Configurar a Infraestrutura de Proxy de Aplicativo Web.
Para obter informações sobre como configurar um endereço IP de cluster ou FQDN de cluster usando NLB, consulte Especificando os parâmetros de cluster em http://go.microsoft.com/fwlink/?LinkId=75282.
Requisitos do repositório de atributos
O AD FS requer que pelo menos um repositório de atributos seja usado para autenticar usuários e extrair declarações de segurança para esses usuários. Para obter uma lista de repositórios de atributos compatíveis com o AD FS, consulte a função de repositórios de atributos.
Observação
O AD FS cria automaticamente um repositório de atributos "Active Directory", por padrão. Os requisitos do repositório de atributos dependem se sua organização está atuando como o parceiro de conta (hospedando os usuários federados) ou o parceiro de recurso (hospedando o aplicativo federado).
Repositórios de Atributos LDAP
Quando você trabalha com outros repositórios de atributos baseados em LDAP (Lightweight Directory Access Protocol), você deve se conectar a um servidor LDAP que dê suporte à autenticação integrada do Windows. A cadeia de conexão LDAP também deve ser escrita no formato de uma URL LDAP, conforme descrito no RFC 2255.
Também é necessário que a conta de serviço do serviço do AD FS tenha o direito de recuperar informações do usuário no repositório de atributos LDAP.
Repositórios de atributos do SQL Server
Para que o AD FS no Windows Server 2012 R2 opere com êxito, os computadores que hospedam o repositório de atributos do SQL Server devem estar executando o Microsoft SQL Server 2008 ou superior. Ao trabalhar com repositórios de atributos baseados em SQL, você também deve configurar uma cadeia de conexão.
Repositórios de Atributos Personalizados
Você pode desenvolver repositórios de atributos personalizados para habilitar cenários avançados.
A linguagem de política incorporada ao AD FS pode referenciar repositórios de atributos personalizados para que qualquer um dos seguintes cenários possa ser aprimorado:
Criando declarações para um usuário autenticado localmente
Suplementar declarações para um usuário autenticado externamente
Autorizando um usuário a obter um token
Autorizar um serviço a obter um token sobre o comportamento de um usuário
Emissão de dados adicionais em tokens de segurança emitidos pelo AD FS para partes confiáveis.
Todos os repositórios de atributos personalizados devem ser criados com base no .NET 4.0 ou superior.
Ao trabalhar com um repositório de atributos personalizado, talvez você também precise configurar uma cadeia de conexão. Nesse caso, você pode inserir um código personalizado de sua escolha que habilita uma conexão com seu repositório de atributos personalizado. A cadeia de conexão nessa situação é um conjunto de pares nome/valor que são interpretados como implementados pelo desenvolvedor do repositório de atributos personalizado. Para obter mais informações sobre como desenvolver e usar repositórios de atributos personalizados, consulte a Visão geral do Repositório de Atributos.
Requisitos do aplicativo
O AD FS dá suporte a aplicativos com reconhecimento de declarações que usam os seguintes protocolos:
Web Services Federation
WS-Trust
Protocolo SAML 2.0 usando perfis IDPLite, SPLite &eGov1.5.
Perfil de concessão de autorização do OAuth 2.0
O AD FS também dá suporte à autenticação e autorização para todos os aplicativos sem reconhecimento de declarações compatíveis com o Proxy de Aplicativo Web.
Requisitos de autenticação
Autenticação do AD DS (Autenticação Primária)
Para acesso à intranet, há suporte para os seguintes mecanismos de autenticação padrão para o AD DS:
Autenticação Integrada do Windows usando Negotiate for Kerberos &NTLM
Autenticação de Formulários usando nome de usuário/senhas
Autenticação com Certificados usando certificados mapeados para contas de usuário no AD DS
Para acesso à extranet, há suporte para os seguintes mecanismos de autenticação:
Autenticação de Formulários usando nome de usuário/senhas
Autenticação com Certificados usando certificados mapeados a contas de usuário no AD DS
Autenticação Integrada do Windows usando Negotiate (somente NTLM) para pontos de extremidade WS-Trust que aceitam a Autenticação Integrada do Windows.
Para autenticação de certificado:
Estende-se a cartões inteligentes que podem ser protegidos por PIN.
A interface gráfica para que o usuário insira seu PIN não é fornecida pelo AD FS e precisa estar integrada ao sistema operacional do cliente, que é exibido ao usar o TLS de cliente.
O leitor e o CSP (provedor de serviços criptográficos) para o cartão inteligente devem funcionar no computador em que o navegador está localizado.
O certificado do cartão inteligente deve estar vinculado a uma raiz confiável em todos os servidores AD FS e nos servidores de proxy de aplicativo web.
O certificado deve ser mapeado para a conta de usuário no AD DS por qualquer um dos seguintes métodos:
O nome da entidade do certificado corresponde ao nome diferenciado LDAP de uma conta de usuário no AD DS.
A extensão do nome alternativa da entidade do certificado tem o nome UPN de uma conta de usuário no AD DS.
Para autenticação integrada contínua do Windows usando Kerberos na intranet,
É necessário que o nome do serviço faça parte dos Sites Confiáveis ou dos sites da Intranet Local.
Além disso, o HOST/<adfs_service_name> SPN deve ser definido na conta de serviço na qual o farm do AD FS é executado.
Autenticação Multifator
O AD FS dá suporte à autenticação adicional (além da autenticação primária com suporte do AD DS) usando um modelo de provedor pelo qual fornecedores/clientes podem criar seu próprio adaptador de autenticação multifator que um administrador pode registrar e usar durante o logon.
Cada adaptador MFA deve ser criado com base no .NET 4.5.
Para obter mais informações sobre mfa, consulte Gerenciar risco com autenticação multifator adicional para aplicativos confidenciais.
Autenticação de dispositivo
O AD FS dá suporte à autenticação de dispositivos usando certificados provisionados pelo Serviço de Registro de Dispositivo quando um usuário final associa seu dispositivo ao ambiente de trabalho.
Requisitos de ingresso no local de trabalho
Usuários finais podem ingressar seus dispositivos em uma organização usando o AD FS. Isso é compatível com o Serviço de Registro de Dispositivo no AD FS. Como resultado, os usuários finais obtêm o benefício adicional do SSO nos aplicativos compatíveis com o AD FS. Além disso, os administradores podem gerenciar riscos restringindo o acesso a aplicativos somente a dispositivos que ingressaram no local de trabalho da organização. Abaixo estão os requisitos a seguir para habilitar esse cenário.
O AD FS dá suporte ao ingresso no local de trabalho para dispositivos Windows 8.1 e iOS 5+
Para usar a funcionalidade Workplace Join, o esquema da floresta à qual os servidores do AD FS são ingressados deve ser o Windows Server 2012 R2.
O nome alternativo da entidade do certificado SSL para o serviço do AD FS deve conter o valor enterpriseregistration, seguido pelo sufixo UPN (nome principal do usuário) da sua organização, por exemplo, enterpriseregistration.corp.contoso.com.
Requisitos de criptografia
A tabela a seguir fornece informações adicionais de suporte de criptografia sobre a assinatura de token do AD FS, a funcionalidade de criptografia/descriptografia de token:
| Algoritmo | Comprimentos de chave | Protocolos/aplicativos/comentários |
|---|---|---|
| TripleDES – 192 padrão (com suporte 192 – 256) – http://www.w3.org/2001/04/xmlenc#tripledes-cbc | >= 192 | Algoritmo com suporte para descriptografar o token de segurança. Não há suporte para criptografar o token de segurança com esse algoritmo. |
| AES128 - http://www.w3.org/2001/04/xmlenc#aes128-cbc | 128 | Algoritmo com suporte para descriptografar o token de segurança. Não há suporte para criptografar o token de segurança com esse algoritmo. |
| AES192 - http://www.w3.org/2001/04/xmlenc#aes192-cbc | 192 | Algoritmo com suporte para descriptografar o token de segurança. Não há suporte para criptografar o token de segurança com esse algoritmo. |
| AES256 - http://www.w3.org/2001/04/xmlenc#aes256-cbc | 256 | Padrão. Algoritmo com suporte para criptografar o token de segurança. |
| TripleDESKeyWrap - http://www.w3.org/2001/04/xmlenc#kw-tripledes | Todos os tamanhos de chave compatíveis com o .NET 4.0+ | Algoritmo com suporte para criptografar a chave simétrica que criptografa um token de segurança. |
| AES128KeyWrap - http://www.w3.org/2001/04/xmlenc#kw-aes128 | 128 | Algoritmo com suporte para Criptografar a chave simétrica que criptografa o token de segurança. |
| AES192KeyWrap - http://www.w3.org/2001/04/xmlenc#kw-aes192 | 192 | Algoritmo com suporte para Criptografar a chave simétrica que criptografa o token de segurança. |
| AES256KeyWrap - http://www.w3.org/2001/04/xmlenc#kw-aes256 | 256 | Algoritmo com suporte para Criptografar a chave simétrica que criptografa o token de segurança. |
| RsaV15KeyWrap - http://www.w3.org/2001/04/xmlenc#rsa-1_5 | 1024 | Algoritmo com suporte para Criptografar a chave simétrica que criptografa o token de segurança. |
| RsaOaepKeyWrap - http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p | 1024 | Padrão. Algoritmo com suporte para Criptografar a chave simétrica que criptografa o token de segurança. |
| SHA1-http://www.w3.org/PICS/DSig/SHA1_1_0.html | Não aplicável | Usado pelo Servidor do AD FS na geração SourceId do artefato: neste cenário, o STS usa SHA1 (de acordo com a recomendação no padrão SAML 2.0) para criar um valor curto de 160 bits para o sourceiD do artefato. Também é usado pelo agente Web do AD FS (componente herdado do período WS2003) para identificar mudanças no valor de tempo da "última atualização", permitindo reconhecer quando deve atualizar as informações do STS. |
| SHA1withRSA- | Não aplicável | Usado em casos em que o Servidor AD FS valida a assinatura da solicitação de autenticação SAML, assina a solicitação ou resposta de resolução de artefato, ou cria um certificado para assinatura de tokens. Nesses casos, SHA256 é o padrão e SHA1 é usado somente se o parceiro (terceira parte confiável) não puder dar suporte a SHA256 e precisar usar SHA1. |
Requisitos de permissões
O administrador que executa a instalação e a configuração inicial do AD FS deve ter permissões de administrador de domínio no domínio local (em outras palavras, o domínio ao qual o servidor de federação está ingressado.)