Windows 11 22H2 breaks provisioning with 0x800700b7 errors

Microsoft says the Windows 11 2022 Update is breaking provisioning, leaving Windows 11 enterprise endpoints partially configured and failing to finish installing.

According to Microsoft, this known issue most likely affects provisioning packages (.PPKG files used to configure new endpoints on enterprise or school networks without imaging) during the initial setup phase.

“Using provisioning packages on Windows 11, version 22H2 (also called Windows 11 2022 Update) might not work as expected,” Redmond explained.

“Windows might only be partially configured, and the Out Of Box Experience might not finish or might restart unexpectedly.”

Microsoft added that this issue would not impact IT administrators provisioning Windows devices on their network. The list of unaffected devices also includes Windows systems used in home or small office networks.

Windows admins have been experiencing provisioning problems for more than a week, as confirmed by multiple reports on Microsoft’s Q&A platform.

“Sadly that is true, packages working fine on 21H2 but fail miserably on 22H2 with error 0x800700b7,” one report reads.

“Seems that the package gets indeed installed, just not processed and then errors out for whatever reason.”

Installing Windows 11 provisioning packages
Installing Windows 11 provisioning packages (Microsoft)

Workaround available

Microsoft says it’s currently investigating this newly acknowledged issue and will provide an update with an upcoming release.

Until an official fix for these provisioning problems is available, Redmond suggests provisioning end-user devices before the Windows 11 22H2 upgrade.

“If you can provision the Windows device before upgrading to Windows 11, version 22H2, this will prevent the issue,” Microsoft said.

The company is also investigating user reports of issues with Remote Desktop after installing the Windows 11 22H2 update, causing Remote Desktop clients not to connect, randomly disconnect, or freeze without warning.

Microsoft has also added compatibility holds to block the Windows 11 2022 Update on some systems due to printer issues or blue screens.

Since Tuesday, October 4, Windows 11 22H2 has entered a new deployment phase as it is now available to all seekers on eligible devices.

Related Articles:

Microsoft investigates Windows 11 22H2 Remote Desktop issues

Windows 11 22H2 blocked on some systems due to printer issues

Windows 11 22H2 blocked due to blue screens on some Intel systems

NVIDIA GeForce Experience beta fixes Windows 11 22H2 gaming issues

Microsoft: Windows 11 22H2 now available for all eligible devices

Source :
https://www.bleepingcomputer.com/news/microsoft/windows-11-22h2-breaks-provisioning-with-0x800700b7-errors/

Enabling & Managing Windows Firewall Settings

About this article

In this article, we are going to start by describing what the Windows Firewall feature is and what it is used for. This information will then allow you to enable and manage the Windows Firewall on your Windows PC or laptop. We will cover all the different versions of the Windows operating system that are currently supported by the Secure Remote Worker Validation Tool.

Lets first describe what a firewall actually is.

What is a firewall?

A firewall can be either a physical hardware device, software-based application that you install on your PC, or in the case of the Windows Firewall, an integrated feature of the operating system that is designed to protect your PC against the attack of malicious files. The firewall checks information and data sent across the internet or other networks to your PC. If the firewall detects that the information may contain malicious files then it will block them from reaching your PC, therefore protecting your PC from that threat. Equally, it can prevent you PC sending malicious content to other PCs.

Windows Firewall is an integrated firewall solution that is part of the Windows operating system. In this article, we are going to configure the Windows Firewall to work with Secure Remote Worker. In the following sections, we are going to discuss the process for each of the different version of the Windows operating, starting with Windows 10.

Important configuration note:

You should only have one software firewall solution installed at any one time. If you install additional security software on your PC that also has its own software-based firewall solution, then you will need to disable this if you are to use the Windows Firewall solution.

Enabling the firewall on Windows 10 devices

In this section, we are going to describe the process for enabling the Windows Firewall feature on Windows 10. Follow the steps below to work through the process of enabling the firewall:

  1. Press the Windows key on your keyboard and then start to type in “control panel” in the search box highlighted (1). You will then see the Control Panel App appear at the top of the list as the best match, highlighted (2). Click on the Control Panel App to launch it as shown in the following screenshot:

Click to Zoom

2. You will now see the Control Panel as shown in the following screenshot:

Click to Zoom

3. Now click on System and Security as highlighted (3) in the screenshot above.

4. You will now see the System and Security configuration options as shown in the following screenshot:

Click to Zoom

5. Click on Windows Defender Firewall as highlighted (4) in the above screenshot.

6. You will now see the Windows Defender Firewall configuration screen as shown in the following screenshot:

Click to Zoom

7. Click on Turn Windows Defender Firewall on or off as highlighted (5) in the above screenshot.

8. You will now see the Customize settings for each type of network as shown in the following screenshot:

Click to Zoom
9. First, enable the firewall for private networks. To do this click the radio button for Turn on Windows Defender Firewall under the Private network settings section as highlighted (6) in the previous screenshot.

10. Next, enable the firewall for public networks. To do this click the radio button for Turn on Windows Defender Firewall under the Public network settings section as highlighted (7) in the previous screenshot.

11. The other thing to configure is to make sure that you check the box for Notify me when Windows Defender Firewall blocks a new app for both network settings, so Public and Private. This means that you will be notified when something potentially malicious is blocked.

12. Finally, once configured, click the OK button to close the configuration window, and then click the red X button in the top right-hand corner to close the control panel.

You have now successfully enabled the Windows Firewall for Windows 10 operating systems.

Enabling the firewall on Windows 8.1 devices

In this section, we are going to describe the process for enabling the Windows Firewall feature on Windows 10. Follow the steps below to work through the process of enabling the firewall:

1. Press the Windows key on your keyboard and then start to type in “control panel” in the search box highlighted (1). You will then see the Control Panel icon appear at the top left of the screen in the Results section, highlighted (2). Double click on the Control Panel icon to launch it as shown in the following screenshot:

Click to Zoom

2. You will now see the Control Panel as shown in the following screenshot:

Click to Zoom

3. Now click on System and Security as highlighted (3) in the screenshot above.

4. You will now see the System and Security configuration options as shown in the following screenshot:

Click to Zoom

5. Click on Windows Firewall as highlighted (4) in the above screenshot.

6. You will now see the Windows Firewall configuration screen as shown in the following screenshot:

Click to Zoom

7. Click on Turn Windows Firewall on or off as highlighted (5) in the above screenshot.

8. You will now see the Customize settings for each type of network as shown in the following screenshot:

Click to Zoom

9. First, enable the firewall for domain networks. To do this click the radio button for Turn on Windows Defender Firewall under the Domain network settings section as highlighted (6) in the previous screenshot.

10. Next, enable the firewall for private networks. To do this click the radio button for Turn on Windows Defender Firewall under the Private network settings section as highlighted (7) in the previous screenshot.

11. The final one to enable is the firewall for public networks. To do this click the radio button for Turn on Windows Defender Firewall under the Public network settings section as highlighted (8) in the previous screenshot.

12. The other thing to configure is to make sure that you check the box for Notify me when Windows Firewall blocks a new app for domain settings, public settings, and private settings. This means that you will be notified when something potentially malicious is blocked.

13. Finally, once configured, click the OK button to close the configuration window, and then click the red X button in the top right-hand corner to close the control panel.

You have now successfully enabled the Windows Firewall for Windows 8.x operating systems.

Enabling the firewall on Windows 7 devices

In this section, we are going to describe the process for enabling the Windows Firewall feature on Windows 7. Follow the steps below to work through the process of enabling the firewall:

1. Press the Windows key on your keyboard and then start to type in “control panel” in the search box highlighted (1). You will then see the Control Panel icon appear at the top of the screen under Programs(1), highlighted (2). Double click on the Control Panel icon to launch it as shown in the following screenshot:

Click to Zoom

2. You will now see the Control Panel as shown in the following screenshot:

Click to Zoom

3. Now click on System and Security as highlighted (3) in the screenshot above.

4. You will now see the System and Security configuration options as shown in the following screenshot:

Click to Zoom

5. Click on Windows Firewall as highlighted (4) in the above screenshot.

6. You will now see the Windows Firewall configuration screen as shown in the following screenshot:

Click to Zoom

7. Click on Turn Windows Firewall on or off as highlighted (5) in the above screenshot.

8. You will now see the Customize settings for each type of network as shown in the following screenshot:

Click to Zoom

9. First, enable the firewall for domain networks. To do this click the radio button for Turn on Windows Defender Firewall under the Domain network location settings section as highlighted (6) in the previous screenshot.

10. Next, enable the firewall for private networks. To do this click the radio button for Turn on Windows Defender Firewall under the Home or work (private) network location settings section as highlighted (7) in the previous screenshot.

11. The final one to enable is the firewall for public networks. To do this click the radio button for Turn on Windows Defender Firewall under the Public network location settings section as highlighted (8) in the previous screenshot.

12. The other thing to configure is to make sure that you check the box for Notify me when Windows Firewall blocks a new program for domain settings, public settings, and private settings. This means that you will be notified when something potentially malicious is blocked.

13. Finally, once configured, click the OK button to close the configuration window, and then click the red X button in the top right-hand corner to close the control panel.

You have now successfully enabled the Windows Firewall for Windows 7 operating systems.

Source :
https://kb.thinscale.com/secure-remote-worker-validation-tool/enabling-managing-windows-firewall-settings

Customer Guidance for Reported Zero-day Vulnerabilities in Microsoft Exchange Server

September 30, 2022 updates:

  • Added link to Microsoft Security blog in Summary.
  • Microsoft created a script for the URL Rewrite mitigation steps and modified step 6 in the Mitigations section.
  • Microsoft released the Exchange Server Emergency Mitigation Service (EMS) mitigation for this issue. More information is in the Mitigations section. 
  • Antimalware Scan Interface (AMSI) guidance, and auditing AV exclusions to optimize detection, and blocking of the Exchange vulnerability exploitation in the Detections section.
  • Microsoft Sentinel hunting queries in the Detections section.

Summary

Microsoft is investigating two reported zero-day vulnerabilities affecting Microsoft Exchange Server 2013, Exchange Server 2016, and Exchange Server 2019. The first one, identified as CVE-2022-41040, is a Server-Side Request Forgery (SSRF) vulnerability, and the second one, identified as CVE-2022-41082, allows Remote Code Execution (RCE) when PowerShell is accessible to the attacker.  

Currently, Microsoft is aware of limited targeted attacks using these two vulnerabilities.  In these attacks, CVE-2022-41040 can enable an authenticated attacker to remotely trigger CVE-2022-41082. It should be noted that authenticated access to the vulnerable Exchange Server is necessary to successfully exploit either vulnerability.

We are working on an accelerated timeline to release a fix. Until then, we’re providing mitigations and the detections guidance below to help customers protect themselves from these attacks. 

Microsoft Exchange Online has detections and mitigations to protect customers. As always, Microsoft is monitoring these detections for malicious activity and we’ll respond accordingly if necessary to protect customers.

Microsoft Security Threat Intelligence teams have provided further analysis of observed activity along with mitigation and detection guidance in a new Microsoft Security blog.

We will also continue to provide updates here to help keep customers informed. 

Mitigations

Exchange Online customers do not need to take any action.

The current Exchange Server mitigation is to add a blocking rule in “IIS Manager -> Default Web Site -> URL Rewrite -> Actions” to block the known attack patterns. Exchange Server customers should review and choose only one of the following three mitigation options.

Option 1: For customers who have the Exchange Server Emergency Mitigation Service (EMS) enabled, Microsoft released the URL Rewrite mitigation for Exchange Server 2016 and Exchange Server 2019. The mitigation will be enabled automatically. Please see this blog post for more information on this service and how to check active mitigations.

Option 2: Microsoft created the following script for the URL Rewrite mitigation steps. https://aka.ms/EOMTv2 

Option 3: Customers can follow the below instructions, which are currently being discussed publicly and are successful in breaking current attack chains. 1. Open IIS Manager. 
2. Select Default Web Site.
3. In the Feature View, click URL Rewrite.

4. In the Actions pane on the right-hand side, click Add Rule(s)…  

5. Select Request Blocking and click OK. 

6. Add the string “.*autodiscover\.json.*\@.*Powershell.*” (excluding quotes).
7. Select Regular Expression under Using.
8. Select Abort Request under How to block and then click OK.

9. Expand the rule and select the rule with the pattern .*autodiscover\.json.*\@.*Powershell.* and click Edit under Conditions

10. Change the Condition input from {URL} to {REQUEST_URI}

NOTE: If you need to change any rule it is best to delete and recreate it.

Impact: There is no known effect on Exchange functionality if URL Rewrite is installed as recommended. 

Detections

Microsoft Sentinel 

Based on what we’re seeing in the wild, looking for the techniques listed below will help defenders. Our post on Web Shell Threat Hunting with Microsoft Sentinel also provides guidance on looking for web shells in general.  

The Exchange SSRF Autodiscover ProxyShell detection, which was created in response to ProxyShell, can be used for queries as there are similarities in function with this threat. Also, the new Exchange Server Suspicious File Downloads and Exchange Worker Process Making Remote Call queries specifically look for suspicious downloads or activity in IIS logs. In addition to those, we have a few more that might be helpful when looking for post-exploitation activity:

Microsoft Defender for Endpoint 
Microsoft Defender for Endpoint detects post-exploitation activity. The following alerts can be related to this threat:  

  • Possible web shell installation 
  • Possible IIS web shell
  • Suspicious Exchange Process Execution 
  • Possible exploitation of Exchange Server vulnerabilities 
  • Suspicious processes indicative of a web shell 
  • Possible IIS compromise 

Customers with Microsoft Defender Antivirus enabled can also detect the web shell malware used in exploitation of this vulnerability in-the-wild as of this writing with the following alerts:

  • ‘Chopper’ malware was detected on an IIS Web server 
  • ‘Chopper’ high-severity malware was detected 

Microsoft Defender Antivirus 
Microsoft Exchange AMSI integration and Antivirus Exclusions

Exchange supports the integration with the Antimalware Scan Interface (AMSI) since the June 2021 Quarterly Updates for Exchange. It is highly recommended to ensure these updates are installed and AMSI is working using the guidance provided by the Exchange Team, as this integration provides the best ability for Defender Antivirus to detect and block exploitation of vulnerabilities on Exchange.

Many organizations exclude Exchange directories from antivirus scans for performance reasons. It’s highly recommended to audit AV exclusions on the Exchange systems and assess if they can be removed without impacting performance and still ensure the highest level of protection. Exclusions can be managed via Group Policy, PowerShell, or systems management tools like System Center Configuration Manager.

To audit AV exclusions on an Exchange Server running Defender Antivirus, launch the Get-MpPreference command from an elevated PowerShell prompt.

If exclusions cannot be removed for Exchange processes and folders, running Quick Scan in Defender Antivirus scans Exchange directories and files regardless of exclusions.

Microsoft Defender Antivirus (EPP) provides detections and protections for components and behaviors related to this threat under the following signatures: 

Why Continuous Security Testing is a Must for Organizations Today

The global cybersecurity market is flourishing. Experts at Gartner predict that the end-user spending for the information security and risk management market will grow from $172.5 billion in 2022 to $267.3 billion in 2026.

One big area of spending includes the art of putting cybersecurity defenses under pressure, commonly known as security testing. MarketsandMarkets forecasts the global penetration testing (pentesting) market size is expected to grow at a Compound Annual Growth Rate (CAGR) of 13.7% from 2022 to 2027. However, the costs and limitations involved in carrying out a penetration test are already hindering the market growth, and consequently, many cybersecurity professionals are making moves to find an alternative solution.

Pentests aren’t solving cybersecurity pain points

Pentesting can serve specific and important purposes for businesses. For example, prospective customers may ask for the results of one as proof of compliance. However, for certain challenges, this type of security testing methodology isn’t always the best fit.

1 — Continuously changing environments

Securing constantly changing environments within rapidly evolving threat landscapes is particularly difficult. This challenge becomes even more complicated when aligning and managing the business risk of new projects or releases. Since penetration tests focus on one moment in time, the result won’t necessarily be the same the next time you make an update.

2 — Rapid growth

It would be unusual for fast-growing businesses not to experience growing pains. For CISOs, maintaining visibility of their organization’s expanding attack surface can be particularly painful.

According to HelpNetSecurity, 45% of respondents conduct pentests only once or twice per year and 27% do it once per quarter, which is woefully insufficient given how quickly infrastructure and applications change.

3 — Cybersecurity skills shortages

As well as limitations in budgets and resources, finding the available skillsets for internal cybersecurity teams is an ongoing battle. As a result, organizations don’t have the dexterity to spot and promptly remediate specific security vulnerabilities.

While pentests can offer an outsider perspective, often it is just one person performing the test. For some organizations, there is also an issue on trust when relying on the work of just one or two people. Sándor Incze, CISO at CM.com, gives his perspective:

“Not all pentesters are equal. It’s very hard to determine if the pentester you’re hiring is good.”

4 — Cyber threats are evolving

The constant struggle to stay up to date with the latest cyberattack techniques and trends puts media organizations at risk. Hiring specialist skills for every new cyber threat type would be unrealistic and unsustainable.

HelpNetSecurity reported that it takes 71 percent of pentesters one week to one month to conduct a pentest. Then, more than 26 percent of organizations must wait between one to two weeks to get the test results, and 13 percent wait even longer than that. Given the fast pace of threat evolution, this waiting period can leave companies unaware of potential security issues and open to exploitation.

5 — Poor-fitting security testing solutions for agile environments

Continuous development lifecycles don’t align with penetration testing cycles (often performed annually.) Therefore, vulnerabilities mistakenly created during long security testing gaps can remain undiscovered for some time.

Bringing security testing into the 21st-century Impact

Cybersecurity Testing

A proven solution to these challenges is to utilize ethical hacker communities in addition to a standard penetration test. Businesses can rely on the power of these crowds to assist them in their security testing on a continuous basis. A bug bounty program is one of the most common ways to work with ethical hacker communities.

What is a bug bounty program?

Bug bounty programs allow businesses to proactively work with independent security researchers to report bugs through incentivization. Often companies will launch and manage their program through a bug bounty platform, such as Intigriti.

Organizations with high-security maturity may leave their bug bounty program open for all ethical hackers in the platform’s community to contribute to (known as a public program.) However, most businesses begin by working with a smaller pool of security talent through a private program.

How bug bounty programs support continuous security testing structures

While you’ll receive a certificate to say you’re secure at the end of a penetration test, it won’t necessarily mean that’s still the case the next time you make an update. This is where bug bounty programs work well as a follow-up to pentests and enable a continuous security testing program.

The impact of bug bounty program on cybersecurity

By launching a bug bounty program, organizations experience:

  1. More robust protection: Company data, brand, and reputation have additional protection through continuous security testing.
  2. Enabled business goals: Enhanced security posture, leading to a more secure platform for innovation and growth.
  3. Improved productivity: Increased workflow with fewer disruptions to the availability of services. More strategic IT projects that executives have prioritized, with fewer security “fires” to put out.
  4. Increased skills availability: Internal security team’s time is freed by using a community for security testing and triage.
  5. Clearer budget justification: Ability to provide more significant insights into the organization’s security posture to justify and motivate for an adequate security budget.
  6. Improved relationships: Project delays significantly decrease without the reliance on traditional pentests.

Want to know more about setting up and launching a bug bounty program?

Intigriti is the leading European-based platform for bug bounty and ethical hacking. The platform enables organizations to reduce the risk of a cyberattack by allowing Intigriti’s network of security researchers to test their digital assets for vulnerabilities continuously.

If you’re intrigued by what you’ve read and want to know about bug bounty programs, simply schedule a meeting today with one of our experts.

www.intigriti.com

Source :
https://thehackernews.com/2022/09/why-continuous-security-testing-is-must.html

How to Find the Source of Account Lockouts in Active Directory

In this post, you will learn how to find the source of account lockouts in Active Directory.

Here are the steps to find the source of account lockouts:

Users locking their accounts is a common problem, it’s one of the top calls to the helpdesk.

What is frustrating is when you unlock a user’s account and it keeps randomly locking. The user could be logged into multiple devices (phone, computer, application, and so on) and when they change their password it will cause ongoing lock-out issues.

This guide will help you to track down the source of those lockouts.

Check it out:

Step 1: Enabling Auditing Logs

The first step to tracking down the source of account lockouts is to enable auditing. If you do not turn on the proper auditing logs then the lockout events will not be logged.

Here are the steps to turn on the audit logs:

1. Open Group Policy Management Console

This can be from the domain controller or any computer that has the RSAT tools installed.

2. Modify Default Domain Controllers Policy

Browse to the Default Domain Controllers Policy, right-click, and select edit. You can also create a new GPO on the “Domain Controllers” OU if you prefer to not edit the default GPO.

3. Modify the Advanced Audit Policy Configuration

Browse to computer configuration -> Policies -> Security Settings -> Advanced Audit Policy Configuration -> Audit Policies -> Account Management

Enable success and failure for the “Audit User Account Management” policy.

Next, enable the following:

computer configuration -> Security Settings -> Advanced Audit Policy Configuration -> Audit Policies -> Account Logon

Enable Success and Failure for “Audit Kerberos Authentication Service.

Auditing is now turned on and event 4740 will be logged in the security events logs when an account is locked out. In addition, the Kerberos logs are enabling which will log authentication failures with the lockout. Sometimes event 4740 does not log the source computer and the Kerberos logs provide additional details.

Step 2: Using the User Unlock GUI Tool to Find the Source of Account Lockouts

This step uses the User Unlock Tool to find the event ID 4740 and other event IDs that will help troubleshoot lockouts.

I created this tool to make it super easy for any staff member to unlock accounts, reset passwords and find the source of account lockouts. It also has some additional features to help find the source of lockouts.

This is a much easier option than PowerShell.

1. Open the AD Pro Toolkit

You can download a free trial here.

Click on the “User Unlock” tool in the left side menu.

Step 2. Select Troubleshoot Lockouts

Select Troubleshoot lockouts and click run

You will now have a list of events that will show the source of a lockout or the source of bad authentication attempts.

In the above screenshot, you can see the account “robert.allen” lockout came from computer PC1.

There will be times when event 4740 does not show the source computer. When that happens you can use the other logged events to help troubleshoot log out events. For example, if the above screenshot had no event 4740 I can look at 4771 and see the failed authentication attempt was from a computer with the IP 192.168.100.20.

In addition, you can unlock the account and reset the password all from one tool. The tool will display all locked accounts, you can select a single account or multiple accounts to unlock.

The unlock tool is part of the AD Pro Toolkit. Download your free trial here.

Step 3: Using PowerShell to Find the Source of Account Lockouts

Both the PowerShell and the GUI tool need auditing turned before the domain controllers will log any useful information.

1. Find the Domain Controller with the PDC Emulator Role

If you have a single domain controller (shame on you) then you can skip to the next step…hopefully you have at least two DCs.

The DC with the PDC emulator role will record every account lockout with an event ID of 4740.

To find the DC that has the PDCEmulator role run this PowerShell command

get-addomain | select PDCEmulator

2: Finding event ID 4740 using PowerShell

All of the details you need are in event 4740. Now that you know which DC holds the pdcemulator role you can filter the logs for this event.

On the DC holding the PDCEmulator role open PowerShell and run this command

Get-WinEvent -FilterHashtable @{logname=’security’; id=4740}

This will search the security event logs for event ID 4740. If you have any account lockouts you should see a list like the below.

To display the details of these events and get the source of the lockout use this command.

Get-WinEvent -FilterHashtable @{logname=’security’; id=4740} | fl

This will display the caller computer name of the lockout. This is the source of the user account lockout.

You can also open the event log and filter the events for 4740

Although this method works it takes a few manual steps and can be time consuming. You may also have staff that is not familiar with PowerShell and need to perform other functions like unlock or reset the user’s account.

That is why I created the Active Directory User Unlock GUI tool. This tool makes it super easy for staff to find all locked users and the source of account lockouts.

I hope you found this article useful. If you have questions or comments let me know by posting a comment below.

Source :
https://activedirectorypro.com/find-the-source-of-account-lockouts/

How to Find Which Logon Server You Authenticated to (Domain Controller)

There are times when you need to determine which domain controller you have authenticated to. This can be helpful for a number of reasons such as troubleshooting group policy, slow logins, application issues, map network drives or printers, and so on.

For example, recently I ran into an issue where single sign-on was not working for multiple applications. I was troubleshooting the issue on multiple virtual desktops and noticed that single sign on was working on one of them. I thought this was strange considering all the virtual desktops were the exact same. That is when I checked which domain controller it authenticated against and noticed it was DC2 and all the others were DC1.

How to Check Logon Server

You can check the logon server with either the command line or PowerShell.

Option 1 – Using the Command Line

Open the command line, type the command below, and press enter

set l

In the screenshot above I authenticated to the DC2 domain controller. The set l command displays everything from the set command that starts with l so it’s displaying the localappdata also. You could just type set logon to see only the logonserver.

Option 2 – Using PowerShell

Open PowerShell, type the command below, and press enter

$env:LOGONSERVER

Find Domain Controller Group Policy Was Applied From

If you need to know which domain controller a computer or user applied its group policy settings from then run the gpresult /r command.

gpresult /r

You can see in the above screenshot the group policy was applied from DC2.

Make sure you check the user settings section as the policy could apply from a different domain controller.

Recommended Tool: Permissions Analyzer for Active Directory

This FREE tool lets you get instant visibility into user and group permissions and allows you to quickly check user or group permissions for files, network, and folder shares.

You can analyze user permissions based on an individual user or group membership.

This is a Free tool, download your copy here.

3 thoughts on “How to Find Which Logon Server You Authenticated to (Domain Controller)”

Source :
https://activedirectorypro.com/find-logon-server-domain-controller/

How to Demote a Domain Controller (Step-by-Step Guide)

Do you need to demote a domain controller?

Is your domain controller dead and do you want to manually remove it?

No problem.

In this guide, I’ll walk through two options to remove a domain controller. If you still have access to the server then option 1 is the preferred choice.

  • Option 1: Demote a Domain Controller Using Server Manager
    • Use this option if you still have access to the server.
  • Option 2: Manually Remove a Domain Controller
    • Use this option if the server is dead or you no longer have access to it.

In both examples, I’ll be using Windows Server 2016 server but these steps will work for Server 2012 and up.

Tip #1 Starting with Server 2008 domain controller metadata is cleaned up automatically. Windows Server 2003 server or earlier will require using the ntdsutil command to cleanup metadata. With that said you still need to manually remove the server from sites and services.

Tip #2 Make sure there are no other services running on the server (like DNS or DHCP) before shutting down the server. If you can avoid this you may save yourself a big headache.

Tip #3 If the domain controller you are removing has FSMO roles configured they will get transferred to another DC automaticallyYou can check this with the netdom query FSMO command.

Video Tutorial

https://youtube.com/watch?v=-RUtkm3PvA4%3Ffeature%3Doembed

If you don’t like video tutorials or want more details, then continue reading the instructions below.

Option 1: Demote a Domain Controller Using Server Manager

This is Microsoft’s recommended method for removing a domain controller.

Step 1. Open Server Manager

Step 2. Select Manage ->”Remove Roles and Features”

Click next on the “Before you begin page”

Step 3. On the server selection page, select the server you want to demote and click the next button.

In this example, I’m demoting server “srv-2016”

Step 4. Uncheck “Active Directory Domain Services” on the Server Roles page.

When you uncheck you will get a popup to remove features that require Active Directory Domain Services.

If you will plan on using the server to manage Active Directory then keep these installed. In this example, I plan to decommission the server so I will remove these management tools.

Step 5. Select Demote this domain controller

On the next screen make sure you DO NOT select “Force the removal of this domain controller”. You should only select this if you are removing the last domain controller in the domain.

You can also change credentials on this screen if needed.

Click Next

Step 6. On the warnings screen, it will give you a warning this server hosts additional roles. If you have client computers using this server for DNS you will need to update them to point to a different server since the DNS role will be removed.

Check the box “Proceed with removal and click next

Step 7. If you have DNS delegation you can select “Remove DNS delegation and click next. In most cases, you will not have DNS delegation and can uncheck this box.

Step 8. Now put in the new administrator password. This will be for the local administrator account on this server.

Step 9. Review options and click “Demote”

#Tip – There is a “view script” button that generates a PowerShell script to automate all the steps we just walked through. If you have additional domain controllers to remove you could use this script.

When you click demote the server will be demoted and rebooted. Once it reboots the server will be a member server. You can log in with domain credentials to the server.

Related: How to Change Domain Controller IP Address

Additional Cleanup Steps

For some reason, Microsoft decided not to include sites and services in the cleanup process. Maybe it’s left there in case you want to promote the server back to a domain controller. If you are not going to promote the server back to a DC then follow these steps.

  1. Open Active Directory Sites and Services and remove the server

You can see above the server I just demoted is still listed in sites and services. I’ll just right-click on it and delete it.

That is it for option 1. You can go into the “Domain Controllers” folder and verify the server is removed. It’s also a good idea to run dcdiag after removing a DC to make sure your environment has no major errors.

You may also need to review and test replication. You can use the repadmin command to test for replication issues.

Option 2: Manually Remove a Domain Controller

Use this option if the server is dead, disconnected, or you just can’t access it. There is really only 1 step.

Step 1. On another domain controller or computer with RSAT tools open “Active Directory Users and Computers”

Go to the domain Controllers folder. Right click the domain controller you want to remove and click delete.

On the next screen select the box “Delete this Domain Controller anyway” and click delete”

If the DC is a global catalog server you will get an additional message to confirm the deletion. I’m going to click Yes.

That is pretty much it. Easy hu?

The last step would be to remove the server from Sites and Services just like I showed you in option 1.

As I mentioned at the top of this article starting with server 2008 the metadata cleanup is done automatically with both options. Most how to guides will tell you to open the command prompt and run the ntdsutil to cleanup the metadata. This is not needed if your server operating system is 2008 or above.

It seems easier to just manually remove the DC than going through the server manager wizard. Technically I’m not sure what the difference is but Microsoft recommends using the removal wizard if you can. Use the manual method as a last option.

Summary

In this guide, I showed you two methods for removing a domain controller. Microsoft has made this process very easy by automatically cleaning up the metadata starting with server 2008. As networks and systems are constantly changing there may come a time when you need to remove a domain controller. I’ve provided some Microsoft links below if you would like to read more about this topic.

Sources

How to Find Inactive User Accounts in Active Directory

Did you know inactive user accounts can lead to major security risks?

Center for Internet Security says “it is easier for a threat actor to gain unauthorized access through valid user credentials than through hacking accounts”.

This is just one reason why you should be searching Active Directory for inactive user accounts and disabling them on a regular schedule.

I think you will be surprised at how many inactive and dormant accounts you will find.

In this guide, I’ll show you two methods for finding these risky accounts.

Table of Contents:

How are Inactive User Accounts Identified?

This part is a little long but it explains what user attribute is used to find inactive user accounts. If you are not interested in this then skip to the examples.

User accounts have an attribute called “lastLogonTimeStamp” the purpose of this attribute is to help identify inactive user and computer accounts. Yes, it can be used for computer accounts also.

There are certain logon types that will update the lastLogonTimeStamp attribute they are, Interactive, Network, and Service logons. Interactive logon is what he cares about, this is when someone logs on at a console.

Let’s look at this attribute in ADUC GUI.

Open an account, click on the Attribute Editor tab and go down to the lastLogonTimestamp attribute.

lastLogonTimestamp in ADUC

What is the lastLogon value used for?

You can see in the above screenshot there is also a lastLogon value, you will also see this when using PowerShell. The lastLogon value is not replicated to all domain controllers where the lastLogonTimestamp is. This is important because with the lastLogon attribute you would have to query every domain controller to find out when a user logged on. Microsoft understood this and that is why they introduced the lastLogonTimestamp attribute way back in 2003.

You could technically use the lastLogon to find an inactive account but it’s much more difficult.

Now let’s look at this value with PowerShell.

For some reason, Microsoft renamed this value to LastLogonDate in PowerShell.

Why I have no idea but it’s the same value. If you happen to know why Microsoft renamed it in PowerShell please comment below.

Open up PowerShell and run this command.

get-aduser -identity username -properties *

Here is a screenshot of the same account in my domain.

LastLogonDate in PowerShell

You can see that lastLogonTimestamp and LastLogonDate have the same data and time.

Just remember this.

PowerShell = LastLogonDate
ADUC GUI = lastLogonTimestamp

Using these attributes we can search Active Directory for inactive user accounts.

If you want to know all the technical nerdy stuff about the lastlogonTimestamp attribute then check out this article by Ned Pyle (Microsoft employee) – The LastLogonTimeStamp Attribute – What it was designed for and how it works

Why You Should be Removing Inactive User Accounts

Security is the #1 reason for cleaning up inactive user accounts. Here is the complete list.

  1. Security Risks – CIS controls #5 says “There are many ways to covertly obtain access to user accounts, including weak passwords, accounts still valid after a user leaves the enterprise, dormant or lingering test accounts, shared accounts that have not been changed in months or years, service accounts embedded in applications for scripts” I highly recommend you download the CIS controls it is a great source to help defend and secure environments.
  2. Inventory & Tracking Issues – Active Directory is a centralized database. Not only can you use it to track your assets but it can be integrated with other systems for a complete asset management solution. If you don’t cleanup your AD assets then your inventory system will inaccurate.
  3. Ease of management – Kinda along the same lines as#2. A cluttered AD environment leads to a difficult and stressful environment to manage. Think about running a PowerShell script or trying to deploy software to hundreds of computers or users. You will get a lot of returned errors when trying to manage an environment with stale and inactive accounts.
  4. Data Integrity – A lot of these have the same thing, data integrity. Again AD is a centralized database and can be integrated with many systems. If the data in AD is incorrect then all systems connected to AD will be incorrect.
  5. Licensing – Here is a real world exampe. You AD User accounts sync with a 3rd party system such as McAfee. Mcafee charges you based on user accounts. If you have hundreds of inactive accounts syncing with 3rd party products you could be paying for a lot of extra licenses you don’t need. This is the case when syncing AD with cloud products also.

Best Practices for Removing Inactive User Accounts

Here are some best practices for cleaning up inactive users or computer accounts.

  • Never immediatly remove accounts that are identified as inactive. Disabled them first for at least 30 days (longer the better).
  • Search for accounts with a lastLogonTimestamp that is 45 days or older, meaning the AD account shows no logon activity for 45 days or longer.
  • Disable the accounts for at least 30 days, I typically go with 60. With remote access, VPNs, laptops sometimes AD doesn’t get updated. By disabling an account first its very easy to re-enable it and give the user their access back.
  • Add a description to the account with the date disabled and your initians. This is very helpful for other admins in case someone asks why an account is disabled.
  • An inactive on premise account might not mean an inactive Office 365 account. This would be for hybrid environments that sync with Office 365. The disabling of the account vs immedialy deleting is critical for these types of environments. You could have users working from home that never authenticate to the on prem AD environment but log into office 365 daily.
  • Run the cleanup process every month.

Example 1: Find Inactive User Accounts with PowerShell

To find inactive accounts with PowerShell you will need the RSAT tools installed or run these commands on the domain controller.

All of these examples use the LastLogonDate attribute that I went over in the first part of this article.

Find inactive accounts in the last 60 days


$When = ((Get-Date).AddDays(-60)).Date
Get-ADUser -Filter {LastLogonDate -lt $When} -Properties * | select-object samaccountname,givenname,surname,LastLogonDate

Find inactive accounts in the last 30 days


$When = ((Get-Date).AddDays(-30)).Date
Get-ADUser -Filter {LastLogonDate -lt $When} -Properties * | select-object samaccountname,givenname,surname,LastLogonDate

Here is an example from my domain.

PowerShell inactive accounts in last 30 days

You can export the results to CSV by adding | export-csv -path c:\ps\inactiveusers.csv

$When = ((Get-Date).AddDays(-30)).Date
Get-ADUser -Filter {LastLogonDate -lt $When} -Properties * | select-object samaccountname,givenname,surname,LastLogonDate | export-csv -path c:\ps\inactiveusers.csv

To limit the scope to an organizational unit use the SearchBase parameter with the distinguished name of the OU.

$When = ((Get-Date).AddDays(-30)).Date
Get-ADUser -Filter {LastLogonDate -lt $When} -SearchBase "OU=Accounting,OU=ADPRO Users,DC=ad,DC=activedirectorypro,DC=com" -Properties * | select-object samaccountname,givenname,surname,LastLogonDate

Find inactive users and disable the accounts

$When = ((Get-Date).AddDays(-30)).Date
Get-ADUser -Filter {LastLogonDate -lt $When} -Properties * | select-object samaccountname,givenname,surname,LastLogonDate | Disable-ADAccount

In the above example, I added | Disable-ADAccount at the end to disable all inactive accounts.

You can also use these commands to search computer accounts just change Get-ADUser to Get-ADComputer

As you can see It’s easy to identify inactive user accounts with PowerShell by filtering on the user’s LastLogonDate. If you are into PowerShell you can create a very powerful tool for cleaning up AD.

If you are not into PowerShell or just want a simple GUI tool then check out example 2.

Example 2: Find Inactive User Accounts with the AD Cleanup Tool

The AD Cleanup Tool makes it extremely easy to find inactive users and computers. I also added filters to quickly find expired users, disabled and users with no logon history. These are often forgotten accounts that also should be part of the cleanup process.

Let’s look at an example

To find all inactive accounts for the last 30 days just enter 30 in the search options and click run. You can enter any number into the search options box.

Search inactive accounts in the last 30 days

By default, this tool will display both inactive user and computers. To view just user accounts, uncheck “show Computers” from the filters dropdown.

Change the filter to list just user accounts

This searches the entire domain.

You can limit the search by choosing an OU or group. For example, I want to check for inactive accounts in all of my accounting security groups. I click browse and now I can select all my groups or any OUs.

Select OU or groups to search

To disable or move the accounts I just select them and then click the action button.

I’m going to move these accounts to an Inactive OU I created. I click the move button then select the OU.

Select OU to move accounts into

Now I’ll check ADUC to verify the accounts have been moved. This makes it easy to see all the accounts that I’m going to disable because they are identified as inactive.

If you wanted to see all disabled user accounts, just drop down the filters list and select disabled users.

Display all disabled user accounts

In the screenshot above you can also quickly display all expired user accounts and users with no logon history by simply selecting them in the filter. You can then take action on these accounts by moving or disabling them.

There are a lot of options with this tool and the easy to use interface saves you valuable time when it comes to cleaning up your AD environment.

Summary

I showed you two examples for finding and removing inactive user accounts in Active Directory. I highly recommend you add this to your monthly maintenance checklist. Security is a big concern with Active Directory but as I pointed out there are several reasons why this is an important task. PowerShell is a great option for finding inactive accounts but does require knowledge of scripting. For those that are not into scripting or just want a quick and simple solution, there is the AD Cleanup GUI Tool.

Source :
https://activedirectorypro.com/find-inactive-user-accounts-in-active-directory/

How to Move Users to Another Domain

Moving users to another domain tutorial

In this tutorial, I will demonstrate moving Active Directory users from one domain to another.

I’m going to move 2747 users from one domain (running server 2019) to a new domain running server 2022. You can move accounts to an existing domain or a new one.

The tools used in this guide will work with domain controllers running 2008 and later operating systems. Also, you can move accounts in the same domain forest, a different forest, domain trust, or no trust.

Reasons for moving users:

  • Creating a test environment
  • Merging with another company
  • Moving or upgrading to a new server
  • No trust between domains
  • Moving users to a single domain (consolidating domains)

Steps for Moving Users From One Domain To Another Domain

To complete the move I will use some PowerShell scripts to re-create the OUs and groups. I’ll then use the export and import tool from the AD Pro Toolkit to move the accounts.

Note

This method does not migrate computer user profiles or SID history. It will move user data from Active Directory such as OUs, group membership, and user fields (address, manager, phone number, state, etc).

Video Tutorial

https://youtube.com/watch?v=RYXqXjMulhc%3Ffeature%3Doembed

If you don’t like video tutorials or want more details, then continue reading the instructions below.

1. Export users from the source domain

First, you need to export a list of users to a CSV file. This can be done with PowerShell or the User Export Tool.

With the export tool, you can select to export from the entire domain, an OU or group.

step 1 export users

You can also change the columns to preserve user settings when moving to the new domain.

select user attributes

Below is a screenshot of the CSV file exported from my source domain. I exported 2747 users and it includes 31 columns of user properties. Again, you can use the attribute selector to add or remove columns. These user properties will be preserved and imported into the other domain.

csv example

2. Modify CSV File for the new domain

To import these accounts into the new domain you will need to add a password column. If it is a different domain you will also need to modify the OU path. I’m going from ad.activedirectorypro.com to ad2.activedirectorypro.com so I’ll need to update the ou path. You can easily do this in excel with a search and replace.

You can change additional details in the CSV to reflect the new domain. For example, you can change proxyAddresses to the new domain name or change the userPrincipalName.

step 2 modify csv file

Now I’m ready to import all 2747 accounts into the new domain. This will import them into the new domain, add them into the OUs, add to groups and keep their user settings from the old domain.

3. Import Users Into the New Domain (or existing domain)

If you are moving the users to an existing domain you probably don’t need to create OUs or groups. If it’s a new domain and you want to replicate the AD structure of the source domain then you can use some PowerShell scripts. See the links below for step by step instructions.

Next, open the bulk import tool.

Select the CSV file, your import options, and click run.

step 3 import users into new domain

When the import is complete you can check the logs and Active Directory to verify the import.

verify import of users

Above you can see a screenshot of the source and the new domain. All of the accounts are imported into the same OUs and groups.

Using the export and import tool makes it really easy to move users to a new domain while keeping their group membership and user properties from Active Directory. It also is very flexible as you can move users from an old domain such as 2008 to a newer server like 2019 or later.

You also don’t have to worry about trust relationships or connections between the two domains.

Below are some PowerShell commands to help you verify the numbers in Active Directory.

Count the Number of Active Directory Objects using PowerShell

Here are some PowerShell commands I used to count the number of objects in the source domain.

Get the number of AD users

(Get-ADUser -filter *).count

The above command gets the count for all users in the domain. To get the count for just an OU use this command. Change the SearchBase to the path of your root OU.

(Get-ADUser -filter * -SearchBase "OU=ADPRO Users,DC=ad,DC=activedirectorypro,DC=com").count
use powershell to count ad objects

2747 is the number of users in my source domain so this means all the users imported into the new domain successfully.

Get the number of AD Computers

(Get-ADComputer -Filter *).count

Get the number of Organizational Units

(Get-ADOrganizationalUnit -filter *).count

Get the number of AD Security groups

(Get-ADGroup -Filter *).Count

Conclusion

That’s how you move users from one domain to another using tools from the AD Pro Toolkit and PowerShell. An alternative to moving users to another domain is by using the Microsoft Active Directory Migration Tool. The ADMT (Active Directory Migration Tool) will migrate SID and computer profiles. The only problem with this tool is it is not updated, has no support, and often fails. It also is not as flexible as the method I demonstrated in this guide.

Have you ever moved users to a new domain?

If so, how did it go?

Let me know in the comments section below.

Source :
https://activedirectorypro.com/moving-users-to-another-domain/

How to Transfer FSMO Roles (2 Easy Steps)

how to transfer fsmo roles

Do you need to transfer FSMO roles to another domain controller?

No problem, it is very is to do.

In this tutorial, I’ll show you step-by-step instructions to transfer the FSMO roles from one domain controller to another. I’ll show you two methods: the first is using PowerShell and the second is using the ADUC GUI.

Why Transfer FSMO roles?

By default, when Active Directory is installed all five FSMO roles are assigned to the first domain controller in the forest root domain. Transferring FSMO roles is often needed for several reasons including:

It is recommended to only transfer FSMO roles when the current role holder is operational and is accessible on the network. For a complete list of considerations see the MS article Transfer or seize FSMO Roles in Active Directory Services.

Step 1: List Current FSMO Role Holders

Before moving the FSMO roles it is a good idea to check which domain controllers hold which roles.

You can list which domain controllers hold FSMO roles with these two PowerShell commands:

Get domain level FSMO roles

get-addomain | select InfrastructureMaster, PDCEmulator, RIDMaster

Get forest level FSMO roles

Get-ADForest | select DomainNamingMaster, SchemaMaster

Below is a screenshot of the results in my domain.

get fsmo roles

List of installed roles in my domain:

  • InfrastructureMaster is on DC1
  • PDCEmulator is on DC2
  • RIDMaster is on DC2
  • DomainNamingMaster is on DC1
  • Schemamaster is on DC1

I want to move all the roles from DC2 to DC1, I’ll demonstrate this below.

Step 2: Transfer FSMO Roles

I’ll first demonstrate transferring roles with PowerShell, it is by far the easier option of the two (in my opinion).

You want to log into the server that you will be transferring the roles to, in my case it is DC1.

To move a role with PowerShell you will use the Move-ADDirectoryServerOperationMasterRole cmdlet, then the hostname of the server to transfer to.

Transfer PDCEmulator

Move-ADDirectoryServerOperationMasterRole -Identity "dc1" PDCEmulator

Transfer RIDMaster

Move-ADDirectoryServerOperationMasterRole -Identity "dc1" RIDMaster

Transfer InfrastrctureMaster

Move-ADDirectoryServerOperationMasterRole -Identity "dc1" Infrastructuremaster

Transfer DomainNamingMaster

Move-ADDirectoryServerOperationMasterRole -Identity "dc1" DomainNamingmaster

Transfer SchemaMaster

Move-ADDirectoryServerOperationMasterRole -Identity "dc1" SchemaMaster

Here is a screenshot of when I moved PDCEmulator and RIDMaster to DC1.

transfer fsmo roles with powershell

Now if I re-run the commands to list the FSMO roles I should see them all on DC1.

list fsmo roles again

Yes, I have confirmed all the roles are now on DC1. As you can see moving FSMO roles with PowerShell is very easy to do.

Now let’s see how to transfer FSMO roles using the Active Directory Users and Computers GUI.

Transfer FSMO Roles Using ADUC GUI

Just like PowerShell you need to log into the server that you will be transferring to. I’m transferring from DC2 to DC1 so I’ll log into DC1.

Open the Active Directory Users and Computers console, then right-click on the domain and click on operations masters.

move operations masters roles with GUI

You should now see a screen with three tabs (RID, PDC, and Infrastructure).

transfer RID role with gui

To transfer one of these roles just click on the change button. You can’t select which domain controller to transfer the role to, that is why you need to log into the server that you want to transfer to. if I wanted to transfer the RID role to DC3 I would log into that server.

To transfer the domain naming operations master role you will need to open Active Directory Domains and Trusts. Right-click on “Active Directory Domains and Trusts” and select “Operations Master”.

move operations master role with gui

Now click change to transfer the role to another DC.

moving roles

To transfer the schema master role follow these steps.

Open a command line and run the command regsvr32 schmmgmt.dll

register schmngmt.dll

Next, you need to open an MMC console. To do this click on start then type mmc. and click the icon.

open mmc console

Next, click File, then Add/Remove Snap-in

add remove to mmc console

Add “Active Directory Schema” from the list and click ok.

add active directory schema to mmc console

Right click on “Active Directory Schema” and change the domain controller to the server you want to transfer the role to.

In this example, I’ll change the domain controller to DC2.

Now you can right-click on Active Directory schema and select “Operations Master” to transfer the schema master role.

Confirm the role is changing to the correct DC and click the “change” button.

As you can see transferring FSMO roles with the GUI takes a lot of extra steps and that is why I prefer to use PowerShell. But if you are not into Powershell then the GUI works just fine.

Summary

Moving FSMO roles to another server is not a daily task but is necessary at times. Microsoft recommends the server be online when moving roles. The steps in this tutorial should help you when it comes time to move roles.

Source :
https://activedirectorypro.com/transfer-fsmo-roles/