As part of the May 2014 Update Rollup, Microsoft has fixed a problem that I hope has not been bugging any Active Directory Admin…
On Windows Server 2012 and Windows Server 2012 R2-based Domain Controllers, an issue was identified that blocks access to the Directory Services Restore Mode (DSRM).
On Windows Server 2012 or Windows Server 2012 R2-based Domain Controllers, you applied the Admin Approval Mode for the built-in Administrator account Group Policy setting.
When you restart the Domain Controller in Directory Services Restore Mode (DSRM) and you log on as a local administrator (against the local Security Accounts Manager (SAM) database, that is offline during normal operations of the Domain Controller), only a black screen is displayed after the authentication screen. At this point, you can do nothing except log off by pressing Ctrl+Alt+Delete.
This leaves the Directory Services Restore Mode (DSRM) unusable. You cannot perform the actions you would want to perform in Directory Services Restore Mode (DSRM).
To resolve this issue, install 2955164 Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 update rollup: May 2014 on the Domain Controllers.
You do not have to restart these servers after you apply this hotfix.
I recommend installing the 2955164 Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 update rollup: May 2014, because the Directory Services Restore Mode (DSRM) is essential in troubleshooting advanced issues with Domain Controllers; You don’t want to encounter any issues while in this mode.
Related KnowledgeBase articles
2937044 You cannot log on as a local administrator when you restart in DSRepair mode
2955164 Windows RT 8.1, Windows 8.1, and Server 2012 R2 update rollup: May 2014
How to add a DSRM startup option in Windows Server 2008 and Windows Server 2008 R2
Active Directory Domain Services Command Fu, Part 3
Rebooting Windows Server 2012-based DCs into Directory Services Restore Mode
And you will keep your password updated …
New features in AD DS in Windows Server 2012, Part 6: Recycle Bin GUI
Restoring a DC from a Snapshot
Last week, the Zero Day Initiative (ZDI) decided that Microsoft has had enough time within its coordinated vulnerability disclosure program to fix a vulnerability in Internet Explorer 8.
A Belgian researcher found a problem in Internet Explorer 8, last year. He sold the information via the Zero Day Initiative to TippingPoint, who reported the vulnerability to Microsoft on October 11, 2013. On May 8, 2014, the Zero Day Initiative warned Microsoft to come up with a solution. A mere two weeks later, on May 21, 2014, the Zero Day Initiative made the vulnerability public.
Apparently, there is a difference between responsible vulnerability disclosure and coordinated vulnerability disclosure… I don’t know, yet, which one serves me better.
The vulnerability only impacts Microsoft Internet Explorer 8.
This fact, plus the fact that the vulnerability is not actively exploited in the field, makes it very plausible that this vulnerability ended up at the bottom of the pile of stuff to fix in Microsoft Internet Explorer. In fact, I will even state that admins confronted with exploits, have themselves more than Microsoft to blame.
- Internet Explorer 11 is the default browser for Windows 8.1. This version of Internet Explorer is not vulnerable.
- Internet Explorer 10 is the default browser for Windows 8. This version of Internet Explorer is not vulnerable.
- While Internet Explorer 8 was the default version of Internet Explorer for Windows 7, but Microsoft has, since RTM, made several versions of Internet Explorer available as Important updates. Only when Windows 7’s Internet Explorer has not been updated, its Internet Explorer 8 installation is vulnerable.
Windows 7 without Service Pack 1 is no longer supported by Microsoft.
However, this Service Pack did not contain an updated Internet Explorer.
- Internet Explorer 7 is the default browser in Windows Vista. The most recent version of Internet Explorer for Windows Vista, however, is Internet Explorer 9.
- Internet Explorer 6 was the default browser for Windows XP. Internet Explorer 8 is the most recent version for Windows XP, but Windows XP is out of support.
An attacker who successfully exploited this Internet Explorer vulnerability could gain the same user rights as the current user. Just like with the Internet Explorer ‘WontFix’ bug last month (CVE-2014-1776), in organizations, implementing Windows with Least Administrative Privilege is the best practice and the standard. It should come as no surprise this principle is extensively covered in all Windows-oriented Microsoft exams.
Again, admins confronted with exploits in environments without this best practice applied, have themselves more than Microsoft to blame.
Microsoft has been able to reproduce the undesirable Internet Explorer behavior and the ability to be able to run code as the logged on user.
For admins that fins themselves stuck with Internet Explorer 8 (for instance, on Windows Server 2003 (R2)-based Terminal Services), Microsoft has formulated a couple of workarounds that make the vulnerability in Internet Explorer 8 non-exploitable:
- Set Internet security zone settings to "High" to block ActiveX Controls and Active Scripting in these zones.
- Configure Internet Explorer to prompt before running Active Scripting or to disable Active Scripting in the Internet and Local intranet security zone.
- Install and configure the Enhanced Mitigation Experience Toolkit (EMET) to work with Internet Explorer.
While we’re waiting for Microsoft to fix this vulnerability in Internet Explorer (except for Windows XP), the workarounds can be applied:
Change Internet Explorer zone’s settings
All of these actions can be performed using Group Policy and Group Policy Preferences.
You can find these as part of the User Configuration, Preferences, Control Panel Settings, Internet Settings of a Group Policy Object (GPO). Simply add settings for Internet Explorer 8 and 9 or change any settings you might have in place.
Setting the Internet Zone security level to High can be done on the Security tab:
Alternatively, you can leave the default Medium-high settings for the Internet Zone, and change the Active Scripting settings using the Custom Level… button. Press F8 first to not configure all these settings for Internet Explorer installations (unless you want to). Then scroll down to Automatic prompting for ActiveX controls, press F6 and configure this specific setting to Enable:
Alternatively, you can disable ActiveX altogether, by not configuring the Automatic prompting for ActiveX controls setting (press F7 to not apply the setting) and configuring the Run ActiveX controls and plug-ins. Again, Press F6 to enable the setting, then configure it as Disable:
When done press OK to close the Internet Zone properties. When you’ve chosen to change the specific ActiveX settings, also apply them to the Local Intranet Zone. Press OK in the Internet Explorer 8 and 9 Properties screen and close the Group Policy Management Editor screen to finish the Group Policy Object. Then, apply the object to users running Internet Explorer 8.
Install and configure EMET
The above three strategies will secure the Internet Explorer 8 installations within an organization, but are not very user-friendly. The best way to deal with vulnerabilities like these, is to install and configure the Enhanced Mitigation Experience Toolkit (EMET). You can use the Software Installation capabilities of Group Policy to deploy it. Not only, will it protect from exploits of this particular vulnerability in this particular version of Internet Explorer, but most vulnerabilities in all supported versions of Internet Explorer.
Internet Explorer 8 is five years old. Admins have had multiple chances to get rid of it and other ancient technology.
Vulnerability Note VU#239151
ZDI-14-140 (0Day) Microsoft Internet Explorer CMarkup Use-After-Free Remote Code Execution Vulnerability
Microsoft IE Zero-Day Flaw Could Leave Millions at Risk
Microsoft Intentionally Failing to Patch Critical Vulnerability in Explorer IE 8
New Internet Explorer Zero-Day Vulnerability Publicly Disclosed; Identified in October 2013
Microsoft warns of major Internet Explorer bug; no fix for Windows XP
Today, a colleague came up to me to ask me a question on a weird situation he encountered while troubleshooting an Active Directory Federation Services (AD FS) implementation at a customer site.
We didn’t implement this situation, but after solving this challenge, we gave some great pointers to get the environment sorted.
This customer has a highly redundant Active Directory environment, hosted by Domain Controllers that have never experienced any problems. They also have a single Windows Server 2012 Full installation, with the Active Directory Federation Services Server Role installed and configured with a relying party trust that instructs it to be the identity provider for a web application.
On the perimeter network (DMZ), a Windows Server running Forefront Threat Management Gateway (TMG) is deployed. In TMG, a Web Publishing Firewall Rule was configured to pass traffic, destined for the AD FS server address to the AD FS server on the internal network.
The rule is configured without Authentication Delegation, as you can see on the Authentication Delegation tab in the screenshot of the Web Publishing rule, below (rule name removed to protect the innocent):
In the case of this customer, when colleagues accessed a claims-enabled web application they would get a password prompt instead of the AD FS logon page when they’d be using Internet Explorer:
When these colleagues would use Google’s Chrome or Mozilla’s FireFox, the AD FS logon page would display correctly.
The customer wanted a consistent logon experience for their employees on each of these browsers. The systems administrator, obviously, wanted to eradicate the Windows Authentication taking place outside of the network.
Because of the way Forefront Threat Management Gateway (TMG) is implemented at this customer, the Active Directory Federation Services (AD FS) Server misinterprets the location where the authentication request is originating from. When we looked at the Global Authentication Policy in AD FS Management, we saw the default settings still applied, allowing Windows Authentication from the Intranet.
We unchecked the option for Windows Authentication for the Intranet:
After we clicked OK, the problem was solved for this customer; regardless of the browser capabilities, employees would get the AD FS logon page served.
15 Minutes of work. One happy customer. 3 billable hours.
Although this document specifically mentions AD FS 2.1 on Windows Server 2012, the same applies to AD FS 3.0 on Windows Server 2012 R2.
Last week, Microsoft released Security Bulletin MS04-025, including guidance and an update that resolves a publicly disclosed vulnerability in Microsoft Windows. The vulnerability could allow elevation of privilege if Active Directory Group Policy preferences are used to distribute passwords across the domain - a practice that could allow an attacker to retrieve and decrypt the password stored in the cpassword value of Group Policy preferences.
The problem with cpasswords
Group Policy Preferences (GPPs) allow system administrators to set passwords using the following GPP extensions:
- Local user and group
- Mapped drives
- Scheduled tasks (Uplevel)
- Scheduled tasks (Downlevel)
- Immediate tasks (Uplevel)
- Immediate tasks (Downlevel)
- Data sources
An example would be a Group Policy Preference that sets the local administrator password for all domain-joined devices within the scope of the Group Policy Object (GPO). This scope can be configured with Organizational Units (OUs), but also through WMI Filters.
Now, when you’d set a password this way in the Group Policy Editor on Windows 8, Windows 8.1, Windows Server 2012 and Windows Server 2012 R2, the Group Policy Editor, already, warns you:
This warning message tells you that the password is stored. Authenticated Users can discover and access its value by simply browsing through the System Volume (SYSVOL). The password is not encrypted, but, as the warning suggests, merely obscured.
It’s true. Settings in GPPs are stored in XML files. Passwords in GPPs are stored in these XML files using the cpassword field. Below is the groups.xml file corresponding to a GPP with the extension used to create a new account with a non-expiring password for the Demo User:
Other XML files in the SYSVOL share of Domain Controllers, where you can find cpassword values are scheduledtasks.xml, services.xml and datasources.xml.
Of course, the password for the Demo User Account is configured as P@ssw0rd, as are all the passwords I tend to share with you on this blog… You can easily confirm it, by using the Get-GPPPassword PowerShell script that is part of PowerSploit.
Fixing your environment
Step 1, Determine the impact on your environment
By now, You might be wondering what the impact is on your Active Directory environment. Group Policy Preferences containing passwords may have been implemented before your time, before you had Windows Server 2012 (R2)-based Domain Controllers or other admins might just have been ignoring warning messages on this malpractice.
As part of KnowledgeBase Article 2962486, Microsoft has released a PowerShell script to detect Group Policy Preferences (GPPs) using GPP Extensions that rely on the cpassword.
I recommend running the Get-SettingsWithCPassword.ps1 PowerShell script with an account with sufficient privileges to access all Group Policy Objects on a domain-joined device.
When the device is a Windows client, make sure to have the Remote Server Administration Tools (RSAT) installed, since the script uses PowerShell Modules included with these tools.
The script does not support to be run from a device that is not joined to the Active Directory environment you are trying to scan.
The output of the script, when run successfully, is a list of GPPs containing cpasswords.
Step 2, Get rid of cpassword values
Now that you have determined the impact on your environment, you can remedy the situation (where needed):
For the Local User Management portion of GPPs that contain cpasswords, Microsoft has made the Invoke-PasswordRoll PowerShell script available to set the local account passwords on remote machines to random passwords.
Administrators can add local administrator accounts to computers by creating an Active Directory group and adding it to the local Administrators group through Group Policy Preferences -> Local Group. This method does not cache credentials in cpassword values.
To map drives and assure only authorized access to the network location is allowed, protect the mapped drive using Active Directory objects to control permissions to the folder.
In environments where the Services preference extension is used to change service properties in such a way that they run in a context, other than their original security context, admins can use (group) Managed Service Accounts (MSAs). This method does not cache credentials in cpassword values or in registry.
When you encounter cpassword values in Group Policy Objects (GPOs) that specify running scheduled tasks in specific security contexts, the best practice is to select the Do not store password. The task will only have access to local resources. option.
The Data Sources preference is used to associate a data source with a computer or user. Unfortunately, Microsoft does not have a workaround available to make these available in such a way in a secure manner.
Of course, when you repurpose old accounts, make sure you don’t use passwords that are equal to passwords found in obfuscated cpassword values, and, also, cannot be easily guessed based on old passwords. Someone might already have made a ‘backup’ of your SYSVOL…
When you reconfigure a Group Policy Preference (GPP) the corresponding XML files get overwritten. Any passwords stored in obfuscated cpassword values will be gone, after you click OK in the Properties of the GPP and close the Group Policy Object (GPO). SYSVOL replication will take care of replacing the XML files on all Domain Controllers in the domain.
Step 3, Neuter the User Interface
As part of MS14-025, Microsoft has released two security updates, as part of these KnowledgeBase articles:
- Microsoft Knowledge Base Article 2928120 for systems with the security update from KnowledgeBase Article 2919355 installed.
- Microsoft Knowledge Base Article 2961899 for systems without the security update from KnowledgeBase Article 2919355 installed.
When you install these updates on Windows client systems and Windows Server installations with the Remote Server Administration Tools (RSAT) installed or the Group Policy Management Tools (gpmc.msc) enabled, the User Interface for the Group Policy Editor (gpedit.msc) User Interface (UI) gets stripped from the management capabilities to create or edit cpassword values.
When you’ve already applied the security updates above and figured out you needed to perform step 2, you can always implement a system without the security update to granularly manage Group Policy Preference (GPP) settings.
After years of guidance and warnings from Microsoft to not use passwords in Group Policy Preferences, MS14-025 finally triggers blocking the ability to configure them via the User Interface (UI). Be prepared.
Related KnowledgeBase Articles
Microsoft Security Bulletin MS14-025 – Important
2962486 MS14-025: Vulnerability in Group Policy Preferences could allow elevation of privilege: May 13, 2014
2928120 MS14-025: Description of the security update for Group Policy Preferences for systems that have update 2919355 installed: May 13, 2014
Group Policy Preferences Password Behaviour Change – MS14-025
MS14-025: An Update for Group Policy Preferences
Passwords in Group Policy Preferences
Passwords in Group Policy Preferences (updated)
During the 2014 Dutch TechDays, I participated in a Microsoft knowledge contest by Compu’Train, that dared Developers and IT Professionals to answer questions in their respective areas. As a mere joke I entered the competition, while Daniel continuously tried to distract me.
Nonetheless, I answered the most IT Pro questions correctly of the 200 TechDays attendees that took the test(s): I answered 13 questions correctly of the 20 questions and I took 5 minutes to do so. Not a great score, but it was the high score for the IT Pro part of the contest during TechDays.
As my prize, I won a Surface 2.
Today, I was invited by Compu’Train for the finale of the contest in Business Center Netherlands (BCN) Utrecht. Compu’Train set up the location as The Battle for TechEd, as the grand prize was to win a trip to TechEd Europe 2014 in Barcelona, Spain.
Compu’Train didn’t just invite me… they invited the 10 Developers that answered the most questions the fastest at TechDays, the 10 IT Pros that answered the most questions the fastest at TechDays, and the four best online contestants.
The finale for the Microsoft knowledge contest was pretty straightforward: both groups got their own 80-question exam, that they needed to complete within 30 minutes. This would give an accurate non-cheatable score for each contestant.
To compare the results of the two groups, the average scores and average time needed for the top 25 of each group at TechDays would serve as the denominator for their scores and times. What you should know: the Developers at TechDays scored high on average and didn’t need the entire 5 minutes, in contrast to the IT Pros, who scored poorly and needed the entire 5 minutes most of the time.
I was up against a really good developer. Of the 80 questions he checked 74 correct answers and only needed 13 minutes to do so. I scored 49 out of 80 and achieved it in 21 minutes. However, due to the results of the people at TechDays, Compu’Train declared me the winner.
That’s right. The largest IT training company of the Netherlands declared me the winner of their Microsoft knowledge contest against 400 other Developers and IT Professionals, declaring me
the best allround-skilled Microsoft IT Professional of the Netherlands!
Last week, I presented my first session ever on TechEd. I co-presented the session PCIT-B341 Upgrading Active Directory the Safe Way: Using Virtualization Technologies with Mike Resseler in the last presentation slot of TechEd North America 2014 in Houston.
The story how I obtained the speaker position (in typical MVP manner) can be found in my blogpost I will be speaking at TechEd North America 2014. When you’re curious about the contents of the session you can read my blogpost Upgrading Active Directory using virtualization on 4Sysops.com.
My buddy Raymond made some photos during the session, that I think will give you a good impression on the fun we had:
This week I’m in Houston for Microsoft’s 2014 TechEd North America event.
Yesterday, at the TechExpo, I ran into a couple of familiar faces. I talked to Ben Armstrong for a while, together with Didier van Hoye, MVP Hyper-V. While we were getting drinks for the guys at the booths, we ran into Mike Resseler, MVP System Center Cloud and Datacenter Management and working for Veeam.
It’s a small world, and what happened next illustrates exactly how small.
While I was discussing Mike Resseler’s PCIT-B341 Upgrading Active Directory the Safe Way: Using Virtualization Technologies session with him, I asked him if he was expecting any hard Active Directory-related questions. I offered to take a seat in the front row, so I could help him out. You know, that’s what Microsoft Most Valuable Professionals (MVPs) do…
Mike thought about it for a moment, but then replied:
“I’d much rather have you on stage with me.”
So, there you have it. I’ll be speaking at TechEd North America 2014.
Here’s some more information on the session:
PCIT-B341 Upgrading Active Directory the Safe Way: Using Virtualization Technologies
Thursday, May 15 2:45 PM - 4:00 PM Room: General Assembly C
Speaker(s): Mike Resseler, Sander Berkouwer
Track: People-centric IT
Session Type: Breakout
Topic: Active Directory Domain Services
Upgrading technologies can always be a challenge and dangerous. By using your backup solution and virtualization technology (Hyper-V) you can try out everything upfront on your real production data without risking destroying the environment. The Change Management Process will become much easier.
When you’re also at TechEd North America, please visit our session. If not, make sure to visit Channel 9 after TechEd ends to see the recording of this session on demand.
Next week, Microsoft organizes TechEd North America in Houston. As I’ve written last week, I’ll be attending, but you might not have gotten your hands on a ticket… this event is sold out.
However, you can still use your ginormous bandwidth (in contrast to the Hotel Wi-Fi in Houston) to be the first to get to know Microsoft’s new strategy, or simply follow the event from the comfort of your couch at home. The links below will provide you with a dose of Microsoft news:
http://www.twitter.com/TechEd_NA and hashtag #msteched
Just like in previous years, Microsoft allows you to watch the keynote near live on Monday May 12, 2014 9:00 AM – 10:30 AM US Central Time.
Brad Anderson will be hosting the keynote during TechEd North America. Since he is Microsoft’s Corporate Vice President for Windows Server and System Center Program Management, you might want to tune into it here.
As a TechEd North America Alumni, I was thrilled to hear TechEd North America will be held in Houston, Texas this year from May 12, 2014 to May 16, 2014.
Since “Everything is bigger in Texas”, I though the booths would be bigger as well. Of course, I applied to staff and speak at TechEd again, but, luckily, they found more capable people than me to do so. I’ve booked my ticket and flight two weeks ago and was pretty stoked to see the event sold out mere days later.
Due to these circumstances, I’ll have a lot more time on my hands than the last two TechEds in the US I attended, which is a bonus. Also, my travelling schedule is a bit less complicated than it was these last times, since I don’t have anything on my schedule for Saturday or Sunday. Additionally, Raymond offered to share his room with me, which meant I didn’t have to look for accommodations.
I’ll be flying from Amsterdam Schiphol Airport (AMS) to Houston George Bush Intercontinental Airport (IAH) with flight KL0661 on Monday May 12, 2014. This is a direct flight on a KLM Boeing 747-400 (Mixed configuration). My return flight is another direct flight; Flight KL0662 on Friday May 16, 2014 on the same type of aircraft, which means I could actually catch some sleep on the way home…
I’ll be staying at the Houston Magnolia, six blocks from the George Brown Convention Center, where TechEd North America is held.
See you in Houston!
I’ll be staffing at TechEd North America 2013
I will be staffing at TechEd North America (Orlando)
Stay up to date with TechEd North America (Orlando)
Looking at the news these last couple of days, you’d think the XPocalypse has begun.
A vulnerability has been discovered in Internet Explorer 6 through 11 and code has been made publicly available to attack it. Since, according to several websites, this is a critical vulnerability that was discovered after Microsoft officially ended support for Windows XP, thus, organizations using this old technology are and will remain at risk.
The Verge describes the impact of this vulnerability as:
Microsoft published a security advisory today warning its customers that a vulnerability in all versions of Internet Explorer (6 through 11) could let hackers gain full user permissions over your computer, allowing them to install programs, view and delete data, and much more simply by visiting a website.
I think it’s interesting that Dante D'Orazio of The Verge uses the word “full”, while linking to Microsofts official Security Advisory 2963983. This webpage clearly describes:
An attacker who successfully exploited this vulnerability could gain the same user rights as the current user. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.
The ability to execute code is limited to the rights the compromised account has on the system. In organizations, implementing Windows with Least Administrative Privilege is the best practice and the standard. It should come as no surprise this principle is extensively covered in all Windows-oriented Microsoft exams.
While deleting (and possibly encrypting) user data can be a real nuisance, restoring data from backups is still available on well-implemented systems, since the system integrity isn’t typically compromised by these attacks.
This vulnerability is a critical vulnerability in terms of Microsofts Security Bulletin Severity Rating System bacause of the Remote Code Execution ability.
Although Internet Explorer is identified as the faulty product by many tech websites, the initial attack vector is not Internet Explorer, but a vulnerability in Adobe’s Flash Player that is described in CVE-2014-0515. Internet Explorer has a vulnerability in the way it accesses an object in memory that has been deleted or has not been properly allocated, but this vulnerability, at the moment, is only exploitable through Adobe Flash Player.
Because, in recent years, Adobe Flash accounted for a lot of attack vectors towards Windows systems, for Windows 8 and Windows 8.1, Microsoft has adopted a new patching mechanism, together with Adobe, to update Flash Player through Internet Explorer and Windows Update mechanisms. Through this update mechanism, Windows 8 and Windows 8.1-based systems have already been updated with Adobe Flash Player 13.0.206.
For Internet Explorer versions running on Windows systems before Windows 8, Adobe has issued an update to Flash Player for Windows, that brings its version to 220.127.116.11. Adobe still supports Windows XP when you’ve patched it through to Service Pack 3. So, even when people in your organization run Internet Explorer 6 on Windows XP, you can protect them from these initial attacks.
You can use Windows Server Update Services (WSUS) to push the Adobe Flash Player update.
Mitigating factors and workarounds
The list of mitigating factors and workarounds in Microsofts official Security Advisory 2963983 is long. In addition to updating Adobe Flash Player and Windows, and implementing the principle of least administrative privilege, these actions help you protet against exploitation of this vulnerability:
- Internet Explorer Enhanced Security Configuration (IE ESC) mitigates this vulnerability. (This is enabled by default on Windows Server installations.)
- You can deploy version 4.1 or version 5.0 of the Enhanced Mitigation Experience Toolkit (EMET). EMET helps to mitigate this vulnerability in Internet Explorer on systems where EMET is installed and configured to work with Internet Explorer.
- When you set Internet and Local intranet security zone settings to "High" to block ActiveX Controls and Active Scripting in these zones, this protects against exploitation of this vulnerability.
- When you configure Internet Explorer to prompt before running Active Scripting or to disable Active Scripting in the Internet and Local intranet security zone, this protects against exploitation of this vulnerability.
- When you unregister or modify the ACLs on vgx.dll, web applications that render VML will no longer do so. This protects against exploitation of this vulnerability.
- When you Enable Enhanced Protected Mode For Internet Explorer 11 and Enable 64-bit Processes for Enhanced Protected Mode protects against exploitation of this vulnerability.
No solution for Windows XP
It’s true that home-users and small businesses running Windows XP will (most likely) not gain access to an update for the vulnerability in Internet Explorer (if/when it becomes available). Microsoft has done a stellar job providing free support for nearly 13 years.
Large organizations and governments, however, had the opportunity to buy extended support on Windows XP for at least another year. Organizations that have made this purchase will see an update to address this vulnerability (if/when it becomes available).
I'm very interested to see if Microsoft decides to support Windows XP for customers. I Imagine the code that is needed to patch Internet Explorer on Windows XP is not that different from the code for Windows Server 2003 and more recent versions of Windows. There's multiple ways to look at it.
Fear, uncertainty & doubt (FUD)
To top things of, many news outlets and government agencies are now actively discouraging the use of Internet Explorer. A perfect example is this tweet by the Dutch Police Team High Tech Crime:
When you translate the text to English, you’ll notice that the Dutch government is actually discouraging using Internet Explorer for the time being. As a side note, they tell us that no solution will become available for Windows XP.
With the list of mitigating factors and workarounds available to protect against exploitation of the vulnerability in Internet Explorer, and the availability for updates for organizations that have purchased Windows XP extended support, I feel the whole tweet can be discarded, regardless of the good intentions it was written with.
The impact of this Internet Explorer / Flash vulnerabity is relatively low, since code can only be executed with the privileges of the logged on user account.
When you communicate to colleagues, end-users and customers, make sure you give them proper advice.
The attack is non-exploitable when Adobe Flash Player for Windows is updated to version 18.104.22.168 or up and at least one of the actions in the list of mitigating factors and workarounds is performed.
These vulnerabilities, CVE-2014-1776 and CVE-2014-0515, are business as usual.
New Zero-Day Exploit targeting Internet Explorer Versions 9 through 11 Identified in Targeted Attacks
Security flaw puts all Internet Explorer users at risk, exposes Windows XP
Microsoft Races To Fix Massive Internet Explorer Hack: No Fix For Windows XP Leaves 1 In 4 PCs Exposed
Windows XP is permanently vulnerable to the newest Internet Explorer zero-day flaw
0-Day Vulnerability in Internet Explorer Threatens Windows XP
Internet Explorer hack spells trouble for Windows XP users
There's A Dangerous Bug In Internet Explorer, But Microsoft Won't Fix It For Windows XP Users
US, UK govt: Friends don't let friends use Internet Explorer – try Chrome or Firefox
In extensively managed networking environments, devices are generally domain-joined and employees gain mobility across these devices through folder redirection, offline files and roaming profiles. VPN access is mostly available, but when looking closely you might distinguish the occasional DirectAccess implementation.
In these environments, mobility over several devices, for instance a desktop and a laptop, often, offers challenges in terms of applications, settings and access to data.
While the above solutions offer a functioning environment when all devices run the same Operating System, it’s a different story when one device runs another or previous Operating System version.
In the past…
In the past, Roaming Profile incompatibilities have resulted in version 2 profiles. This distinction made sure colleagues with Windows XP and Windows Vista/7 devices could continue working effectively on both platforms, enjoying the same data, but not necessarily the same settings.
You probably remember the Username.V2 Roaming Profile folder names, if, at some point in the past, you’ve implemented Roaming Profiles on devices running Windows Vista, and beyond, in a Windows 2000 Professional / Windows XP Professional-based networking environment.
In the Windows 8.x era
To make matters more complicated, but more robust towards the people using devices with different Windows versions, Microsoft has updated the profile format in Windows 8. According to Microsoft KnowledgeBase article 2887239, the updated profile format, causes profiles to be incompatible between Windows 7 (and Windows Vista) on one side and Windows 8 and Windows 8.1 on the other side of the equation.
This means, that when a colleague switches from a Windows 7-based device with Roaming Profiles configured to a Windows 8-based device with the same Roaming Profiles configuration, the user profile is updated to the new Windows 8 format and the user profile is no longer compatible with the Windows 7-based device. But, both profiles are version 2 profiles.
Now, when you’re migrating your organization to Windows 8.1 from Windows 7 (and prior)and you’re not able to migrate all PCs for a specific colleague at one moment in time, this will cause problems when the colleague switches back and forth.
Introducing Version 3/4 profiles
Luckily, you can configure Windows 8 and Windows 8.1 to create a different Roaming Profile. This Roaming Profile, then gets a dot, a ‘v’ and a version number appended to the folder name.
The version number corresponds with the version of Windows that is used on the device on which you want a different Roaming Profile:
- Windows 7 and Windows Server 2008 R2 add the string .v2 to the folder name.
- Windows 8 and Windows Server 2012 add the string .v3 to the folder name
- Windows 8.1 and Windows Server 2012 R2 add the string .v4 to the folder name.
Thus, on Windows 8.1, Roaming Profiles become designated as version 4 profiles.
Implementing version 4 profiles
This is achieved by making a change in the Windows registry and rebooting.
According to Microsoft KnowledgeBase article 2890783, the update that adds this functionality to Windows 8.1 is included in November 2013 update rollup. Make sure you have this update installed on devices where you want to use version 4 profiles.
The update is also available in Windows 8.1 Update 1.
To perform the specific registry change, follow these steps:
- Swipe in from the right edge of the screen, and then tap Search. Or, if you are using a mouse, point to the lower-right corner of the screen, and then click Search. In the search box, type regedit, and then tap or click regedit.
When you are prompted for an administrator password, type the password. If
you are prompted for confirmation, provide confirmation.
- Locate and then tap or click the following registry subkey:
- On the Edit menu, point to New, and then tap or click DWORD (32-bit) Value.
- Type UseProfilePathExtensionVersion.
- Press and hold or right-click UseProfilePathExtensionVersion, and then tap or click Modify.
- In the Value data box, type 1, and then tap or click OK.
It should look like this:
- Exit Registry Editor.
After you configure the UseProfilePathExtensionVersion registry entry, you have to restart the computer.
After the reboot, Windows 8.1 creates a new Roaming Profile and appends the suffix ".v4" to the profile folder name to differentiate it from earlier Roaming Profile versions.
Of course, you can also use a Group Policy Preference (GPP) setting to add the registry key to Windows installations. You can target Windows 8.1-based devices specifically by either placing them in separate Organizational Units (OUs) within Active Directory Domain Services, or (when all devices reside in the same Organizational Unit) through WMI filters.
If you need new Roaming Profiles for colleagues that experience Roaming Profile incompatibilities between Windows 8.1 and previous versions of Windows, implement version 4 Roaming Profiles with the registry change above.
Together with Folder Redirection, these colleagues should only experience different settings between two devices, but still have access to the files, folders and applications they need to perform their jobs.
Is your organization ready for Windows 8.1? Part 1, Overview
Is your organization ready for Windows 8.1? Part 2, The best hardware for the job
Is your organization ready for Windows 8.1? Part 3, Start Button and Boot to Desktop
Is your organization ready for Windows 8.1? Part 4, Automatic App Updates
Is your organization ready for Windows 8.1? Part 5, Managing SkyDrive
Is your organization ready for Windows 8.1? Part 6, Start Screen Layout Management
Is your organization ready for Windows 8.1? Part 7, Managing Start Screen Theming
Is your organization ready for Windows 8.1? Part 8, Start Screen App Pinning
Is your organization ready for Windows 8.1? Part 9, Disable help tips in The New Interface
Is your organization ready for Windows 8.1? Part 10, Group Policy Caching
Is your organization ready for Windows 8.1? Part 11, IE Enhanced Protected Mode
Is your organization ready for Windows 8.1? Part 12, Assigned Access
Is your organization ready for Windows 8.1? Part 13, Quiet hours
Is your organization ready for Windows 8.1? Part 14, Logon Script Delay
Related KnowledgeBase Articles
2890783 Incompatibility between Windows 8.1 roaming user profiles and those in earlier versions of Windows
2887239 Incompatibility between Windows 8 roaming user profiles and roaming profiles in other versions of Windows
Thanks to JSchlackman for pointing out some errors in a previous version of this blogpost.
Last week, Microsoft Netherlands organized the 2014 TechDays at the World Forum in The Hague, where both Dutch and Belgian Developers and IT Professionals enjoyed two days of sessions, networking opportunities and catering.
On Wednesday April 16th, Raymond Comvalius and I were scheduled to deliver a 75-minute presentation on Bring Your Own (BYO), so we arrived early. Luckily, the event also started early both days, with the first sessions starting at 7:45 AM each day.
Our session was scheduled for 10:50 AM in room Onyx. This room was fitted with 300 seats, a nice stage and two projection screens.
Our session was great fun, and afterwards we received some great feedback. Needless to say I was proud of our achievement.
After our session, I dumped my stuff in the speaker room, switched from my blue Speaker polo to the orange Expert polo, and headed for the Ask the Experts (AtE) Area. I also spent the larger part of Thursday April 17th at the Ask the Experts (AtE) Area. A lot of my buddies were there and we had a lot of fun. The XBox One combined with Experts proved to be a real crowd pleaser.
I had a blast, and I hope you did too.
See you at TechDays 2015?
You may have read my blogpost on the actions admins need to take to continue working with Windows XP in their networking environments. It’s a long list. While many blogs and websites have shared similar information, one action is on everybody’s list:
Update Windows XP with the latest updates.
So, how easy is it to perform this task?
Without a fourth ServicePack for Windows XP, containing all the updates for Windows XP up till April 8th, 2014, it’s really about connecting a device running Windows XP to the internet and downloading the updates through Windows Update, or connecting a device to the corporate network and downloading updates from the on-premises Windows Server Update Services (WSUS) installation. This, of course, is not the best of ideas: Every security expert has warned against connecting Windows XP boxes to the internet or your corporate network after April 8th…
Straight from my toolbox comes a tool that helps you with this task:
WSUS Offline is an unofficial program, that you can use to update Windows installations for situations with no and low-speed Internet connectivity. It was previously known as "c't offline update" and "DIY Service Pack".
It allows you to simply check Microsoft products, after which it will fetch all the updates from Microsoft’s official FTP server. So far, this sounds like the official Windows Server Update Services (WSUS) that Microsoft offers, but Offline WSUS has another trick up its sleeve: After you’ve downloaded all the applicable updates, you can create a virtual CD/DVD (*.iso file) per product, per architecture (x86 / x64) and/or per language.
Version 9.1 of Offline WSUS was released on April 4th, 2014 and is the last version of Offline WSUS. This, then, is the version of Offline WSUS you want. You can get it from wsusoffline.net.
After you’ve downloaded wsusoffline91.zip, check it is 2281694 bytes in size and use Microsofts File Checksum Integrity Verifier to check it has a SHA1 checksum corresponding to 369d17656164139de81f49c3c32192286c492b1b.
Next, extract the contents of the file and run UpdateGenerator.exe. Next, select the Legacy products tab. This is where you’ll find updates for Windows XP x86:
Download Office 2003 through WSUS Offline as well, when you’re running it in a networked environment, since support on this product also ended on April 8th, 2014.
You can point WSUS Offline to your on-premises Windows Server Update Services (WSUS) installation to pull all the updates. Use the WSUS… button to this purpose. After successful download and tests, you can free up (expensive) hard disk space by cleaning up the Windows XP updates there.
Today, I’ve selected English and Dutch for Windows XP (including ServicePacks) and ended up with two virtual DVDs (*.iso files) in to iso subdirectory of where I unpacked to:
807 MB, 181 applicable updates
821 MB, 181 applicable updates
From each of these virtual DVDs, I can now use the UpdateInstaller.exe executable to update 32-bit installations of Windows XP without an internet connection, without hassle.
WSUS Offline allows you to download updates for Windows XP (and Office 2013) to update them with Microsoft updates, once and for all. After that, you can easily run the executable from the (virtual) DVD or USB drive to update Windows XP without an internet and/or network connection, without hassle.
So you want to continue using Windows XP?
How to install Windows XP Mode for Application Compatibility
Windows 7 Migration Checklist
Windows 8 Migration Checklist
Microsoft File Checksum Integrity Verifier
Windows XP support has ended
WSUS Offline Update
Microsoft Windows Update
Windows Server Update Services Home
This week, the Internet was abuzz with HeartBleed,a vulnerability in OpenSSL. This meant many secure websites and webservices, protected by OpenSSL, suddenly became a security risk and OpenSSL (and open source software, in general) suddenly became a lot less trustworthy.
The HeartBleed bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure Internet traffic. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private networks (VPNs). CVE-2014-0160 is the official reference to this bug.
The HeartBleed bug allows anyone to read the memory of the systems ‘protected’ by the vulnerable versions of the OpenSSL software (versions 1.0.1 through 1.0.1f). This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.
HeartBleed and Microsoft
In formal communications, only when you’ve installed and configured OpenSSL you’d need to take action, when running Microsoft Operating Systems (OSs).
While this is strictly true, in the modern world of Single Sign-On and claims-based authentication, this might not necessarily be the right way to look at it…
Many organizations have implemented Single Sign-On (SSO) by integrating their applications into Active Directory Domain Services (AD DS). While Active Directory, itself, was not affected by HeartBleed, any application or service utilizing OpenSSL and integrating with said Active Directory can be used to leak information from Active Directory like usernames, passwords, SIDs and token information.
Also, the private key used may be leaked, which, in turn, might contain information for a targeted attack against Active Directory Certificate Services (AD CS) and services relying on it, like Active Directory Rights Management Services (AD RMS).
Not until these OpenSSL implementations have been updated, the certificates in use have been replaced with different certificates (with a different private key) and users have changed passwords, the situation might be resolved.
Indeed, one single link in the authentication chain might cause the entire chain to fail…
To remedy such a situation, first, the vulnerable version of OpenSSL should be upgraded to at least version 1.0.1g or recompiled with -DOPENSSL_NO_HEARTBEATS. Additionally, any certificates in use by the OpenSSL implementation need to be reissued.
From there on, you might ask or force users to reset their passwords, unless you’ve already deployed a multi-factor authentication solution. When a security token is required, a malicious party can not login to a service with just the password alone.
So, claims-based authentication, must be safe then? Passwords can’t leak from OpenSSL, when the OpenSSL process (or deamon) doesn’t have it, right?
While it’s true that OAuth2, OpenID Connect and SAML2 endpoints at resource providers may not leak passwords, because these endpoints typically only have signed tickets, other risks are still present. Also, the endpoint of the identity provider might be protected by a vulnerable implementation of OpenSSL…
When you’re the resource provider in a claims-based authentication implementation, you should make sure the identity provider you have federated with are not running vulnerable OpenSSL implementations. Their signing key may have been compromised and, thus, a malicious party could sign tickets as if they would have originated at the identity provider.
When you’re the identity provider in a claims-based authentication implementation, you should make sure the resource providers you have federated with are not running vulnerable OpenSSL implementations. Examples of affected resource providers are Facebook, Yahoo and Google. The private key of their implementation(s) may have been compromised and a certificate may have been issued that allows a malicious party to pretend to be your resource provider to get signed tickets from you.
Indeed, one single link in the authentication chain might cause the entire chain to fail…
To identify vulnerable identity and/or resource providers, use the tools at Filippo.io and/or the list on Mashable. Contact vulnerable identity and/or resource providers to have them upgrade their OpenSSL implementation(s) to at least version 1.0.1g or have their OpenSSL implementation(s) recompiled with -DOPENSSL_NO_HEARTBEATS. Additionally, they should reissue the certificates used by the implementation(s).
From there on, you might ask or force users to reset their passwords, unless you’ve already deployed a multi-factor authentication solution.
The Heartbleed Bug
Vulnerability Summary for CVE-2014-0160
OpenSSL Security Advisory [07 Apr 2014]
How to Protect Yourself From the Heartbleed Bug
Information on Microsoft Azure and Heartbleed
Heartbleed bug puts the chaotic nature of the Internet under the magnifying glass
In the first post of this series, I’ve shown how to uncover the VM-GenerationID, the random value that unlocks all that Windows Server 2012 Active Directory Domain Services magic, on VMware’s vSphere and Workstation virtualization solutions.
Today, I’m showing you how to interpret this value and how this value might be different between versions of the VMware solutions used and the version of the VMware tools used.
You’ll need specific versions of VMware ESXi
First of all, if you want to run Windows Server 2012 on VMware vSphere, you’ll need at least ESXi 5.0 Update 1, since this is the first version of the hypervisor on which VMware supports Windows Server 2012.
But, VMware has implemented the VM-GenerationID functionality, as designed by Microsoft, into its products in the summer of 2012. It used the whitepaper and example code shared by Microsoft in its products. It did not finish this work prior to March, thus ESXi 5.0 Update 1 (released March 15, 2012) does not include the VM-GenerationID functionality.
These VMware ESXi versions support the VM-GenerationID functionality:
- VMware ESXi 5.0 Update 2 (Build 914586) and subsequent updates to ESXi 5.0
- VMware ESXi 5.1 (Build 799733) and subsequent updates to ESXi 5.1
- VMware ESXi 5.5 (Build 1331820) and subsequent updates to ESXi 5.5
One thing to know, however, is the VM-GenerationID functionality in ESXi 5.0 Update 2 was implemented (and released on December 20, 2012), based on a draft of the VM-GenerationID whitepaper. Microsoft made a significant update to this whitepaper and the example code it shared with VMware and Citrix, before making it final:
In the draft version of the VM-GenerationID whitepaper, the VM-GenerationID value was defined as a random 64bit value. In the final version of the VM-GenerationID whitepaper, the VM-GenerationID value was defined as a random 128bit value.
This means you will find significant smaller values in the virtual machine configuration (*.vmx) file on the host and in the (hidden) Microsoft Hyper-V Generation Counter system device in virtual machines running on top of VMware ESXi 5.0 Update 2, compared to virtual machines running on top of later versions of ESXi, including ESXi 5.0 Update 3 (released October 17, 2013).
You’ll need VMware Tools
Without the VMware Tools installed, a virtual machine running Windows Server 2012 (or up) will not be able to benefit from the VM-GenerationID capabilities, since the VM-GenerationID value will not be put in the virtual machine’s RAM.
Without the VM-GenerationID in RAM, a virtual Domain Controller will not be able to see when it is reverted to snapshot or cloned and you will not benefit from the virtualization safeguards in Active Directory Domain Services that make it virtualization-safe(r).
Of course, updating to a more recent version of the hypervisor, requires upgrading the VMware Tools in virtual machines running atop the hypervisor, to be upgraded, too, to remain in a supported state.
Besides running in an unsupported state, running virtual machines with version 5.0 Update 1 of the VMware Tools on top of ESXi 5.0 Update 2 (or up) will not enable the VM-GenerationID functionality, since 5.0 Update 1 of the VMware Tools does not support it yet.
When you want to utilize the VM-GenerationID functionality in a networking environment, virtualized with VMware products, in a supported manner, you will need to:
- Run ESXi 5.0 Update 2 (or up), ESXi 5.1, ESXi 5.5 as the hypervisor.
- Have the VMware tools installed in the virtual machines.
- Have the VMware tools version installed, corresponding to your hypervisor version.
Virtualization-safe(r) Active Directory in VMware environments, Part 1
List of Hypervisors supporting VM-GenerationID
Citrix XenServer joins the VM-GenerationID family
New features in AD DS in Windows Server 2012, Part 13: Domain Controller Cloning
New features in AD DS in Windows Server 2012, Part 12: Virtualization-safe Active Directory
Cloning Windows Server 2012 Domain Controllers on vSphere 5
Windows Server 2012 VM-Generation ID Support in vSphere