Windows 10 DirectAccess Collect logs not Working

Posted by Ahmed Nabil In | 3 comments»
Microsoft DirectAccess is an awesome technology that connect you seamlessly to your corporate network without installing any client or configuring any setting from the end user. Sometimes Direct Access doesn't get connected or stay in the "connecting" state for a long time and when you try to contact your Direct Access Administrator the first thing required will be collecting the DirectAccess logs and sending it to your administrator.

So if everything is configured correctly and you have an email client configured on your computer (whether its outlook or default Windows Mail), when you navigate to your modern Windows 10 Settings - Network & Internet - DirectAccess, you will find a button named "Collect" and when you hit collect it will open your configured mail client and attach the DirectAccess logs to this mail and you can enter your "TO" address (Example you administrator or Help Desk team) or it may be populated with this address if your administrator configured it from the server.

Super easy and very efficient and all you need from your user is to click on Collect and you will get his logs and analyze it, figure the problem and that's it.

So what is the catch ? Well its not working as designed ! this was noticed on several machines starting Windows 10 1703 where the users will hit "Collect" and nothing happens although they have everything configured correctly (Mail client and server side settings)

So upon checking this issue with Microsoft Support team it was concluded that this is a kind of a bug that started with Windows 10 1703 (earlier versions like Windows 10 1607 works fine) and only with Machines with memory more than 3.8 GB (Most of our new hardware Laptops and machines). It will work fine if you have 3.8 GB memory or Less

Reason of Problem:

The reason behind this bug is that starting with the creators update (Windows 10 1703) a new feature is introduced which is the split feature that allowed something like SVCHOST to run independent process for each service. So the one in question here is the Networking connectivity Assist "NCASVC" that runs under the NetSVC SVCHOST.

So the "NCASVC" will split into its own SVCHOST and log collection fails. The log collection process is series of powershell commands that runs on the machine to collect logs which it will fail to launch due to missing the privilege "SeAssignPrimaryTokenPrivilege" on this splitted new process.


So we have two workarounds/solutions provided by Microsoft which is either to stop/disable this split process or grant the needed privilege. To fix this issue you need to do just one of the below solutions:

  1. Disable the Split mentioned above by creating DWORD registry parameter "SvcHostSplitDisable" and set it to 1 under  "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NcaSvc" - Need to restart your client machine                                                                                                                                                                                                                                                    
  2. Add the "SeAssignPrimaryTokenPrivilege" to "RequiredPrivileges"  in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NcaSvc - Need to restart your client machine

So that's all you need to do on your client machine (Windows 10 1703 and above with more than 3.8 GB Memory). Test it on one machine and then you can distribute this Registry fix on all your DirectAccess machines using SCCM, Intune or any software distribution tool.

Hopefully this will help some of you facing this issue.

Microsoft DirectAccess 2016 Implementation Part 1

Posted by Ahmed Nabil In | 1 comments»
Microsoft DirectAccess is a very cool technology when it comes to connecting to your corporate network from anywhere over the Internet in a very secure manner. DirectAccess was available since Server 2008R2 with very limited capabilities and then came the Microsoft Unified Access Gateway (UAG) which was an amazing technology at that time that allowed DirectAccess protected by Microsoft ISA server (Good old days).

The UAG offered core features like the DNS64 and NAT64 (Please note that DirectAccess works over IPV6) and these features was important because up till now we can rarely find any corporate running all its internal network on IPV6. Later on Windows 2012R2 server as well as Windows 2016 server came with the DirectAccess role offering most of the features in UAG and new ones that simplify the deployment especially for Windows 8 and Windows 10 clients.

Why do I love DirectAccess ?

  1. Seamless and Always on connection. No client is needed like regular VPN deployments. All you need is corporate configured Laptop/Computer/Server (Yes DirectAccess can be implemented on your remote site servers) and Internet connection (Any public Internet) and once you are logged you are connected securely.                                                                                
  2. Transparent bi-directional. The DirectAccess client is connected to the corporate network as if its inside the network, it can connect to resources in the corporate and users from the corporate like help desk team can connect to the DirectAccess client for any troubleshooting. Also any management software like SCCM, Active Directory, WSUS......etc can still access and apply all policies on these remote DirectAccess clients.

Requirements and Server Preparation.

  1. Installation and Implementation is done on Server 2016 (Latest version and updates as of July 2018). One server deployment (Single Server Site deployment)                                                                                                                                                      
  2. Recommended deployment is to have one server with two Network cards, the first network (Internal) is connected to the internal corporate network and the second network card (External) is connected to the DMZ which is behind your corporate firewall. This is the recommended deployment which I will go through these blog series however you can have the DirectAccess server with one NIC or on your network edge facing the Internet directly however each of these deployments has its drawbacks and its not fully secured. Again it depends whether production or lab but I highly recommend going with 2 NIC model behind the firewall.                                                                                                                                                     
  3. Since we are behind the Firewall then we need to create a Destination NAT rule to forward DirectAccess traffic (Inbound 443) to the DirectAccess External NIC. As we are behind the Firewall we will be using IP-HTTPS Not Teredo or direct IPv4  (IPV6 transition technologies to IPV4)                                                                                                                                                          
  4. Active Directory should be running DFSR                                                                                                      
  5. Create an OU in your Active Directory and give it a convenient name. All DirectAccess computers will be under this OU.                                                                                                                                 
  6. Create a Security Group for DirectAccess clients and give it any convenient name.                              
  7. DirectAccess can run with self signed certificate if you are running Windows 8 and 10 clients only (which is our case) however for more secure deployment you will need internal PKI to generate client certificates and you need public SSL certificate for your DirectAccess server. You can create one and name it "". In your external DNS make sure to assign a public IP to this name, this IP will be used to create the Destination NAT from it to the server External NIC (DMZ) as we mentioned above. Some Key factors for the internal certificates that will be assigned to your clients are shown below.                                                                       
  8. Internal PKI DirectAccess Client template, make sure to have the certificate recipient Windows 8.1 or higher to support Windows 8 and 10, If you need to support Windows 7 then the Authority should be Windows 2008 R2 and Recipient Windows 7                                                                                                                                                                                                                                                                                                            
  9. Minimum Key size should be at least 2048                                                                                                                                                                                                                                                                                                                          
  10. Make sure Subjectname is built from Active Directory - DNS. The Certificate will have the DNS name of the computer.                                                                                                                                                                                                                                                                                                                         
  11. The most important step while creating the DirectAccess client certificate template is to ensure the DirectAccess Security group created in Active directory - step 6 (In my case i named it DirectAccess_Clients) has the enroll and Autoenroll check box. You will need to have an Autoenroll Group policy to allow these clients to pick and renew the certificates automatically.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  

Server Deployment/Installation.

  1. Installing DirectAccess can be done either by PowerShell or GUI. PowerShell is very simple single command to install it and the command is as follows "Install-Windowsfeature Directaccess-vpn -includeManagementTools"                                                                                                                                                                                                                                                                        
  2. The other way is the GUI and we will go through the installation step by step.  Open Server Manager and add new role                                                                                                                                                                                                                                 
  3. Pick the Remote Access Role                                                                                                                                                                                                                                                                                                      
  4. Choose DirectAccess and VPN role services and add the needed features needed by DirectAccess                                                                                                                                                                                                                                                                                                                                         
  5. That's all you need and then Finish and reboot the server.

In the next part of this series we will be discussing the post configuration for the server and share some tips to ensure you have a smooth up and running DirectAccess implementation.

Hopefully you enjoyed reading this post.                                                                                                                                                                                                                                                                        

Office 365 DMARC rule blocking NDR mails from On-premise servers

Posted by Ahmed Nabil | 2 comments»
This is a very interesting scenario and I guess common one for all Office 365 hybrid configurations with DMARC enabled. I recently faced this issue and had to dig into several tools and troubleshooting techniques and contacted Microsoft support team for the best solution after identifying the problem.

Problem Description:

In an Office 365 Hybrid solution (Where you have online users/mailboxes and on-premise users/mailboxes), Online mail users reported that they are not receiving Non-Delivery-Report mails from on-premise server/users.

For example if the on-premise user mail box is full or if the online user sent an email with huge attachment beyond the on-premise server mailbox attachment limit, they never receive the NDR and accordingly they assume their mail was delivered which lately turns to be wrong.

Investigation Steps

To identify the root cause of this problem, I started troubleshooting as follows:

  1. Checked the On-premise servers for the email sent by the online user and for any response using power shell "Get-MessageTrackingLog" and an Undeliverable mail (NDR) was generated and sent to the online user.                                                                                                                             
  2. Since the mail wasn't received by the online user in his mailbox i went and checked the Quarantine queue (Office 365 - Admin Centers - Exchange - Protection - Quarantine), Advanced search and entered the email address of the online user in the "Recipient mail address" and I found this mail quarantined in his queue.                                                                                                                                                                                                                                                                                                                         
  3. The mail was quarantined because its classified as SPAM (Check above image) so the next step was to check Message header by clicking view message header (check above image)                                                                                                                        
  4. Copied the content from the Message Header and fired the Microsoft Message Header Analyzer Tab at the bottom to analyze the header for further details.                                                                                                                                                                                                                                                                                                       
  5. Few important things to note from the message analyzer as follows (Check below image):                        
    •  SPAM confidence Level (SCL) is 9 which is the highest score                                                     
    • It was filtered by SKS (Transport rules). Check this link for more details on the Anti-Spam Message header and their meaning                                                        
    • The Authentication Results shows that DMARC Failed.                                                                  
    • Return-Path (Item 19) is empty                                                                                                                                                                                                                                                                                                                       
  6.  So the question is why it was marked SPAM SCL 9 and the impact of the DMARC failure since we have DMARC implemented on this domain.                                                                                                
  7.  My immediate next step was checking the Exchange Admin Center - Mail flow - Message Trace. The sender is the mail i got from the Header Analyzer "From" field which is the on-Premise Microsoft Exchange mail ( - Option 5 in the above image and the recipient is the online user mail address.  Click Search to check this criteria                                                                                                                                                                                                                                                                          
  8. Upon opening the result trace, it was clear as shown in the below image that the mail was quarantined and SPAM level set by a transport rule named "Block Spoof Mail with DMARC"  This is the transport rule created when we activated DMARC. It confirms the earlier results that it was quarantined and considered SPAM by a transport rule (SKS) and it has relation to the failure of DMARC                                                                                                                                                                                                                                                                                                                                                                                                                                                          
  9. My next check of course was the transport rules (Exchange Admin Center - Mail Flow - Rules) and it was very clear that this rule "Block Spoof Mail with DMARC" was the reason since its criteria is to set the mail SCL to 9 if DMARC fails (which was exactly our case) - Check below image                                                                                                                                                                                                                                                                                                                                                                                   
Root Cause, Why DMARC Failed ? 

DMARC helps fighting and protecting our mail systems against spoofing along with SPF and DKIM (Will have several post on these three technologies). DMARC stands for Domain-Based message authentication, reporting and conformance.

DMARC works by comparing the "From" Field with "Return-Path" field and they should be the same (normally you are receiving mail from and will reply back to The two fields will never match when the mail is spoofed.

Ex: You think you are getting a mail from (From field) however when you reply its going to (Both fields didn't match)

For Exchange System Generated NDRS, they don't contain any value/address in the Return-Path by design and that's why the DMARC test in our Case failed which triggered the Transport rule which in return set its SCL to 9 and got Quarantined.

How can we fix it ?

We have three options (checked by Microsoft Support Team) to fix this issue by editing the Transport rule in question and creating an exception:

  1. Edit the Transport rule - Except if - The Sender - IP address is in any of these ranges or Exactly Match - IP (Your on-premise Exchange server Public IP address)                                                                                                                                                   
  2. Except If - The Sender - Is this person - add the email address of the NDR mail which is (This is unique per each domain and won't change)                                                                                                                                                        
  3. Except if - A Message header - includes these text patterns - Auto-submitted header contains "auto-replied"


Also make sure to set the "Match sender address in message" to "Header and Envelope"

This was a nice case and passed by several sections and views to troubleshoot it. Hopefully this post might help others facing the same issue/problem. Source

Windows 10 Fall update 1709 Security Feature 4: Exploit Guard Attack Surface Reduction

Posted by Ahmed Nabil | 3 comments»
Another cool feature in the Exploit Guard Intrusion prevention tool offered starting Windows 10 1709 is the Attack Surface Reduction (ASR). ASR is key component in the Exploit Guard tools and as I mentioned earlier that Exploit Guard is key component in the Windows 10 defensive stack and its mainly concerned with Pre-breach phase and its main goal is to prevent the attack from occurring.

Most of the recent attacks especially Ransomware attacks came from malicious office files,  or mail that is sent to the user and when the user clicks it, the malicious payload is downloaded and run on the local computer or connect back to the command and control center (C&C) to download further files and the end result is infecting the computer or get it encrypted (ask for ransom)

Attack Surface Reduction is dealing mainly with the below rules to protect your entry points (Surface):

  1. Office Rules: Prevent Office apps from creating Executable content, launching child process or injecting into other process.........etc.                                                                                                             
  2. Script Rules: Block malicious scripts, obfuscated macro codes and others.                                            
  3. Mail Rules: Block running executable content from your mail client and web mail.

For more details please check this link

There are given set of rules in the ASR and each rule has a unique GUID, to enable these rules you simply enable them by the GUID (Check Below image)

So for example if you would like to block executable content from your mail client and web mail, you need to activate the rule with GUID BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550 (First rule)

How to implement ASR on Standalone Machine:

I would highly recommend to implement first ASR on standalone machine and test the rules and their effect on your application and daily work processes. Power shell (Admin elevated) will be used to enable ASR. For example let us enable the first rule (Blocking executable content form mail and web mail)

PowerShell Command

Set-MpPreference -AttackSurfaceReductionRules_Ids BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550 -AttackSurfaceReductionRules_Actions AuditMode

This will turn on the first rule of blocking executable content in mail in Audit Mode. You have three options when running this command which are Enabled, Disabled, AuditMode. I would recommend to turn it first in AuditMode so you can check your logs and event viewer for ASR blocking events without interrupting your business.

How to check the ASR events in Event Viewer:

  1. Download the exploit guard evaluation package and extract the ZIP file                                                                                                                                                                                                                   
  2. Open the event Viewer  - Import Custom View - Pick the asr-events                                                                                                                                                                                                                                          
  3. All events can be checked from this custom view, this is very beneficial especially in the AuditMode phase while ASR is under test.

How to Simulate and Demo the Attack Surface Reduction:

In the same Exploit Guard Evaluation Package, you can find a file named Exploit Guard ASR test tool (for 32 bit and 64 bit OS), Running this file will display the ASR rules and their status on your machine itcallswin (whether blocked, enabled or in AuditMode) and you can run a simulation to ensure its working. For example I will run the simulation for the first rule (Executable content in mail and web mail) which will try running notepad.exe and get it blocked. Its very cool test tool that you need to play around with it.

How to enable ASR for Enterprise/Domain computers:

After you are fully satisfied with the test results you can start rolling it out on all client computers using group policy. The location of the Group policy is as follows:

Computer Configuration - Administrative Templates - Windows Components - Windows Defender Antivirus - Windows Defender Exploit Guard - Attack Surface Reduction

You need to add the Rule ID and value (0, 1 & 2). Its little bit confusing but O=Off (Nothing happen, rule disabled), 2=AuditMode and 1=Block (which means enabling the rule)

So another exciting feature and I would encourage everyone on Windows 10 1709 to give it a try.

Windows 10 Fall update 1709 Security Feature 3: Exploit Guard Protection Settings

Posted by Ahmed Nabil | 3 comments»
Exploit Guard as you may have noticed is very exciting security feature in Windows 10 1709, they are set of host/endpoint Intrusion Prevention tools defending against malicious macro, email and script based threats.

For those familiar with Microsoft free EMET (Enhanced Mitigation Experience Toolkit) tool they will find that Exploit Guard is the natural successor to EMET where its used to limit an block attacks on the application level using memory mitigation techniques as well as other options.

It should be noted that EMET end of support is July 31, 2018. You can easily import and convert your EMET configuration and settings to Exploit Guard. For detailed comparison between both EMET and Exploit Guard check the below link

To import older EMET configuration to Exploit Guard you need first to covert it and then import it. Both conversion and Import are done using Power Shell Commands as follows:

  1. Conversion:                                                                                                                                                                                                                                                                             ConvertTo-ProcessMitigationPolicy -EMETFilePath emetFile.xml -OutputFilePath filename.xml                                                                                                                                                                        
  2. Importing your converted file to Exploit Guard:                                                                                                                                                                                                                                         Set-ProcessMitigation -PolicyFilePath filename.xml

Exploit Guard is a family of tools and they fall in the pre-breach threat resistance, there are mainly three tools under Exploit Guard as follows:

  1. Attack surface Reduction: Protect entry vectors as Macros  -Office files with Macros that download and execute content (Office rules, script rules and mail rules) - This will be discussed in my next blog post.                                                                                                                                
  2. Controlled Folder Access: Protecting Files in your critical folders on your system (Ransomware). Check my earlier post                                                                                                                              
  3. Network Protection: Part of the Exploit Guard protecting against internet based attacks (building on the earlier browser smart screen protection......etc)
In this article i am mainly discussing the Exploit protection settings for both the systems and applications (Mitigation similar to former EMET tool)

Configuring Exploit Protection settings on Standalone machine:

You can open the Exploit Protection smadav antivirus as well protection settings from the Windows Defender Security Center - App and Browser Control - Scroll down and click on Exploit Protection

Two main things to note is the export settings option at the end of the page which is very beneficial to export all settings once you have a well tested and appropriate settings for your windows 10 machines and need to deploy it via group policy to all other clients in your organization.

Also Exploit protection includes both the System settings and Program settings, in the system area you will find mostly memory mitigation settings similar to the ones we used to have in EMET and then the program settings were you have your programs protected and you can add other programs by name or path to be protected as shown below

Configuring Exploit Protection settings on domain machines using group policy:

As we discussed earlier in the standalone configuration, normally you will start configuring one client, testing all applications and mitigation techniques and once satisfied you will export the settings and will deploy it to all the computers in your enterprise running Windows 10 1709 or later.

This is where the group policy kicks in, you will create a new GP and link it to your Windows 10 1709 computers,  navigate to Computer Configuration - Policies - Administrative Templates - Windows Components - Windows Defender Exploit Guard - Exploit Protection

There is only one setting available where you can point to the settings file (Exported from any tested standalone machine)

That's it for now and see you on my next post and Exploit Guard Attack Surface reduction.

Windows 10 Fall update 1709 Security Feature 2: Exploit Guard - Controlled Folder Access

Posted by Ahmed Nabil | 1 comments»
Today we will discuss another new security feature released in windows 10 fall update 1709 which is the controlled folder access. This feature was mainly introduced as a step to try stop or contain Ransomware attacks on endpoint clients by protecting specific folders from unauthorized access by malicious apps or processes.

This protection is real time and will block instantly such malicious activity and give you immediate warning message on your desktop notifications.

When you enable the controlled folder access feature, it will protect specific folders by default as your desktop, documents, favorites, pictures and videos. however you can add any other folder to get protected as well.

If you received a notification that an app was blocked access to one of  your protected folders You can allow this app if you are aware of its usage and you are sure its a business legitimate app.

How to enable Controlled Folder Access:

  1. From the Windows Defender Security Center - Virus and Threat Protection settings (Check below screen shots)                                                                                                                                                                           

  2. After Clicking on the Virus and Threat Protection Settings - scroll down to the Controlled Folder access and enable it.                                                                                                                                                                       
  3. Click on Protected folders to give you list for current default protected folders or click Allow an app through Controlled folder access to allow legitimate app that might not be known to Microsoft and is getting blocked.                                                                                                                                                                                                                                                  

Configuring Group Policy to enable Controlled Folder Access:

  1. You can use powershell as usual to enable controlled folder access and for enterprise users group policy can be implemented by editing the Computer Configuration - Policies - Administrative Templates - Windows Components - Windows Defender Antivirus - Windows Defender Exploit Guard - Controlled Folder Access                                                                                                                                                                                                                                                                                                                                                                                                                                                                 
  2. Please remember to extend your AD Group policy templates with the new 1709 templates as mentioned in part 1 of this series.                                                                                                                                          
  3. To enable it you need to edit the "Configure Controlled Folder Access" settings as shown below, either to enable it or keep in Audit mode (Changes to protected folder will be allowed but audited which means you can view these changes in the Event logs)                                                                                                                                                                                                                                                                                                                                                                                                                             
  4. The other two settings is to add another protected folder other than the default ones and to allow specific app to access the protected folder.

How to view Controlled Folder Access Events:

  1. Download the Exploit Guard Evaluation Package  (Zip folder that need to be extracted)                                                                                                                                                                                                                                         
  2. Open Event Viewer - Action - Import Custom View                                                                                                                                                                                                                                                                                             
  3. Open the downloaded Evaluation Package and pick cfa-events.xml                                                                                                                                                                                                    
  4. Confirm the selection and add it to the custom view                                                                                                                                                                                                                                                                                                   
  5. It will appear under the Event Viewer custom view as shown below                                                                                                                                                                                                                                                                     
  6. Upon checking some logs, i noticed that the Controlled folder access blocked Adobe to make a change on a file on my desktop and here comes the value of the Audit mode. Adobe is a legitimate application and IDM i have PDF files that need to be edited on the desktop. If Audit mode was set, the change/edit will be done however i will be notified in the logs to later on add Adobe as approved app to the list of apps in the controlled folder Access.                                                                                                                                                                                                                                                                                                                                                                                                                     

Controlled Folder Access (CFA) is another useful tool introduced in Windows 10 1709 tackling mainly Ransomware problems. Hope you enjoyed this post and see on the next feature.

For more information on the first blog post please check the below Link