Windows Firewall - network card not detecting the correct connection profile

For people familiar with Windows firewall, there are 3 profiles that you can create rules for: Private, Public, and Domain. The operating system uses the Network Location Awareness service (NLAsvc) to attempt to identify what type of connection each NIC is on. If you machine is domain joined to an Active directory on-prem domain, it will make connection attempts to domain controllers to see if a specific NIC can reach one. For other tests, it will try to connect to websites to see if there internet connectivity. The problem with windows firewall and its domain checks is that you might not have a well enough functioning network connection when the NLAsvc tries to perform its checks. On a domain controller, this is particularly problematic. To work around this you cand modify the service settings in the registry to add some additional service dependencies. This will delay the start up of the NLAsvc process and give the system more time to be ready for the checks. To do this, open regedit and navigate to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NlaSvc. Edit the "DependOnService" REG_MULTI_SZ value. For new entries, you will add one entry per line. The values you will want to add are: NSI, RpcSs, TcpIp, Dhcp, Eventlog, DNS, Netlogon.

There are some additional configurations you will want to push as well:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NlaSvc\Parameters\AlwaysExpectDomainController (REG_DWORD) = 0x1
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Dnscache\Parameters\MaxNegativeCacheTTL (REG_DWORD) = 0x0
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters\NegativeCachePeriod (REG_DWORD) = 0x0

These will add some additional stability for NLA.

Quick way to find all OU's in a domain that block gpo inheritence

Using bitwise and on the gpotions attribute of organizational Unit objects. This will run in seconds compared to attempting to use higher level functions like get-adorganizationalunit in combination with get-gpinheritance.

get-adobject -ldapfilter "(&(objectclass=organizationalunit)(gpoptions:1.2.840.113556.1.4.803:=1))"

Some useful links for group policy client side debugging

Group policy debugging:

How to enable it: http://blogs.technet.com/b/mempson/archive/2010/01/10/userenvlog-for-windows-vista-2008-win7.aspx

Enabling it for older OS's: http://social.technet.microsoft.com/wiki/contents/articles/4506.group-policy-debug-log-settings.aspx

How to understand the log files: http://blogs.msdn.com/b/richpec/archive/2009/07/20/userenv-debugging-line-by-line.aspx

Repairing local security policy: https://support.microsoft.com/en-us/kb/278316

Finding OU's that block GPO inheritence

import-module activedirectory
get-adobject -LDAPFilter "(&(objectclass=OrganizationalUnit)(gPOptions=1))"

GPO software restrictions

There is a feature in group policy called software restriction policies which allows you to try to block users from running certain specified applications (black listing), or provide a list of applications which are allowed while blocking all others by default(white listing). There are several types of rules you can create:

Hash Rule: Crypto hash of the binary file
Certificate: A software publisher certificate that was used to digitally sign the file
Path: The file path or registry path to the file
Zone: What internet zone is used.

These types of rules can help to guard against predictable malware or certain versions of applications. The problem is that they are frequently very easy to get around.

Hash Rule (avoiding blacklist)
Lets assume our block rule covers txdns.

C:\Users\nl\Downloads>md5sum txdns.exe
f59a3d8e94f0f61130874fd794c38aa7 *txdns.exe

Using a hash rule to block something like this requires some considerations. First, every version and every patch level will have a unique hash. For applications that are frequently updating, you will never be able to keep up with them. If you have a file that has limited versions and no further development, it is still trivial to bypass this. Most files will have some text strings inside the executable. If we open txdns.exe with a hex editor, and immediately we see a string "This program cannot be run in DOS mode". We can change the T in This to lower case without effecting the program.

C:\Users\nl\Downloads>md5sum txdns.exe
42e19fdaeda1a12f21af5512396f37b9 *txdns.exe

Here we can see our hash is radically different than the original. A GPO administrator can't get around this with their blacklists. So what would blacklisting a hash be useful for? There may be a rare case where you encounter a specific and non mutating virus/malware that is in your organization. If you can throw up a hash rule and have systems update group policy, you can help to reduce the spread by this type of policy.

Certificate rules

It would be a bit rare to blacklist something that is signed. Many exe files won't be signed. If they are, and you have a specific one to block, you can look in the file properties to see the signature, and extract the certificate. Load this into a rule to block the software. This may work for something like Stuxnet that is reported to be signed by several stolen certs. Certificate rules would be primarily used in white listing mode, but again many exe's are not signed, or they may be signed with many certs. If you go looking through Microsoft software and downloads you will find either no signing or multiple certs used. Trying to keep up with external vendors' signed applications would take a lot of effort. If you were white listing a limited number of apps for a smaller set of machines, then this may be a useful method for one rule of your whole GPO.

Path rules

Getting path rules to work well in a blacklisting scenario would require a well locked down system to start with. Targeting a specific file using a standard install path would be pointless as the application could be moved or installed to a non standard location. If a user did not have access to create files and folders outside of their own home directory, you could blacklist everything in their profile to prevent execution of all code and scripts. Path rules allow for wildcards. So if you specify c:\documents and settings\*, no executable files can be run in this folder or any subfolders. This also includes attempts to access these files/folders using 8.3 format directory names. In the main policy settings, you can specify the extensions of files to protect against. You can try renaming the extension of a file such as file.exe to file.1 and trying to run it from cmd.exe. This will attempt to execute the file, but the system still sees it as the appropriate file type and blocks it. So, in general, if you need your systems to be extremely locked down, path rules can be a powerful addition.


The software restriction policy mechanism is being replaced by applocker, which is available in windows 7. It is possible to use both in policies, but only the newer OS's can process the applocker rules. I have yet to look at applocker, and I hope it is a step in the right direction for security and manageability.

Managing odd services in group policy

If you feel that using group policy to manage system services for security purposes is a good idea, and you want to block certain services that typically won't be in the list of services in the edit console, there are several ways to get around this. One suggestion (the hard way, and bad way), is to have the service installed on a machine, and edit the GPO from that machine. That will work, but it is time consuming, and may open up security problems just to set up the GPO.

The easier way is to create a GPO and pick any service from the list. Use this service to set whatever permissions, start type, and other options you want. From here you can either backup the GPO, or just directly edit the files in sysvol. In the policy you will see 3 folders:

Adm
Machine
User

The services are under machine, so open this. Drill down through Microsoft-> Windows NT->SecEdit and open the GptTmpl.inf in notepad. From here you can see a section called [Service General Settings]. One example line here for a vnc service:

"WinVNC4",4,"D:AR(D;;DCRPWPDTSDRC;;;BA)(A;;CCLCSWLOCRRC;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)"

Here we have the service name (this is not the display name you see in the services MMC. It is the service name you use with "net start" or how you find it in the registry. You can get this with psservice or sc.exe). Since we already set up all the other settings that we want, we can keep all the ACL information in place, and just change the name of the service that is in the first set of quotations. Edit what you want, add more services if you need and save.

If you backed up the GPO before editing it, you can just import this information into a new GPO object. If you are directly editing sysvol files you may need to update the version details in the same file (and possibly in other files and the GPO AD object), so it is best to go with the backup/restore method and create a new group policy object. This gives versioning flexibility and an easier backout path in case of problems.