Integrando o FreeIPA ou o RH IdM em um ambiente existente do MS AD

Question

Desejo implantar o FreeIPA ou o Red Hat IdM no meu ambiente existente

Atualmente, meu domínio é gerenciado pelo MS AD, que é controlado por um grupo separado. Suponha que mudar alguma coisa no MS AD seja difícil ou impossível por razões políticas.

Para Linux, recentemente configurei sistemas para usar a autenticação de senha Kerberos fornecida diretamente pelo MS AD, usando o SSSD no Enterprise Linux. Informações de identidade ainda são fornecidas no sistema local.

Meu maior problema agora é descobrir como propor o novo espaço de nomes de domínio.

Posso usar um subdomínio do nosso domínio do MS AD e delegá-lo ao FreeIPA?

Eu acho que pode ser desejável ter as configurações do Kerberos apontando diretamente para o MS AD, ele já é extremamente resiliente, por que não aproveitar a infraestrutura existente? Mas isso me causará mais problemas do que vale a pena? Não tenho certeza de como as coisas se integrarão.

Considere isso:

Nosso padrão de nomenclatura de host é algo como "app-id-dev / prd.domain.com". Por exemplo, por exemplo: "server01dev.domain.com"

Por política, nós não duplicamos o ID do servidor entre os ambientes dev / prd, então eu estava pensando que uma maneira bacana de usar subdomínios seria converter o exemplo anterior para “server01.dev.domain.com”. Uma característica interessante disso seria que, ao especificar o nome abreviado de um host, não precisaríamos mais especificar dev / prd se a ordem de pesquisa do nosso domínio estivesse configurada corretamente no cliente.

Vantagem Percebida: Isso permitiria que eu me tornasse a autoridade de certificação desses subdomínios. Isso deve simplificar qualquer certificado relacionado no futuro.

Desvantagem percebida: o que isso significaria para autenticação? Eu ainda quero que os usuários autentiquem usando um nome de usuário que já existe no domínio original. Exemplo: [email protected] não [email protected]

Outra dúvida que tenho é se há algum ponto em usar o MS AD Kerberos diretamente, porque se as informações de Identidade não estiverem disponíveis no FreeIPA LDAP, elas ainda impedirão que o usuário efetue login corretamente, a menos que tenham uma identidade local no sistema do cliente.

Se isso é um problema real, fico imaginando se é possível sincronizar a informação LDAP do FreeIPA com o AD, mas acho que os usuários precisariam ser criados no subdomínio.

Ou, devo jogar fora qualquer noção de usar o MS AD diretamente para resiliência e aceitar que preciso criar um ambiente resiliente FreeIPA / RH IdM?

    

Answer 1

Primeiramente, usarei o FreeIPA e o Red Hat Enterprise IdM de forma intercambiável. Se isso causar desconforto, deixe-me sugerir uma bebida.

O FreeIPA deve ser um território do Kerberos separado do Active Directory e deve usar uma zona DNS separada correspondente ao território do Krb5. Se o domínio do AD usa a zona DNS "domain.com" com zonas filho "dev" e "prd", você deve criar uma nova zona DNS chamada algo como "idm.domain.com" e quaisquer sub-reinos sob isto. Você iria querer criar um reino Krb5 chamado "IDM.DOMAIN.COM", com todos os UPNs como [email protected] e todos os SPNs como HOST / SERVER123.IDM.DOMAIN. COM ou algo semelhante (talvez WWW / SERVER123.PRD.IDM.DOMAIN.COM ).

Você pode usar a mesma zona DNS que o AD, mas é uma idéia ruim REALMENTE . Além de perder a descoberta de serviço usando DNS, você precisa fazer mapeamentos manuais e provavelmente terá problemas para solucionar problemas de clientes que tentam passar um token do Krb inadequado para os servidores no domínio IdM

Você precisará trabalhar com a equipe do AD pelo menos brevemente para que eles configurem uma relação de confiança entre domínios. Eles podem querer que seja uma relação de confiança unidirecional, em que AD é o domínio confiável e FreeIPA é o domínio de confiança. Na maioria dos casos, isso não deve ser um problema.

No momento, a versão do FreeIPA fornecida com o RHEL 7 não suporta o estabelecimento de confiança com o domínio do AD do forest-apex e a passagem para domínios filho para autenticação. Foi-me dito no RHEL 7u1 que isso será remediado, pois o suporte à confiança transitiva será adicionado ao FreeIPA, mas não estou prendendo a respiração até ver a lista de recursos um dia após o congelamento de código. Como solução alternativa, você deve poder configurar a confiança no domínio filho, no qual os objetos do usuário são gerados.

Estou trabalhando em um esforço similar. Boa sorte, deixe-nos saber como isso funciona. Eu tenho a sorte de ter a equipe do AD como um elemento do meu time (e eles se sentam bem na minha frente). Entramos para o mesmo líder no nível de equipe (unidade do tamanho de um esquadrão) e temos muito apoio do nosso líder de divisão, que deseja que essa integração seja bem-sucedida.