Compartilhar via

Farm de servidores de federação do AD FS herdado com o SQL Server

Essa topologia do AD FS (Serviços de Federação do Active Directory) é diferente do farm de servidores de federação que usa a topologia de implantação do WID (Banco de Dados Interno do Windows), pois não replica os dados para cada servidor de federação do farm. Em vez disso, todos os servidores de federação no farm podem ler e gravar dados em um banco de dados comum armazenado em um servidor que executa o Microsoft SQL Server que está localizado na rede corporativa.

Important

Se você quiser criar um farm do AD FS e usar o SQL Server para armazenar seus dados de configuração, poderá usar o SQL Server 2008 e versões mais recentes, incluindo o SQL Server 2012 e o SQL Server 2014.

Considerações de implantação

Esta seção descreve várias considerações sobre o público-alvo, benefícios e limitações pretendidos associados a essa topologia de implantação.

Quem deve usar essa topologia?

  • Grandes organizações com mais de 100 relações de confiança que precisam fornecer aos usuários internos e usuários externos acesso de SSO (logon único) a aplicativos ou serviços federados

  • Organizações que já usam o SQL Server e desejam aproveitar suas ferramentas e conhecimentos existentes

Quais são os benefícios de usar essa topologia?

  • Suporte para um número maior de relações de confiança (mais de 100)

  • Suporte para detecção de reprodução de token (um recurso de segurança) e resolução de artefatos (parte do protocolo SAML (Security Assertion Markup Language) 2.0)

  • Suporte para os benefícios completos do SQL Server, como espelhamento de banco de dados, clustering de failover, relatórios e ferramentas de gerenciamento

Quais são as limitações do uso dessa topologia?

  • Essa topologia não fornece redundância de banco de dados por padrão. Embora um farm de servidores de federação com a topologia do WID replique automaticamente o banco de dados do WID em cada servidor de federação do farm, a topologia do farm de servidores de federação com o SQL Server contém apenas uma cópia do banco de dados

    Note

    O SQL Server dá suporte a muitas opções diferentes de redundância de dados e aplicativos, incluindo clustering de failover, espelhamento de banco de dados e vários tipos diferentes de replicação do SQL Server.

O departamento de TI (Tecnologia da Informação) da Microsoft usa o espelhamento de banco de dados do SQL Server no modo de alta segurança (síncrono) e o clustering de failover para fornecer suporte de alta disponibilidade para a instância do SQL Server. As replicações transacional (de ponto a ponto) e de mesclagem do SQL Server não foram testadas pela equipe de produto do AD FS da Microsoft. Para obter mais informações sobre o SQL Server, consulte a visão geral de soluções de alta disponibilidade ou a seleção do tipo apropriado de replicação.

Versões do SQL Server com suporte

As seguintes versões do SQL Server têm suporte com o AD FS no Windows Server 2012 R2:

  • SQL Server 2008 /R2

  • SQL Server 2012

  • SQL Server 2014

Recomendações de posicionamento do servidor e layout de rede

Semelhante ao farm de servidores de federação com a topologia do WID, todos os servidores de federação do farm são configurados para usar um nome DNS (Serviço de Nomes de Domínio) de cluster (que representa o nome do Serviço de Federação) e um endereço IP de cluster como parte da configuração do cluster NLB (Balanceamento de Carga de Rede). Isso ajuda o host NLB a alocar solicitações de cliente aos servidores de federação individuais. Os proxies do servidor de federação podem ser usados para as solicitações de cliente proxy para o farm de servidores de federação.

A ilustração a seguir mostra como a empresa fictícia Contoso Pharmaceuticals implantou seu farm de servidores de federação com a topologia do SQL Server na rede corporativa. Ele também mostra como essa empresa configurou a rede de perímetro com acesso a um servidor DNS, um host NLB adicional que usa o mesmo nome DNS de cluster (fs.contoso.com) usado no cluster NLB de rede corporativa e com dois proxies de aplicativo Web (wap1 e wap2).

Ilustração que mostra como a empresa fictícia Contoso Pharmaceuticals implantou seu farm de servidores de federação com a topologia do SQL Server na rede corporativa.

Para obter mais informações sobre como configurar seu ambiente de rede para uso com servidores de federação ou proxies de aplicativo Web, consulte a seção "Requisitos de resolução de nomes" nos Requisitos do AD FS e planeje a WAP (Infraestrutura de Proxy de Aplicativo Web).

Opções de alta disponibilidade para farms de SQL Server

No Windows Server 2012 R2, há duas novas opções no AD FS para dar suporte à alta disponibilidade em farms do AD FS usando o SQL Server.

  • Suporte para grupos de disponibilidade AlwaysOn do SQL Server

  • Suporte para alta disponibilidade distribuída geograficamente usando replicação de mesclagem do SQL Server

Esta seção descreve cada uma dessas opções, quais problemas elas resolvem respectivamente e algumas considerações importantes para decidir quais opções implantar.

Note

Os farms do AD FS que usam WID (Banco de Dados Interno do Windows) fornecem redundância de dados básica com acesso de leitura/gravação no nó do servidor de federação primário e acesso somente leitura em nós secundários.  Isso pode ser usado em uma topologia geograficamente local ou geograficamente distribuída.

Ao usar o WID, lembre-se das seguintes limitações:

  • 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.
  • Um farm WID não dá suporte à detecção de reprodução de token nem à resolução de artefatos (parte do protocolo SAML, Security Assertion Markup Language).

A tabela a seguir fornece um resumo para o uso de uma fazenda WID:

1 a 100 relações de confiança de RP Mais de 100 Trusts 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: Não é suportado com WID – SQL é necessário Mais de 30 nós do AD FS: Não é suportado com WID – SQL é necessário

Grupos de Disponibilidade AlwaysOn

Overview

Os grupos de disponibilidade AlwaysOn foram introduzidos no SQL Server 2012 e fornecem uma nova maneira de criar uma instância do SQL Server de alta disponibilidade.  Os grupos de disponibilidade AlwaysOn combinam elementos de clustering e espelhamento de banco de dados para redundância e failover na camada da instância do SQL e na camada do banco de dados.  Ao contrário das opções de alta disponibilidade anteriores, os grupos de disponibilidade AlwaysOn não exigem um armazenamento comum (ou rede de área de armazenamento) na camada de banco de dados.

Um grupo de disponibilidade é composto por uma réplica primária (um conjunto de bancos de dados primários de leitura/gravação) e de uma a quatro réplicas de disponibilidade (conjuntos de bancos de dados secundários correspondentes).  O grupo de disponibilidade dá suporte a uma única cópia de leitura/gravação (a réplica primária) e uma a quatro réplicas de disponibilidade somente leitura.  Cada réplica de disponibilidade deve residir em um nó diferente de um único cluster do WSFC (Windows Server Failover Clustering).  Para obter mais informações sobre grupos de disponibilidade AlwaysOn, consulte Visão geral dos Grupos de Disponibilidade AlwaysOn (SQL Server).

Da perspectiva dos nós de um farm de SQL Server do AD FS, o grupo disponibilidade AlwaysOn substitui a única instância do SQL Server como o banco de dados de política/artefato.  O ouvinte do grupo de disponibilidade é o que o cliente (o serviço de token de segurança do AD FS) usa para se conectar ao SQL.

O diagrama a seguir mostra um AD FS SQL Server Farm com o grupo de disponibilidade AlwaysOn.

Diagrama que mostra um AD FS SQL Server Farm com o grupo de disponibilidade AlwaysOn.

Note

Os grupos de disponibilidade AlwaysOn exigem que as instâncias de SQL Server residam em nós WSFC (Clustering de failover do Windows Server).

Note

Apenas uma réplica de disponibilidade pode atuar como um destino de failover automático, as outras três dependerão de failovers manuais.

Principais considerações sobre implantação

Se você planeja usar grupos de disponibilidade AlwaysOn em combinação com a replicação de mesclagem do SQL Server, anote os problemas descritos em "Considerações chave para implantação ao usar o AD FS com a Replicação de Mesclagem do SQL Server" abaixo.  Em particular, quando um grupo de disponibilidade AlwaysOn contendo um banco de dados que é um assinante de replicação executar failover, a assinatura de replicação apresentará falha. Para retomar a replicação, um administrador de replicação deve reconfigurar manualmente o assinante.  Consulte a descrição do SQL Server sobre o problema específico em Assinantes de Replicação e Grupos de Disponibilidade AlwaysOn (SQL Server) e as declarações gerais de suporte para grupos de disponibilidade AlwaysOn com opções de replicação em Replicação, Controle de Alterações, Captura de Dados de Alterações e Grupos de Disponibilidade AlwaysOn (SQL Server).

Configurando o AD FS para usar um grupo de disponibilidade AlwaysOn

Configurar um farm do AD FS com grupos de disponibilidade AlwaysOn requer uma pequena modificação no procedimento de implantação do AD FS:

  1. Os bancos de dados que você deseja fazer backup devem ser criados antes que os grupos de disponibilidade AlwaysOn possam ser configurados.  O AD FS cria seus bancos de dados como parte da preparação e da configuração inicial do primeiro nó de serviço de federação de uma nova farm de servidores SQL do AD FS.  Como parte da configuração do AD FS, você deve especificar uma cadeia de conexão SQL, portanto, você precisará configurar o primeiro nó de farm do AD FS para se conectar diretamente a uma instância do SQL (isso é apenas temporário).   Para obter diretrizes específicas sobre como configurar um farm do AD FS, incluindo a configuração de um nó de farm do AD FS com uma cadeia de conexão do SQL Server, consulte Configurar um servidor de federação.

  2. Depois que os bancos de dados do AD FS tiverem sido criados, atribua-os a grupos de disponibilidade AlwaysOn e crie o ouvinte TCPIP comum usando as ferramentas do SQL Server e o processo na Criação e Configuração de Grupos de Disponibilidade (SQL Server).

  3. Por fim, use o PowerShell para editar as propriedades do AD FS e atualizar a cadeia de conexão SQL para usar o endereço DNS do listener do grupo de disponibilidade AlwaysOn.

    Exemplo de comandos PSH para atualizar a cadeia de conexão SQL para o banco de dados de configuração do AD FS:

    PS:\>$temp= Get-WmiObject -namespace root/ADFS -class SecurityTokenService
PS:\>$temp.ConfigurationdatabaseConnectionstring="data source=<SQLCluster\SQLInstance>; initial catalog=adfsconfiguration;integrated security=true"
PS:\>$temp.put()

  4. Exemplo de comandos PSH para atualizar a cadeia de conexão SQL para o banco de dados do serviço de resolução de artefatos do AD FS:

    PS:\> Set-AdfsProperties –artifactdbconnection "Data source=<SQLCluster\SQLInstance >;Initial Catalog=AdfsArtifactStore;Integrated Security=True"

Replicação de mesclagem do SQL Server

Também introduzida no SQL Server 2012, a replicação de mesclagem permite a redundância de dados de política do AD FS com as seguintes características:

  • Capacidade de leitura e gravação em todos os nós (não apenas no primário)

  • Quantidades menores de dados replicadas de forma assíncrona para evitar a introdução da latência ao sistema

O diagrama a seguir mostra farms de SQL Server do AD FS geograficamente redundantes com replicação de mesclagem (1 editor, 2 assinantes):

farm de servidores que usa o SQL

Principais considerações de implantação para usar o AD FS com replicação de mesclagem do SQL Server (anote os números no diagrama acima)

Para obter instruções mais detalhadas sobre como configurar o AD FS para usar uma replicação de mesclagem do SQL Server, consulte Configuração de redundância geográfica com replicação do SQL Server.

Consulte Também

Planeje sua topologia de implantação do AD FSGuia de Design do AD FS no Windows Server 2012 R2

  • Last updated on