Advice Request How would you protect a Local Primary Domain Controller

[Victor M]

Hi Everyone,

I read a long time ago that it is quite difficult to harden a Windows Primary Domain Controller. I tried just yesterday to disable Windows Remote Shell on it and then it can't install the Domain Controller Role. Like what the heck, Windows uses Remote Shell to install a local server? I know I can disable that After choosing the role - so nothing else will break.

Anyways, what else can I do to protect it ?

 

[Andrezj]

Hi Everyone,

I read a long time ago that it is quite difficult to harden a Windows Primary Domain Server. I tried just yesterday to disable Windows Remote Shell on it and then it can't install the Domain Controller Role. Like what the heck, Windows uses Remote Shell to install a local server?

Anyways, what can I do to protect it ?

winrm is a service, not a protocol, and uses the wsman protocol (web services for management, another service) to implement powershell remoting
powershell remoting is enabled by default windows for server 2012+, so winrm is enabled by default
disable powershell remoting using administrative command:
disable-psremoting -force
winrm uses ports 5985 and 5986, you can block those ports

install local server and then disable winrm service, did you try?

 

[Victor M]

Yes, I let the role configuration finish, and I was able to disable Windows Remote Management as well as Windows Remote Shell in gpedit.

 

[Victor M]

Are there any free or cheap tools? Hardening can only so much.

 

[Victor M]

EDIT hardening can only do so much.

 

[Andrezj]

Are there any free or cheap tools? Hardening can only so much.

Some Windows hardening with free tools



Windows PowerShell script that finds misconfiguration issues which can lead to privilege escalation.

GitHub - enjoiz/Privesc: Windows batch script that finds misconfiguration issues which can lead to privilege escalation.

Windows batch script that finds misconfiguration issues which can lead to privilege escalation. - GitHub - enjoiz/Privesc: Windows batch script that finds misconfiguration issues which can lead to ...

github.com

GitHub - decalage2/awesome-security-hardening: A collection of awesome security hardening guides, tools and other resources

A collection of awesome security hardening guides, tools and other resources - GitHub - decalage2/awesome-security-hardening: A collection of awesome security hardening guides, tools and other reso...

github.com

 

[Victor M]

Thanks @Andrezj

All the hardening links are appreciated. I will go through them.

 

[Victor M]

Hit a brick wall.

I am trying to implement Defender Firewall > Connection Security Rules on my trial version of Win Server.

On the workstation I have done this:
New Rule > Isolation > Request authentication for inbound and outbound connections > Computer (Kerberos VS) , all profiles checkmarked

On the Domain Controller I have done this:
New Rule > Isolation > Require authentication for inbound and outbound connections > Computer (Kerberos VS) , all profiles checkmarked

Both Win11 22H2 and Win10 22H2 workstations failed to connect to PDC, it says 'Unidentified Network', instead of 'MyDomain.box' when looking at the network adapter systray and gpupdate fails to connect to PDC.

When I remove the Connection Security Rule on the PDC, the client workstations can connect properly.

Network isolation for the PDC is important because it cuts connection to any PC which is not part of the domain.

Anyone have any ideas? Surely MS would have done regression testing and tested that this feature is working?

Before hastily testing this, I will ask that if this seems to work, then reboot the client workstation and see that it still works. The workstation fooled me by seemingly able to connect to the PDC right after I built the firewall rule but upon reboot it says Unidentified network because the server and the workstation are not connected to the gateway. And if it truly is working you should be able to do 'gpupdate' on the workstation after a reboot.

 

[Victor M]

I don't understand, what does Request Outbound Request Inbound mean. I am only able to establish connection when the PDC uses this setting. And it doesn't matter if the workstation is set either to Request Outbound Request Inbound or If the workstation does not have a Connection Security Rule, They also can still talk to each other. So this "Request Outbound Request Inbound'" rule is useless and does not provide any authentication benefit for the PDC.

When both sides are set to Request Qutbound Request Inbound, the firewall shows something in Monitoring > Security Associations > Main mode and Quick mode. So Kerberos is working. But it doesn't work when the PDC is set to Require Outbound Require Inbound.

 

[ForgottenSeer 98186]

I don't understand, what does Request Outbound Request Inbound mean. I am only able to establish connection when the PDC uses this setting. And it doesn't matter if the workstation is set either to Request Outbound Request Inbound or If the workstation does not have a Connection Security Rule, They also can still talk to each other. So this "Request Outbound Request Inbound'" rule is useless and does not provide any authentication benefit for the PDC.

When both sides are set to Request Qutbound Request Inbound, the firewall shows something in Monitoring > Security Associations > Main mode and Quick mode. So Kerberos is working. But it doesn't work when the PDC is set to Require Outbound Require Inbound.

Some settings only apply until after IPSec is enabled and configured.

You have to remember that Windows Firewall has not gotten an update in many years, the documentation is minimal and quite a bit is undocumented.

You are better off seeking an answer on Server Fault or Network Engineering Stack Exchange .

You can try the current Microsoft Tech Community for Windows Server: Windows Server Community

 

[Victor M]

Thanks for your suggestion, I posted a message to Server Fault.

 

[ForgottenSeer 98186]

Thanks for your suggestion, I posted a message to Server Fault.

Do you mind providing the link to the topic on ServerFault? I myself am interested in this topic and the replies it will receive.

Thank you

 

[Victor M]

Here's the link: Cannot establish Network Isolation - Require Inbound Require Outbound for Domain Controller

 

[Neno]

To harden the main DC... that is the (huge) topic with many dependencies. But the first (kind of) step would be 'Security baseline' implementation (Security baselines guide).
Happy reading

 

[ForgottenSeer 98186]

Here's the link: Cannot establish Network Isolation - Require Inbound Require Outbound for Domain Controller

Thanks

 

[Victor M]

@Neno Hi, thanks for the link. I have already applied the MS Security Baseline.

I am just hoping that Network Isolation is achievable, it seems to promise that nobody outside the domain can talk to the DC. Hence, no data leaks, no RATs etc.

 

[valvaris]

Hi Everyone,

I read a long time ago that it is quite difficult to harden a Windows Primary Domain Controller. I tried just yesterday to disable Windows Remote Shell on it and then it can't install the Domain Controller Role. Like what the heck, Windows uses Remote Shell to install a local server? I know I can disable that After choosing the role - so nothing else will break.

Anyways, what else can I do to protect it ?

Hi,

if you try to harden a Windows Server with a Domain Controller Role (DNS) it is great to have a Security centric DNS Chain.

Example:

So, if a request comes in for a local resource it passes thru the Firewall and then to the Domain Controller/s.
DC <<-----Firewall Appliance (With DNS Request Route) <<----Client
Then if a request comes in for a external resource (www.google.com)
DNS Uplink Server (Cloudflare DNS or others) <<--------Firewall Appliance (DNS Uplink) <<--- Client

Like this you could also Use a TLD and harden your Services with a WildCard Cert from a known CA. (Not a Split-brain DNS approach). You still manage your local Zone on your Domain Controller and External Public DNS on the Public DNS Servers.

The other part is Services like Web, Mail and so on...

----------------------------
Remediation for Active Directory:
- Keep your Systems Up-to-date
- Use LAPS and GPO to Rename and Auto-Set Default strong Passwords for Domain Joined (Clients and Servers)
- Disable Remote PowerShell / RDP (I use Splashtop over a RMM Service to have granular Auditing - Even Splashtop as a Business License is genuinely nice)
- Create GPO to rename Local Administrator Account/s
- Disable SMBv1 and Block it!
- Enable Windows Firewall
- Proper IP/DNS Settings (Use BPA for help if needed ^^)
- Use an Endpoint Security for Servers (Example: Sophos Intercept X Advanced with XDR for Servers - For ppl that do not have an expert IT-Security Team use the MDR Complete option that has a 24/7 SOC Team for Monitoring and much more... )
---- With tools that have EDR / XDR you can have a DataLake and use queries to see changes, manipulations and so on...
- Implement RBAC (Role Based Access Control) [Never use a DA (Domain Admin.) or OA (Organization Admin.) Account for normal day to day work. Only use a DA or OA Account if you need to do Admin. work on the Servers]
- Check for Password Venerability's -> Free -> Specops Password Auditor
- Never Stop researching it is a journey

-------------------------------------------------

Nice Video 1 Source Manage Engine:

Nice Video 2 Source Black Hills Information Security:

-----------------------------------------------
If you are a huge Enterprise, I recommend using BigFix by HCL former IBM Product:
- Build in Remediation with Fixes that are easy to deploy to X Servers and maintain a Baseline.
- Patch Managment
- Security Compliance with known standards by CIS and NIS with deployment options build in.
- Reports that ensure proper deployment of sed tasks
- It has tons more features...
- Link -> HCLSoftware

Hope I could help.

Val.

 

[Bot]

It's definitely important to secure your Primary Domain Controller (PDC) to ensure the security of your network. Here are a few suggestions to help you protect your PDC:

1. Keep your PDC up-to-date with the latest security patches and updates. Make sure that you have a regular schedule for applying these updates, and test them in a non-production environment before deploying them.

2. Implement strong passwords and account lockout policies to prevent brute force attacks. Consider using multi-factor authentication to further secure user accounts.

3. Disable unnecessary services and features on your PDC. Only run the services that you need to run, and disable everything else.

4. Configure your firewall to only allow necessary traffic to reach the PDC. Consider using a separate firewall rule for inbound and outbound traffic.

5. Monitor your PDC for unauthorized access or activity, and review log files regularly.

6. Implement network segmentation to isolate your PDC from other parts of the network.

These are just a few suggestions to help you protect your PDC. Remember that security is an ongoing process, so it's important to review and update your security measures regularly. Also, consider seeking the help of a professional IT security consultant to ensure that your PDC (and your entire network) is as secure as possible.