# Identify and disable users who have not logged in in x days $disableDaysNeverLoggedIn=(Get-Date).AddDays(-($neverLoggedInDays)) $disableDaysInactive=(Get-Date).AddDays(-($inactiveDays)) # Remove "-WhatIf"s before putting into production. # New-EventLog -LogName Application -Source "DisableUsers.ps1" Only needed once on each machine running this script. # comment out the Write-EventLog lines if no event logging is # Also, make sure to create the EventLog source before running, or
# days unless this attribute is set to a shorter interval. # default lastLogonDate only replicates between DCs every 9-14 # Set msDS-LogonTimeSyncInterval (days) to a sane number. I then created the below Powershell script in a directory. I then right-clicked my domain and selected “Properties.” The msDS-LogonTimeSyncInterval was “not set” as expected, so I changed it to “1” to ensure that the timestamp was replicated daily for all users. Under “View”, I selected “Advanced Features” to expose the attributes I needed to view or change. Be aware before using this in production that it will increase replication traffic, especially during periods when many users are logging in simultaneously domain controllers will be replicating this attribute daily instead of every 9 to 14 days.Īs none of these caveats applied in my homelab, I launched Active Directory Users and Computers. For the purposes of my relatively small domain, I’m comfortable with increasing the replication frequency of lastLogonTimeStamp. For more information, see this blog post.Ĭaveats aside, this is what we have to work with. Also, there’s a Kerberos operation called “Service-for-User-to-Self” (“S4u2Self”) which allows services to request Kerberos tickets for a user to perform group and access checks for that user without supplying the user’s credentials. Otherwise, it’s the same as lastLogonTimeStamp and has the same 9-to-14-day replication delay.Īnother caveat for all three of these attributes is that the timestamp is updated for many logon operations, including interactive and network logons and those passed from another service such as RADIUS or another Kerberos realm. Technically that’s true it’s a copy of lastLogonTimeStamp that the domain controller has converted to a standard date/time for you. LastLogonDate – There are a lot of blogs that will state that this is not a replicated timestamp. In addition, this attribute is stored in a 64-bit signed numeric value that must be converted to a proper date/time to be useful in Powershell. Needless to say, this is not useful for our purposes. Therefore, by default, lastLogonTimeStamp is replicated somewhere between 9 and 14 days after the previous replicated value. By default the msDS-LogonTimeSyncInterval attribute is unset, which makes it default to 14 days. The value of lastLogonTimeStamp is replicated based on a random time interval of up to five days before the msDS-LogonTimeSyncInterval. To reduce domain replication traffic, the replication frequency depends on a domain attribute called msDS-LogonTimeSyncInterval. However, it is not replicated immediately. LastLogonTimeStamp – This is a replicated version of the lastLogon timestamp. This means that any script that uses this attribute will need to pull the attribute from every domain controller in the domain and then use the most recent of those timestamps to determine that actual last logon. Each domain controller retains its own version of this attribute with the last timestamp that the user logged onto that particular domain controller. LastLogon – This provides a time stamp of the user’s last logon, with the caveat that it is not a replicated attribute.
Here are the three available AD attributes: The Elusive Time StampĪctive Directory actually provides three different timestamps for determining when a user last logged on, and none of them are awesome. For instance, Active Directory doesn’t actually provide very good tools out of the box for determining when a user last logged on. After reading up on the subject, I found that this is not quite as straightforward as it may seem.
USING WINDOWS 365 PRODUCT AFTER DEACTIVATED SOFTWARE
There are software products on the market that provide this functionality, but for my homelab, my goal is do this on the cheap.
This is surprising since many companies have such a policy and some information security standards such as PCI require it. While Microsoft provides the ability to set an expiration date on an Active Directory user account, there’s no built-in facility in Group Policy or Active Directory to automatically disable a user who hasn’t logged in in a defined period of time.
0 kommentar(er)
