Multiplas politicas de senha por dominio
Alguem já tentou configurar diversas politicas de senhas dentro de um mesmo dominio (Active Directory) ? Pois é acreditem, não funciona!
A politica de senhas é domain wide. É comum termos cenarios onde um grupo de contas em especifico tenham uma politica mais forte, mas infelizmente não há como obrigarmos.
Na verdade caso você queira especificar uma politica em uma determinada OU, as contas que estiverem dentro da OU (somente máquinas, pois esta politica se aplica a máquinas... mas pera, eu quero aplicar a politica em contas de usuarios, pq essa politica só se aplica a máquinas ? já explico...) terão a politica valendo somente para contas locais, ficou claro ? Claro que não!
A Microsoft diz oficialmente que a politica de senhas se aplica a máquina, pois como tudo para o ad é uma conta (seja usuarios ou maquinas) e aplicando a politica em nivel de dominio, todas as maquinas receberao estas politicas e por consequencia os usuarios.
A resposta nao oficial é que setar esta politica pra cada usuário seria muito trabalho. Pois quando um usuário quisesse trocar sua senha, seria necessário verificar a politica daquele usuário, depois da maquina, ver quem faz overhide em quem e ai fazer valer a politica correta. Sendo tudo por máquina, se N usuários tentarem trocar a senha a partir daquela maquina, a politica verificada será a mesma.
Um ponto de atencao: Se vc tiver N politicas que definem a politica de senhas, prevalecerá a ultima politica a ser aplicada, portanto tome cuidado com as wide domain policies, você pode estar enfraquecendo as politicas de senha do seu dominio.
Agora, qual seria a solução onde é necessário uma politica de senhas para usuários (10 chars, alfanumericos, politica de desbloqueio mais rigida) e precisa de outra politica para senhas de servicos (20 chars, aflanumericos, sem politica de desbloqueio ou politica de desbloqueio mais "light") ?
A principio temos duas soluções:
Alguem já tentou configurar diversas politicas de senhas dentro de um mesmo dominio (Active Directory) ? Pois é acreditem, não funciona!
A politica de senhas é domain wide. É comum termos cenarios onde um grupo de contas em especifico tenham uma politica mais forte, mas infelizmente não há como obrigarmos.
Na verdade caso você queira especificar uma politica em uma determinada OU, as contas que estiverem dentro da OU (somente máquinas, pois esta politica se aplica a máquinas... mas pera, eu quero aplicar a politica em contas de usuarios, pq essa politica só se aplica a máquinas ? já explico...) terão a politica valendo somente para contas locais, ficou claro ? Claro que não!
A Microsoft diz oficialmente que a politica de senhas se aplica a máquina, pois como tudo para o ad é uma conta (seja usuarios ou maquinas) e aplicando a politica em nivel de dominio, todas as maquinas receberao estas politicas e por consequencia os usuarios.
A resposta nao oficial é que setar esta politica pra cada usuário seria muito trabalho. Pois quando um usuário quisesse trocar sua senha, seria necessário verificar a politica daquele usuário, depois da maquina, ver quem faz overhide em quem e ai fazer valer a politica correta. Sendo tudo por máquina, se N usuários tentarem trocar a senha a partir daquela maquina, a politica verificada será a mesma.
Um ponto de atencao: Se vc tiver N politicas que definem a politica de senhas, prevalecerá a ultima politica a ser aplicada, portanto tome cuidado com as wide domain policies, você pode estar enfraquecendo as politicas de senha do seu dominio.
Agora, qual seria a solução onde é necessário uma politica de senhas para usuários (10 chars, alfanumericos, politica de desbloqueio mais rigida) e precisa de outra politica para senhas de servicos (20 chars, aflanumericos, sem politica de desbloqueio ou politica de desbloqueio mais "light") ?
A principio temos duas soluções:
- Criar contas locais nos servidores que contem os servicos, jogar essas maquinas numa OU e aplicar a politica de senhas em cima desta OU
- Criar um dominio separado para as contas de servico, fazer trust entre os dominios e criar uma politica de senhas separadas
Como vocês podem ver, nenhuma das duas é boa em "Facilidade de gerenciamento". Acredito que a Microsoft poderia melhorar este controle, garantindo apenas que politicas pontuais aplicadas em OUs não enfraquecessem a politica default.
posted by Jose Silva at 7:37 PM
2 Comments:
VP,
O motivo principal é que atrás da "beleza" do AD ainda há a ruim e velha SAM.
Lembre-se, porém, que a API para fazer a crítica de senha no momento da mudança é aberta, inclusive com o código da famosa "passfilt.dll" como exemplo. É só criar algo que faça uma query no AD e aplique a política de acordo com a posição do usuário.
Além disso ainda está na lista de "To do" deles implementar salt na criptografia das senhas e trocar o MD4. Mais importante que muita perfumaria que estão colocando nas novas versões.
Gugu,
O problema é que você não consegue granularizar, se eu entendi sua proposta, eu nao conseguiria colocar uma passfilt somente para uma OU. Eu nao posso definir complexidade somente nas contas dentro de uma OU. Isso deveria ser possivel desde que nao enfraquecesse a politica default do dominio
Post a Comment
<< Home