Windows 10 Security Part 1 :Windows 10 Defender is Microsoft SCEP Client

Posted by Ahmed Nabil | 0 comments»
Windows defender is shipped free of charge with Windows starting Windows 8 to protect the PC against Malware (Viruses, Spyware......etc.). It was mainly geared towards personal computers/Home computers providing adequate malware protection free of charge out of the box. For Enterprises Microsoft had another offering which was Microsoft System Center Endpoint Protection (SCEP) with its policy based templates based on your workload and fully configured and controlled with Microsoft System Center Configuration Manager.

Lately i was trying to install Microsoft SCEP on a new Windows 10 RTM Enterprise machine, after pushing the SCEP client the following was noticed:

  1. There is no SCEP on the machine !
  2. CCMSETUP and Endpointprotection logs showed successfully installation
  3. Windows Defender (shipped on windows 10) can't get disabled !
  4. All my SCEP policies and settings are applied on the windows defender.

It turned out to be that in Windows 10, Microsoft SCEP will manage the built in Defender. No SCEP agent will get installed as previous versions with Microsoft 8. All reporting and Management are coming now from the defender.

I found one article on TechNet referring to this issue for Windows Technical Preview

Few members of Server 2012R2 Protected Users Group are not able to log in locally or remotely to their computers and servers

Posted by Ahmed Nabil | 2 comments»
Microsoft introduced a new security group named "Protected Users Group" with Server 2012 R2 and windows 8.1 clients to offer additional protections against the credential theft/compromise and help in your overall mitigation plan for Pass of the Hash (PtH) attack. Its highly recommended to add all your service and high privileged accounts to this group for more protection.

For more information on this Security group, please check the below link.

Microsoft Published two documents (Version 1 & 2) explaining in details the Pass of Hash Attack and possible mitigation, i would highly advice downloading these documents from the below link


Back to our main post, we had a scenario with some companies adding their main critical service accounts and admin accounts in the Protected Users Group. Some of these accounts (not all of them) reported that they were not able to log in to their local machines or remotely to any server whether its 2008 or 2012 family. The error message the user receives is as shown below:

As soon as these users are removed from the Protected group, they just work back normally. The weird thing is that this error occurred only for few accounts in the Protected Users group and not all accounts.

The following event was logged in the Event viewer at the same time of log in failure


Upon further investigation on this problem we were able to identify a common factor for all these accounts that were unable to log in after being added to the Protected Users group:

  1. They were old accounts, created few years ago when the domain was 2003 Domain/Forest Functional Level.
  2. These accounts have Non-Expiry passwords (Since most of them are service accounts) !

Microsoft SCOM sent alerts when one of these users tried to connect/log in to the domain controller which helped understanding and solving the problem.

As per the SCOM alert, this was the fix. Resetting and changing these specific user passwords fixed the problem and they were able to log in either locally or remotely normally.

What was the problem ?

As we mentioned before these accounts were created long time ago when the domain/Forest functional level was 2003 and at that time there were no Kerberos hash created and password didn't change from that time.

Password hashes are kept on the domain controller with all available etypes (Encryption Types). It seems that the passwords for these accounts which were set not to expire did not have the AES hash but only got the NTLM hash. Protected Users group is only using AES and that's why these users were not able to connect because their passwords can't be verified since there is no AES hash.

After resetting the password all those hashes were available and the problem was fixed :)

For more information on Hashes and how passwords works in Windows environment please check the below articles.

Hopefully this post can help any user with the same problem and shed some light on how passwords work in Windows environment.

Lenovo CTO admits SuperFish adware Spoof attack, Is this the end of problem ? or Just the Beginning ?

Posted by Ahmed Nabil | 0 comments»
Lenovo CTO admits the problem of SuperFish adware which was loaded on several consumer Lenovo PCs/Laptops and confirms the company has published the needed removal tools

Lenovo additionally is promising its customers with a more cleaner and safer future products in attempt to save its reputation after what happened lately with the SuperFish.

How did the story begin ?

Lenovo came under fire last Month (February) after it was discovered that it was preinstalling the SuperFish Adware on Lenovo Laptops since 2010. The reports came heavily from different sources confirming this fact until Lenovo itself admitted the issue and released a removal tool.

The United States Cert (US-Cert) released this issue as a spoofing attack

Lately The United States Department of Homeland security asked Lenovo to uninstall SuperFish from its products

What is SuperFish ?

Its an advertising company based in California and was founded in Israel back in 2006 developing various advertising software based on visual search engine. This Adware installs its own certificate and act as a Man in the Middle proxy with HTTPS connections that are encrypted making users vulnerable.

For More details on how it work, please check the following link:

Microsoft and MacAfee Antivirus reacted quickly and their engines were updated to remove the SuperFish vulnerability from Lenovo Laptops

Will this end the problem ? Well many of the consumers and IT professionals already blacklisted Lenovo Laptops and they won't be using it anymore. A Lawsuit is already filed against Lenovo although they admitted it was a mistake. For more details please check the following article:

Things didn't stop on the Lenovo reputation or the legal actions, Actually things are getting worse, it was tracked that the SuperFish is based on a 3rd party SDK (Software Development Kit) called SSL Decoder created by an Israeli company named Komodia. Several users now are compiling lists of software and applications using this SDK.

For more details, please check the following article:

So what should we do in this totally un-secure environment, I believe we should stick back to the basis as educating users and our selves. The Internet can be a good educational place but at the same time there is this dark side that no one would like to face nowadays.

We need to be extra cautious for Public Wi-Fi networks, regularly check our passwords and ensure they are hardened, regularly check our Credit Cards and ensure our devices are protected by at least two protection layers (Personal Firewall, Antivirus/Spyware and Vulnerability scanners).

Securing our devices is getting harder and threats are changing all the time and sometimes are shipped with trusted software. We need to be extra cautious as long as we are on the Internet.

Microsoft and Symantec Endpoint Updates hit Internet Explorer

Posted by Ahmed Nabil In | 0 comments»
Microsoft Internet Explorer was heavily hit this week with the Latest Microsoft Endpoint Update as well as Symantec Endpoint updates. While Symantec released a fix, Microsoft is still working on updated version to fix this issue.

  1. The Latest Microsoft Protection breaks Internet Explorer downloads, for more details check the following article                                                                                                                                                                                                                         
  2. Symantec Endpoint protection update crashes Microsoft Internet Explorer. For more details check the following article

The Symantec update affected both Windows 7 and Windows 8 machines while the Microsoft Endpoint update was mainly observed on Windows 8.1 machines. Users should stay tuned for an expected quick fix from Microsoft.

How to Prevent users from changing EMET application settings by using Group Policy ?

Posted by Ahmed Nabil | 0 comments»
EMET is a very great tool for users seeking additional layer of security against Zero-day vulnerabilities. When configuring EMET for Enterprise it gets tricky as there are some gaps for deployment. The easiest way to control and push EMET settings on all users in your enterprise Active Directory is to use group policies however the EMET template is not covering all mitigation and has some limitations.


We need to push the EMET configuration/settings for applications to all users in the network and prevent users from changing these settings (For Example: Removing ASR mitigation from the Internet Explorer). This issue gets worse with users who are admin on their machines and can open the EMET GUI and change any application setting.


Users may change the EMET application GUI settings to disable a mitigation or remove specific application from the list. This change will result in an Event ID 11 written in the local application event log. We will use this Event as a trigger when its recorded to re-import/push back our EMET application settings on the client using Group policy.

  1. I am assuming EMET is already installed on all users (Can be done via SCCM or any other tool) which is another discussion.                                                                                                                
  2. We need to install EMET (Latest current version is 5.1) on a machine, add all popular applications (Located under EMET Installation folder - \EMET 5.1\Deployment\Protection Profiles) and company business applications if needed and apply/test different mitigation.                    
  3. After configuring and changing all wide system and application configuration and you are fully satisfied of deploying it on all clients, Export the settings (XML file) from the main EMET interface as shown below.                                                                                                                             
  4. We need to create a GPO to import this XML file (exported in the previous step) on all computers in the domain. A very good article on TechNet that explains this step in details can be found at                                                                                                                         
  5. Basically what we need to do as per the TechNet article is to create a new GPO, link it to your domain or computers OU and copy the XML file in the GPO folder.                                                      
  6. Create a Task scheduler using the group policy Preferences, for more details check this TechNet article                                                                                                                                                            
  7. This scheduled task main action is to import the XML file to the machines as per the below screen shot. The program will be the EMET_Conf.exe and the path should reflect the current version of EMET used in your environment. The Arguments will be the Import of the XML command and it should be something like this:                                                                                                                                                                                                                                        --import \\\sysvol\\Policies\{2368E536-C9BA-41E6-A1D8-8AA1C7854275}\emetconfig.xml  (You need to replace the with your actual domain name, Unique ID of your policy and the XML name)                                                                                                                                                                                                                                                 
  8. The tricky part will be the trigger as when this import will occur (XML imported to the users). If any user changed, removed any application settings in the EMET GUI an EVENT ID 11 will be triggered in the application log of the user computer as shown below:                                                                        
                                                                                                                                                              So in this GPO we will use this Event ID as the trigger to re-import and push the settings back to the user.        


This should do the trick and enforce the company EMET settings on all computers and ensure your users won't change them or actually if changed will be reverted back in the same second to ensure full protection.

Hopefully this article is helpful to anyone facing the same issue.


Disable User Account Control in Server 2012/2012 R2 to run SQL Reporting URL

Posted by Ahmed Nabil In | 0 comments»
I was working on installing SQL2012 Server on a new machine as well as the reporting services, after configuring the reporting service i was trying to access the local reporting services URL when i got the attached below message

My account was an admin on the machine and SQL admin as well, i checked the UAC from Control panel and it was already turned off as shown below

Looks like in Server 2012 and 2012R2, even if you changed the setting "Never Notify" as shown above (which worked fine with 2008R2) the UAC is still active. In order to turn it completely you will need to edit registry as follows:

  1. Navigate  to "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system"
  2. Change the "EnableLUA" key value from 1 to 0                                                                                                                                      
  3. Restart the server/computer

Hopefully this can help anyone facing this issue.

Exchange 2013 Sign Out behavior on Microsoft UAG - To finish signing out, please close all open browser windows.

Posted by Ahmed Nabil In | 0 comments»
Recently we noticed with some Exchange 2013 customers having their OWA (Outlook Web access) published on Microsoft UAG (Latest SP4 Rollup update) that they can't sign out properly from their OWA session and instead they get the message "To finish signing out, Please close all open browser windows"

When the user hits OK, nothing happened and he is still logged in.

This issue is not related to the UAG OWA setup or the UAG authentication but rather the Exchange Virtual directories authentication. This behavior occurs because the Exchange OWA virtual directories are set to Windows Integrated Authentication.

In order to change this you will need to do the following:

  1. From Exchange Admin Center go to Servers - Virtual Directories (Pick your server if you have multiple servers.
  2. Edit the OWA (Default Web Site) Authentication.
  3. Uncheck "Use one or more standard authentication methods" and pick an option in the below FBA (Forms based authentication) as shown in the below image                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          
  4. You will need to do the same for the ECP virtual directory (Actually it will display message with this)
  5. Reset/Restart the IIS and the logoff should be normal as expected.

Hopefully this can help anyone encountering this issue.

Your computer is not configured correctly for Directaccess. IPV6 is not enabled correctly

Posted by Ahmed Nabil In | 0 comments»
Few users reported recently that their DirectAccess is not working on their Laptops and its displaying the message "your computer is not configured correctly for directaccess. ipv6 is not enabled correctly"

I checked DirectAccess Group policy and the Machine certificate and they were all fine. Its mainly IPV6 in question. Microsoft added native support for IPV6 and its enabled by default starting from Windows Vista and Server 2008. Some users try to disable IPV6 by unchecking the IPV6 option/check box from the Network card properties however this won't disable IPV6.

Microsoft released several Fixit (One click file) to enable, disable or give preference for IPV6 on IPV4 or vice verse instead of digging deeply in the registry to enable or disable IPV6.

Please check these several Fixit on

In our case IPV6 was disabled and need to be enabled either by using one of the Fixit provided in the link above or by checking the registry as follows:

  1. Locate the following Registry key  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\
  2. Check for  DisabledComponents under the above key.
  3. To Enable IPV6 make sure this key has value of Zero or just delete it. If it has any other value IPV6 won't work correctly.

Hopefully this can help anyone encountering the same issue.

Power/Shutdwon button missing from my Surface Pro 3 Start Screen

Posted by Ahmed Nabil | 1 comments»
I noticed on my Surface Pro 3 device that it doesn't have the Power/Shutdown Button on the Start Menu. This Surface is fully patched with Windows 8.1 Update 1 and all other subsequent updates.

My Surface device was upgraded from the Windows Professional version to the Enterprise version and I was suspecting that its a Windows issue till I came to a recent KB by Microsoft that its not enabled on Surface Pro 3 and it will mainly depend on the device Hardware not the Windows OS.

Note: An entry of "Slate" in the Device Type column means that the hardware reported a Power Platform Role of PlatformRoleSlate. To determine what a system is reporting, run the powercfg /energy command and check the Platform Role in the output.

According to the above mentioned table Surface Pro 3 will not have a Power Button on the Start Screen.

To customize or change this behavior by adding the power button you will need to follow the following steps:

  1. Open the Registry (regedit)
  2. Navigate to HKEY_CURRENT_USER
  3. Create a new Key and name it "Launcher"
  4. In the Launcher key create new DWORD value named Launcher_ShowPowerButtonOnStartScreen
  5. Right click on the new DWORD - Properties
  6. Change the Decimal Value to 1 (0=default which means it won't appear)
  7. Reboot the machine

This issue was weird since Surface Pro 2 will get this Power button. Anyways hopefully this blog post can clear this issue.