Olá, pessoal, tudo bem?

Hoje o assunto e segurança, assunto que gosto de escrever.

Logo abaixo alguns artigos publicados por mim cujo assunto e segurança.

 

1 – O que é WSUS – Planejando sua implantação

Desativando SMB versão 1.0 pelo Windows Admin Center

Usando conta de serviço gerenciado de grupo (gMSA) para execução de tarefas no Agendador de Tarefas do Windows

Habilite o login sem senha (Passwordless) no Azure AD utilizando chaves de segurança (Security Key) FIDO 2

Configurar uma chave de segurança (Security Key) FIDO2 como método de verificação da sua conta pessoal Microsoft

Aumentando a segurança da senha do usuário administrador local

Próxima grande versão do Windows Server – Segurança

Instalando uma infraestrutura simples para acesso a VPN com segurança do NPS

Definindo Windows Defender Firewall por GPO

Windows Defender Browser Protection for Google Chrome

Windows Defender Application Guard – Modo autônomo

 

Políticas de senha refinadas

 

 

Este contéudo faz parte do exame AZ-800: Como administrar a infraestrutura de núcleo híbrido do Windows Server. Recomendo a compra do livro Exam Ref AZ-800 Administering Windows Server Hybrid Core Infrastructure (3570357) (English Edition) do autor Orin Thomas para estudos desta certificação.

 

Nos domínios do Active Directory do Windows 2000 e do Windows Server 2003, apenas uma diretiva de senha e uma diretiva de bloqueio de conta podem ser aplicadas a todos os usuários no domínio. Essas diretivas foram especificadas na Diretiva de Domínio Padrão para o domínio. Como resultado, as organizações que queriam configurações diferentes de senha e bloqueio de conta para diferentes conjuntos de usuários precisavam criar um filtro de senha ou implantar vários domínios. Ambas as opções são caras por razões diferentes.

Com a chegada do sistema operacional Windows Server 2008 ele agora fornece às organizações uma maneira de definir diferentes diretivas de bloqueio de senha e conta para diferentes conjuntos de usuários em um domínio.

Criação de políticas de senha refinadas na Central Administrativa do Active Directory

 

O que as políticas de senha refinadas fazem?

Por exemplo, você pode aplicar configurações mais rígidas a contas privilegiadas e configurações menos rígidas às contas de outros usuários. Em outros casos, talvez você queira aplicar uma diretiva de senha especial para contas cujas senhas são sincronizadas com outras fontes de dados.

Você pode usar diretivas de senha refinadas para aplicar restrições diferentes para diretivas de bloqueio de senha e conta a diferentes conjuntos de usuários em um domínio.

 

Quem se interessará por esse recurso?

  • Planejadores e analistas de tecnologia da informação (TI) que estão avaliando tecnicamente o produto.
  • Planejadores e designers de TI corporativos para organizações.
  • Administradores ou gerentes responsáveis pela segurança de TI.

 

Há alguma consideração especial?

As diretivas de senha refinadas se aplicam somente a objetos de usuário (ou objetos inetOrgPerson se forem usados em vez de objetos de usuário) e grupos de segurança globais. Por padrão, somente os membros do grupo Administradores de Domínio podem definir diretivas de senha refinadas. No entanto, você também pode delegar a capacidade de definir essas políticas para outros usuários.

A diretiva de senha refinada não pode ser aplicada a uma unidade organizacional (UO) diretamente. Para aplicar uma política de senha refinada aos usuários de uma UO, você pode usar um grupo de sombras. Grupo de sombras é um grupo regular do Active Directory que simplesmente contém todos os usuários de uma UO.

Grupo de sombras no Active Directory

 

Armazenando políticas de senha refinadas

Para armazenar diretivas de senha refinadas, o Windows Server 2008 inclui duas novas classes de objeto no esquema dos Serviços de Domínio Active Directory (AD DS):

  • Contêiner de configurações de senha (Password Settings Container)
  • Configurações de senha (Password Settings)

 

Um Contêiner de Configurações de Senha (PSC) é criado por padrão no contêiner Sistema (System) no domínio.

Você pode exibi-lo usando o snap-in Usuários e Computadores do Active Directory com recursos avançados habilitados. Ele armazena os objetos de Configurações de Senha (PSOs) para esse domínio.

Acesso ao PSO pelo Usuários e Computadores do Active Directory

Não é possível renomear, mover ou excluir esse contêiner. Embora você possa criar PSCs personalizados adicionais, eles não são considerados quando o conjunto de diretivas resultante (RSOP) é calculado para um objeto. Portanto, eles não são recomendados. Para obter mais informações sobre como o RSOP é calculado, consulte “RSOP” mais adiante neste artigo.

Uma PSO tem atributos para todas as configurações que podem ser definidas na Diretiva de Domínio Padrão (exceto as configurações de Kerberos). Essas configurações incluem atributos para as seguintes configurações de senha:

  • Impor histórico de senhas (Enforce password history)
  • Idade máxima da senha (Maximum password age)
  • Idade mínima da senha (Minimum password age)
  • Comprimento mínimo da senha (Minimum password length)
  • As senhas devem atender aos requisitos de complexidade (Minimum password length)
  • Armazenar senhas usando criptografia reversível (Minimum password length)

 

Essas configurações também incluem atributos para as seguintes configurações de bloqueio de conta:

  • Duração do bloqueio da conta (Minimum password length)
  • Limite de bloqueio de conta (Minimum password length)
  • Redefinir o bloqueio da conta após (Minimum password length)

 

Além disso, um PSO tem os dois novos atributos a seguir:

  • Link PSO (PSO link). Esse é um atributo de valores múltiplos vinculado a usuários e/ou objetos de grupo.
  • Precedência (Precedence). Esse é um valor inteiro usado para resolver conflitos se vários PSOs forem aplicados a um objeto de usuário ou grupo.

 

Esses novos atributos são obrigatórios. Isso significa que você deve definir um valor para cada um. As configurações de vários PSOs não podem ser mescladas.

 

 RSOP

Um objeto de usuário ou grupo pode ter vários PSOs vinculados a ele, seja devido à associação em vários grupos que têm PSOs diferentes aplicados a eles ou porque vários PSOs são aplicados diretamente ao objeto. No entanto, apenas uma PSO pode ser aplicada como a política de senha efetiva. As configurações de outras PSOs vinculadas ao usuário ou grupo não podem ser mescladas de forma alguma.

 

O RSOP só pode ser calculado para um objeto de usuário. A PSO pode ser aplicada ao objeto de usuário de uma das duas maneiras a seguir:

1. Diretamente: PSO está vinculado ao usuário.

2. Indiretamente: a PSO está vinculada ao(s) grupo(s) do qual o usuário é membro.

Cada PSO tem um atributo adicional chamado msDS-PasswordSettingsPrecedence, que auxilia no cálculo do RSOP. O atributo msDS-PasswordSettingsPrecedence tem um valor inteiro de 1 ou superior. Um valor mais baixo para o atributo de precedência indica que o PSO tem uma classificação mais alta, ou uma prioridade mais alta, do que outros PSOs. Por exemplo, suponha que um objeto tenha dois PSOs vinculados a ele. Uma PSO tem um valor de precedência de 2 e a outra PSO tem um valor de precedência de 4. Nesse caso, o PSO que tem o valor de precedência de 2 tem uma classificação mais alta e, portanto, é aplicado ao objeto.

Se várias POSs estiverem vinculadas a um usuário ou grupo, a OSP resultante aplicada será determinada da seguinte maneira:

 

1. Uma PSO vinculada diretamente ao objeto de usuário é a PSO resultante. (Vários PSOs não devem ser diretamente vinculados a um objeto de usuário.).

2. Se nenhum PSO estiver vinculado diretamente ao objeto do usuário, as associações do grupo de segurança global do usuário e todos os PSOs aplicáveis ao usuário com base nessas associações do grupo global serão comparados. O PSO com o menor valor de precedência é o PSO resultante.

3. Se nenhum PSO for obtido das condições (1) e (2), a Política de domínio padrão será aplicada.

 

Recomendo que você atribua um valor no atributo msDS-PasswordSettingsPrecedence exclusivo para cada PSO criado. No entanto, você pode criar vários PSOs com o mesmo valor no atributo msDS-PasswordSettingsPrecedence. Se vários PSOs com o mesmo valor msDS-PasswordSettingsPrecedence forem obtidos para um usuário a partir das condições (1) e (2), o PSO com o GUID menor será aplicado.

Para determinar o menor GUID, os GUIDs são comparados no nível de bytes. O byte mais à direita da primeira parte do GUID é comparado primeiro. Por exemplo, suponha que duas PSOs com os seguintes GUIDs tenham o mesmo valor do atributo msDS-PasswordSettingsPrecedence.

1. d1742912-87cd-4172-ac6e-ad1e94965e6b

2. 7b41e54e-a075-4a4d-869d-0b0e1433de89

Embora você possa pensar que o PSO 2 será aplicado, já que 7b vem antes de d1 numericamente, o PSO 1 será aplicado porque a operação de comparação de memória compara o byte mais à direita da primeira parte do GUID e 12 é menor que 4e. Para ajudar a evitar resultados inesperados, não aplique o mesmo valor do atributo msDS-PasswordSettingsPrecedence a PSOs diferentes.

Outro novo atributo chamado msDS-ResultantPSO foi adicionado ao objeto de usuário. Um administrador pode consultar esse atributo para recuperar o nome distinto da PSO que, em última análise, é aplicado a esse usuário (com base nas regras listadas anteriormente). Se não houver nenhum objeto PSO que se aplique ao usuário, diretamente ou em virtude da associação ao grupo, a consulta retornará o valor NULL (Nulo).

Atributo msDS-ResultantPSO adicionado a um usuário do Active Directory

Observação: Se o campo msDS-ResultantPSO não aparecer, em filtro, marque para aparecer atributos Criado.

Se desejar que um determinado membro do grupo esteja em conformidade com uma política diferente da política atribuída a todo o grupo, você poderá criar uma PSO excepcional e vinculá-la diretamente a esse usuário específico.

Quando o atributo msDS-ResultantPSO para esse usuário é calculado, o PSO excepcional que está vinculado diretamente ao usuário tem precedência sobre todos os outros PSOs.

O objeto de usuário tem três bits que substituem as configurações que estão presentes no PSO resultante (assim como esses bits substituem as configurações na Diretiva de Domínio Padrão no Windows 2000 e no Windows Server 2003). Você pode definir esses bits no atributo userAccountControl do objeto user:

  • Criptografia de senha reversível necessária
  • Senha não necessária
  • A senha não expira

 

Esses bits continuam a substituir as configurações no PSO resultante que é aplicado ao objeto de usuário.

 

Segurança e delegação

 

Por padrão, somente os membros do grupo Administradores de Domínio podem criar PSOs. Somente os membros desse grupo têm as permissões Criar Filho e Excluir Filho no objeto Contêiner de Configurações de Senha. Além disso, somente os membros do grupo Administradores de Domínio têm permissões de Propriedade de Gravação na PSO por padrão. Portanto, somente os membros do grupo Administradores de Domínio podem aplicar uma PSO a um grupo ou usuário. Você pode delegar essa permissão a outros grupos ou usuários. Você não precisa de permissões no objeto de usuário ou grupo para poder aplicar uma PSO a ele. Ter permissões de Gravação no objeto de usuário ou grupo não lhe dá a capacidade de vincular uma PSO ao usuário ou grupo. O proprietário de um grupo não tem permissões para vincular uma PSO ao grupo porque o link de encaminhamento está na PSO. O poder de vincular uma PSO ao grupo ou usuário é dado ao proprietário da PSO.

As configurações na PSO podem ser consideradas confidenciais; portanto, por padrão, os Usuários Autenticados não têm permissões de Propriedade de Leitura para uma PSO. Por padrão, somente os membros do grupo Administradores de Domínio têm permissões de Propriedade de Leitura no descritor de segurança padrão do objeto PSO no esquema.

Você pode delegar essas permissões a qualquer outro grupo (como a equipe de suporte técnico ou um aplicativo de gerenciamento) no domínio ou na floresta. Isso também pode impedir que um usuário veja suas configurações de senha no diretório. O usuário pode ler os atributos msDS-ResultantPsooumsds-PSOApplied, mas esses atributos exibem apenas o nome distinto da PSO que se aplica ao usuário. O usuário não pode ver as configurações dentro desse PSO.

 

Requisitos

 

 

 

 

Políticas de senha refinadas estão disponíveis em todas as edições do Windows Server 2008 e posteriores.

Nível funcional do domínio Windows Server 2008.

Use o comando Get-ADDomain no Powershell para verificar o nível funcional do domínio.

Saída do comando de Powershell Get-ADDomain

Para aumentar o nível funcional do domínio e floresta do Active Directory, consulte a documentação oficial da Microsoft neste link aqui.

 

Vídeo

No vídeo será demostrado de forma clara e objetiva como configurar uma política de senha refinada no Windows Server 2022, demostrando tanto para usuários e grupo de sombras.Também como verificar a política de senha que se aplica a um usuário pelo Powershell.

Referências

 

 

 

 

https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/adac/introduction-to-active-directory-administrative-center-enhancements–level-100-?WT.mc_id=5003815

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-r2-and-2008/cc770394(v=ws.10)?WT.mc_id=5003815

https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-addomain?view=windowsserver2022-ps&WT.mc_id=5003815

https://learn.microsoft.com/pt-br/troubleshoot/windows-server/identity/raise-active-directory-domain-forest-functional-levels?WT.mc_id=5003815

https://jorgequestforknowledge.wordpress.com/2014/08/08/interesting-attribute-determining-effective-pso-msds-resultantpso/

 

Inscreva-se no meu canal do YouTube ative o sininho para receber as notificações!

No responses yet

Deixe uma resposta

Microsoft MVP
Siga e curta!
Categorias
Arquivo
Inteligência artificial em seu servidor.