As I’m migrating Domain Controllers over to Server Core one of the major issues I’ve run into is managing the Windows Firewall Rules. On a GUI version of Windows Server it is very easy to see what firewall rules are applied, in core… not so much, especially if you are pushing them with GPO (Group Policy).
All of the PowerShell cmdlets and netsh advfirewall commands all seem to return the local firewall rules and not any of the Group Policy pushed firewall rules. Moreover I could not find an easy way to see what the current firewall rules are that are applied via GPO.
As I have disabled all of the built-in firewall rules as to lock down the Domain Controller Firewall Rules as tightly as possible, even with RPC open and the dynamic RPC range locked to specific ports but open the Windows Firewall MMC would not open. I was seeing no blocked traffic in the Windows Firewall Logs.
I received the following error message:
“There was an error opening the Windows Firewall with Advanced Security snap-in”
“The specified computer could not be remotely managed. Ensure that you are not trying to connect to a remote computer with an earlier version of Windows…..”
My solution to this problem was to enable the built-in Firewall Rules for Remote Firewall Management so you can use MMC console:
Windows Firewall Remote Management (RPC) Windows Firewall Remote Management (RPC-EPMAP)
These firewall rules seem to have some special magic to them that I haven’t put my finger on yet that allow the Remote MMC Firewall snap-in to work. You can of course lock these rules down to remote IPs as well.
I currently run this script every hour and I get plenty of overlap for logs. The logs roll relatively quick but not that quick. I’m also logging all allows and I may change that in the future to only log drops.
In order to see dropped traffic outbound you would have to have outgoing firewall rules in place. By default traffic is not blocked going out. You can reference my previous post linked above.
In the example below you can see I’m limiting all TCP/UDP outbound traffic on Non HTTP ports to a certain subset of IP ranges:
If this Domain Controller tries to send any NON-HTTP(s) traffic outside of the organization it will show up in the DC firewall logs.
Example of HTML Report:
If your IT Security group has the hardware firewalls super locked down you may not see much if any traffic being dropped on the local DCs, but it still isn’t a bad idea to have another layer of security around such a high profile service!
**EDIT** If you log into vcenter with an Active Directory account you should be able to modify an already existing Identity Source. I had been logging in with local administrator account.
For reference we already had our linked vCenter talking to Active Directory over LDAPS. However, we are currently in the process of migrating all of our VMs over to new hardware. When we tried to move the main Active Directory server providing authentication to vCenter, lets just say it was not happy.
Upon trying to enter into the Identity Sources and update the server(s) manually on the Identity Source that was already being used we received the following message: “Check the network settings and make sure you have network access to the identity source”.
It was not found until after doing some Googling that you have to remove your current running Identity Source in order to make changes. In other words delete the current identity source and add a “new” one in order to make the changes you want to make.
This just seems bad.
However, after doing a lot of testing in our TEST environment I could not seem to run into any snags. If you login with firstname.lastname@example.org and delete and then immediately re-add the identity source back with the same domain name, alias, etc, there does not seem to be any issues. All of your permissions on objects defined with AD groups will remain.