Latest Entries »




The basics of SMB signing

Server Message Block (SMB) is the file protocol most commonly used by Windows. SMB Signing is a feature through which communications using SMB can be digitally signed at the packet level. Digitally signing the packets enables the recipient of the packets to confirm their point of origination and their authenticity. This security mechanism in the SMB protocol helps avoid issues like tampering of packets and “man in the middle” attacks.

SMB signing is available in all currently supported versions of Windows, but it’s only enabled by default on Domain Controllers. This is recommended for Domain Controllers because SMB is the protocol used by clients to download Group Policy information. SMB signing provides a way to ensure that the client is receiving genuine Group Policy.

SMB signing was introduced in Windows 2000 (at the time it was also ported back to Microsoft Windows NT 4.0 and Microsoft Windows 98). With the introduction of SMB2 in Windows Vista and Windows Server 2008, signing was improved by using a new hashing algorithm (HMAC SHA-256 replaced the old MD5). At that time, the settings were updated to simplify configuration and interoperability (you can find details later in the post). Another important improvement in SMB2 signing is performance. In SMB1, enabling signing significantly decreases performance, especially when going across a WAN. If using SMB2 plus signing with a 1GbE network and a modern CPU, there is limited degradation in performance as compared to SMB1. If using a faster network (like 10GbE), the performance impact of signing will be greater.

If there are multiple valid certificates available in the local computer store, Schannel the Microsoft SSL provider, selects the first valid certificate that it finds store. The LDAP bind may fail if Schannel selects the wrong certificate.

Loading the requested server certificate into the NTDS/Personal certificate store will ensure that the correct server certificate is used for LDAPS


  • Automatic certificate enrollment (auto-enrollment) cannot be utilized to populate NTDS\Personal certificate store
  • Command line tools are not able to manage certificates in the NTDS\Personal certificate store
  • Certificates should be imported into the NTDS\Personal store and not moved through drag-and-drop in the Certificates snap-in
  • The import process must be conducted on each domain controller

LDAP over SSL (LDAPS) Certificate (MS TechNet)

When exporting the certificate:

  • When prompted, select “Yes, export the private key”
  • Select the “Personal Information Exchange – PKCS #12(.pfx)” format
  • Do not select “Include all certificates in the certificate path” or “Delete the private key if the export is successful”
  • Select “Export all extended properties”


This site is not optimized for Internet Explorer version 8 or lower. Please upgrade to a modern browser.

The question is “How do I delegate enabling and disabling Active Directory accounts?”. Unfortunately, these specific operations cannot be individually delegated. The flag that indicates whether a user is enabled or disabled is part of a bitmask called userAccountControl. The vast majority of options in this bitmask are the checkboxes that you see on the account tab of ADUC:

The complete list of what’s stored in the bitmask (copied out of the iads.h header) is below. Most of them should be fairly self explanatory but this MSDN article explains them all. The numbers are the bit which represents this value in the mask (in hex):

  • ADS_UF_SCRIPT = 0x1
  • ADS_UF_LOCKOUT = 0x10
  • ADS_UF_NOT_DELEGATED = 0x100000
  • ADS_UF_USE_DES_KEY_ONLY = 0x200000

Why list all these options? If you delegate a user rights to modify the userAccountControl attribute, you give them rights to set all these other options. If you’re comfortable with this, the steps below show you how to delegate access to the userAccountControl attribute.

In this example, we will grant a group called User Admins rights to modify the userAccountControl attribute on all User objects in the Sales OU. As always, it’s a best practice to never delegate a right to a user but rather to delegate a right to a security group which the user is a member of.

  1. Launch ADSI Edit – start>run>adsiedit.msc
  2. Browse to the Sales OU and open the properties of the OU.
  3. Select the security tab and then click Advanced.
  4. Click Add and enter the name of the group (“User Admins”). At this point your screen should look similar to the following image:

  1. Click OK and then switch to the Properties tab of the ACL editor dialog.
  2. Select “User objects” from the Apply onto dropdown.
  3.  Scroll down to the userAccountControl entry.
  4. Check the Allow checkboxes for Read userAccountControl and Write userAccountControl (technically the Read right is not necessary but I’ve chosen to include it in case default permissions have been modified elsewhere).

Technet reference:

Web links:


Remove-DhcpServerv4Scope -ScopeId -Force

Add-DhcpServerv4Scope -Name “SERVICE-LAN-VIRTUAL” -Description “Virtual Wks Office VLAN” -StartRange -EndRange -SubnetMask -LeaseDuration 7.0:0:0 -State Active -Type Dhcp
Set-DhcpServerv4OptionValue -ScopeId -OptionId 3 -Value
Set-DhcpServerv4OptionValue -ScopeId -OptionId 6 -Value -Force
Set-DhcpServerv4OptionValue -ScopeId -OptionId 44 -Value -Force
Set-DhcpServerv4OptionValue -ScopeId -OptionId 46 -Value “0x8” -Force

Add-DhcpServerv4Failover -ScopeId -PartnerServer -Name TVLAN-$3rdOctet
Get-DhcpServerv4Failover -ScopeId

Behind this catchy title is a real need. As a system administrator, it may be worthwhile to audit all of your organization’s Active Directory accounts to assess the level of security for user accounts. Let’s see how we do it!

Web resources and Methods:

Possible causes of O365 authentications failures:


ADFS account lockouts:


Protecting against DDOS and accounts lockouts:

AD FS Extranet Lockout: a case of the unintended pun

The threshold for Extranet Lockout Protection should be configured to be lower than the Lockout settings in Windows AD, so ADFS can stop trying to log on before it’s too late

Warning: the availability of the PDC is mandatory for WAP (proxy)-based authentications: look this article for more details:

ADFS attacks (video):




Windows firewall with Powershell:

Windows firewall rules groups:

The commands below are to open the firewall for most remote admin functions (since you’re using core and testing it, you’re going to remote manage right?)

Enable-NetFirewallRule -DisplayGroup “Remote Volume Management”
Enable-NetFirewallRule -DisplayGroup “Windows Firewall Remote Management”
Enable-NetFirewallRule -DisplayGroup “Remote Scheduled Tasks Management”
Enable-NetFirewallRule -DisplayGroup “Remote Service Management”
Enable-NetFirewallRule -DisplayGroup “Remote Event Log Management”
Enable-NetFirewallRule -DisplayGroup “Windows Remote Management”

Enable-NetFirewallRule -DisplayGroup “File and Printer Sharing”

Enable-NetFirewallRule -DisplayGroup “Performance Logs and Alerts”

Enable-NetFirewallRule -displaygroup “COM+ Remote Administration”

Enable-NetFirewallRule -displaygroup “COM+ Network Access”


Domain controllers and Windows Firewall Configurations:

As described earlier, you should use the Security Configuration Wizard to capture configuration settings for the Windows Firewall with Advanced Security on domain controllers. You should review the output of Security Configuration Wizard to ensure that the firewall configuration settings meet your organization’s requirements, and then use GPOs to enforce configuration settings.


Powershell cmdlets for Windows security:


How to configure the Windows firewall with netsh (command line):

else the most known commands are:

Import/export firewall settings:

netsh advfirewall import “c:\firewallconfig.wfw”

netsh advfirewall export “c:\firewallconfig.wfw”

query fw rules:

netsh advfirewall firewall show rule name=all

enable or disable windows fw:

netsh advfirewall set allprofiles state on      ;     netsh advfirewall set currentprofile state on     ; netsh advfirewall set currentprofile firewallpolicy blockinboundalways,allowoutbound

netsh advfirewall set allprofiles state off

reset windows fw:

netsh advfirewall reset

windows fw logging:

netsh advfirewall set currentprofile logging filename “d:\firewall.log”

allow or deny PING:

netsh advfirewall firewall add rule name=”ALL ICMP V4″ dir=in action=block protocol=icmpv4

netsh advfirewall firewall add rule name=”ALL ICMP V4″ dir=in action=allow protocol=icmpv4

enable a specific port:

netsh advfirewall firewall add rule name=”open a specific app port” dir=in action=allow protocol=TCP localport=1435

enable a program:

netsh advfirewall firewall add rule name=”allow messenger” dir=in action=allow program=”c:\programfiles\messenger\msnmsgr.exe”

enable file and print sharing:

netsh advfirewall firewall set rule group=”File and Printer Sharing” new enable=Yes

enable remote desktop service:

netsh advfirewall firewall set rule group=”remote desktop” new enable=Yes

enable remote management (winRM):

netsh advfirewall firewall set rule group=”remote administration” new enable=Yes

Tips and Tricks:
Tip: In Exchange Server 2016 the architecture was simplified when compared with previous versions, and nowadays we have only two roles: Mailbox and Edge. Where the Mailbox is the role that is located in the internal network with access to the Active Directory.
Tip Exchange 2013 sp1: the Edge role reappears
Tip: ReFS not supported as File System
Tip: No storage on SMB is supported
Tip: OWA support the certificates and ADFS (strong authent scenario)
Tip: dedicate CAS servers behind hw load balancer – with public URL. the Certificate is managed by internal PKI.
Tip: prefer using Win2012 R2 and Exchange 2013 SP1 (better together!)
Tip: prefer using the command lines to install exchange 2013 role
Tip: when using cmdlets: always for details do | fl prop1,*prop2  or  | ft -autosize

Topology best practice (after SP1 of Exch 2013):

internet —–  FW —– edge server (dmz / in a wkg) —– FW —– hwlb – CAS servers —– MBX servers — FW — AD / PKI servers


Exchange installation prerequisites:

For Exchange 2016:

For Exchange 2013:

Exchange 2016 step by steps:

Cumulative updates:


Exchange and certificates:

public or internal PKI server certificates only on CAS servers, follow the recommendations here:

also the client computers are joined to the AD domain and have also a computer certificate.


Exchange and Firewalls:


Deployment assistant for Exchange: 


Exchange sizing:

HP sizer for Exchange 2013:


How to dedicate DC to Exchange? and It is recommended to exclude the DC PDC server.

How to separate roles for AD admins and roles for Exchange admins? ==> RBAC split permissions and AD split permissions

Test connectivity:

ExLogAnalyzer to the rescue:

Database maintenance:

With Outlook 2013 installed; CTRL+ right-click Outlook icon on the taskbar; then Check Outlook Connectivity and Test Messaging configuration

Validation and monitoring of storage:

When implementing a storage solution for Exchange, an easily overlooked step is the evaluation of storage after it has been put in place to determine a baseline for that storage. Microsoft makes tools to enable this testing. Jetstress and LoadGen available for Exchange 2010/2013 can be used to test storage or Exchange overall and establish a baseline for future comparison.

Jetstress 2013:

LoadGen 2013:

How to improve Windows DNS logging (audit and analytics):


DNS logging (audit and analytics):

Free tool:

Scripts to parse DNS debug logs:

Performance considerations

DNS server performance can be affected when additional logging is enabled, however the enhanced DNS logging and diagnostics feature in Windows Server 2012 R2 and Windows Server 2016 Technical Preview is designed to have a very low impact on performance. The following sections discuss DNS server performance considerations when additional logging is enabled.


Prior to the introduction of DNS analytic logs, DNS debug logging was an available method to monitor DNS transactions. DNS debug logging is not the same as the enhanced DNS logging and diagnostics feature discussed in this topic. Debug logging is discussed here because it is also a tool that is available for DNS logging and diagnostics. See Using server debugging logging options for more information about DNS debug logging. The DNS debug log provides extremely detailed data about all DNS information that is sent and received by the DNS server, similar to the data that can be gathered using packet capture tools such as network monitor. Debug logging can affect overall server performance and also consumes disk space, therefore it is recommended to enable debug logging only temporarily when detailed DNS transaction information is needed.


Enhanced DNS logging and diagnostics in Windows Server 2012 R2 and later includes DNS Audit events and DNS Analytic events. DNS audit logs are enabled by default, and do not significantly affect DNS server performance. DNS analytical logs are not enabled by default, and typically will only affect DNS server performance at very high DNS query rates. For example, a DNS server running on modern hardware that is receiving 100,000 queries per second (QPS) can experience a performance degradation of 5% when analytic logs are enabled. There is no apparent performance impact for query rates of 50,000 QPS and lower. However, it is always advisable to monitor DNS server performance whenever additional logging is enabled.