encontre contas de usuário inativas em seu domínio
o Active Directory é um serviço de diretório que mantém informações sobre usuários, computadores e objetos relacionados. Aqui está como você pode encontrar contas de usuário inativas.
é um banco de dados de informações relacionais que precisa de manutenção ao longo do tempo para ser útil e relevante. Um diretório não terá mais contas usadas. Encontrar essas contas no Active Directory não é tão fácil quanto parece à primeira vista. Vamos encontrar contas de usuário inativas e automatizar a remoção delas.
definir critérios de pesquisa
vamos definir o que é necessário para este processo. Nosso objetivo é localizar contas de funcionários que não entraram na rede por um longo período. Eu sempre usei 90 ou 120 dias como uma boa medida para consultar a inatividade por, mas esse número pode ser tão baixo 14 dias. Você precisa decidir o que é certo para sua organização. 90 dias dá uma almofada grande o suficiente para permitir que as pessoas saiam do Escritório para férias, emergências familiares ou folhas médicas estendidas. Assim que as contas atingirem 90 dias de inatividade, queremos desativar essas contas e movê-las para uma OU separada.
definir o que estamos procurando primeiro nos permite construir um conjunto de regras simples a seguir. Nosso conjunto de regras se parece com isso:
- Localize e desative contas ativas que não têm atividade de logon por 90 dias.
- mova cada conta desativada para o Disabled-Users OU
- marque cada usuário desativado com um comentário de que um processo automatizado o desativou.
encontre propriedades de inatividade da Conta
cada conta de usuário possui vários atributos contendo informações de login. Queremos encontrar atributos que mostram a última hora de login. Se pudermos encontrar esses atributos, podemos usá-los para consultar contas não logadas desde uma determinada data. Podemos usar o PowerShell para exibir todo o conjunto de regras e escolher um atributo para trabalhar.
Get-ADUser é o cmdlet mais usado para mostrar informações do Usuário. Você pode usar Get-ADObject e Search-ADAccount, mas Get-ADUser é o melhor cmdlet para nossa tarefa. Para mostrar todas as propriedades do Usuário, precisamos adicionar-properties * à sintaxe do cmdlet. Se deixarmos essa sintaxe de fora, veremos apenas as propriedades padrão, que são apenas 10 propriedades.
Get-ADUser Michael_Kanakos -Properties *
retornamos uma longa lista de campos de nossa consulta (mais de 150!). Podemos procurar atributos que contenham palavras específicas usando curingas. Isso nos ajuda a localizar atributos que podem ser úteis para nossa tarefa. Queremos encontrar informações de logon, então vamos procurar por atributos que contenham a palavra Logon.
depois de dizer ao PowerShell para obter todas as propriedades, seria útil se pudéssemos limitar a lista de propriedades para mostrar apenas as propriedades que correspondem ao logon do word. Select-Object fornece a capacidade de fazer uma correspondência de wild-card e limitar nossos resultados. O caractere / (chamado “pipe”) pega os resultados à esquerda e os passa para Select-Object. Selecione-objeto, em seguida, executa a correspondência wild-card e, em seguida, limita os resultados com base em nossos critérios wild-card.
Get-ADUser username -Properties * | Select-Object *logon*
BadLogonCount : 0
lastLogon : 132181280348543735
LastLogonDate : 11/11/2019 9:08:45 PM
lastLogonTimestamp : 132179981259860013
logonCount : 328
LogonWorkstations :
MNSLogonAccount : False
SmartcardLogonRequired : False
os resultados variam um pouco com base no nível funcional do domínio do Active Directory. Minha pesquisa retorna oito atributos. Três parecem promissores: LastLogon, LastLogonDate e LastLogonTimeStamp. Alguns dos valores podem parecer um pouco estranhos se você não estiver familiarizado com a forma como o Active Directory armazena informações de data/hora em determinados atributos. Algumas informações de data são informações tradicionais de data e hora, e algumas são salvas como “ticks.”
os valores de data e hora do PowerShell e. NET Framework representam datas como o número de ticks desde as 12:00 da manhã de 1º de janeiro de 0001. Os carrapatos são iguais a um dez milionésimo de segundo, o que significa que existem 10.000 carrapatos por milissegundo. Existem cmdlets matemáticos que podem converter ticks em um formato de data padrão.
PowerShell mostra a marca real que representa a data / hora. Se você estiver confortável convertendo ticks para formato de data, então você pode olhar para esses campos no usuário do Active Directory e computadores ou centro administrativo do Active Directory. Em ambos os aplicativos, os ticks são representados como um formato de data e hora.
ADUser-Logon-Properties
atributos de Logon explicados
nossa pesquisa encontrou várias propriedades que mostram informações de logon de data/hora. Duas propriedades têm a mesma data e hora e uma não. O que se passa aqui?
a variação nas informações de data e hora é projetada e está em vigor para proteger os DCs de serem esmagados com o tráfego de replicação tentando manter todas as informações de logon sincronizadas. A propriedade LastLogon é atualizada toda vez que você autentica, mas os dados são armazenados no DC em que você autenticou e não replicados para os outros DC’S. as propriedades LastLogonTimeStamp e LastLogonDate estão sendo replicadas para todos os DC’s, mas a replicação só acontece com pouca frequência.
se olharmos para as datas, podemos ver como a replicação atrasada pode afetar nossa consulta. Observe que LastLogonTimeStamp está realmente dois dias atrasado neste exemplo. Toda vez que um usuário faz login interativamente, toca em um compartilhamento de arquivos de rede ou executa outras atividades que exigem que a rede autentique a conta, ele armazena informações de logon no Active Directory. Se o dc replicasse esses dados toda vez que alguém tocasse algo na rede, os DCs poderiam ser sobrecarregados em um ambiente grande. O resultado é que algumas informações de logon são precisas, mas não replicadas, e algumas informações de logon são replicadas, mas apenas ocasionalmente.
para nossos requisitos, não precisamos do carimbo de data / hora de logon exato. Só precisamos encontrar contas que não tenham feito login Há muito tempo (mais de 90 dias). Qualquer valor pode ser útil, mesmo que a data esteja desativada em alguns dias. Se usarmos Minhas datas de logon como exemplo, a hora consultada pode ser 11/11 ou 11/13, dependendo do valor que usamos. Avanço rápido de três meses e presumo que nunca mais entrei. Uma data sinalizaria como inativa por ter mais de 90 dias, e um campo não. Mas se eu configurar esse processo para ser executado mensalmente, pegaria a conta na próxima vez que verificarmos. Essa é a parte crítica. Se fizermos isso regularmente, podemos usar qualquer um dos campos, desde que verifiquemos consistentemente.
usei a propriedade LastLogonDate por dois motivos. Primeiro, já é um valor de data, então não preciso lidar com a conversão do valor. Em segundo lugar, é um valor replicado, e isso torna minha vida mais fácil. Se eu usasse LastLogon, teria datas que não estão atualizadas para pessoas que estão se autenticando em outros controladores de domínio em minha rede. Eu teria que consultar o DC local para cada usuário para obter o carimbo de data / hora mais recente, e isso é muito trabalho a fazer e não é muito eficiente.
para obter as informações em uma única conta, o código é simples.
get-aduser Michael_Kanakos -properties LastLogonDate | Select-Object Name, LastLogonDate
Name LastLogonDate
---- -------------
mkanakos 11/11/2019 9:08:45 PM
para fazer isso para todos os meus usuários requer apenas um pouco mais de código. Precisamos usar um filtro para consultar todas as contas de usuário.
Get-ADUser -filter * -properties LastLogonDate | Select-Object Name, LastLogonDate
agora vamos encontrar apenas as contas com uma data de logon com mais de 90 dias. Precisamos da data atual salva para usar como Operador de comparação.
$date = (get-date).AddDays(-90)
Get-ADUser -Filter {LastLogonDate -lt $date} -properties LastLogonDate | Select-Object Name, LastLogonDate
este código recupera todos os usuários que não fizeram login por mais de 90 dias. Salvamos a data há 90 dias para uma variável. Podemos criar um filtro de anúncios para encontrar logons menores que essa data. Em seguida, precisamos adicionar o requisito para consultar apenas contas ativas. Neste exemplo, estou usando splatting para tornar o código mais legível porque a sintaxe é muito longa. Splatting cmdlets AD pode ser complicado, então eu também mostrei a versão de forma longa da sintaxe abaixo do exemplo splatting.
$date = (get-date).AddDays(-90)
$paramhash = @{
Filter = "LastLogonDate -lt $date -and Enabled -eq $true"
Properties = 'LastLogonDate'
}
$SelectProps = 'Name','LastLogonDate','Enabled','DistinguishedName'
$InactiveUsers = Get-Aduser @paramhash | Select-Object $SelectProps
$InactiveUsers = Get-ADUser -Filter {LastLogonDate -lt $date -and Enabled -eq $true} -properties LastLogonDate, DistinguishedName | Select-Object Name, LastLogonDate, Enabled, DistinguishedName
isso nos dá nossos usuários inativos que estão habilitados. Salvamos os resultados em uma variável para reutilização. A propriedade DistinguishedName é necessária mais tarde. Depois de encontrar os usuários, podemos trabalhar em nossa próxima etapa: desativar as contas. Usamos o cmdlet Set-ADUser para fazer alterações na conta do usuário do anúncio.
$Today = Get-Date
$DisabledUsers = (
$InactiveUsers | Foreach-object {
Set-User $_.DistinguishedName -Enabled $false -Description "Acct disabled on $Today via Inactive Users script"}
)
desativamos nossas contas de usuário. É hora de movê-los para uma nova UO. Para o nosso exemplo, usaremos a OU chamada Disabled-Users. O nome distinto para esta UO é “OU=Disabled-Users, DC = Contoso, DC = com” usamos o cmdlet Move-ADObject para mover os usuários para a UO de destino.
$DisabledUsers | ForEach-Object {
Move-ADObject $_.DistinguishedName -TargetPath "OU=Disabled-Users,DC=Contoso,DC=Com"}
em nossa etapa final, usamos o Move-ADObject para mover os usuários para uma nova UO. Agora temos o código principal necessário para fazer uma tarefa automatizada confiável e repetível. Então, o que vem a seguir? Isso depende de suas necessidades individuais. Este código pode e deve ser configurado para ser executado automaticamente ao mesmo tempo todos os meses. Uma maneira fácil de fazer isso é criar um trabalho agendado para executar o código mensalmente.
há mais que poderíamos adicionar a este código para torná-lo melhor. Código para verificação de erros e campos adicionais de informações do usuário seriam duas adições úteis. A maioria das equipes que executam esses tipos de Tarefas gera um relatório do que foi desativado para alguém revisar, portanto, os campos adicionais serão var. Você pode incluir mais campos do Active Directory para tornar um relatório mais útil. Poderíamos levar essa tarefa um passo adiante criando outra tarefa para excluir esses usuários desativados após 6 meses.
resolver solicitações de automação desafiadoras é muito mais fácil quando as tarefas são divididas em partes gerenciáveis. Começamos com os requisitos e construímos nossa sintaxe em pequenas etapas; confirmando que cada etapa funciona antes de tentar adicionar outra variável. Ao fazer isso, tornamos essa tarefa fácil de entender e, com sorte, uma ótima experiência de aprendizado.