Get Smarter

A cyberattack isn’t a sudden single event, but a storyline compromised of multiple stages. First is the initial compromise, followed by the establishment of a foothold or beachhead that the attackers will base operations from. From there the attackers move laterally across the network to perform reconnaissance. The objectives here are to escalate privilege and identify high-value data to target. The final stage is the actual attack itself.

The initial compromise is usually conducted using a compromised standard user account that was captured using a credential stuffing attack or phishing email. To achieve their mission, attackers must work to escalate their privilege to gain access to all areas of the network. This means targeting a privileged user next such as a domain administrator or senior executive. This process may involve the taking over of multiple accounts in the process.

This is why you should enable auditing that will target privilege escalation activities. One option is to enable “Audit Directory Service Changes” which will alert you when a change is made to an AD object. This could be adding a user account to a privilege group for instance or resetting a password. Any alert will provide information about the old and new properties of the changed objects.

To do so, create a GPO and navigate to Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration as shown below.

You can also enable auditing for “Privilege Use” which will alert you when a security principle is exercising a user right or privilege. You can do so by creating a GPO and going to Computer Configuration > Windows Settings > Local Policies > Audit Policy as shown in the screenshot below.

Many K12 school districts are concerned about providing a secure environment for online testing. The integrity of online testing relies on the ability to prevent students from opening a new browser tab to google for answers or copy exam question text to an archive. Take a Test is a secure browser provided by Microsoft that can be set up to only provide access to a single URL or a list of URLs. Students cannot perform the following actions when taking an exam using Microsoft Take a Test:

• Access other applications
• Open another browser tab
• Print or use screen capture
• Change system settings
• Access Cortona
• Access content copied to the clipboard

Microsoft Take a Test is a secured instance of Intune, not an application. There are 2 modes for Microsoft Take a Test. The first is intended for a brief test or quiz that a teacher might wish to administer. By creating a secure assessment URL and sending it to students via email or OneNote, teachers may accomplish this task quickly and easily. The assessment link is constructed in three stages using Microsoft's secure link generator.

• Paste the link to the assessment URL
• Select the options you want to allow during the test
• Generate the link by selecting the button Create link

Below is a screenshot of the secure generator page.

When the students click on the link, Edge will open a secure test taking session for the student to take the exam. Keep in mind that the student must be logged on to a Windows machine already. This deployment method would be a challenge for a large-scale exam such as a high school proficiency or college entrance exam. This is where the Take a Test in Kiosk Mode is better suited. This mode can be deployed using either regular Intune or Intune Education edition.

Intune Education edition is specifically designed to meet the needs of schools and provides a simpler interface than regular Intune. Intune Education edition is the easiest way to deploy Take a Test in kiosk mode as the settings are available in the menu interface. To configure devices for Take a Test, go to Groups and select a group to configure Take a Test for. Then go to Windows device settings > Take a Test profiles and select “Assign a new Take a Test profile. Here you will specify a Profile Name, Account Name, Assessment URL, and an option Description. Finish it by selecting Create and assign profile as shown in the screenshot below.

Once deployed, test takers can log on to a Windows machine using the test taker profile. They will only be able to access the test in a single browser session.

You can also deploy this mode using regular Intune as well although it is a little messier because you must provide the following OMA-URI settings as shown below.

OMA-URI:

./Vendor/MSFT/Policy/Config/LocalPoliciesSecurityOptions/InteractiveLogon_DoNotDisplayLastSignedIn
Data Type: Integer
Value: 1

OMA-URI: 

./Vendor/MSFT/Policy/Config/WindowsLogon/HideFastUserSwitching

Data type: Integer

Value: 1

OMA-URI: ./Vendor/MSFT/SharedPC/AccountModel

Data type: Integer

Value: 1

OMA-URI: ./Vendor/MSFT/SharedPC/EnableAccountManager

Data type: Boolean

Value: True

OMA-URI: ./Vendor/MSFT/SharedPC/KioskModeAUMID

Data type: String

Value: Microsoft.Windows.SecureAssessmentBrowser_cw5n1h2txyewy!App

OMA-URI: ./Vendor/MSFT/SharedPC/KioskModeUserTileDisplayText

Data type: String

Value: Take a Test (or a string of your choice to display in the sing-in screen)

OMA-URI: ./Vendor/MSFT/SecureAssessment/LaunchURI

Data type: String

Value: 

The screenshot below shows all OMA-URIs fully inputted.

Finish the creation wizard out by assigning the configuration profile to a group and you are done. Students will again only have access to the active test session in a locked down desktop environment.

In my two previous blogs I outlined the improved features and capabilities of the latest version of LAPS that was introduced made available with the Windows Update released on April 11, 2023. The new version called Windows LAPS (that I refer to as LAPS2), addressed some of the limitations of the original version called Legacy LAPS (or LAPS1). Those who have relied on LAPS1 will certainly want to upgrade to the newest version but what happens when you bring LAPS2 into a LAPS1 environment? The short answer is that you cannot run both versions of LAPS on the same machine simultaneously. Any settings that are singular to one LAPS version are not accessible in the other one and vice versa.

When you bring LAPS2 into an environment that has preexisting instances of LAPS1 you have two options. Either delete all instances of LAPS1 before implementing LAPS2 or use legacy Microsoft LAPS emulation mode to accommodate both to some degree.

Legacy Microsoft LAPS Emulation Mode Limitations

The original LAPS was implemented by installing the Microsoft LAPS Group Policy Client Side Extension. It is that extension that retrieves the LAPS password information from AD and stores it in the computer’s local security database. You can detect whether a computer has the installed extension by looking for the following registry key:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\{D76B9641-3288-4f75-942D-087DE603E3EA}

Once you deploy LAPS2 to a machine already running LAPS1, that computer is running in emulation mode. Legacy Microsoft LAPS emulation mode prevents both LAPS from running simultaneously as this would create a security risk. That means that while the computer has LAPS2 installed, it is still restricted to some of the limitations of LAPS1. This means that:

1. You can only store passwords to local AD as only LAPS2 supports Azure AD and local AD.

2. Passwords will be stored in clear-text form. LAPS1 does not support password encryption so while the newest version of LAPS does, you cannot take advantage of it.

3. The Windows Server Active Directory Users and Computer management console doesn't support reading or writing legacy Microsoft LAPS schema attributes.

4. You will not be able to use some of the newer LAPS2 scripts. For instance, cannot you use the

Set-LapsADPasswordExpirationTime cmdlet to modify the existing legacy LAPS password expiration attribute.

5. All Windows LAPS policy knobs that aren't supported by legacy Microsoft LAPS will default to their disabled or default settings.

Note that if you try to install LAPS1 on a machine that already has LAPS2, LAPS1 will be ignored. In other words, whichever version of LAPS is installed first takes precedence over the other.

You can tell if a computer is in emulation mode by going to Event Viewer and navigating to Application and Service Logs > Microsoft > Windows > LAPS > Operational and look for the 10023 event which will show Legacy LAPS as the policy source.

Switching from Emulation Mode

Once you have implemented LAPS2, you will want to eventually move on from emulation mode. You can disable Microsoft LAPS emulation mode by creating a REG_DWORD registry value named BackupDirectory under the:

HKLM\Software\Microsoft\Windows\CurrentVersion\LAPS\Config key

and set it to the value of zero. This will prevent LAPS2 from entering legacy Microsoft LAPS emulation mode regardless of whether the Windows LAPS CSE is installed or not.

Remember that the new Windows LAPS does not require you to install any type of CSE. Once a computer receives the April 2023 update and is joined to either Azure or Azure AD, it is LAPS2 capable. After that it just needs the LAPS policy to deliver the configured settings.

I am extending my focus on the new Windows LAPS or as I call it, LAPS2. LAPS2 is Microsoft’s newest release of its Local Administrator Solution which fixes some of the shortcomings of its initial release years ago which is now referred to as Legacy LAPS or LAPS1. In Part 1 of this series, we looked at how to implement LAPS2 and configure the new Group Policy settings for it. Today I am going to finish our discussion on implementing LAPS2 in a traditional AD environment.

The New PowerShell Scripts

The new LAPS introduces a new set of PowerShell scripts. To get the scripts you will need to add the new PowerShell module using the command: Get-Command -Module LAPS as shown below in the screenshot below.

Here are the scripts that you will find the most relevant:

Now let’s put two of these scripts into action. LAPS2 introduces new AD attributes but first you need to update the schema using the Update-LapsADSchema command in PowerShell as shown here.

Note that all domain controllers must have the KB5025229 update installed for the command to finish. If the command fails to complete, you can run the Update -LapsADSchema -Verbose command. You can then read the output to either confirm the completion of schema update or find out where the process is erroring out. The screenshot shows a portion of the output which in this case was completed in its entirety.

Next you need to grant permissions to the machines that will be updating their passwords. This is done by setting inheritable permission to the Organizational Unit(s) where the target machines reside using the Set-LapsADComputerSelfPermission command. In the example below I assigned the permission to the Servers OU.

If you don’t see the Distinguished Name in the output, then the command did not complete.

Once the PowerShell commands have been run, deploy your LAPS GPO and you should be good to go. You can confirm the GPO settings were implemented by going to Event Viewer and confirming it in your LAPS file. You can navigate there by going to:

 Application and Service Logs > Microsoft > Windows > LAPS > Operational.

The screenshot below shows that the LAPS policy has been successfully configured.

Now that the LAPS policy is implemented, its time to retrieve the passwords to login to the machines. There are two ways to do this. You can use the following command in PowerShell:

Get-LapADPassword -Identity Server2022 -AsPlainText as shown below.

You can also use Active Directory. Remember we updated the schema which created new AD attributes. Find the designated computer in Active Directory Users & Computers and view its properties. Then click on the LAPS tab to view the LAPS settings as shown below.

Note that you can also modify the expiration date for the LAPS generated password using this tab as shown here.

If you are having trouble getting LAPS to work properly here are two possible gotchas:

• Your LAPS password policy must be in line with your domain password policy. In other words, you cannot configure an 8-character password for LAPS if your domain requires a 10 character and you must enforce the same complexity requirements or greater.
• Be sure to reboot the computers that you are assigning the LAPS policy to.

Emulation Mode

If a machine has already been using the original LAPS (LAPS1) then the new features of LAPS2 will not be available to it. Running both versions within your environment is referred to as LAPS Emulation Mode.  If a LAPS2 policy is present on the machine, it will always take precedence, regardless of how it was applied. In other words, once a LAPS version is applied to a machine, the other one will not work. In our next installment I will discuss how to uninstall LAPS1 from your environment and escape this complexity.