Category: System and Network Admins

Reference articles to secure a Windows domain:

Microsoft audit Policy settings and recommendations:

Sysinternals sysmon:!2843&ithint=file%2cpptx&app=PowerPoint&authkey=!AMvCRTKB_V1J5ow


Beyond domain admins:

Gathering AD data with PowerShell:

Hardening Windows computers, secure Baseline check list:

Hardening Windows domain, secure Baseline check list:

Securing Domain Controllers to Improve Active Directory Security

Domain hardening in general:

  • Implement 2 or 3 tier model against Pass the Hash threat
  • FGPP implementation
  • LAPS Implementation
  • Process for proper cleanup of unused AD accounts
  • Reset of krbtgt account,domain admins account,IT administrators account
  • Setting Up Jump servers for Tier0,1,2 users
  • Domain joining of all windows boxes
  • Proper account Management Based on privileges
  • Usage of service accounts to run application instead of local system accounts
  • Review of existing AD accounts/Deletion of Unnecessary Accounts/ Review Ou structuring/GPO etc
  • HoneyToken Account Creation in Local boxes as well domain
  • GPO changes for disabling guest accounts across system,restricted RDP mode,Password Policy changes,disabling internet in member servers
  • GPO for Jump server implementation based on PAW GPO settings
  • Rename existing builtin Administrator account and lockdown
  • Sysmon deployment and WEF setup (WEC for symon events)
  • Use Pingcastle  review to assess the AD security
  • Use Bloodhound ( to assess the AD security
  • Use ADTimeline to assess the AD security


Some interesting sites:

Windows hardening:

Privilege admin workstation:

Delegate WMI access to domain controllers:

This post originally came about after several customers asked how to remove users accounts from Domain Admins and the Administrators group in the domain. These accounts are needed to monitor the systems, so we needed to find a way to get them to read the instrumentation of the system with non-elevated privilege.


Reference article:



Full article:



At its most basic, SMB is a protocol to allow devices to perform a number of functions on each other over a (usually local) network. SMB has been around for so long and maintains so much backwards compatibility that it contains an almost absurd amount of vestigial functionality, but its modern core use is simpler than it seems. For the most part, today SMB is used to map network drives, send data to printers, read and write remote files, perform remote administration, and access services on remote machines.

SMB runs directly over TCP (port 445) or over NetBIOS (usually port 139, rarely port 137 or 138). To begin an SMB session, the two participants agree on a dialect, authentication is performed, and the initiator connects to a ‘tree.’ For most intents and purposes, the tree can be thought of as a network share.[1] The PCAP below, shown in Wireshark, demonstrates a simple session setup and tree connect. In this case, the machine is connecting to the “c$” share (equivalent to the C:\ drive) on the machine, which is called “admin-pc


When you connect to remote Server Message Block (SMB) services shares by using \\192.x.y.z\share name, Kerberos is not used, and the Internet Protocol (IP) SMB file share access does not use Kerberos. A network trace shows the following Kerberos error in the KRB_ERROR: Server not found in Kerberos database


By default, Microsoft Windows Server 2003 and Microsoft Windows 2000 try to use Kerberos as the security provider. When a client uses Kerberos to authenticate itself to a server, the client requests a session ticket for the Service Principal Name (SPN). IP addresses are not names, so Kerberos is not used. After this occurs, the server goes through the list of the other supported security providers.


This behavior is by design.
IP addresses typically change, and it is not workable to add these addresses as SPNs. An SPN can be one of the following:

•The DNS name for the domain.
•The DNS name of a host.
•The distinguished name of a service connection point object.

How to export and import DHCP database

Note: be careful, when backup/restore DHCP. Remove the failover configuration on source DHCP before to perform a backup.

Try netsh dhcp export / import => this old method will not backup the FAILOVER settings. So it will help in your case to restore only the scopes.



A) Using the netsh command (OLD method):

To backup:
netsh dhcp server export d:\dhcpbackup\BackupFile.txt all

To restore:
Performing this task will create a file in the d:\dhcpbackup folder
Copy this file to the computer running Windows Server 2016 that will function as the new DHCP server.
You’ll need to install the DHCP server role on this computer and authorize the DHCP server in Active Directory before performing the following actions.
Open an elevated command prompt and run the following commands (this assumes you’ve copied the file to a folder named d:\dhcpbackup\)

Net stop DHCPserver
Del c:\windows\system32\DHCP\DHCP.mdb
Net start DHCPserver
Netsh dhcp server import d:\dhcpbackup\backupfile.txt
Net stop DHCPserver
Net start DHCPserver

B) Else using powershell (Recommended):

To backup:

To restore:

Following commands to be added twice to Linux and Windows :


net ads dns register -P


ipconfig /registerdns

Attack surface analyzer:





Microsoft security compliance toolkit:

Il remplace Security Compliance Manager. Cet outil permet de planifier, créer, et monitorer des baselines de sécurité pour vos postes clients. Le remplacement a été choisi par Microsoft du fait de la complexité de SCM et de la difficulté à maintenir l’outil pour chaque version de Windows. Aujourd’hui, SCT ne supporte pas Desired Configuration Management de System Center Configuration Manager ou SCAP.

how to use it:


Other references:

2012 R2 hardening (CIS):

Windows 10 hardening:




Security baseline reference article:


Download the content here: Windows-10-1903-Security-Baseline-DRAFT. As usual, the content includes GPO backups, GPO reports, scripts to apply settings to local GPO, Policy Analyzer rules files for each baseline and for the full set, and spreadsheets documenting all available GPOs and our recommended settings, settings that are new to this Feature Update, and changes from the previous baselines.

Note that Windows Server version 1903 is Server Core only and does not offer a Desktop Experience (a.k.a., “full”) server installation option. In the past we have published baselines only for “full” server releases – Windows Server 2016 and 2019. Beginning with this release we intend to publish baselines for Core-only Windows Server versions as well. However, we do not intend at this time to distinguish settings in the baseline that apply only to Desktop Experience. When applied to Server Core, those settings are inert for all intents and purposes.

This new Windows Feature Update brings very few new Group Policy settings, which we list in the accompanying documentation. The draft baseline recommends configuring only two of those. However, we have made several changes to existing settings, and are considering other changes. Please review the changes carefully and let us know what you think.

The changes from the Windows 10 v1809 and Windows Server 2019 baselines include:

  • Enabling the new “Enable svchost.exe mitigation options” policy, which enforces stricter security on Windows services hosted in svchost.exe, including that all binaries loaded by svchost.exe must be signed by Microsoft, and that dynamically-generated code is disallowed. Please pay special attention to this one as it might cause compatibility problems with third-party code that tries to use the svchost.exe hosting process, including third-party smart-card plugins.
  • Configuring the new App Privacy setting, “Let Windows apps activate with voice while the system is locked,” so that users cannot interact with applications using speech while the system is locked.
  • Disabling multicast name resolution (LLMNR) to mitigate server spoofing threats.
  • Restricting the NetBT NodeType to P-node, disallowing the use of broadcast to register or resolve names, also to mitigate server spoofing threats. We have added a setting to the custom “MS Security Guide” ADMX to enable managing this configuration setting through Group Policy.
  • Correcting an oversight in the Domain Controller baseline by adding recommended auditing settings for Kerberos authentication service.
  • Dropping the password-expiration policies that require periodic password changes. This change is discussed in further detail below.
  • Dropping the specific BitLocker drive encryption method and cipher strength settings. The baseline has been requiring the strongest available BitLocker encryption. We are removing that item for a few reasons. The default is 128-bit encryption, and our crypto experts tell us that there is no known danger of its being broken in the foreseeable future. On some hardware there can be noticeable performance degradation going from 128- to 256-bit. And finally, many devices such as those in the Microsoft Surface line turn on BitLocker by default and use the default algorithms. Converting those to use 256-bit requires first decrypting the volumes and then re-encrypting, which creates temporary security exposure as well as user impact.
  • Dropping the File Explorer “Turn off Data Execution Prevention for Explorer” and “Turn off heap termination on corruption” settings, as it turns out they merely enforce default behavior, as Raymond Chen describes here.




This might be very useful for certain situations where you want to update a user’s or computer’s group membership without the need to re-logon / restart. The whole magic is behind the issued kerberos tickets after you logged on to a machine or a machine has been started. The tool “klist.exe” cannot only be used for troubleshooting to display the current issued TGT / TGS, it is also capable to purge all current tickets. The purge command results in a re-issuance of the tickets, as soon as the next auth or service request is taking place.

Keep in mind that this method only works for services which authenticate via Kerberos.

NTLM based authentication still requires a fresh logon with updated group membership token.

To purge a user’s tickets: klist purge

To purge tickets of the local system account: Start a cmd or PoSH session with elevated privileges: klist -li 0:0x3e7 purge

klist is a tool that has been included by default since Vista/Server 2008 and above.

If you have a old version of Windows then you’re required to download klist here:

Be aware then the 2003/XP version of klist does not support purging directly the system accoun’s tickets. You can use psexec from sysinternals to launch an interactive command line as the system account (psexec -s -i cmd.exe) and then execute klist purge)

To generally control the lifetime of Kerberos tickets consider the following article:

NDES is the Microsoft Implementation of SCEP:

NDES installation and operations:


(NDES) Frequently Asked Questions (FAQ):


Configuring Network Device Enrollment Service for Windows Server 2008 with Custom Certificates:


NDES enrollment process:

1) Generate a key pair and install it on your device by using procedures provided by your device vendor.

2) Request a password by using the NDES admin site. The default URL is http://<computer_name>/certsrv/mscep_admin.

3) Establish trust between the device and the CA by downloading the CA certificate using the GetCACert operation and procedures provided by your device vendor. The default NDES URL for calling GetCACert is http://<computer_name>/certsrv/mscep?operation=getcacert&message=.

4) Submit the password and certificate request from the device to NDES by using procedures provided by your vendor.

5) NDES uses the request from the device to generate a certificate request and submit it to the configured CA.

6) If NDES certificate requests do not require certificate manager approval, the certificate is immediately returned to the device as part of the NDES response message.

7) If NDES certificate requests require certificate manager approval, the certificate request is held on the CA until it is reviewed by a certificate manager. Check the request status from the device using procedures provided by your vendor until NDES responds with the certificate.

Apple iPads and NDES:

1) The device connects to a deployment wireless network (isolated) while connected via USB to the Mobile Device Management Software (MDM). In this example, the IPad is connected to the Iphone Configuration Utility.

2) The device Administrator connects to the Network Device Enrollment Service (NDES) to obtain a temporary password which is entered in the Mobile Device Management (MDM) as the device’s profile.

3) The Mobile Device Management (MDM) software pushes the profile configuration to the device.

4) The device creates the private/public pair key and sends a request to the Network Device Enrollment Service (NDES)to request a certificate

5) The Network Device Enrollment Service (NDES) sends an RA request to the Certification Authority (CA)

6) The Certification Authority (CA) sends the certificate to the Network Device Enrollment Service (NDES)

7) The Network Device Enrollment Service (NDES) sends the certificate to Device which in turn installs it

8) The Device connects to the corporate network using 802.1X

NDES Operations 101:

– On the Ndes server verify if IIS is running and if NDES application pool is started

– backup IIS and export the HKLM\software\microsoft\cryptography\NDES registry key

– on the Ndes server, on Certificate Computer Store, check if the RA certificates has not been expired (else renew NDES Service Certificates):

Configuring NDES with custom certificates:


– verify if the issuing CA is responding