Use PowerShell to search for accounts in Active Directory that have gone stale!
Dear Microsoft and Active Directory Friends, In a company/organization, employees come and go. This is completely normal and nothing out of the ordinary. But often, from a technical point of view, the Active Directory is somewhat forgotten and account cleanup is rarely or never done. This means there are outdated or no longer current accounts (ghost accounts). This is not a great situation from either a security or administrative perspective. In this article I would like to show you a possible way. But what exactly does "stale" accounts mean? Let me explain my definition to you: 1. Haven't logged in for X days 2. Hasn't logged in 3. Created at least X days ago We can start first with the CMDLET "Search-ADAccount". This gives once a first result. The #tags are comments. #Using Search-ADAccount Search-ADAccount -AccountInactive -TimeSpan '90.00:00:00' -UsersOnly How many accounts would there be? (Search-ADAccount -AccountInactive -TimeSpan '90.00:00:00' -UsersOnly).count But there are a lot of them. Now let's work with filters. We explicitly examine the "LastLogonTimeStamp" property. For an account that has never been logged in, no value is displayed. #Using a filter Get-ADUser "Freida Lazarus" -Properties LastLogonTimeStamp | Select-Object Name,LastLogonTimeStamp An account that has been used for a login will show a value. This number represents a date, this is in FileTime format. We can generate such value. For example, one hour in the past. $LogonDate = (Get-Date).AddHours(-1).ToFileTime() $LogonDate So, for example, we can check who has not logged in during the last hour. Of course we would not work with only one hour. But I'm going to keep working with this one hour so I can illustrate it to you better. #If it is older than $LogonDate $LogonDate = (Get-Date).AddHours(-1).ToFileTime() Get-ADUser -Filter {LastLogonTimeStamp -lt $LogonDate} Or in numbers it would be so many accounts. Now we search for all accounts that do not have this value. #If it doesn't have value Get-ADUser -Filter {LastLogonTimeStamp -notlike "*"} -Properties LastLogonTimeStamp | Select-Object Name,LastLogonTimeStamp But what if the user has not yet logged in because the account has just been created? Let's take a closer look at this as well. #And if the account was created before $createdDate $createdDate = (Get-Date).AddDays(-14) Get-ADUser -Filter {Created -lt $createdDate} -Properties Created | Select-Object Name,Created Bringing all this together, we can determine what exactly "stale" means to us. #Add them all together: $filter = { ((LastLogonTimeStamp -lt $logonDate) -or (LastLogonTimeStamp -notlike "*")) -and (Created -lt $createdDate) } Get-ADuser -Filter $filter | Select-Object SamAccountName We can create a function from it. Function Get-ADStaleUsers { [cmdletbinding()] Param ( [datetime]$NoLogonSince = (Get-Date).AddDays(-90), [datetime]$CreatedBefore = (Get-Date).AddDays(-14) ) $NoLogonString = $NoLogonSince.ToFileTime() $filter = { ((LastLogonTimeStamp -lt $NoLogonString) -or (LastLogonTimeStamp -notlike "*")) -and (Created -lt $createdBefore) } Write-Host $filter Get-ADuser -Filter $filter } # Usage Get-ADStaleUsers This way we can work with our own values. Moreover, we can delete the accounts directly afterwards or at least check with -WhatIf what exactly would be done! Get-ADStaleUsers -NoLogonSince (Get-Date).AddDays(-30) -CreatedBefore (Get-Date).AddDays(-7) | Remove-ADUser -WhatIf Annotation: In the search result from above two Built-In accounts (e.g.: krbtgt) are displayed among others (this is how it turned out in the search). Such Built-In accounts should never be deactivated or even worse deleted, this has very negative effects on the function of the Active Directory. You should never delete user accounts directly. Instead, the accounts should be disabled for some time first. If the accounts were used for other purposes (unknown to you). You should also avoid setting user accounts as service accounts. This is not according to Microsoft "Best Practice". For service accounts, use the so-called group managed service accounts. I realize that this was not necessarily spectacular. It was simply important for me to share my experience with you. Nevertheless, I hope that this article was helpful. Thank you for taking the time to read the article. Best regards, Tom Wechsler P.S. All scripts (#PowerShell, Azure CLI, #Terraform, #ARM) that I use can be found on github! https://github.com/tomwechslerAdd Passkey support to Active Directory
Everyone, Please go to the feedback hub and upvote my suggestion to add passkey support to Active Directory Domain Services: https://aka.ms/AAw8z54 The reason I am recommending this is because there needs to be a standard way to use passkeys in an AD environment.10 hidden Hyper-V features you should know about!
Microsoft added some amazing new features and improvements to Hyper-V over the past few years. A lot of them you can use in Windows Server 2016 Hyper-V today, but there are also a lot of features hidden in the user interface and they are also included in Windows 10 Pro or Enterprise. I think this list should you a good idea about some of them. https://www.thomasmaurer.ch/2017/09/10-hidden-hyper-v-features-you-should-know-about/Add drivers to the Windows Server 2019 ISO Image
In this blog article, I am going to show you how you can add drivers to a Windows Server 2019 ISO Image or WIM file using PowerShell and the DISM module. This will allow you to already have the latest drivers within the Windows Server installation image when you install Windows Server 2019. Find more here: https://www.thomasmaurer.ch/2019/07/add-drivers-to-a-windows-server-2019-iso-image/
Software restriction policy in AD with incompatibility in Windows 11
An Active Directory was configured on Windows Server 2022 STD, the software blocking policy works correctly on Windows 10, however on Windows 11 the same policy is not applied correctly. Checking, I found an article where it says exactly that there is an incompatibility. Here is the link to the article: https://borncity.com/win/2022/11/08/windows-11-22h2-no-longer-supports-software-restriction-policies-srp/ Video link testing on Windows 10/Windows Server : https://drive.google.com/file/d/1AnwBjoRkZfp3SvqzNIRP9FNZvDH3IzSy/view?usp=sharing Video link testing on Windows 11: https://drive.google.com/file/d/1kRP0c1zxn0LI9m-T2-KLytgdTzJybd8V/view?usp=sharing Any ideas on how to get around this problem?Set up and configure Microsoft Local Administrator Password Solution (LAPS)!
Dear Microsoft and Active Directory Friends, Imagine the following scenario. All your systems (Windows clients) have been set up on the basis of a so-called "golden image". "Golden image" means that you have set up a reference system, made all settings, installed apps, etc. Then shutdown the system with Sysprep (generalized). Then set up all other clients with this image. This is all great, but by setting up the Windows client with the "Golden Image", the same password is now available for the local administrator account on every system. Oops! But why should that be a problem? Here is my personal top 3 why this is a bad idea: 1. Employees leave the company knowing these passwords. 2. If all passwords are the same, a lateral pass-to-hash attack is simplified in the event of an infection or attack. 3. If you ever have to give a password to the user (yes, shouldn't happen, but can), then they know the password for all systems. This is where Microsoft Local Administrator Password Solution (LAPS) comes in. Now let's start setting up Microsoft LAPS together. First of all, we need the necessary software. You can download everything you need here: https://www.microsoft.com/en-us/download/details.aspx?id=46899 There are two components in the .msi file I selected. First, the client-side extension (a kind of agent) and the administration components (a small GUI). But we'll look at that a little later. Now that we have downloaded the "tool". We continue in the Active Directory. First we need to check where the client systems are (in which organizational unit) so that we can later configure them with PowerShell. Now we know where the client systems are. Now let's start with the installation of the management tools. In my test environment I use the DC01 system (this is a domain controller) because I have no other system available. You can also use another server for this. As you can see there are several components which can be installed. The default is to install the CSE only. I have customized this selection because I want to install the management tools on this system. File Reference: The installation for the Fat client UI is done to folder: %ProgramFiles%\LAPS AdmPwd.UI.exe AdmPwd.Utils.config AdmPwd.Utils.dll The installation for the PowerShell modules is done to folder: %WINDIR%\System32\WindowsPowerShell\v1.0\Modules\AdmPwd.PS AdmPwd.PS.dll AdmPwd.PS.format.ps1xml AdmPwd.PS.psd1 AdmPwd.Utils.config AdmPwd.Utils.dll %WINDIR%\System32\WindowsPowerShell\v1.0\Modules\AdmPwd.PS\en-us AdmPwd.PS.dll-Help.xml The installation for the Group Policy files is done to folders: %WINDIR%\PolicyDefinitions AdmPwd.admx %WINDIR%\PolicyDefinitions\en-US AdmPwd.adml Next, we will customize the schema right away on this system using PowerShell. For this I use the PowerShell ISE with elevated privileges. Of course you can use the editor you feel comfortable with. (# are Comments) #Extend the AD Schema Import-module AdmPwd.PS Update-AdmPwdADSchema Now we need to adjust the permissions of the computer objects. This is required so the machine can update the password and expiration timestamp of its own managed local Administrator password. #Change Computer object permissions Set-AdmPwdComputerSelfPermission -OrgUnit "Clients" Add the permission (extended right) on the computer accounts to group(s) or user(s) that will be allowed to read (and also the write permissions if you wish) the stored password of the managed local Administrator account on managed computers. #Assign permissions to the group for password access #The extended permissions are only applied to the Domain Admins group Find-AdmPwdExtendedRights -Identity "Clients" #We need to grant the read permissions to "ITAdmins" Security group Set-AdmPwdReadPasswordPermission -Identity "Clients" -AllowedPrincipals prime\ITAdmins #We need to grant the write permissions to "ITAdmins" Security group Set-AdmPwdResetPasswordPermission -OrgUnit "Clients" -AllowedPrincipals prime\ITAdmins #Let's check Find-AdmPwdExtendedRights -Identity "Clients" Now we move on to the group policies. In my test environment there is a so-called central policy store. Depending on how your environment is set up, you need to make sure that the following files are also available at your end. If you are using a central policy store, copy the following two files to the central policy store. The two files can be found in the following path: %WINDIR%\PolicyDefinitions AdmPwd.admx %WINDIR%\PolicyDefinitions\en-US AdmPwd.adml It continues with the creation of a new group policy. Open Group Policy Management and create a new Group Policy object. The settings are located under Computer Configuration\Administrative Templates\LAPS Management of password of local administrator account must be enabled so as the CSE can start managing it. By default this solution uses a password with maximum password complexity, 14 characters and changes the password every 30 days. You can change the values to suit your needs by editing a Group Policy. If you have decided to manage custom local Administrator account, you must specify its name in Group Policy (In my example it is admin). If you do not want to allow setting planning password expiration of admin account for longer time than maximum password age, you can do it in GPO. Now we need to link our new group policy object to the correct "location". Now, before we update the group policies on the client systems, we install the AdmPwd GPO extension on the clients. These can be installed/updated/uninstalled on clients using a variety of methods including the Software Installation feature of Group Policy, SCCM, login script, manual install, etc. If you want to script this you can use this command line to do a silent install: msiexec /i <file location>\LAPS.x64.msi /quiet or Just change the <file location> to a local or network path. Example: msiexec /i \\server\share\LAPS.x64.msi /quiet Now update the group policies and restart the system out of habit. Now we check if everything works as prepared. In the Active Directory Users and Computer tool, make sure that you have selected the advanced features. Right click on the Computer object and switch to the Attribute Editor tab and lo and behold, the password is displayed here. Now let's look at the password in the LAPS graphical tool. Exactly the same password. Great! Works also with the PowerShell. To manually reset the password, just click the Set button in LAPS UI tool. When a Group Policy refresh runs, password will be reset. You can also plan password expiration for the future. To do so, enter desired expiration date/time into respective field. You can also reset the password using PowerShell. For Example: I realize that this was not necessarily spectacular. It was simply important for me to share my experience with you. Nevertheless, I hope that this article was helpful. Thank you for taking the time to read the article. Best regards, Tom Wechsler P.S. All scripts (#PowerShell, Azure CLI, #Terraform, #ARM) that I use can be found on github! https://github.com/tomwechsler
Windows Server 2019: The component store has been corrupted. Error 0x80073712
Hi all, I'm trying to install the Server Backup feature on our 2019 Server, but it results in this error: Any ideas on what may have caused this, and how to solve it? The server was installed about 5 months ago, and the installation is basically stock, not much changes made. Thanks in advance.Building a Windows Server Lab with an Intel NUC
With the release of Windows Server 2019, which includes a ton of Hybrid Cloud integration features, it was time to build a new lab environment. The plan is to create a lab and demo environment for my presentations and workshops. Check out more here: https://www.thomasmaurer.ch/2018/11/windows-server-lab-intel-nuc/
