Apply Group Policy to Security Group

It’s not possible to apply a group policy to a security group . However, you can change the permissions on group policy so that only certain users/groups have read and apply privileges.

Step 1:

Select the Group Policy Object in the Group Policy Management Console (GPMC). Click on the Delegation tab and then click on the Advanced button.

Step 2:

Click on the Add button and select the security group that you wish to apply to . Then select the group (e.g. “Accounting Users”) and scroll the permission list down to the “Apply group policy” option and then select the Allow permission.

This Group Policy now applies to only users or computers that are a member of the Accounting Users security group. However you still need to remember that the user and/or computer should be part of the site/domain/OU to which this Group Policy Object is linked.

References
https://www.manageengine.com/products/active-directory-audit/kb/how-to/how-to-apply-group-policy-to-security-group.html

Adding Users to the Local Admin Group via Group Policy

You can use GPO (Group Policy) to add Active Directory users and groups to the local Administrators group on domain-joined servers and workstations. This allows you to grant local admin privileges on domain computers to technical support staff, HelpDesk team, specific users or other privileged accounts. In this article we’ll show how to manage members of the local Administrator group on domain computers using GPO.

Local Administrators Group in Active Directory Domain

When you joining a computer to an AD domain, the Domain Admins group is automatically added to the local Administrators group, and the Domain User group is added to the local Users group.

The easiest way to grant local admin privileges on a computer is to add a user or group to the local security group Administrators using the Local users and groups snap-in (lusrmgr.msc). However, this method is not convenient if there are a lot of computers and in some time unwanted people may stay the members of the privileged group. If you are using this method of granting local privileges, it is not convenient to control the members of the local admins group on each domain computer.

Microsoft recommends using the following groups to separate administrative privileges in an AD domain:

  1. Domain Admins are used only on domain controllers;
    From the security point of view for privileged administrator accounts, it is not recommended to perform daily administration tasks on workstations and servers under an account with the Domain Admin privileges. These accounts must be used only for AD management  (adding new domain controllers, replication management, Active Directory schema modification, etc.). Most user, computer or GPO management tasks must be delegated to regular administrator accounts (without Domain Admin permissions). Do not use Domain Admin accounts to log on to any workstations or servers other than domain controllers.
  2. Server Admins is a group that allows to manage the domain member servers. It must not be a member of the Domain Admins group or local Administrators group on your workstations;
  3. Workstation Admins is a group for performing administrative tasks on workstations only. Must not be a member of the Domain Admins and Server Admins groups;
  4. Domain Users are common user accounts to perform typical office operations. They must not have any administrator privileges on servers or workstations.
You can also completely refuse from providing any administrator privileges to domain users or groups. In this case, the built-in local Administrator account with a password stored in AD (LAPS-based) is used to perform administrative tasks on workstations.

Suppose, you want to grant local administrator privileges on computers in the specific OU to the group of technical support and HelpDesk employees. Create a new security group in your domain using PowerShell and add the technical support accounts to it:

New-ADGroup munWKSAdmins -path 'OU=Groups,OU=Munich,OU=DE,DC=woshub,DC=com' -GroupScope Global –PassThru
Add-AdGroupMember -Identity munWKSAdmins -Members amuller, dbecker, kfisher

Open the domain Group Policy Management console (GPMC.msc), create a new policy (GPO) AddLocaAdmins and link it to the OU containing computers (in my example, it is ‘OU=Computers,OU=Munich,OU=DE,DC=woshub,DC=com’).

AD Group Policy provides two methods to manage local groups on domain computers. Let’s study them in turn:

  • Local groups management using Group Policy Preferences;
  • Restricted Groups.

How to Add Domain Users to the Local Administrators via GPO Preferences?

Group Policy Preferences (GPP) provide the most flexible and convenient way to grant local administrator privileges on domain computers through a GPO.

  1. Open the AddLocaAdmins GPO you created earlier in the Edit mode;
  2. Go to the following GPO section: Computer Configuration –> Preferences –> Control Panel Settings –> Local Users and Groups;
  3. Add a new rule (New -> Local Group);

  1. Select Update in the Action field (it is an important option!);
  2. In the Group Name dropdown list, select Administrators (Built-in). Even if this group has been renamed on the computer, the settings will be applied to the local Administrators group by its SID — S-1-5-32-544;
  3. Click the Add button and select the groups you want to add to the local administrators group (in our case, it is munWKSAdmins);
    If you want to remove manually added users and groups from the current local Admins group, check the “Delete all member users” and “Delete all member groups” options. In most cases it is reasonable since you guarantee that only the assigned domain groups will have administrator permissions on your domain computers. Then if you add a user to the Administrators group manually using the “Local users and groups” snap-in, it will be automatically removed next time when the policy is applied.

  1. Save the policy and wait till it is applied on the workstation. To apply the policy immediately, run this command gpupdate /force on a user computer;
  2. Open the lusrmgr.msc snap-in on any computer and check the local Administrators group members. Only the munWKSAdmins group will be added to this group, while other users and groups will be removed. You can display the list of the local administrators using the command: net localgroup Administrators
If the policy has not been applied on a domain computer, use the gpresult command to diagnose the problem. Also make sure that the computer is located in the OU the GPO is linked to and check the recommendations from the article “Group policy objects not being applied to computers“ .

You can configure additional (granular) conditions for targeting the policy on the specific computers using the GPO WMI filters or Item-level Targeting.

In the second case, go to the Common tab and check the Item-level targeting. Click Targeting. Here you can specify the conditions when the policy will be applied. For example, I want the policy of adding administrator groups to be applied only to Windows 10 computers, which NetBIOS/DNS names don’t contain adm. You can use your own filtering options.

It is not recommended to add individual user accounts to this policy. It is better to use the domain security groups. In this case, to grant administrator privileges to another tech support employee, it is enough to add them to the domain group (you won’t need to edit the GPO).

Managing Local Admins Group Using Restricted Groups

The Restricted Groups policy also allows to add domain groups/users to the local security group on computers. It is an older method of granting local administrator privileges and is used less often now (it is less flexible than that the Group Policy Preferences method).

  1. Open a GPO in the editing mode;
  2. Expand the section Computer Configuration -> Policies -> Security Settings -> Restricted Groups;
  3. Select Add Group in the context menu;

4.In the next window, type Administrators and then click OK;

5.Click Add in the Members of this group section and specify the group you want to add to the local admins;

  1. Save the changes, apply the policy to user computers and check the local Administrators group. It must contain only the group you have specified in the policy.
This policy always (!) removes all other members of the local administrators group (added manually, or using other policies or scripts). If several policies with the Restricted Groups settings are active for a computer, only the last one is applied. You can bypass this limitation by first adding the munWKSAdmins group to the Restrictred Groups, and then adding this group to the Administrators group.

Using GPO to Add a Single User to the Local Admin Group on a Specific Computer

Sometimes you may need to grant a single user the administrator privileges on the specific computer. For example, you have several developers who need elevated privileges from time to time to test drivers, debug or install them on their computers. It is not advisable to add them to the group of workstation admins on all computers.

To grant local administrator privileges on the specific computer, you can use the following scheme:

Right in the GPO preference section (Computer Configuration –> Preferences –> Control Panel Settings –> Local Users and Groups) of AddLocalAdmins policy created earlier create a new entry for the Administrators group with the following settings:

  • Action: Update
  • Group Name: Administrators (Built-in)
  • Description: “Add amuller to the local administrators on the mun-dev-wsk21 computer”
  • Members: Add -> amuller

In the Common -> Targeting tab, specify this rule: “the NETBIOS computer name is mun—dev-wks24.” It means that this policy will be applied only to the computer specified here.

Also, pay attention to the order in which groups are applied on the computer (the Order GPP column). Local group settings are applied from top to bottom (starting from the Order 1 policy).

The first GPP policy (with the “Delete all member users” and “Delete all member groups” settings as described above) removes all users/groups from the local administrator groups and adds the specified domain group. Then the additional  computer-specific policies are applied that add the specified user to the local admins. If you want to change the membership order in your Administrators group, use the buttons on top of your GPO Editor console.

Create a New Active Directory User Account in Windows Server

This article walks through creating a new Active Directory user account using the Active Directory Users and Computers MMC.

1. Open Active Directory Users and Computers MMC

2. Right click the folder where you want to create the new user account, select new and then click user. If you have not created additional organizational units, you can put the new account in the Users folder. In my example, I’m putting the account in the Winadpro Users folder that I have created.

References
https://activedirectorypro.com/how-to-create-a-new-active-directory-user-account/

Disable the Windows Password Policy Rules in Windows Server

The Windows password policy rules can place restrictions on password history, age, length, and complexity. If you enable the PPE rules and the Windows rules, then users will have to comply with both sets of rules.

PPE has its own History, Minimum Age, Maximum Age, Length, and Complexity rules. You can use the PPE and Windows rules together, but it is easier to disable the Windows rules and use the PPE rules instead. To disable the Windows password policy rules:

1. Use the Group Policy Management Console, or Active Directory Users and Computers console to display the GPOs linked at the domain level.
2. Right-click the Default Domain Policy GPO (or whichever GPO you use to set your domain password policy), and then click Edit.
3. Expand the Computer Configuration, Policies (if it exists), Windows Settings, Security Settings, Account Policies, and Password Policy items.
4. Double-click Enforce password history in the right pane of the GPO Editor. Type 0 in the text box, and then click OK.
5. Repeat the step above for the Maximum password age, Minimum password age, and Minimum password length policies.
6. Double-click Password must meet complexity requirements in the right pane. Select the Disabled option, and then click OK.
7. Close the Group Policy Management Editor.

You do not have to disable all the Windows password policy rules to use PPE. You can use a combination of PPE and Windows rules together if you like. Just remember that a password is only accepted if it complies with the rules enforced by both Windows and PPE.

References
https://anixis.com/doc/ppe76ag/ppe_disable_the_windows_password_policy_rules.htm

Block Inbound Connection for RDP in Windows Server

1 – Search for Windows Firewall, and click to open it.
2 – On the left, click Advanced Settings.
3 – From the left pane of the resulting window, click Inbound Rules.
4 – In the right pane, locate the following rules:

Remote Desktop - Shadow (TCP-In)
Remote Desktop - User Mode (TCP-In)
Remote Desktop - User Mode (UDP-In)

5 – Right-click each rule and choose Disable Rule.

References
https://kb.iu.edu/d/amyp

Installing Intel I211, I217V, I218V and I219V drivers on Windows Server 2016 with EUFI boot

Introduction
This blog will be all about installing Intel I211, I217V, I218V and I219V drivers on Windows Server 2016 with EUFI boot. I’m running Windows Server 2016 as my main OS for lab, testing, Hyper-V with nested virtualization etc. I like it that way because I have all the options of the server OS at my disposal. Especially with the nested virtualization an NVME disk comes in handy. I also boot from NVMe so I need UEFI and use secure boot. That’s OK as it’s way better than the old BIOS and enables more scenario.

Windows Server 2016 doesn’t have any drivers for the I211, I217V, I218V and the I219V NICs.

The Intel driver for them are only for Windows 10 and won’t install on a server OS. As you can see in the screenshot above that’s a system where I have the I211 driver already installed actually. We’ll work on the I218V as an example here.

That’s nothing new and we’ve dealt with this before by editing the .inf file for the driver. What might be new to some people as EUFI & NVME become a bit more popular is how to get a driver with an edited .inf file installed on your Windows Server OS.

Don’t worry even with an OS booting from EUFI with secure boot you can still disable driver signing / integrity checking when needed. We’ll walk you through an approach for installing Intel I211, I217V, I218V and I219V drivers on Windows Server 2016 with EUFI boot.

Installing Intel I211, I217V, I218V and I219V drivers on Windows Server 2016 with EUFI boot

Google for the Intel drivers of your NIC. Mine is a I218V. The instructions will work for a I217V or and i219V as well. Just adapt accordingly.

After downloading the most recent Windows 10 (x64 bit, we’ll use them with a server OS so there is no 32 bit here) Intel drivers form the Intel site we rename the exe to identify what package it is. We then extract the content to our work space. A free tool like 7zip will do the job just fine

Prepping the .INF file

For the I211 we need to edit the .inf file and for the I217V, 218V and 219V we’ll edit the e1d65x64.inf file in note pad or your editor of choice. You’ll find it in the NDIS65 folder: C:\SysAdmin\PROWinx64\PRO1000\Winx64\NDIS65. The 65 in the folder and file names identifies our OS version (Windows 10 / Windows Server 2016).

But how do we know what .inf file to edit? We grab the hardware ID’s from the properties of our NIC or NICS.

Below you see the Hardware IDs for mu I218V. The I211 has PCI\VEN_8086&DEV_1539&SUBSYS_85F01043&REV_03 and my Iv218V has PCI\VEN_8086&DEV_15A1&SUBSYS_85C41043&REV_05.

Drop the PCI\ from the beginning of the string and everything from the “&” on at the end. So for the I211 we’ll use VEN_8086&DEV_1539 and for the I218V we’ll use VEN_8086&DEV_15A1. We throw these ID strings into some PowerShell we run in our C:\SysAdmin\PROWinx64\PRO1000\Winx64\NDIS65 folder.

Get-ChildItem -Path “C:\SysAdmin\IntelWindows10Drivers21.1\PRO1000\Winx64\NDIS65” ` -recurse | Select-String -pattern “ven_8086&dev_1539” | group path | select name
Get-ChildItem -Path “C:\SysAdmin\IntelWindows10Drivers21.1\PRO1000\Winx64\NDIS65” ` -recurse | Select-String -pattern “ven_8086&dev_15A1” | group path | select name

So for my I218V I open op the e1d65x64.inf file in notepad++

I search for [ControlFlags] section and I edit the content of that section by deleting everything in it.

So it looks likes

Then I search for section [Intel.NTamd64.10.0.1] and I copy everything in there (I don’t bother to only copy the entries for my particular NIC or so.

Copy everything under that heading

I then search for section [Intel.NTamd64.10.0] and I paste what I just copied from section [Intel.NTamd64.10.0.1] nicely underneath what’s already in there.

Save the file. Basically, you’re done here.

Installing the driver

We now need to alter the standard startup setting of Windows Server 2016 temporarily because we will not be able to install a driver that’s been tampered with. If you don’t lower the security settings, you’ll get an error just like this one:

What I did is run the following in an elevated command prompt:

bcdedit /set LOADOPTIONS DISABLE_INTEGRITY_CHECKS

Note: as I’m using UEFI & secure boot the following won’t work as if you were using an older BIOS without secure boot.

bcdedit /set TESTSIGNING ON

bcdedit /set nointegritychecks OFF

But that’s OK. What we need to do is turn it of in another way. That last command bcdedit /set nointegritychecks OFF iIs not needed anyway. So, forget about that one. As a replacement for bcdedit /set TESTSIGNING ON you can use and advanced start option (requires reboot). You can also disable secure boot in EUFI, start again and then run bcdedit /set TESTSIGNING ON. I prefer the first as fixes itself the next boot and I don’t have to turn secure boot on again afterwards.

Go to setting and select Update & security.

Navigate to Recovery and click Restart Now

It will reboot to the following screen.Click Troubleshoot.

Select and click Advanced options.

Click Startup Settings.

We click restart on the next screen

It will restart Advanced boot options. Select to disable driver signature enforcement. Hit ENTER.

When your server has restarted, you’ll be able to install the driver you tampered with. To do so, in device manager select your NIC and click Update Driver Software.

Select to Browse my computer for driver software

Point to the C:\SysAdmin\PROWinx64\PRO1000\Winx64\NDIS65 folder with your edited .inf files.

You’ll get a warning that the publisher of this driver can’t be verified. But as you’re the one doing the tampering here, you’ll be fine.

The result is successful install of the driver with a functional NIC for your system.

Cool, you’re in business!

No please reverse the setting you made to the integrity checks to make your system more secure again. From an elevated command prompt run:

bcdedit /set LOADOPTIONS ENABLE_INTEGRITY_CHECKS

Now reboot and you’re all secure again. That’s it, you’re done. I had both an I211 and an I218V NIC on my motherboard so I had to do this for both. Happy testing!

References
https://blog.workinghardinit.work/2017/06/19/installing-intel-i211-i217v-i218v-i219v-drivers-windows-server-2016-eufi-boot/

Install a New Windows Server Active Directory Forest

AD DS Role Installation

AD DS Role Configuration

Installation Type

Server Selection

Server Roles and Features

Domain Controller Options

DNS Options

Additional Options

Paths

References
https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/deploy/install-a-new-windows-server-2012-active-directory-forest–level-200-
https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/deploy/ad-ds-installation-and-removal-wizard-page-descriptions
https://computingforgeeks.com/how-to-install-active-directory-domain-services-in-windows-server/
https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/active-directory-domain-services

Template Matching on Images using OpenCvSharp

//read image
// var refMat = new Mat("001f.png", ImreadModes.Unchanged);
// var tplMat = new Mat("001.png", ImreadModes.Unchanged);
using (Mat refMat = new Mat("001f.png", ImreadModes.Unchanged))
using (Mat tplMat = new Mat("001.png", ImreadModes.Unchanged))
using (Mat res = new Mat(refMat.Rows - tplMat.Rows + 1, refMat.Cols - tplMat.Cols + 1, MatType.CV_32FC1))
{
    //Convert input images to gray
    Mat gref = refMat.CvtColor(ColorConversionCodes.BGR2GRAY);
    Mat gtpl = tplMat.CvtColor(ColorConversionCodes.BGR2GRAY);

    Cv2.MatchTemplate(gref, gtpl, res, TemplateMatchModes.CCoeffNormed);
    Cv2.Threshold(res, res, 0.8, 1.0, ThresholdTypes.Tozero);

    while (true)
    {
        double minval, maxval, threshold = 0.8;
        Point minloc, maxloc;
        Cv2.MinMaxLoc(res, out minval, out maxval, out minloc, out maxloc);

        if (maxval >= threshold)
        {
            //draw a rectangle of the matching area
            Rect r = new Rect(new Point(maxloc.X, maxloc.Y), new Size(tplMat.Width, tplMat.Height));
            Cv2.Rectangle(refMat, r, Scalar.Red, 2);

            //debug
            String msg =
                $"MinVal={minval.ToString()} MaxVal={maxval.ToString()} MinLoc={minloc.ToString()} MaxLoc={maxloc.ToString()} Rect={r.ToString()}";
            Console.WriteLine(msg);

            //fill in the res mat so you don't find the same area again in the minmaxloc
            //Rect outRect;
            //Cv2.FloodFill(res, maxloc, new Scalar(0), out outRect, new Scalar(0.1), new Scalar(1.0), FloodFillFlags.Link4);
            Cv2.FloodFill(res, maxloc, new Scalar(0));
        }
        else
        {
            break;
        }
    }
}