Requisitos do AD FS para o Windows Server
A seguir, temos os vários requisitos com os quais você deve estar em conformidade ao implantar o AD FS:
Requisitos de certificado
Os certificados exercem a função mais crítica na proteção das comunicações entre os servidores de federação, os proxies de Aplicativo Web, os aplicativos com reconhecimento de declaração e os clientes Web. Os requisitos dos certificados variam, dependendo de você configurar um servidor de federação ou um computador proxy, conforme descrito nesta seção.
Certificados de servidores de federação
| Tipo de certificado | Requisitos, suporte e o que você deve saber |
|---|---|
| Certificado SSL (Secure Sockets Layer): este é um certificado SSL padrão usado para proteger as comunicações entre servidores de federação e clientes. | – Este 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 nos servidores da 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 com suporte pelo Windows Server 2012 R2 para certificados SSL. – Não dá suporte a certificados que usam chaves CNG. - Quando usado com o serviço Workplace Join/Registro de Dispositivo, o nome alternativo da entidade do certificado SSL para o serviço do AD FS deve conter o valor enterpriseregistration seguido pelo sufixo UPN 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 para o 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, ele precisa ser o mesmo ao dar suporte a pontos de extremidade de Autenticação Integrada do Windows por meio do Proxy de Aplicativo 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, talvez você queira considerar a escolha de um Nome da entidade em qualquer certificado emitido por uma nova AC que represente melhor o nome da sua empresa ou organização para os 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 do seu farm do AD FS, bem como todos os proxies de Aplicativo Web em seu farm do AD FS. |
| Certificado de comunicação de serviço: esse certificado habilita a segurança da mensagem WCF (Windows Communication Foundation) para proteger as comunicações entre os servidores de federação. | – Por padrão, o certificado SSL é usado como o certificado das comunicações 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 a Segurança de Mensagens do WCF. – Recomendamos que você use um certificado de autenticação de servidor emitido por uma AC (autoridade de certificação) pública (de terceiros), por exemplo, VeriSign. – 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 autenticação de tokens: este é um certificado X509 padrão usado para autenticar 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. – Também há suporte para certificados emitidos pela AC, e podem ser alterados usando o complemento de gerenciamento do AD FS – 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 os 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 a organização tiver políticas que exigem que certificados diferentes sejam 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ê poderá 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 nem a substituição automática dos certificados. Esse processo precisa ser executado por um administrador. Para permitir a substituição do 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 autenticação de tokens são publicados nos metadados de federação, mas apenas o certificado de autenticação de tokens principal é usado pelo AD FS para realmente autenticar tokens. |
| Certificado de criptografia/descriptografia de tokens: esse é um certificado X509 padrão usado para descriptografar/criptografar tokens 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. – Também há suporte para certificados emitidos pela AC, e podem ser alterados usando o complemento de gerenciamento do AD FS – 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 os 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 a organização tiver políticas que exigem 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 descriptografar de token, o AD FS não executa a renovação automática dos certificados. Esse processo precisa 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. Clientes que gerenciam seus próprios certificados de assinatura de token e descriptografia/criptografia de token deverão garantir que o backup desses certificados seja feito e que estejam disponíveis de forma independente durante um evento de recuperação.
Observação
No AD FS, você poderá alterar o nível de SHA (Secure Hash Algorithm) usado para assinaturas digitais para SHA-1 ou SHA-256 (mais seguro). O AD FS não dá suporte para 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 melhor prática de segurança, recomendamos que você use o SHA-256 (que é definido por padrão) em todas as assinaturas. O SHA-1 é recomendado apenas para uso em situações 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, certifique-se de que todos os certificados sejam importados para o repositório de certificados pessoais do computador local. Você pode importar certificados para o repositório pessoal com o snap-in do 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 | Quatro núcleos, 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 do 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 do Proxy de Aplicativo Web não podem ser instalados no mesmo computador.
Requisitos de AD DS
Requisitos de controlador de domínio
Controladores de domínio em todos os domínios de usuário e o domínio ao qual os servidores do AD FS sã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 o Windows Server 2003. Recomendamos enfaticamente que os clientes atualizem seus controladores de domínio o mais rápido possível. Acesse esta página para obter informações adicionais sobre o Ciclo de Vida de Suporte da Microsoft. Para problemas descobertos específicos para ambientes de controlador de domínio do Windows Server 2003, 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 no qual os servidores AD FS são ingressados devem estar operando no nível funcional do domínio do Windows Server 2003 ou posterior.
A maioria dos recursos do AD FS não exigem modificações de nível funcional no AD DS para que funcionem bem. No entanto, o nível funcional do domínio do Windows Server 2008 ou superior é exigido para que a autenticação de certificados de clientes funcione bem, caso o certificado esteja associado explicitamente à conta de usuário do AD DS.
Requisitos de esquema
O AD FS não exige alterações de esquema nem modificações de nível funcional para o AD DS.
Para usar a funcionalidade Workplace Join, o esquema da floresta à qual os servidores do AD FS são ingressados deve ser definido como o Windows Server 2012 R2.
Requisitos de 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 do serviço gerenciado de grupo. Isso requer pelo menos um controlador de domínio (é recomendável implantar 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 farm do AD FS se ele tiver permissões suficientes para executar essa operação.
A conta de serviço do AD FS precisa ser de confiança em todos os domínios que contenham usuários que se autenticam no serviço do AD FS.
Requisitos de Domínio
Todos os servidores AD FS devem ser ingressados em um domínio do AD DS.
Todos os servidores AD FS em um farm devem ser implantados em um só domínio.
O domínio no qual os servidores AD FS são ingressados precisa confiar em todos os domínios de conta do usuário que contenham usuários que se autenticam no serviço do AD FS.
Requisitos de várias florestas
O domínio no qual os servidores AD FS são ingressados precisa confiar em todos os domínios de conta do usuário ou florestas que contenham usuários que se autenticam no serviço do AD FS.
A conta de serviço do AD FS precisa ser de confiança em todos os domínios que contenham usuários que se autenticam no serviço do AD FS.
Requisitos de banco de dados de configuração
Estes são os requisitos e as 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 Detecção de Reprodução de Token no banco de dados de configuração do WID. Essa funcionalidade é usada apenas 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 externos.
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 para usar um farm WID. Use-o para planejar sua implementação.
| 1 a 100 relações de confiança de RP | Mais de 100 relações de confiança de RP |
|---|---|
| 1 a 30 nós do AD FS: Suporte ao WID | 1 a 30 nós do AD FS: Sem suporte para uso do WID – O SQL é exigido |
| Mais de 30 Nós do AD FS: Sem suporte para uso do WID – O SQL é exigido | Mais de 30 Nós do AD FS: Sem suporte para uso do WID – O SQL é exigido |
SQL Server
Para o AD FS no Windows Server 2012 R2, você pode usar 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 deve atender aos seguintes requisitos:
O JavaScript deve estar habilitado
Os cookies devem ser ativados
É necessário ter suporte para SNI (Indicação de Nome de Servidor)
Para a autenticação de certificado do usuário e do dispositivo(funcionalidade Workplace Join), o navegador deve dar suporte à autenticação de certificado de cliente SSL
Vários navegadores e plataformas importantes passaram por validação de renderização e funcionalidade, cujos detalhes estão listados abaixo. Navegadores e dispositivos que não são abordados nesta tabela ainda terão suporte 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 do Workplace Join que identifica o dispositivo usando o certificado do dispositivo não está funcional em 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 persistentes e baseados na sessão que devem ser armazenados nos computadores cliente para fornecer conexão, saída do serviço, SSO (logon único) e outras funcionalidades. Portanto, o navegador do cliente deve estar 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 criados 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. Os cookies persistentes são usados para preservar a seleção de usuário do provedor de declarações. Você pode desabilitá-los usando uma definição de configuração do arquivo de configuração das páginas de conexão do AD FS. Por motivos de segurança, é exigido o suporte a TLS/SSL.
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 Reversível da Extranet exigem o uso do Proxy de Aplicativo Web. Para obter mais informações gerais sobre Proxy de Aplicativo Web, consulte Proxy de Aplicativo Web. `
Requisitos de rede
Configurar os seguintes serviços de rede corretamente é essencial para a implantação bem-sucedida do AD FS na sua organização:
Configurando o Firewall Corporativo
O firewall localizado entre o Proxy de Aplicativo Web e o farm de servidores de federação e o firewall entre os clientes e o Proxy de Aplicativo Web deve ter a porta TCP 443 habilitada para entrada.
Além disso, se a autenticação de certificado de usuário cliente (autenticação clientTLS que usa 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 servidor do AD FS e do Proxy de Aplicativo Web.
Configuração do 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 AD FS ou o servidor AD FS.
Para acesso à extranet, é necessário que todos os clientes que acessam o serviço do AD FS de fora da rede corporativa (extranet/internet) possam resolver o nome de serviço do AD FS (nome fornecido pelo certificado SSL) para o balanceador de carga dos servidores do Proxy de aplicativo Web ou do servidor do Proxy de Aplicativo Web.
Para que o acesso à extranet funcione corretamente, cada servidor Proxy de Aplicativo Web no DMZ deve poder resolver o nome do serviço do AD FS (nome fornecido pelo certificado SSL) para o balanceador de carga dos servidores AD FS ou do servidor AD FS. Isso pode ser feito usando um servidor DNS alternativo na rede DMZ ou alterando a resolução do servidor local que usa 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 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" em Etapa 1: Configurar a Infraestrutura de Proxy de Aplicativo Web.
Para obter mais informações sobre como configurar um endereço IP ou um FQDN de cluster usando o NLB, confira Como especificar os parâmetros de cluster em http://go.microsoft.com/fwlink/?LinkId=75282.
Requisitos de repositório de atributos
O AD FS exige 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 com suporte pelo AD FS, consulte A função dos repositórios de atributos.
Observação
Por padrão, o AD FS cria automaticamente um repositório de atributos do "Active Directory". Os requisitos de repositório de atributos dependem de sua organização estar agindo como parceiro de conta (hospedando os usuários federados) ou parceiro de recurso (hospedando o aplicativo federado).
Repositórios de Atributos de LDAP
Quando você trabalha com outros repositórios de atributos baseados no protocolo LDAP, você deve estabelecer conexão com um servidor LDAP que suporte a autenticação integrada do Windows. A cadeia de conexão LDAP também deve ser escrita no formato de uma URL LDAP, como 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 SQL Server precisam estar executando o Microsoft SQL Server 2008 ou superior. Quando trabalha 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 da política interna do AD FS pode referenciar repositórios de atributos personalizados para que qualquer um dos seguintes cenários seja aprimorado:
Criar declaração para um usuário autenticado localmente
Suplementar declarações para um usuário autenticado externamente
Autorizar 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 terceiros confiáveis.
Todos os repositórios de atributos personalizados devem ser criados com base no .NET 4.0 ou superior.
Quando você trabalha com um repositório de atributos personalizado, você também pode precisar configurar uma cadeia de conexão. Nesse caso, você pode inserir um código personalizado de sua escolha que permite uma conexão com o repositório de atributos personalizado. A cadeia de conexão nessa situação é um conjunto de pares nome/valor 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 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:
O certificado do provedor de identidade do Web Services Federation
WS-Trust
Protocolo SAML 2.0 usando os perfis IDPLite, SPLite e eGov1.5.
Perfil de Concessão de Autorização de 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 para Kerberos e NTLM
Autenticação de Formulários usando nome de usuário/senhas
Autenticação de Certificado 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 de Certificado usando certificados mapeados para 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 GUI para o usuário inserir o PIN não é fornecida pelo AD FS e precisa fazer parte do sistema operacional cliente que é exibido ao usar o TLS do cliente.
O leitor e o CSP (provedor de serviços de criptografia) do cartão inteligente devem funcionar no computador onde o navegador está localizado.
O certificado de cartão inteligente deve ser encadeado a uma raiz confiável em todos os servidores do AD FS e servidores do Proxy de Aplicativo Web.
O certificado deve ser associado à conta de usuário no AD DS por 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 SPN HOST/<adfs_service_name> 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 segundo o qual fornecedores/clientes podem criar o próprio adaptador de autenticação multifator que um administrador pode registrar e usar durante o logon.
Cada adaptador de MFA deve ser criado com base no .NET 4.5.
Para obter mais informações sobre a MFA, consulte Manage Risk with Additional Multi-Factor Authentication for Sensitive Applications.
Autenticação de dispositivo
O AD FS dá suporte à autenticação de dispositivo usando certificados provisionados pelo Serviço de Registro de Dispositivo durante o ato de um usuário final ingressar no dispositivo dele.
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 têm o benefício adicional do SSO entre os 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 serem seguidos 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 | Aplicativos/protocolos/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 | Default. 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/D | Usado pelo Servidor do AD FS na geração SourceId do artefato: nesse 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 a sourceiD do artefato. Também usado pelo agente Web do AD FS (componente herdado do período WS2003) para identificar alterações em um valor de hora da "última atualização" para que ele saiba quando atualizar informações do STS. |
| SHA1withRSA- | N/D | Usado em casos em que o Servidor do AD FS valida a assinatura da AuthenticationRequest SAML, assina a solicitação ou resposta de resolução de artefato, cria um certificado de assinatura de token. Nesses casos, SHA256 é o padrão e SHA1 só será usado se o parceiro (terceiro 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 (ou seja, o domínio ao qual o servidor de federação está ingressado.)