validação PEAP contra um domínio secundário diferente?

Question

Provavelmente um pouco confuso, então deixe-me explicar a situação.

Nossa empresa deseja implementar uma autenticação corporativa sem fio LAN com PEAP . Infelizmente, alguém cometeu um grande erro em nosso design do Active Directory há 10 anos.

O nome de domínio que estamos usando, company.ch , não é de nossa empresa, mas de outra pessoa. Isso torna impossível emitir um certificado SSL público para o servidor RADIUS e nosso domínio do Active Directory é grande demais para renomear.

Já pensamos em usar nosso PKI privado e lançar o certificado gerado pela CA via GPO , mas isso cobriria apenas nossos clientes corporativos e não qualquer dispositivo em nosso ambiente da nossa política BYOD ( Smartphones, tablets, laptops ..)

Existe uma maneira de adicionar um nome de domínio secundário como company2.ch , emitir um certificado público e unir RADIUS a esse domínio secundário, para que possamos configurar esse domínio secundário por meio de DHCP para todos os domínios secundários. pools de clientes?

Ou há outra maneira, por exemplo, com um novo servidor RADIUS em seu próprio domínio ( company2.ch ) que está conectado com algum tipo de confiança ao domínio company.ch ?

Eu não sou um cliente-servidor, mas espero que você me entenda.

    

Answer 1

Primeiro de tudo, deixe-me dizer que você (bem, seus chefes, talvez) realmente precisam deixar de usar um domínio que você não possui. Você diz que é muito grande para fazer isso agora, mas você está sendo míope. Se é "muito grande" mudar agora, o que acontece no futuro, quando é ainda maior? Você está apenas deixando o problema crescer e crescer, até que (se a empresa realmente tiver sucesso e continuar a crescer) você acabe com um problema que realmente será "muito grande" para lidar, e você gastará quantias fantásticas de dinheiro e tempo e criar um monte de impacto do usuário para corrigir o que você provavelmente poderia corrigir agora por muito menos esforço. No mínimo, você deve ver se pode comprar o domínio que seu AD está usando de seu proprietário atual, que seria a maneira mais rápida de corrigir isso.

De qualquer forma, tendo dito, e supondo que seus chefes não estão dispostos a serem realmente razoáveis, espertos ou pensarem mais no futuro do que o próximo cheque de bônus, existe uma maneira bem oriental de contornar isso, que você mencionou em seu pergunta.

O que você gostaria de fazer é:

1. Crie um segundo domínio filho em sua floresta do Active Directory .
   • Escolha um domínio que você possui dessa vez ou compre qualquer domínio que escolher, pelo amor de Deus.
2. Crie uma confiança entre o novo domínio e o antigo (dentro do AD ).
3. Crie grupos de usuários, recursos e permissões apropriados no novo domínio.
   • Configure um RADIUS / NPS server aqui que tenha permissões para autenticar no domínio antigo, ou talvez apenas em seus dispositivos compatíveis com RADIUS, e permita que eles se autentiquem no domínio antigo (ou no entanto você deseja fazer isso ).
4. Gerencie permissões no domínio antigo para que os usuários do novo domínio precisem de acesso.
   • Por exemplo, certifique-se de que qualquer SSL cert comprado para esse domínio será aceito pelo domínio antigo, se essa for a rota desejada.
5. (OPCIONAL, mas ALTAMENTE RECOMENDADO ) Use o novo domínio filho para migrar do antigo que você não possui
   • Quando os trusts estiverem estabelecidos e funcionando, você poderá usá-los para migrar os usuários do antigo domínio que não possui para algo que você faz e acabar com o problema eventualmente.
     • Estou realmente no meio de uma migração de domínio do Windows Active Directory e é assim que estamos lidando com isso.
     • Criamos um segundo domínio filho, estabelecemos relações de confiança e começamos a migrar lentamente usuários, serviços, máquinas (tudo) para o novo domínio, para que o antigo domínio corrompido fique vazio e sem uso. vou eliminá-lo.