Active Directory para autenticação na Web: escala para usuários de 1 milhão?

Question

Estou interessado em quão bem o Active Directory seria o back-end de autenticação de um site, dimensionado para ~ 1 milhão de usuários. Você tem experiência com o AD em ambientes web dessa escala e, em caso afirmativo, qual o nível de hardware necessário?

[Update] Com relação à frequência do login: concordo que esse é um fator-chave, mas ainda não temos essas informações. Suponha uma configuração regular de comércio / site bancário: faça login por meio de um formulário uma vez, carregue sua identidade em uma sessão (ou seja, sem chamadas de autenticação para o AD em páginas diferentes da página de login).

O AD não armazenará uma quantidade significativa de informações do usuário além do necessário para autenticação.

• Quão ocupado você está esperando que o site seja : Assuma um site comercial / bancário normal. Nenhuma informação adicional sobre isso.

• Este anúncio será particionado : Pode ser, embora a arquitetura mais simples seja a preferida.

• Este anúncio servirá qualquer outra coisa : Não.

• Quão complicada será a estrutura da sua UO

• Você estenderá o esquema: O esquema padrão será usado. A estrutura da UO será bastante simples.

• Você realizará muitas pesquisas sobre ele : apenas para pesquisar nome de usuário / email para uma ligação subsequente.

• Você armazenará muitas informações contra os Objetos do Usuário : Não

• Intercâmbio será envolvido com este AD : Não

Answer 1

Você poderia? Sim. Você deveria? Não.

Primeiro, a carga de escalonamento - os usuários de 1 milhão com uma média de 1 login por segundo são muito diferentes dos usuários de 1 milhão, com uma média de 100 a 1.000 logins por segundo.

Apenas algumas considerações gerais sobre isso - Embora tecnicamente isso possa ser feito, não sei se o Active Directory seria o veículo ideal para armazenar todos os usuários em um único domínio. Se você usasse isso para seu aplicativo da Web e começasse a ter problemas de desempenho, seria muito difícil solucionar problemas. Pessoalmente, para algo que dê suporte aos usuários do 1M, ele realmente precisa ser algo mais dedicado a essa tarefa específica.

Se este é o benchmark que você precisa atingir e você realmente quer usar o AD, você provavelmente precisará envolver a Microsoft para garantir que sua arquitetura esteja absolutamente correta e tenha seu teste de carga / desempenho no mínimo.

A quantidade de "outras coisas" que o Active Directory faz e introduz (camadas, replicação, extensões, preocupações de segurança das contas no seu domínio de "produção") quando você só precisa delas para um banco de dados de autenticação é, IMHO, não é apropriado para a quantidade de usuários e a relativa simplicidade necessária. Muito exagerado e complexo.

    

Answer 2

Você pode usar o AD para isso. Mas eu recomendo que você vá com o ADAM (ou "AD LDS" é chamado agora). Deve dar-lhe muitos dos benefícios do AD, ou seja, conhecimento técnico pré-existente e coisas como FRS para replicação. Se os benefícios do AD para isso são baixos em sua lista de "profissionais", você deve realmente considerar um pacote LDAP diferente, como o Siteminder, embora isso requeira reunir mais componentes de tecnologia para construir um sistema escalável.

O maior problema de desempenho que você precisa analisar são as solicitações de logon simultâneas, como muitos pôsteres indicaram. A maneira mais fácil de contornar isso é construir seus controladores de domínio em hardware de 64 bits e certificar-se de que seu controlador de domínio tenha RAM suficiente para armazenar todo o arquivo .dit. Isso melhorará significativamente seu desempenho, pois eliminará completamente a paginação durante o processamento de consultas LDAP. Você poderia ir com o hardware de 32 bits do seu arquivo .dit é inferior a 1,5 GB, mas por que se preocupar?

Além disso, se você estiver procurando por algum tipo de alta disponibilidade, esteja ciente de que a replicação e o reconhecimento do site no AD não são realmente projetados para fornecer isso no nível que você pode precisar para um aplicativo comercial. Você precisará estar ciente das limitações de localizar um controlador de domínio e gravar seus aplicativos para usar a API do Windows para lidar corretamente com os CDs offline / não disponíveis. Eu vejo este problema muito, onde um aplicativo dev apenas aponta seu pacote de autenticação LDAP em fqdn.ad.domain, mas esse endereço é apenas um round-robin simples e não será atualizado se você colocar um DC off-line.

    

Answer 3

Geralmente, você deve usar o AD-LDS (ADAM) para usuários do aplicativo. Não há uma taxa de licenciamento e os usuários do LDS não podem ser usados como credenciais de segurança para os próprios servidores. Isto é uma coisa boa. Se o seu diretório de usuários estiver comprometido, seu diretório operacional ainda estará funcional.

VOCÊ DEVE usar o AD para gerenciar as máquinas. Verifique se não há contas locais, use a política de grupo para restringir as configurações de segurança. (Eu acho que a maioria das pessoas ficaria surpreso com o quão apertado isso pode ser.)

Estes incluem:

• Usando o IPSEC para garantir que o NTLM sempre transite com criptografia.
• Desativando credenciais em cache.
• Aplique algoritmos de criptografia de maior intensidade no Kerberos.
• Em branco, liste os aplicativos que são executados nos servidores com as políticas do Applocker / Software Restriction, caso você precise usar uma instalação completa. Tente usar o núcleo do servidor. (Pelo menos tente ... é tudo o que estou dizendo.)

A verdade é ... se este é um novo sistema. O LDS seria um ótimo lugar para colocar seus usuários. Ele tem uma ótima política de senhas, complexidade de senhas, blá blá blá ... Você deveria estar realmente usando o SAML ou o OpenID ... Se você tem uma mistura de usuários que federam e usuários que não devem ainda codificar as reivindicações modelar e abstrair o código específico do provedor de autenticação.

    

Answer 4

Eu não quero levar isso em uma direção que você já considerou ou rejeitou por outros motivos, mas o que o AD lhe dará de que algo como o RADIUS não o fará? Provavelmente você poderia facilmente configurar um servidor RADIUS escalável e eu acho que já vi alguns que usarão um banco de dados como o MySQL para um backend, permitindo que você dimensione e replique facilmente sem os recursos adicionais que AD lhe daria que você soou como se você não fosse usar. O RADIUS foi feito apenas para tarefas de autenticação ... mas sinta-se à vontade para me corrigir nos comentários ...

Nós costumávamos usá-lo para usuários de acesso discado em algumas empresas em que eu trabalhei há muitas luas atrás, não tentei com autenticação na web.

    

Answer 5

Esta nota afirma que mesmo o Windows Server 2000 antigo estava executando 2.376 com base em LDAP buscas completas por segundo em um diretório de 5 milhões de objetos. E eles tinham hardware bastante simples para seus testes.

De qualquer forma, acho que o AD é a melhor solução para autenticação confiável, porque é muito escalável (você pode ter controladores de domínio, tanto quanto você precisa e onde você precisa), seguro. Ele foi projetado para autenticação e gerenciamento de contas e agora está bastante maduro em sua evolução.

Eu não sei sobre o licenciamento, mas acho que você não precisa ter CALs para os usuários, se você usar o AD somente para autenticação. Mas acho que você precisa consultar o MSFS para o seu cenário específico.

    

Answer 6

O número de usuários é bastante irrelevante em comparação com o número de usuários que você atende ao mesmo tempo. Se você tivesse um milhão de usuários, mas tivesse apenas um login por dia, não precisaria de muito hardware. Também depende de como você está fazendo a autenticação. Se você estiver usando a autenticação HTTP, provavelmente terá que fazer uma pesquisa a cada solicitação. Se, no entanto, você usar um formulário HTML, poderá fazer a pesquisa em uma solicitação de login e retornar um cookie para as solicitações a seguir, o que significa que você realiza muito menos pesquisas de autenticação.

Você gostaria de ver como a AD se expande; quantos servidores você pode ter solicitações de serviço antes que a replicação se torne um problema, seja manutenção ou produzindo retornos decrescentes, adicionando mais.

Além disso, você pode adicionar armazenamento em cache para acelerar suas pesquisas. Isso seria muito mais importante para a configuração de autenticação HTTP.

    

Answer 7

Não esqueça o licenciamento. Você deve obter um conector externo do Windows Server , já que as 1M CALs seriam muito caras.

A Senhora do Licenciamento da Microsoft ajuda a explicar o que é um usuário externo .

    

Answer 8

Falta muito detalhe na sua pergunta:

1. Quão ocupado você está esperando que o site seja
2. Este anúncio será particionado
3. Este anúncio estará servindo qualquer outra coisa
4. Quão complicada será sua estrutura de UO
5. Você realizará muitas pesquisas sobre ele
6. Você estenderá o esquema
7. Você armazenará muitas informações em relação aos objetos do usuário
8. A troca será envolvida com este anúncio

Muitas informações de que precisamos, antes de podermos fazer um julgamento sobre os requisitos de hardware.

    

Answer 9

Não sei se o artigo sobre Dimensionando o Active Directory com o Commerce Server contém qualquer dicas e dicas genéricas de dimensionamento do AD. Pode valer a pena navegar rapidamente?

    

Answer 10

Se isso for apenas para autenticar usuários externos - por que incomodar com o AD?

    

Answer 11

Com base nas suas edições da pergunta, o AD deve funcionar bem. Você pode querer usar pequenas sub-redes para poder particionar grupos de servidores web e DCs em sites para que você não possa trocar acidentalmente um único servidor com todas as suas autenticações.

Por outro lado, você está deixando muitas funcionalidades na mesa, como outros já disseram, e você pode estar melhor com a autenticação baseada em formulários voltando a um banco de dados. Eu acredito que a pilha MSFT vem com controles razoavelmente ricos para fazer exatamente isso.

Exagerar, mas apenas funciona, vs. Nunca uma pergunta fácil.