Implantação gigante de diretório ativo versus gigante Sun LDAP

7

No trabalho, estamos nas fases iniciais de um projeto de gerenciamento de identidade. Isso tudo é no contexto do ensino superior, onde temos um casal de professores / funcionários e cerca de vinte mil alunos.

Alguém usou o servidor LDAP da Sun com um domínio do AD (kerberos realm) para armazenamento de senhas? Alguém já executou um domínio do AD com um quarto de milhão de entradas antes?

Uma opção que temos para nosso gerenciamento de identidade é enviar a equipe ativa para o AD e outra cópia das informações de senha / identidade para o LDAP. Precisamos ter um local central para alterar as senhas, se fizermos isso, de modo que, se você alterar sua senha do AD (ou ldap), as alterações sejam sincronizadas com as outras (ou elas poderão divergir)

A outra opção é ter o AD como autoridade única em senhas e, depois, teremos diretores para todos os afiliados (assim como todos os afiliados antigos) por uma década ou duas, para que possamos ter um quarto de milhão de entidades no AD , dos quais apenas 20-30k seria acessado com qualquer freqüência.

AD explodiria sob a carga? Existem outras maneiras de manter as senhas entre o LDAP da Sun e o AD sincronizado? Quais são as experiências de outras pessoas?

    
por chris 01.09.2009 / 21:08

4 respostas

4

Este é um bom lugar para começar: link .

Esta ferramenta está bastante desatualizada (foi criada para Windows 2000 e só sabe sobre CPUs de < 1 Ghz), mas ainda diz que 3-4 DCs serão mais do que suficientes para 500.000 usuários, dos quais 50.000 são ativos diariamente. Eu não acho que você deveria ter algum problema em gerenciar tal banco de dados com o hardware de hoje.

    
por 01.09.2009 / 21:24
5

Trabalho com clientes de alto nível o tempo todo discutindo exatamente o cenário que você está investigando.

O AD não terá nenhum problema com muitos objetos. Eu trabalhei em ambientes de clientes que têm vários múltiplos disso.

Muitos dos clientes com quem trabalho no seu cenário acabam desabilitando as alterações de senha nativamente por meio do AD e forçando as pessoas por um tipo de portal que fala com uma ferramenta que alimenta a senha em todos os sistemas que precisam de uma cópia de. Isso está bem, a menos que quebre e as coisas fiquem fora de sincronia. Eu também trabalhei com o cenário do Curb e, enquanto ele funciona, não é algo que muitas pessoas saibam como executar ou apoiar, então você provavelmente está pedindo problemas lá em termos de pessoal operacional.

Você também pode procurar algo como o ILM da Microsoft, que capturará alterações de senha no AD e permitirá que você as encaminhe para outros sistemas (por exemplo, Sun LDAP, etc). Isso permite que as pessoas usem a funcionalidade de alteração de senha nativa no AD em vez de um aplicativo interno.

Ter pessoas com afiliações como ex-alunos, inscrição, comunidade, etc. está bem. A única coisa que chamo a atenção das pessoas é ter em mente que as permissões padrão como Todos / Usuários Autenticados lançam uma rede muito mais ampla, então você precisa ACL coisas com grupos que representam afiliações que representam os usuários reais que você deseja permitir (por exemplo estudantes, professores, funcionários, etc). Eu também tento fazer com que as pessoas limpem contas regularmente para pessoas afiliadas a aplicativos.

Em geral, eu insisto muito para não ter diretórios LDAP paralelos. É realmente um desperdício de tempo e dinheiro, em geral, ter dois (ou mais) serviços fazendo a mesma coisa.

    
por 05.09.2009 / 23:59
2

Would AD explode under the load?

Eu era um desenvolvedor de portal ASP.NET para mais de 80 escolas vocacionais online / terrestres, principalmente nos EUA, com mais de 250.000 objetos AD e provavelmente com um uso de conta ativo na área de 60k ( ao meu conhecimento ). Eu nunca vi nenhum problema de produção com o AD. Tenha em mente que também tínhamos o segundo maior objeto Exchange / AD do mundo na época. O AD pode manter-se sob carga quando adequadamente projetado e configurado para isso. Eu costumava ser cético em relação ao AD da Microsoft ou como costumava pensar nele como M $ LDAP, mas parece razoavelmente estável, confiável se configurado para seu caso de uso / ambiente.

Are there other ways to keep the passwords between Sun's LDAP and AD synchronized?

Eu não posso falar pelo LDAP da Sun nem pela sincronização. A replicação do AD (por si só) foi confiável e oportuna. Em achamos que tivemos um total entre 4 e 6 servidores de AD e não consigo me lembrar de um único problema.

Você já está implementando o AD e procurando anexar o Sun LDAP ou o contrário? Talvez seja melhor ficar com uma solução (Sun ou Microsoft, não tenho preferência), pois gerenciar várias contas pode se tornar um problema. Eu sempre acho que, ao criar uma solução híbrida, posso ou não ter as ferramentas para tornar as coisas gerenciáveis. Eu não sou de forma alguma um mestre de LDAP / AD, mas mesmo programar contas de AD e usar ferramentas de snap-in do AD MMC para encontrar contas era bastante entediante.

    
por 02.09.2009 / 00:23
1

Há altos e baixos em cada abordagem.

A parte interessante sobre o uso do Sun LDAP para autenticação e autorização de aplicativos é que é fácil de suportar em redes e em DMZs. Em um ambiente universitário com muitos silos, isso pode ser uma vantagem real, já que você pode definir padrões flexíveis que provavelmente serão realmente cumpridos ... O LDAP é fácil de gerenciar em firewalls, é flexível e você tem várias maneiras de proteger seus aplicativos, de simples ligação LDAP a soluções SSO como o Siteminder.

A grande desvantagem é que você está comprando um monte de software, e agora você precisa de pessoas Unix / LDAP.

Se você realmente deseja integração de senha única, pode usar um meta-diretório como o ILM ou uma ferramenta de Federação como o Ping para manter seus usuários ativos do AD sincronizados com o LDAP. A vantagem de uma solução da Microsoft é que é mais fácil "graduar" os tipos de MCSE, e você obtém a capacidade de "engolir uma única garganta" quando as coisas correm no meio da noite.

Buscar o modelo AD é factível - o AD pode ser tão alto. O grande problema do IMO é que você vai precisar de mais servidores com mais recursos, e suportar um AD central em DMZs pode ser uma experiência menos que agradável. No meu mundo, com a filosofia de design de rede e as políticas de segurança com as quais lidamos, entregar serviços de AD fora do ambiente de computação do cliente é um pesadelo.

Se eu estivesse no seu lugar, dadas as informações da sua pergunta, eu examinaria uma abordagem híbrida LDAP / AD. Deixe o AD atender os 20-30k usuários ativos e obtenha os outros 250k no sistema Sun. A melhor resposta é provavelmente muito dependente de como você provisiona ...

    
por 02.09.2009 / 03:28