Using Powershell to locate your Geographical Location with the help of GeoLocation (IP-Address) is quite easy, cool and useful!
When we build Private and Hybrid Clouds across the globe in various countries and continents I want to make sure the Active Directory PDC Emulator is using a valid time source based on that location.
So with this small script (it’s using multiple WebServices to cycle through until it gets an answer) we can get a rough location for where we are and in my case it’s usually enough to know what country the datacenter is in.
That can then be used as you see fit. Though for me, I’m using it to update the Group Policy being applied to the PDC Emulator to point to the country specific NTP Pool with the generic pool as backup value.
It’s a Group Policy being applied to all Server Admins utilizing Group Policy Preferences to delete two files (one for Windows Server 2012R2 and one for Windows Server 2016). But it’s only doing it once to make sure that if a admin does any changes to the file it won’t be deleted again. The idea is that it will be deleted once to reset settings to the one in ServerManager.exe.config but not repeatedly after that if the administrator saves any other changes.
That file only contains new default WelcomeTileVisibility setting, hiding the Welcome tile for you when you launch Server Manager. And if you do any changes in Server Manager, the new settings will be saved to that file too.
But that’s a per user setting and it has to be copied to the profile after it’s been created etc etc. Making it all a bit more complicated.
Luckily there is a better and easier way to do it, where you also help your co-workers at the same time!
In your reference image, or in your Server deployment script or with PowerShell or with Group Policies or any other way you find worthy. Just use the same information as above, but save it in this path to be machine wide;
Notice that it’s still the exact same content of the file;
But it’s now stored together with the ServerManager.exe file in the system32 folder making it server wide. It’s a lot easier to copy it there just once so it’s applied to everyone rather than try to get the config file into each persons profile.
Notice: If you already have a user.config file in your Profile, it may override the settings from serverManager.exe.config so delete your user.config file to verify your new setup is working as expected.
In our environment, we are deploying the file in our Server Deployment solution, and also copying it to all server with a Group Policy Preference just in case someone installed a server manually for some unknown reason.
If you are trying to get NAP (Network Access Protection) and SDI (Server & Domain Isolation) to play nice, you might not get the results you are expecting. I’m going to explain howto get NAP with Server and Domain Isolation to play together
There are plenty of Blogs and Guides out there, explaining how to get either NAP or Server and/or Domain Isolation to work. And that’s basically no problem so I won’t cover that here today.
But I’ve so far not found anyone who’s tried to combine both technologies.
First of all, some background for my environment. I’m working on a project where we want to implement NAP to get the health check, but also Server and Domain Isolation to make sure that only trusted clients and users can talk to the systems they have access to. There was no doubt that we would use Certificates to validate the client health state.
Two Windows Server 2008 R2 Servers with HRA/NAP Roles and the Stand-Alone CA Role were installed for redundancy. Clients are getting the Health Certificates and all is good. The SA (Security Associations) policy on the servers and clients is configured to “Require Inbound and Request Outbound Authentication”, with a requirement for a Health Certificate from the organizations CA Servers. So far, so good.
The clients can now access the server when they have a valid health state, and are unable to access the server if they don’t. Yay! NAP works.
And the nice thing is that since the HRA only serves Domain Joined clients. As the servers won’t talk to any client without a Health Certificate, and only Domain Joined client can get one, we have also got “Domain Isolation”. Ok, two out of three check boxes done.
Now, try to use Server Isolation and configure a Firewall Rule to only allow ClientA to talk to connect to ServerX via RDP. That does not work. Well, it does work to create the rule, but it will never allow the traffic.
The reason is that when you use a NAP Certificate to authenticate the connection, there is no mapping to the computer account. Which makes it impossible to use a Computer Based rule.
Notice “No Authentication”.
Okay, so if you use the check box “Enable certificate to account mapping”?
Sorry, that doesn’t work either. When you use the Health Certificate feature, no certificate mapping is done in the Windows Firewall. This has been verified in the Windows source code.
This blog post does state that it should be possible to use that check box and then use a Policy “Access this computer from the network” where you can specify which computers are able to access the server over the network. But it’s still “All or nothing”. You can’t specify that ClientA should be able to access the SQL Server but nothing else.
Solution for NAP with Server and Domain Isolation
Luckily, there is a kind of workaround. To be honest, it’s not that common that you want to restrict so only ClientA, ClientB and ClientC can access the SQL Service on ServerX. I would dare to say its more common that you want to restrict which Users can access the service. Right?
I want to control so UserD, UserE and userF can access the RDP (Remote Desktop) Service, from any Health Domain Joined Client. It doesn’t really matter which client they connect from as long as it’s healthy and domain joined. Or I could control which clients they are able to logon to.
So by using a “Secondary Authentication” option, where we Authenticate the User, like this.
Still the same options for the Computer Authentication. Just add a Secondary Authentication on the SA for User (Kerberos v5). It’s then possible to restrict which users are able to connect to a specific service.
In your firewall RDP Rule, configure it to Require a secure connection, and specify which users should be able to access the service. Now try to connect with two different users via RDP. You should see how the rule is applied and works.
I decided to create a Firewall Rule for RDP that only allowed “TestUser” to connect to the service.
In the screenshot below, the upper RDP is started with the TestUser Account, while the bottom RDP Client is started with “Runas Domain\Administrator” which according to the rule, should not be allowed to connect. And as you see, it’s not able to connect, which is expected.
To get NAP to work with Server Isolation, you have to enable “Second Authentication” for the User with Kerberos Authentication, so there is Authentication done when the connection is established. Which in turn makes it possible to create Firewall Rules that can be applied to User Object, unfortunately not to computer objects.