What if I'm asked to provide a list with users from active directory that have not logged on for "X" days, for cleaning purposes ?
Hey guys !!
How are you doing today ?
Today we are going to talk about one very common situation that most of us get quite frequently.
How to come up with a list of users that have not logged on for "X" days.
From time to time, we should clean stuff up and many times, it is hard to keep AD database clean due to a number of facts that is out of control of the IT department. People leave company, get fired and not all times, IT department get notified in the way it should. You may end up with a bunch of disabled accounts but maybe, not all of them get moved to a disabled OU, or even get deleted when time comes, if company policy allows for account deletion.
Powershell can help us to get a comprehensive list of users that have not logged on for whatever number of days make sense in your environment.
There are tons of powershell scripts out there that can do this for you but one thing that is very important to understand is that, there are two attributes that can confuse you and might give you an inaccurate answer. Once you understand the differences between them, you can leverage your script of choice and provide an almost 100% accurate report to your boss. I will leave up to you to get your script of choice and now I will explain the differences between these two attributes.
LastLogon and LastLogonDate.
LastLogon
It will record timestamp ONLY on a domain controller where the object authenticated against. It is probably the most accurate one but, it will only give you an accurate response if you query the right domain controller. This attribute is not replicated to other domain controllers. This may not be practical for companies that have many, like hundreds of domain controllers but might be a good idea for small companies.
LastLogonDate
This one is just a human readable translation of LastLogonTimeStamp. The advantage here is , because it is replicated to all domain controllers, you will get the same timestamp regardless of what domain controller you query, as long as all domain controllers have converged. The downside is, by design, to avoid replication storm caused by many objects (users,computers,etc.) logging in on a daily basis and having potentially thousands of updates being sent to domain controllers, Microsoft put in place a 9 - 14 days delay on this particular attribute. Meaning, the only time this attribute will be updated is when the timestamp is greater than 9 - 14 days compared to its current value.
e.g - Bob logs on today, for the first time and LastLogonTimestamp is populated with today's date. As a result, LastLogonDate will show today's date and all domain controllers are notified and update Bob's LastLogonTimeStamp attribute. If you query Bob's account, no matter which domain controller you use, you should get the same result.
Tomorrow, Bob logs on again and because tomorrow and today's date are not greater than 14, it's only a 1 day difference, the attribute will not be updated. Then, fifteen days from now, when Bob logs on again, the difference between 15 days from now and the last logon date will be greater than 14. at this point, LastLogonTimeStamp gets a new value and the attribute is updated on all domain controllers.
Let's check picture below to get a better understanding
Let's explain what happened here in plain english.
Because "lastlogon" attribute is empty on ( number 1) and we already know "lastlogon" attribute does not replicate to all domain controllers, we can assume my user "lastlogondate" authenticated against DC01. Why? Because "lastlogon" is populated in DC01 (number 2). It has this weird value 132084605320048519 that when I use [datetime] do convert it, I got July 24th 2019 at 12:48:52 exactly what lastlogondate attribute shows on both, DC01 and DC02.
This proves my point that "lastlogontimestamp", which is the same as "lastlogondate" attribute gets replicated to all other domain controllers. Just keep in mind, depending on your replication topology, you may need to wait some time until you get the updated value on all domain controllers.
Now, I will prove that "lastlogon" attribute only gets updated on a domain controller the user authenticated against and that it actually reflects last time user logged on. I've gone ahead and disabled the network card of DC02 to force my "lastlogondate" user using DC01 for authentication and logged on one more time.
See what happens now :
We see that the only attribute that got updated is "lastlogon". Remember? Previous value was 132084605320048519 and current value is 132084620075399617. When I use [datetime] to convert it to a human readable value I got July 24th 2019 at 1:13:27 PM.
Now, I've put DC02 back into rotation and let's see what we get:
As expected, nothing has changed. I would expect "lastlogondate" attribute to change after 9 - 14 days from now or, "lastlogon" gets updated next time lastlogondate user authenticates against DC02.
Let's do this now. I will take DC01 out of rotation to force authentication against DC02. I expect seeing "lastlogon" attribute populated now.
And here we go folks. Now, since user authenticated against DC02 we see "lastlogon" populated and when we convert we see July 24th 2019 at 1:28:06 PM.
So, this proves my earlier points but, there is still one thing I'd like to show you so we can close the loop. When will we be able to see "lastlogondate" attribute updated ? After 15 days ?
So, I did a time travel to the future and fast forwarded to August 15th 2019. :)
I changed the date in my domain controller DC02 and my workstation to August 15th and I logged on using "lastlogondate" user. Check this out. You will be amazed !!! :)
Isn't that awesome ?? When theory meets practice ?
As you can see now, because August 15th compared with July 24th is greater than 14, "lastlogondate" attribute gets updated after lastlogondate user logs on.
There you have it folks. I hope this has been helpful and thanks again for stopping by.
Here is a great article that Warren wrote about this: ClickHere
===========================================
Portugues
E ai pessoal !!
Como vocês estão hoje ?
Hoje vamos falar sobre uma situação muito comum que a maioria de nós recebe com bastante frequência.
Como criar uma lista de usuários que não se logam no AD depois de "X" dias.
De tempos em tempos, devemos dar manutenção na base do AD e muitas vezes é difícil manter a base do AD clean como deveria ser devido a uma série de fatos que estão fora de controle do departamento de TI. As pessoas saem da empresa, são demitidas e nem sempre, o departamento de TI é notificado da maneira como deveria.Você pode acabar com várias contas desativadas mas talvez, nem todas sejam movidas para uma unidade organizacional própria para isso ou sejam devidamente excluídas, se assim a política da empresa permitir.
Powershell pode nos ajudar a obter uma lista de usuários que não estão se logam desde X dias, ou o intervalo que fizer sentido para você.
Existem muitos scripts de powershell por aí que podem fazer isso por você, mas uma coisa muito importante é entender dois atributos que podem confundir vocês e dar uma resposta imprecisa.
LastLogon e LastLogonDate.
LastLogon
Ele guardará o timestamp SOMENTE no controlador de domínio no qual o usuário foi autenticado. É provavelmente o mais preciso, mas só funcionará se você consultar o controlador de domínio correto. Este atributo não é replicado para outros controladores de domínio. Isso pode não ser prático para empresas que possuem muitos, como centenas de controladores de domínio, mas pode ser uma boa ideia para pequenas empresas.
LastLogonDate
Este é apenas uma tradução legível de LastLogonTimeStamp. Você pode obter um timestamp legível logo após o comando powershell, pois LastLogonTimeStamp é difícil de ler. A vantagem é que, como ele é replicado para todos os controladores de domínio, você obterá o mesmo timestamp em não importa qual controlador de domínio você consultar, contanto que todos os controladores de domínio ja tenham convergido. A desvantagem é, por design, para evitar replication storm causada por muitos objetos que fazem logon diariamente e provocar, potencialmente milhares de atualizações enviadas para os controladores de domínio, a Microsoft implementou um atraso de 9 a 14 dias para que esse atributo seja atualizado. Ou seja, a única vez que esse atributo será atualizado em todos os controladores de domínio é quando o timestamp é maior que 9 a 14 dias comparando com o valor atual desse atributo.
Por exemplo: Bob faz logon hoje, pela primeira vez, e LastLogonTimestamp é preenchido com a data de hoje. Como resultado, LastLogonDate mostrará a data de hoje e todos os controladores de domínio serão notificados e atualizarão o atributo LastLogonTimeStamp de Bob. Se você consultar a conta de Bob, independentemente do controlador de domínio usado, você deverá obter o mesmo resultado.
Amanhã, Bob faz logon novamente e, porque amanhã e a data de hoje não são maiores que 14, é apenas uma diferença de 1 dia, o atributo não será atualizado. Então, quinze dias a partir de agora, quando Bob fizer logon novamente, a diferença entre 15 dias a partir de agora e a data do último logon será maior que 14. neste momento, LastLogonTimeStamp obtém um novo valor e o atributo é atualizado em todos os controladores de domínio.
Vamos verificar a imagem abaixo para obter uma melhor compreensão
Vamos explicar o que aconteceu aqui em Portugês simples.
Como o atributo "lastlogon" está vazio em (número 1) e já sabemos que o atributo "lastlogon" não é replicado para todos os controladores de domínio, podemos assumir que meu usuário "lastlogondate" foi autenticado pelo DC01. Por quê? Porque "lastlogon" é preenchido em DC01 (número 2). Tem esse valor estranho 132084605320048519 que quando eu uso [datetime] para converter, eu tenho 24 de julho de 2019 às 12:48:52 exatamente o que o atributo lastlogondate mostra em ambos, DC01 e DC02.
Isso prova meu argumento de que o atributo "lastlogontimestamp", que é o mesmo que "lastlogondate", é replicado para todos os outros controladores de domínio. Apenas tenha em mente que, dependendo da topologia de replicação, talvez seja necessário aguardar algum tempo até obter o valor atualizado em todos os controladores de domínio.
Agora, provarei que o atributo "lastlogon" só é atualizado em um controlador de domínio em que o usuário foi autenticado e que, na verdade, reflete o usuário da última vez que efetuou logon. Eu desabilitei a placa de rede do DC02 para forçar meu usuário "lastlogondate" usando o DC01 para autenticação e loguei mais uma vez.
Veja o que acontece agora:
Vemos que o único atributo que foi atualizado é o "lastlogon". Lembra? O valor anterior era 132084605320048519 e o valor atual é 132084620075399617. Quando uso [datetime] para convertê-lo em um valor legível, temos 24 de julho de 2019 às 13:13:27.
Agora, eu coloquei o DC02 de volta em rotação e vamos ver o que temos:
Como esperado, nada mudou. A ideia e que o atributo "lastlogondate" seja alterado após 9 a 14 dias a partir de agora ou que "lastlogon" seja atualizado na próxima vez que o usuário lastlogondate se autenticar no DC02.
Vamos fazer isso agora. Vou tirar DC01 de rotação para forçar a autenticação contra o DC02. Espero ver o atributo "lastlogon" preenchido agora.
E aqui vamos nós pessoal. Agora, como o usuário autenticado no DC02, vemos "lastlogon" preenchido e, quando convertemos, vemos 24 de julho de 2019 às 1:28:06.
Então, isso prova meus pontos anteriores, mas ainda há uma coisa que eu gostaria de mostrar para que possamos fechar terminar esse assunto. Quando poderemos ver o atributo "lastlogondate" atualizado? Depois de 15 dias?
Então, eu fiz uma viagem no tempo para o futuro e fui para o dia 15 de agosto de 2019. :)
Alterei a data no meu controlador de domínio DC02 e minha estação de trabalho para 15 de agosto e fiz logon usando o usuário "lastlogondate". Veja isso. Você ficará surpreso !!! :)
Isso não é incrível? Quando a teoria encontra a prática?
Como você pode ver agora, como 15 de agosto comparado com 24 de julho é maior que 14, o atributo "lastlogondate" é atualizado depois que o usuário lastlogondate faz logon.
E isso e tudo por hoje pessoal ! Espero que isso tenha sido útil e obrigado novamente pela visita.
Aqui está um ótimo artigo que Warren escreveu sobre isso:
How are you doing today ?
Today we are going to talk about one very common situation that most of us get quite frequently.
How to come up with a list of users that have not logged on for "X" days.
From time to time, we should clean stuff up and many times, it is hard to keep AD database clean due to a number of facts that is out of control of the IT department. People leave company, get fired and not all times, IT department get notified in the way it should. You may end up with a bunch of disabled accounts but maybe, not all of them get moved to a disabled OU, or even get deleted when time comes, if company policy allows for account deletion.
Powershell can help us to get a comprehensive list of users that have not logged on for whatever number of days make sense in your environment.
There are tons of powershell scripts out there that can do this for you but one thing that is very important to understand is that, there are two attributes that can confuse you and might give you an inaccurate answer. Once you understand the differences between them, you can leverage your script of choice and provide an almost 100% accurate report to your boss. I will leave up to you to get your script of choice and now I will explain the differences between these two attributes.
LastLogon and LastLogonDate.
LastLogon
It will record timestamp ONLY on a domain controller where the object authenticated against. It is probably the most accurate one but, it will only give you an accurate response if you query the right domain controller. This attribute is not replicated to other domain controllers. This may not be practical for companies that have many, like hundreds of domain controllers but might be a good idea for small companies.
LastLogonDate
This one is just a human readable translation of LastLogonTimeStamp. The advantage here is , because it is replicated to all domain controllers, you will get the same timestamp regardless of what domain controller you query, as long as all domain controllers have converged. The downside is, by design, to avoid replication storm caused by many objects (users,computers,etc.) logging in on a daily basis and having potentially thousands of updates being sent to domain controllers, Microsoft put in place a 9 - 14 days delay on this particular attribute. Meaning, the only time this attribute will be updated is when the timestamp is greater than 9 - 14 days compared to its current value.
e.g - Bob logs on today, for the first time and LastLogonTimestamp is populated with today's date. As a result, LastLogonDate will show today's date and all domain controllers are notified and update Bob's LastLogonTimeStamp attribute. If you query Bob's account, no matter which domain controller you use, you should get the same result.
Tomorrow, Bob logs on again and because tomorrow and today's date are not greater than 14, it's only a 1 day difference, the attribute will not be updated. Then, fifteen days from now, when Bob logs on again, the difference between 15 days from now and the last logon date will be greater than 14. at this point, LastLogonTimeStamp gets a new value and the attribute is updated on all domain controllers.
Let's check picture below to get a better understanding
- My environment has 2 domain controllers (DC01 and DC02);
- I created an user named lastlogondate for this test;
- I logged on to my workstation as user lastlogondate.
Let's explain what happened here in plain english.
Because "lastlogon" attribute is empty on ( number 1) and we already know "lastlogon" attribute does not replicate to all domain controllers, we can assume my user "lastlogondate" authenticated against DC01. Why? Because "lastlogon" is populated in DC01 (number 2). It has this weird value 132084605320048519 that when I use [datetime] do convert it, I got July 24th 2019 at 12:48:52 exactly what lastlogondate attribute shows on both, DC01 and DC02.
This proves my point that "lastlogontimestamp", which is the same as "lastlogondate" attribute gets replicated to all other domain controllers. Just keep in mind, depending on your replication topology, you may need to wait some time until you get the updated value on all domain controllers.
Now, I will prove that "lastlogon" attribute only gets updated on a domain controller the user authenticated against and that it actually reflects last time user logged on. I've gone ahead and disabled the network card of DC02 to force my "lastlogondate" user using DC01 for authentication and logged on one more time.
See what happens now :
We see that the only attribute that got updated is "lastlogon". Remember? Previous value was 132084605320048519 and current value is 132084620075399617. When I use [datetime] to convert it to a human readable value I got July 24th 2019 at 1:13:27 PM.
Now, I've put DC02 back into rotation and let's see what we get:
As expected, nothing has changed. I would expect "lastlogondate" attribute to change after 9 - 14 days from now or, "lastlogon" gets updated next time lastlogondate user authenticates against DC02.
Let's do this now. I will take DC01 out of rotation to force authentication against DC02. I expect seeing "lastlogon" attribute populated now.
And here we go folks. Now, since user authenticated against DC02 we see "lastlogon" populated and when we convert we see July 24th 2019 at 1:28:06 PM.
So, this proves my earlier points but, there is still one thing I'd like to show you so we can close the loop. When will we be able to see "lastlogondate" attribute updated ? After 15 days ?
So, I did a time travel to the future and fast forwarded to August 15th 2019. :)
I changed the date in my domain controller DC02 and my workstation to August 15th and I logged on using "lastlogondate" user. Check this out. You will be amazed !!! :)
Isn't that awesome ?? When theory meets practice ?
As you can see now, because August 15th compared with July 24th is greater than 14, "lastlogondate" attribute gets updated after lastlogondate user logs on.
There you have it folks. I hope this has been helpful and thanks again for stopping by.
Here is a great article that Warren wrote about this: ClickHere
===========================================
Portugues
E ai pessoal !!
Como vocês estão hoje ?
Hoje vamos falar sobre uma situação muito comum que a maioria de nós recebe com bastante frequência.
Como criar uma lista de usuários que não se logam no AD depois de "X" dias.
De tempos em tempos, devemos dar manutenção na base do AD e muitas vezes é difícil manter a base do AD clean como deveria ser devido a uma série de fatos que estão fora de controle do departamento de TI. As pessoas saem da empresa, são demitidas e nem sempre, o departamento de TI é notificado da maneira como deveria.Você pode acabar com várias contas desativadas mas talvez, nem todas sejam movidas para uma unidade organizacional própria para isso ou sejam devidamente excluídas, se assim a política da empresa permitir.
Powershell pode nos ajudar a obter uma lista de usuários que não estão se logam desde X dias, ou o intervalo que fizer sentido para você.
Existem muitos scripts de powershell por aí que podem fazer isso por você, mas uma coisa muito importante é entender dois atributos que podem confundir vocês e dar uma resposta imprecisa.
LastLogon e LastLogonDate.
LastLogon
Ele guardará o timestamp SOMENTE no controlador de domínio no qual o usuário foi autenticado. É provavelmente o mais preciso, mas só funcionará se você consultar o controlador de domínio correto. Este atributo não é replicado para outros controladores de domínio. Isso pode não ser prático para empresas que possuem muitos, como centenas de controladores de domínio, mas pode ser uma boa ideia para pequenas empresas.
LastLogonDate
Este é apenas uma tradução legível de LastLogonTimeStamp. Você pode obter um timestamp legível logo após o comando powershell, pois LastLogonTimeStamp é difícil de ler. A vantagem é que, como ele é replicado para todos os controladores de domínio, você obterá o mesmo timestamp em não importa qual controlador de domínio você consultar, contanto que todos os controladores de domínio ja tenham convergido. A desvantagem é, por design, para evitar replication storm causada por muitos objetos que fazem logon diariamente e provocar, potencialmente milhares de atualizações enviadas para os controladores de domínio, a Microsoft implementou um atraso de 9 a 14 dias para que esse atributo seja atualizado. Ou seja, a única vez que esse atributo será atualizado em todos os controladores de domínio é quando o timestamp é maior que 9 a 14 dias comparando com o valor atual desse atributo.
Por exemplo: Bob faz logon hoje, pela primeira vez, e LastLogonTimestamp é preenchido com a data de hoje. Como resultado, LastLogonDate mostrará a data de hoje e todos os controladores de domínio serão notificados e atualizarão o atributo LastLogonTimeStamp de Bob. Se você consultar a conta de Bob, independentemente do controlador de domínio usado, você deverá obter o mesmo resultado.
Amanhã, Bob faz logon novamente e, porque amanhã e a data de hoje não são maiores que 14, é apenas uma diferença de 1 dia, o atributo não será atualizado. Então, quinze dias a partir de agora, quando Bob fizer logon novamente, a diferença entre 15 dias a partir de agora e a data do último logon será maior que 14. neste momento, LastLogonTimeStamp obtém um novo valor e o atributo é atualizado em todos os controladores de domínio.
Vamos verificar a imagem abaixo para obter uma melhor compreensão
- Meu ambiente tem 2 controladores de domínio (DC01 e DC02);
- Eu criei um usuário chamado lastlogondate para este teste;
- Eu entrei na minha estação de trabalho como usuário lastlogondate.
Vamos explicar o que aconteceu aqui em Portugês simples.
Como o atributo "lastlogon" está vazio em (número 1) e já sabemos que o atributo "lastlogon" não é replicado para todos os controladores de domínio, podemos assumir que meu usuário "lastlogondate" foi autenticado pelo DC01. Por quê? Porque "lastlogon" é preenchido em DC01 (número 2). Tem esse valor estranho 132084605320048519 que quando eu uso [datetime] para converter, eu tenho 24 de julho de 2019 às 12:48:52 exatamente o que o atributo lastlogondate mostra em ambos, DC01 e DC02.
Isso prova meu argumento de que o atributo "lastlogontimestamp", que é o mesmo que "lastlogondate", é replicado para todos os outros controladores de domínio. Apenas tenha em mente que, dependendo da topologia de replicação, talvez seja necessário aguardar algum tempo até obter o valor atualizado em todos os controladores de domínio.
Agora, provarei que o atributo "lastlogon" só é atualizado em um controlador de domínio em que o usuário foi autenticado e que, na verdade, reflete o usuário da última vez que efetuou logon. Eu desabilitei a placa de rede do DC02 para forçar meu usuário "lastlogondate" usando o DC01 para autenticação e loguei mais uma vez.
Veja o que acontece agora:
Vemos que o único atributo que foi atualizado é o "lastlogon". Lembra? O valor anterior era 132084605320048519 e o valor atual é 132084620075399617. Quando uso [datetime] para convertê-lo em um valor legível, temos 24 de julho de 2019 às 13:13:27.
Agora, eu coloquei o DC02 de volta em rotação e vamos ver o que temos:
Como esperado, nada mudou. A ideia e que o atributo "lastlogondate" seja alterado após 9 a 14 dias a partir de agora ou que "lastlogon" seja atualizado na próxima vez que o usuário lastlogondate se autenticar no DC02.
Vamos fazer isso agora. Vou tirar DC01 de rotação para forçar a autenticação contra o DC02. Espero ver o atributo "lastlogon" preenchido agora.
E aqui vamos nós pessoal. Agora, como o usuário autenticado no DC02, vemos "lastlogon" preenchido e, quando convertemos, vemos 24 de julho de 2019 às 1:28:06.
Então, isso prova meus pontos anteriores, mas ainda há uma coisa que eu gostaria de mostrar para que possamos fechar terminar esse assunto. Quando poderemos ver o atributo "lastlogondate" atualizado? Depois de 15 dias?
Então, eu fiz uma viagem no tempo para o futuro e fui para o dia 15 de agosto de 2019. :)
Alterei a data no meu controlador de domínio DC02 e minha estação de trabalho para 15 de agosto e fiz logon usando o usuário "lastlogondate". Veja isso. Você ficará surpreso !!! :)
Isso não é incrível? Quando a teoria encontra a prática?
Como você pode ver agora, como 15 de agosto comparado com 24 de julho é maior que 14, o atributo "lastlogondate" é atualizado depois que o usuário lastlogondate faz logon.
E isso e tudo por hoje pessoal ! Espero que isso tenha sido útil e obrigado novamente pela visita.
Aqui está um ótimo artigo que Warren escreveu sobre isso:
Comments
Post a Comment