Previously, we’ve looked at the WorkPlace Join functionality in Active Directory Federation Services (AD FS) in Windows Server 2012 R2 (and up) and the accompanying Registered Device objects in Active Directory Domain Services (AD DS).

When WorkPlace Join is enabled for a networking environment, by default anyone has the right to WorkPlace Join devices, by default.

In Active Directory Domain Services, a special container is created for Registered Devices: the msDS-DeviceContainer. This is the default location where WorkPlace-Joined device have their registered device object (msDS-Device) stored.

On this container, Authenticated Users have read rights, just like they do in the greater part of the Active Directory. However, the Device Registration Service (DRS) service account in Active Directory Federation Services (AD FS) has an awful amount of rights on the container and actually creates the Registered Device object in Active Directory Domain Services.

Note:
By default, the service account for Device Registration Service (DRS) is the same as the service account for Active Directory Federation Services (AD FS).

Since Device Registration is a Relying Party Trust in Active Directory Federation Services (AD FS), the most logical way to look at granularly revoking access is to modify the Issuance Authorization Rules.

Perform these steps to gain access to the authorization rules for the Device Registration Service (DRS) in Active Directory Federation Services:

• Log on with an account that has Domain Administrator rights on a device that is capable of running the Windows Server 2012 R2 version of the AD FS Management Management Snap-in (Microsoft.IdentityServer.msc).
• In the left pane, open Relying Party Trusts.
• In the main pane, now select Device Registration Service and, then, in the (right) task pane click the Edit Claim Rules… shortcut. This will open the Edit Claim Rule for Device Registration Service window:

• Click on the second tab, labeled Issuance Authorization Rules.

• Here you’ll find the Permit Access to All Users rule.

Changing access to WorkPlace Join

Depending on your scenario, you might want to specifically permit or specifically deny users that are member of specific group(s):

Permitting WorkPlace Join only for a specific group

If you want to permit the use of the Device Registration Service (DRS) and thus the ability to WorkPlace Join devices to only colleagues that are members of a specific group or a couple of specific groups, create a new Issuance Authorization Rule:

• Click the Add Rule… button.
• The Add Issuance Authorization Claim Rule Wizard appears. Its first screen is the Select Rule Template screen.

• As the Claim rule template: select the default Permit or Deny Users Based on an Incoming Claim. Press Next >.
• In the Configure Rule screen, type a suitable name in the field below Claim rule name:. Then, as the Incoming claim type:, select Group SID from the drop-down list.

• Click Browse… to browse for a group or a set of groups that you want to explicitly permit.

• Press OK when done.
• Press Finish in the Add Issuance Authorization Claim Rule Wizard window to create the Issuance Authorization claim rule.In the Edit Claim Rules for Device Registration Service window, select the Permit Access to All Users rule. Click the Remote Rule… button.
• Click Yes to answer Are you sure you want to delete this claim rule?.

Note:
If you have no Issuance Authorization rules to Permit claims, no one will be able to use Device Registration Service (DRS) and thus no one will be able to WorkPlace Join devices.

• Click OK to close the Edit Claim Rules for Device Registration Service window.

Denying WorkPlace Join for a specific group

The other method is to deny a specific group of colleagues the use of the Device Registration Service (DRS) and thus the ability to WorkPlace Join devices. While this sounds harsh, there might actually be good reasons to deny this right to specific groups, like the Protected Users group.

Note:
Membership to the Protected Users group protects a lot of older insecure access protocols, but it does not deny WorkPlace Join, by default.

Let’s create a new Issuance Authorization Rule that denies this group that right:

• Click the Add Rule… button.
• The Add Issuance Authorization Claim Rule Wizard appears. Its first screen is the Select Rule Template screen.
• As the Claim rule template: select the default Permit or Deny Users Based on an Incoming Claim. Press Next >.
• In the Configure Rule screen, type a suitable name in the field below Claim rule name:. Then, as the Incoming claim type:, select Group SID from the drop-down list.
• Click Browse… to browse for a group or a set of groups that you want to explicitly deny.
• Press OK when done.
• Select Deny access to users with this incoming claim.

• Press Finish in the Add Issuance Authorization Claim Rule Wizard window to create the Issuance Authorization claim rule.
• In the Edit Claim Rules for Device Registration Service window, Select the Permit Access to All Users rule. Move this rule down in the order in which the Issuance Authorization Rules will be processed, by clicking the blue down arrow to the right of the list with rules.

Note:
It is a best practice to place rules with Deny issued claims above rules with Permit issued claims. Place the Permit Access to All Users as the last rule, when possible.

• Click OK to close the Edit Claim Rules for Device Registration Service window.

Concluding

Since the Device Registration Service (DRS) is a Relying Party Trust in Active Directory Federation Services (AD FS), the most logical way to look at granularly granting or revoking access to it is to modify the Issuance Authorization Rules.

Related blogposts

WorkPlace Join vs. Domain Join
New features in Active Directory Domain Services in Windows Server 2012 R2, Part 5: WorkPlace Join and Registered Device objects

Further reading

Set-AdfsRelyingPartyTrust
When to Use an Authorization Claim Rule
The Role of Claim Rules
The Role of the Claims Pipeline

When we discussed the WorkPlace Join functionality in Active Directory Federation Services in Windows Server 2012 R2 (and up) and the accompanying Registered Device objects in Active Directory Domain Services, you might have gotten the feeling that the directory might get cluttered with Registered Devices.

Microsoft has built in a feature in the Device Registration Service (DRS) that makes it automatically clean up unused devices, by default. Its default setting is 90 days.

The Device Registration Service (DRS) is the part of Active Directory Federation Services that is responsible for WorkPlace Join. Since the Device Registration Service (DRS) is part of Active Directory Federation Services ‘unused days’ can best be interpreted as ‘the amount of days before a device object is removed because of inactivity in accessing claims-based resources involving the AD FS infrastructure the DRS is part of’. Popularly speaking, when you’re not using the single sign-on functionality of WorkPlace Join, Microsoft feels it can disable this functionality and clean up after 90 days of you not using it.

Now, don’t get me wrong. I feel 90 days is a perfectly healthy and balanced value for this behavior of the Device Registration Service (DRS) in most environments.

However, you might want to change it.

Changing the inactivity time-out

The Device Registration Service (DSR) is exposed for authentication and authorization in Active Directory Federation Services (AD FS), but has its own distinct endpoint and service. Much of that is controlled to DRS-specific PowerShell Cmdlets.

You can change the inactivity time-out with the following steps:

• Log in with an account that is a member of the Domain Admins group to a device capable of offering the Active Directory Federation Services 3.0 PowerShell module.
• Start PowerShell
• Perform this PowerShell one-liner:

Set-AdfsDeviceRegistration -MaximumInactiveDays n

You can specify a value between 0 and 1000 for n. When you specify 0, the Device Registration Service (DRS) will no longer clean up inactive WorkPlace-joined devices.

• Exit PowerShell and log off, or type logoff directly in PowerShell.

Tip!
You can check the current number of days before the Device Registration Service (DRS) in Active Directory Federation Services (AD FS) deletes Registered Devices using the Get-AdfsDeviceRegistration PowerShell Cmdlet. You can also use this Cmdlet to check your change.

Best practices

As noted earlier, I think the default 90 days value is a healthy and balanced value for the inactivity clean-up time-out for the Device Registration Service (DRS) within Active Directory Federation Services (AD FS).

You might want to clean up unused devices more frequently, because typically you use the WorkPlace Join functionality for contractors that are assigned for a far shorter period to your organization. In terms of security, you might also want the trusted combination of user and device to expire faster than 90 days of inactivity.

You could clean-up inactive user/device combinations faster, but configuring it too short might only prove it an inconvenience to colleagues using claims-based apps often, either because they want single sign-on functionality or either because you utilize WorkPlace Join as an authorization mechanism. Additionally, you run the risk of RID Pool depletion in Active Directory Domain Services.

You want to clean up unused devices less frequently, because you experience colleagues use claims-based application less frequently than 90 days and are prompted to WorkPlace-join devices. I can think of a couple of applications I only use once or twice per year.

This other side of the spectrum might also prove tricky. Not cleaning up inactive devices might expose single sign-on access to apps on devices that are no longer used, were lost or stolen (but never reported as such).

Concluding

You can change the inactivity clean-up time-out for the Device Registration Service (DRS) within Active Directory Federation Services (AD FS) with the Set-AdfsDeviceRegistration PowerShell Cmdlet. Use sensibly.

Related blogposts

Granularly permitting or denying the right to WorkPlace Join
WorkPlace Join vs. Domain Join
New features in AD DS in Windows Server 2012 R2, Part 5: WorkPlace Join and Registered Device objects

Further reading

Set-AdfsDeviceRegistration
Get-AdfsDeviceRegistration
ADFS 3.0: Enabling Device Registration Service (DRS)
AD FS W2012 R2 – Workplace Join via WAP
Conditional Access with Azure Device Registration Service (aka Workplace Join)

We’ve discussed the WorkPlace Join functionality in Active Directory Federation Services in Windows Server 2012 R2 (and up) and the accompanying Registered Device objects in Active Directory Domain Services, and we’ve looked into granularly granting and revoking access to WorkPlace Join by specifying Issuance Authorization Rules for the Device Registration Services (DRS) and configuring the time-out before the Device Registration Services (DRS) deletes these Registered Device objects.

Today, let’s look at restricting the amount of devices a user can Workplace Join.

Note:
The default WorkPlace Join quota does not apply to administrators.
Members of the group Domain Admins (RID 512) can WorkPlace Join up to 2147483647 (2 ^31-1) devices as this is specifically defined in an Issuance Authorization Rule for the Device Registration Service (DRS) in Active Directory Federation Services (AD FS).

By default, domain users can WorkPlace Join up to 10 devices.

The quota of 10 devices a colleague can WorkPlace Join is strikingly identical to the quota of 10 devices a colleague can Domain Join, by default.

Changing the quota

The Device Registration Service (DSR) is exposed for authentication and authorization in Active Directory Federation Services (AD FS), but has its own distinct endpoint and service. Much of that is controlled to DRS-specific PowerShell Cmdlets.

You can change the inactivity time-out with the following steps:

• Log in with an account that is a member of the Domain Admins group to a device capable of offering the Active Directory Federation Services 3.0 PowerShell module.
• Start PowerShell
• Perform this PowerShell one-liner:

Set-AdfsDeviceRegistration –DevicesPerUser n

You can specify a value between 0 and 1000 for n. When you specify 0, no quote will be applied to non-admin colleagues WorkPlace-joining devices.

• Exit PowerShell and log off, or type logoff directly in PowerShell.

Tip!
You can check the current quote using the Get-AdfsDeviceRegistration PowerShell Cmdlet. You can also use this Cmdlet to check your change.

Concluding

You can change the inactivity clean-up time-out for the Device Registration Service (DRS) within Active Directory Federation Services (AD FS) with the Set-AdfsDeviceRegistration PowerShell Cmdlet.

Related blogposts

Granularly permitting or denying the right to WorkPlace Join
WorkPlace Join vs. Domain Join
New features in AD DS in Windows Server 2012 R2, Part 5: WorkPlace Join and Registered Device objects

Further reading

Set-AdfsDeviceRegistration
Get-AdfsDeviceRegistration
ADFS 3.0: Enabling Device Registration Service (DRS)
AD FS W2012 R2 – Workplace Join via WAP
Conditional Access with Azure Device Registration Service (aka Workplace Join)

In six months time, on July 14 2015, Microsoft ends the extended support for Windows Server 2003. After 11 years and 6 months (Windows Server 2003 became generally available on May 28th, 2003) the plug is pulled on updates to the product and the support information on TechNet, MSDN and its KnowledgeBase.

Running Active Directory on Operating systems that lack support is a pretty bad idea and considered a bad practice among many of the people and writers in the IT industry.

Active Directory is the cornerstone of every Microsoft-oriented networking environment. This, alone, should be the reason to migrate to a next version of Windows Server for your Active Directory Domain Controllers. However, in my opinion, merely upgrading for support may not offer the largest benefits to your organization. Taking advantage of the advances made in Active Directory since Windows Server 2003, does.

So, please, take advantage of these new and improved features that were added to Active Directory since Windows Server 2003 (in chronological order):

Fine-grained Password Policies

Initial version: Windows Server 2008
Recommended version: Windows Server 2012

Certain accounts in Active Directory should use stronger passwords. You can’t expect the concierge to change his/her 12-character complex password every 42 days, and be somewhat productive, though. Where password policies in Windows 2000 Server and Windows Server 2003-based Active Directory environments were domain-scoped only, in Windows Server 2008 (and up) you can apply password (and account lockout) settings (objects) to specific Active Directory user objects and global security groups.

Note:
Fine-grained password policies cannot be applied to Organizational Units (OUs).

With fine-grained password policies, you can have multiple password policies in a single Active Directory domain.

This functionality is unlocked through the Windows Server 2008 Active Directory schema. However, AdsiEdit or 3rd party tooling is needed to manage fine-grained password policies on platforms earlier than Windows Server 2008 R2. This latter platform introduced PowerShell Cmdlets to manage these policies.

You will want to use the Active Directory Administrative Center (dsac.exe) on Windows Server 2012 (or up) or from the Windows 8 (or up) Remote Server Administration Tools (RSAT), since this tool provides a Graphical User Interface (GUI) to manage fine-grained password policies.

Read-only Domain Controller

Initial version: Windows Server 2008

Windows Server 2008 (and up) installations can be promoted to Read-only Domain Controllers in addition to the (default) Read/Write Domain Controllers.

Read-only Domain Controllers (RoDC) can be considered compromised by default. Accordingly, the RoDC features many security measures, including read-only access to Active Directory and DNS, separation of administrative priviliges (so branch office admins can perform some tasks, but not in the local Active Directory database or DNS) and Password Replication Policies (PRPs).

RoDCs cater to the kitchen cupboard server scenario, that many admins are faced with in branch offices, Some perimeter networks, or DMZs, are also perfect places for RoDCs.

The requirements for RoDCs are pretty straightforward: You’ll need at least one Windows Server 2008-based Read/Write Domain Controller (or up) for the RoDC(s) to communicate with.

Active Directory Recycle Bin

Initial version: Windows Server 2008 R2
Recommended version: Windows Server 2012

Accidentally deleting objects from Active Directory is unfortunate. Prior to Windows Server 2008 R2, when you wanted to undelete an object, you would reanimate it. The resulting object would have the same security identifier (SID) but would be stripped from group memberships and the likes. Authoritative restores were the true answer but were difficult, time consuming and required Domain Controller reboots.

The Windows Server 2008 R2 Forest Functional Level (FFL) introduced the Active Directory Recycle Bin. In order to use this functionality, all Domain Controllers need to run Windows Server 2008 R2 (or up) and the functional levels need to be Windows Server 2008 R2 (or up).

However, just with the Fine-grained Password Policies, management of the Active Directory Recycle Bin was quite the ordeal before Windows Server 2012. The Active Directory Administrative Center (dsac.exe) on Windows Server 2012 (or up) or from the Windows 8 (or up) Remote Server Administration Tools (RSAT) introduces a graphical way to enable the Active Directory Recycle Bin and manage the functionality.

Managed Service Accounts

Initial version: Windows Server 2008 R2
Recommended version: Windows Server 2012

Did you know that when you provide (domain) credentials for a service, those credentials are stored in the Windows Registry in a way that is not very secure?
Furthermore, these accounts, typically, are not limited to one machine and have privileges. Changing their passwords breaks the service everywhere.

To address this situation, Windows 7 and Windows Server 2008 R2 can use Managed Service Accounts (MSAs). These virtual domain accounts don’t get their credentials stored and are limited to services on one domain-joined machine. When you want automatic password and SPN management for these MSAs, you’ll want the Windows Server 2008 R2 Domain Functional Level.

When you want to use MSAs on multiple hosts for the same service, you’ll need the group Managed Service Accounts (gMSAs) introduced with Windows 8 and Windows Server 2012.

Active Directory PowerShell Manageability

Initial version: Windows Server 2008 R2
Recommended version: Windows Server 2012 R2

Windows Server 2008 R2 saw the advent of the PowerShell Active Directory Module. This started the revolution of managing Active Directory on the PowerShell. Since then, an additional ADDSDeployment Module was added to deploy Active Directory and many new PowerShell Cmdlets have been added to the modules. Active Directory’s new go-to management tool, the Active Directory Administrative Center (dsac.exe) is even completely built upon PowerShell.

The latest ActiveDirectory module features the most PowerShell Cmdlets, so you’ll want to use it. The ActiveDirectory and ADDSDeployment PowerShell modules on Windows Server 2012 (or up) or from the Windows 8 (or up) Remote Server Administration Tools (RSAT) include the latest features. You can use them in many ways.

Virtualization safeguards & DC Cloning

Initial version: Windows Server 2012

Virtualization has proven to be an easy way to wreck Active Directory. In the pre-Windows Server 2012 era, Microsoft recommended to treat virtualized Domain Controllers as physical hosts, restraining from using snapshots, cloning, etc.

Virtualized Windows Server 2012-based Domain Controllers (and up) leverage the Virtual Machine Generation Identifier (VM-GenerationID) provided by all major virtualization platforms to detect when it is reverted to a snapshot. This prevents USN Rollbacks and Lingering Objects. Additionally, the same VM-GenerationID functionality can be used to safely clone virtualized Domain Controllers for fast deployment and recovery.

Any virtualized Domain Controller running Windows Server 2012 (and up) has the virtualization safeguards, when it has the integration tools installed for the virtualization platform and the latter supports VM-GenerationID. For Domain Controller Cloning, additionally, the Domain Controller running the PDCe FSMO role needs to run Windows Server 2012 (or up) and needs to be available when cloning.

Dynamic Access Control

Initial version: Windows Server 2012

In environments with high amounts of group memberships you might experience token bloat issues. In complex file server authorization scenario’s, additionally, you might lose track of who has access where. Dynamic Access Control in Windows Server 2012 introduces claims in Kerberos, so you can authorize access to files and folders, based on any attribute for objects in Active Directory.

You’ll need at least one Domain Controller needs to run Windows Server 2012 or up. File Servers, where you want to use claims-based access control need to be running Windows Server 2012, or up. 3rd party storage vendors may also support the feature.

When you want to use Compound Identity, to authorize access based on attributes of the domain-joined device used, Kerberos Armoring (FAST) is required.

Protected Users

Initial version: Windows Server 2012 R2

From a security point of view, accounts and devices can be more sensitive than others. More strict password policies to user accounts and groups with the Fine-Grained Password Policies functionality and Group Policies to disallow interactive logons and network logons to user accounts and groups in Active Directory on Organizational Units (OUs) on certain domain-joined devices were considered solutions to these challenges.

However, there was no way to restrict sensitive accounts in terms of the lifetime of the Ticket Granting Tickets (TGTs), restricting more vulnerable authentication protocols (like NTLM), encryption standard to use in the pre-authentication process, the ability to be (constrainedly) delegated, or criteria for the devices sensitive accounts log on to.

The Protected Users global security group in the Users container in environments with the Windows Server 2012 R2 schema triggers these types of protection on devices and servers running Windows Server 2012 R2 and Windows 8.1, and on Active Directory Domain Controllers in domains running the Windows Server 2012 R2 Domain Functional Level (DFL).

Authentication Policies and -Silos

Initial version: Windows Server 2012 R2

When the Protected Users group isn’t granular enough to cater to the needs of your environment, Authentication Policies and Authentication Policy Silos can be used.

Authentication policy silos tie user objects and computer objects together using a claim with the name of the silo to apply the authentication policy. When the requirements set in the authentication policy are met, the policy applies to Kerberos Ticket Granting Ticket (TGT) lifetime and renewal. When they are not met, no (TGT) is issued and, thus, logon is denied, effectively creating silos for objects.

Concluding

Active Directory in Windows Server has seen numerous improvements. Depending on your environment you can take advantage of these. Business Cases for upgrading Domain Controllers might see financial benefits from these features.

The list above is not a full list of new features in Active Directory since Windows Server 2003.

Last weekend, I had the opportunity to speak at ITPRO|DEV Connections 2014 in Athens, Greece.

This meant I not only had the opportunity to share knowledge with Greek IT Pros, joined by the their IT professional community autoexec.gr and developers community, dotNETZone.gr, but also to enjoy some nice weather and meet with old friends again.

As I mentioned previously, Adnan and I were invited back to this event. This meant we met up at Schiphol Amsterdam Airport on Friday afternoon. I decided to spend my morning teaching a half class to MCSA students, while Adnan decided to use the time to fly from Helsinki to Amsterdam. We met at the KLM Lounge.

After an eventful flight, we arrived at Paris Charles de Gaulle airport, where we waited on our connecting flight to Athens in the Air France lounge. Around 11 PM (including an hour time difference) we arrived at Athens Eleftherios Venizelos International Airport. The cab ride to the Holiday Inn, the organization booked for us took us just a short 15 minutes.

Saturday

At breakfast on Saturday morning, we met with Elias and Dimitris. Half an hour later, Antonios gave us a ride to the Metropolitan.

1 PM meant showtime for me, because I volunteered to provide a session to fill in the empty slot that Peter left by not being able to attend. I decided to provide the audience with an interactive 1-hour session on Microsoft licensing: Ask me Anything on Licensing People Centric-IT.

After I’d announced that the room would not be used for a session on desktop migration, the greater part of the audience left. The remaining people, however, opted in for the interactivity and got all their questions answered. According to Kostas Sinodinos (who I asked to attend to help out with any Lost in Translation situations) we covered the entire spectrum of Microsoft licensing that hour.

Adnan, then, performed his session on deploying Windows 8.1 and Windows Server 2012 R2, after which is was my turn again to rock Room C with my Ten most common mistakes when deploying AD FS session:

After being done with our sessions, it was time to relax and keep the promise Adnan and I made last year: We wanted to eat real Greek food.

Luckily, Antonios knew just the place in Chalandri: Kitsoulas Tavern. We had a really good meal and the best companion with Elias, Manos and George:

Sunday

Sunday, we decided to give the city of Athens, and more specifically the Acropolis a visit. We acted like genuine tourists, so we took plenty of photos:

Just before 5 PM we took a flight back to Amsterdam.

Concluding

Just like last year, IT PRO | DEV Connections was a hugely successful event. I am thankful for being able to be a part of it. I also feel lucky that in my last trip for 2014 we could mix business with pleasure.

Related blogposts

Speaking at ITPRO | DEV Connections Greece again 
Pictures of ITPRO/DEV Connections Greece 2013 
Speaking at ITPro|Dev Connections Greece

Sometimes, an easy task becomes daunting. Especially when you’re working with technology like Active Directory Domain Services and you can’t even get a server promoted to a Domain Controller because the promotion process hangs and you’re left without clues.

The situation

You can promote a Windows Server to an Active Directory in the following ways:

• Using the Install-ADDSForest, Install-ADDSDomain or Install-ADDSDomainController PowerShell Cmdlet
• Using  dcpromo.exe in combination with an answer file, or
• With the Active Directory Domain Services Configuration Wizard.

When you do, the promotion process is logged in two log files:

• C:\Windows\debug\dcpromo.log
  All the events regarding the creation and removal of Active Directory, SYSVOL trees and the installation, modification and removal of key services
• C:\Windows\debug\dcpromoui.log
  All the events from a graphical interface perspective

When the Promotion process stops responding, these two logs may provide clues to what has happened.

In the case of the issue identified, the following lines are recorded in dcpromo.log:

….

[INFO] EVENTLOG (Error): NTDS Replication / DS RPC Client : 1963

Internal event: The following local directory service received an exception from a remote procedure call (RPC) connection. Extensive RPC information was requested. This is intermediate information and might not contain a possible cause

 

[INFO] EVENTLOG (Error): NTDS Replication / DS RPC Client : 1962

Internal event: The local directory service received an exception from a remote procedure call (RPC) connection. Extended error information is not available.

….

Error value:

A security package specific error occurred. 1825directory service:

<hostname>

Additional Data

 

Error value: Could not find the domain controller for this domain. (1908)

 

[INFO] EVENTLOG (Error): NTDS Replication / Setup : 1125

The Active Directory Domain Services Installation Wizard (Dcpromo) was unable to establish connection with the following domain controller. Domain controller: <DC name>.<DNS domain name>.<top level domain name>

Additional Data

Error value:

1908 Could not find the domain controller for this domain.

The issue

Active Directory promotion fails, because:

• NetBIOS over TCP/IP is disabled, because:
  • Disable NetBIOS over TCP/IP is selected in the Advanced settings for the Internet Protocol Version 4 (TCP/IPv4) Properties for the network connection, or

• NetBIOS over TCP/IP is disabled on the DHCP Server, and/or
• IPv4 is disabled and hosts communicate using IPv6 only.
• “Short” credential names, in the DOMAIN\User are used in the Active Directory Domain Services Configuration Wizard, in the Domain Controller promotion answer file or or as value for -credential for one of the PowerShell Cmdlets.

In this case, Kerberos cannot locate a Domain Controller to authenticate with by using the specified credentials.

When you run Active Directory Domain Services Configuration Wizard in a NetBIOS-less\WINS-less environment, it introduces some DC-locator limitations to be aware of in situations where short domain names are used. This is especially true on a non-domain-joined device.

DC-locator tries to map short domain names to fully qualified domain names (FQDNs) by using the trusted-domain-list, which involves DNS to be used most of the time. If DNS cannot be used, locator has to use WINS\NetBIOS. However, WINS\NetBIOS is not available when NetBIOS over TCP/IP is disabled.

Workarounds

You can prevent this issue when you next start the Add-ADDSForest, Add-ADDSDomain or Add-ADDSDomainController PowerShell Cmdlet, dcpromo.exe or the Active Directory Domain Services Configuration Wizard after you end the process in task manager or process monitor, by making any one of these changes:

• Specify “long” credentials, for example, domain.tld\administrator in stead of DOMAIN\administrator, in the Active Directory Domain Services Configuration Wizard, in the promotion answer files or as value for -credential for the PowerShell Cmdlet.
• Configure the DNS search suffixes, so that when the DNS search suffixes are concatenated with the provided NetBIOS domain name, they can be resolved to the FQDN of the Active Directory Domain that hosts the user account being used to perform the authenticated operation.

Note:
This issue can be partly worked around by the DNS-suffix feature that is added to DC-locator in Windows Server 2012 R2 and Windows 8.1 but that is not always a 100% reliable solution.

• Join the device to the Active Directory domain prior to promotion in the target Active Directory Domain, restart, and then retry the promotion.
• Temporarily enable NetBIOS over TCP/IP in order to complete the promotion.

Concluding

When promotion of an Active Directory Domain Controller stops responding, check the log files to gain clues on what has happened. When you want to promote a Windows Server in an environment without NetBIOS over TCP/IP or without IPv4, use one of the workarounds above.

Related blogposts

How to install a Server Core R2 Domain Controller

Related KnowledgeBase Articles

2948052 Domain controller promotion stops responding when NetBIOS over TCPIP is disabled in Windows Server 2012 R2

During the November 2014 Patch Tuesday, Microsoft has released Security Bulletin MS114-077, that describes how a vulnerability in Active Directory Federation Services (AD FS) could allow unintentional information disclosure and how you can fix this by installing the security update that is part of KB3003381 on your Active Directory Federation Servers, including proxies.

About MS14-077

The security update resolves a privately reported vulnerability in Active Directory Federation Services (AD FS). The vulnerability could allow unintentional information disclosure if a person leaves their browser open after logging off from an application, and an attacker reopens the application in the browser immediately after the person has logged off.

This problem has been described in CVE-2014-6331 as “when a configured SAML Relying Party lacks a sign-out endpoint, does not properly process logoff actions, which makes it easier for remote attackers to obtain access by leveraging an unattended workstation”.

Affected implementations of AD FS

This security update is rated Important for the following implementations of Active Directory Federation Services (AD FS):

• AD FS 2.0 when installed on 32-bit and x64-based editions of Windows Server 2008
• AD FS 2.0 when installed on x64-based editions of Windows Server 2008 R2
• AD FS 2.1 when installed on x64-based editions of Windows Server 2012
• AD FS 3.0 when installed on x64-based editions of Windows Server 2012 R2

Mitigating factors

Microsoft has not identified any mitigating factors for this vulnerability.

Workarounds

Microsoft has not identified any workarounds for this vulnerability.

Call to Action

Since no mitigating factors or workarounds are available, I urge you to install KB3003381 in a test environment as soon as possible, assess the risks and possible impact on your production environment and, then, roll out this update to all systems with the Active Directory Federation Services role installed, including ADFS Proxies and Web Application Proxies.

Related KnowledgeBase Articles

3003381 MS14-077: Vulnerability in Active Directory Federation Services could allow information disclosure: November 11, 2014

Further reading

Microsoft Security Bulletin MS14-077 – Important
Assessing Risk for the November 2014 Security Updates
Terminology used in ADFS

Earlier today, Microsoft released a new preview for Windows 10, codenamed Technical Preview 2 and wearing build number 9926 (in proud lime green on navy blue, oh wait…)

Windows 10 Technical Preview 2

You can download the Windows 10 Technical Preview 2 ISO files or install the Windows 10 Technical Preview update from the Windows Insiders website.

Upgrade

To upgradee a Windows 7, Windows 8 or Windows 8.1 installation to Windows 10 Technical Preview 2 (build 9926), you need to use a virtual machine or device with the minimum specifications for Windows 8.1. Next, join the Windows Insider Program (free) and click the purple Start upgrade now button here.

Iso files

Alternatively, you can download the English (United States) ISO (*.iso) files from the Windows Insiders website:

• Windows 10 Technical Preview (x64)
  Download (3.92 GB) Windows10_TechnicalPreview_x64_EN-US_9926.iso
• Windows 10 Technical Preview (x86)
  Download (3.01 GB) Windows10_TechnicalPreview_x32_EN-US_9926.iso

The *.iso files are available for download in another twenty-one languages, including Arabic, Brazilian Portuguese, Czech, Dutch, English (United Kingdom), French, French (Canadian), German, Finnish, Italian, Japanese, Korean, Polish, Russian, Spanish, Spanish (Latin America), Simplified Chinese, Swedish, Thai, Traditional Chinese and Turkish.
Click here.

Tip!
Vietnamese, Catalan and Hindi are also available as languages for Windows 10 Technical Preview 2, but only as Language Interface Pack. Download and install the EN-US ISO (*.iso) file and then download and install the language of your choice.

Update

When you’re already running Windows 10 preview on a device, you can update is to Technical Preview 2 seamlessly. Open the PC settings, head to Update and recovery and then select Preview builds in the left pane. The option to update to the Technical Preview 2 build is available there, regardless whether you’ve joined the slow ring or the fast ring, but as long as you have KB3025380 installed on it. Hit the Download now button to start the update.

Windows 10 Enterprise Technical Preview 2

Although not directly available for Windows Insiders, ISO (*.iso) files for the Enterprise Edition of Windows 10 Technical Preview 2 was also released to MSDN subscribers in the same languages as described above and for both 64bit and 32bit architectures.

Concluding

You can now download Windows 10 Technical Preview 2.

Have fun!

Windows 10 Technical Preview for phones is coming in February.

Related blogposts

Is your organization ready for Windows 8.1? Part 2, The best hardware for the job

Recently, after deploying Azure Self-service Password Reset (SSPR) for a customer, I discovered some odd behavior. After we worked through the error tree, we finally worked out the issue. Since it wasn’t documented yet (many other errors are!) at Microsofts KnowledgeBase, here it is.

The situation

In an organization with an on-premises Active Directory environment, you install and configure Azure Active Directory Connect (AAD Connect) to synchronize the environment with Azure Active Directory Premium.

You specify a service account in the on-premises Active Directory for Azure Active Directory Connect and, thus Azure Active Directory Sync. This account is known as the Active Directory Management Agent service account. You enable password write-back in the wizard.

After successful synchronization(s), you enable the Self-service Password Reset (SSPR) functionality in the Azure Active Directory portal.

The issue

Now, when people with on-premises Active Directory accounts try to perform a password reset through the MyApps portal, you receive an error:

Your request could not be processed

We’re sorry, but we cannot reset your password at this time. Unfortunately, this is due to an unrecoverable issue with your account configuration, so trying again won’t work. Please contact your admin to reset your password for you.

However, the Change password functionality in the MyApps portal does change the password successfully.

Additionally, when you check the Azure Active Directory reports via Azure, Active Directory, then your directory name, Reports, and then Password Reset Activity, you see a line stating:

We encountered a problem while resetting the user’s on-premises password. Check your sync machine’s event log.

On the Windows installation with Azure Active Directory Sync, in the application log in Event Viewer (eventvwr.msc) you find error events with event ID 31003 and specific text ‘Access Denied’.

The solution

This issue occurs because the service account in the on-premises Active Directory environment for Azure Active Directory Sync does not have the appropriate rights to reset and/or change the password for the account, belonging to the person trying to reset his/her password.

To correct this issue, perform these steps:

• Log on to an Active Directory Domain Controller, using a domain account with administrative permissions.
• Open Active Directory Users and Computers (dsa.msc).
• In the View Menu option, make sure Advanced Features is turned on.
• In the left panel, right click the object that represents the root of the domain.

Note:
Alternatively, choose the Organizational Unit (OU), containing the user accounts, belonging to persons experiencing the above issue.

• Click on the Security tab.
• Then click Advanced.
• On the Permissions tab, click Add.
• Select the account you want to give permissions to (this is the same account that was specified while setting up sync for that forest).
• In the drop down on the top, select Descendent User objects.
• In the Permission Entry dialog box that shows up, check the box for Reset Password and Change Password.
• Then click Apply/Ok through all the open dialog boxes.
• Close the Active Directory Users and Computers MMC Snap-in.
• Log off.

Concluding

You experience the ‘Your request could not be completed’ error , when a person tries to use the Azure Self-service Password Reset (SSPR) functionality and the Active Directory Management Agent does not have the Reset Password and/or Change Password rights to the account in the on-premises Active Directory environment.

The speaker season for 2015 is about to start. Of course, we’re kicking off with the Nordic Infrastructure Conference (NICConf) in Oslo, Norway. I’ll be copresenting two sessions with Raymond Comvalius at NIC’s 4th edition. As our session on Experts Live 2014 on the pitfalls when virtualizing Domain Controllers was a huge success, we will be delivering that session in a slightly updated format in Oslo. Also, as we’ve been digging into the latest build of Windows 10, we found some interesting tidbits we want to share.

About the Nordic Infrastructure Conference

The Nordic Infrastructure Conference (NICConf) is a premier event for IT Pros, offering broad technical education on Microsoft and 3rd party products, tools and services. This two-day event will focus on deep dives and practical knowledge.

NICConf will be hosted for the third time on Februari 12 and February 13, 2015. It’s location will be the Oslo Spektrum in the heart of Oslo, Norway.

NIC attracts the top speakers on its topics, Cloud Services, Systems Management, Server and Client, Unified Communications and Virtualization. No wonder, you’ll run into Alex de Jong, Sami Laiho, Andy Malone, Johan Arwidmark, Morgan Simonsen, John Craddock, Peter de Tender, Mikael Nyström, Aleksander Nikolic, Magnus Björk and Paula Januszkiewicz. Keynoting this year is Mark Minassi on No Sunny Days, but That’s Not So Bad: Clouds in 2015.

About our sessions

During NIC 4th Edition, Raymond and I will be delivering two presentations in the Virtualization track:

Running highly-sensitive Domain Controllers on Hyper-V and Azure

Friday February 13, 2015 9AM – 10AM Room 4

Active Directory Domain Controllers hold the keys to your kingdom. So how do you virtualize these castles of identity, without compromising on the requirements of your organization? In this session, Raymond Comvalius (Windows Expert – IT Pro MVP) and Sander Berkouwer (Directory Services MVP) give best practices for hardening, backing up, restoring and managing virtualized Domain Controllers. In their real-time demos, they’ll integrate with environments like yours, showing you the real world possibilities and impossibilities.

Join the virtualized!

Friday February 13, 2015 1:40PM – 2:40PM Room 4

Windows 10 brings a huge change when it comes to joining the trusted environment. How does the virtualization of the join change the security paradigm that we got so used to over the past decade. What happens to single sign-on and management of the workplace? Where are the new boundaries of the virtualized territory? How did Windows 10 just change the landscape. You’ll be surprised about the new opportunities! Come join Raymond Comvalius (Windows Expert – IT Pro MVP) and Sander Berkouwer (Directory Services MVP) to learn about the new features that Windows 10 and Windows Azure are bringing.

Don’t miss out on NIC! Register here.

Previously, I discussed the differences and commonalities for WorkPlace Join and Domain Join. Today, I would like to discuss the differences and commonalities between two very similar and yet widely different remote access technologies: WorkPlace Join and DirectAccess.

Let’s start with the characteristics these two technologies have in common:

1. WorkPlace Join and DirectAccess are both remote access methods to gain access to functionality on internal networks, using Microsoft products.
2. WorkPlace Join and DirectAccess are both built-in into the latest version of Windows Server.
3. WorkPlace Join and DirectAccess both do not require additional configuration or programs for end users to gain access to organizational resources.
4. WorkPlace Join and DirectAccess both offer access to organizational resources supported by Single Sign-on.

Although WorkPlace Join and DirectAccess have a lot in common, they also differ widely:

DirectAccess follows a more secure model

DirectAccess is a technology, where Windows Servers, configured as DirectAccess servers, allow DirectAccess-enabled Windows devices to automatically connect to an organizations internal network based on tunneling. The tunneling technology is often seen in Virtual Private Networking (VPN) solutions. DirectAccess tunnels are automatically setup after a device connects to the Internet and are secured using IPSec. Traffic inside DirectAccess tunnels are encapsulated IPv6-based network packets into IPv4-based network packets.

WorkPlace Join, on the other hand, has a less strict model. Once a device is configured as a WorkPlace-joined device, access to corporate resources is based on authentication (and authorization) via Active Directory Federation Services (AD FS) and traffic flows as HTTP-based packets, ‘secured’ by SSL/TLS encryption. The claims-based AD FS authentication is based on open standards, like SAML and Oauth.

DirectAccess offers more on-premises functionality

DirectAccess offers seamless access to organizational resources. When DirectAccess functions, end users may have access to all organizational resources, even based on short hostnames for servers. Of course, access can be limited to only certain hosts on the network, certain network traffic and certain networks.

WorkPlace Join is confined to claims-aware applications. When WorkPlace Join is used in scenarios with Web Application Proxies, it also allows access to Kerberos-enabled web applications, that are able to offer Kerberos Constrained Delegation (KCD).

DirectAccess offers built-in management

In DirectAccess implementations Network Access Protection (NAP) can be implemented to automatically detect and remediate deviations of the corporate policy. For instance, when a device does not have the latest anti-malware update, it can be placed in a remediation network to update, before it gains access.

Since DirectAccess basically expands the internal corporate network on a per-device basis, it allows for Group Policy-based device management, the way administrators have been used to for the last decade-and-a-half. Group Policy can even be used to deploy DirectAccess to devices located on-premises and through Offline Domain Join.

WorkPlace Join, on the other hand, does not offer strong built-in management. In scenarios with WorkPlace Join, authentication and authorization may be governed using Issuance Authorization Rules, but these, for instance, won’t allow you to remediate outdated anti-malware definitions.

However, with the addition of a Mobile Device Management (MDM) solution, like Microsoft’s System Center Configuration Manager (ConfigMgr), and its IsManaged claimtype flowing back into the same Issuance Authorization Rules in AD FS, these scenarios are easily achieved too.

WorkPlace Join is available more widely

DirectAccess is supported on devices running Windows 7 Ultimate, Windows 7 Enterprise, Windows 8 Enterprise and Windows 8.1 Enterprise. Basically, this limits DirectAccess to organizations with Software Assurance on their Windows volume licenses.

WorkPlace Join is available on Windows 7, Windows 8.1, and iOS.

Note:
WorkPlace Join is not available on Windows 8. (8.0 RTM)

Note:
WorkPlace Join on Windows 7 requires a separate download.

WorkPlace Join offers more cloud interoperability

Where DirectAccess is focused on remote access to the internal network (and perhaps is the best technology at it), WorkPlace Join is not confined to mere seamless yet secure access to applications that live on-premises.

WorkPlace Join is just as easily used to provide Single Sign-on to on-premises apps, as it is to provide Single Sign-on to cloud-based apps. WorkPlace Join may be the bridge technology to enabling seamless yet secure access in a Software-as-a-Service world.

Concluding

DirectAccess offers a convenient method to expand the internal network seamlessly to a remote device, allowing secure remote access to any kind of app or service on the internal network.

Although WorkPlace Join offers seamless access to only claims-aware resources, it is available on more platforms and based on open standards. As organizations continue to move towards Software-as-a-Service and web-based software, WorkPlace Join becomes the more appealing remote access technology.

Related blogposts

WorkPlace Join vs. Domain Join
New features in AD DS in Windows Server 2012 R2, Part 5: WorkPlace Join and Registered Device objects
KnowledgeBase: DirectAccess server cannot ping a DNS Server or a Domain Controller in Windows Server 2012

For its February 2015 Patch Tuesday on Tuesday February 10, Microsoft has released two security bulletin to address issues in Group Policy that would allow an attacker using a Man-in-the-middle (MitM) approach to bypass security policies, by forging packets sent by Domain Controllers.

The situation

In my organizations, Group Policies are used to centrally configure settings, printers, drivers and software.

These settings and preferences can be applied locally using gpedit.msc and secpol.msc. However, settings and preferences can also be set centrally using Active Directory on the site, domain and even granularly per Organizational Unit (OU). Tools used are gpmc.msc and, again, gpedit.msc. For non-domain-joined devices, the Security Configuration Manager (SCM) Solutions Accelerator and Offline Domain Join (ODJ) can be used to configure settings.

Responsible for applying security settings from both the local computer security policy and Group Policy objects on a device, is the Security Configuration Engine. It receives and applies the policy data in policy files and makes sure they get applied.

The issues

Multiple issues exist with Group Policy that can be used to cause undesired behavior:

MS15-011

First, an issue has been identified in the way how the Security Configuration Engine picks up Group Policy.

By default, the Security Configuration Engine on domain-joined devices automatically downloads security settings in updated Group Policy Objects (GPOs) from SYSVOL, which the scecli.dll part of the Security Configuration Engine discovers and accesses using the Universal Naming Convention (UNC) paths.

An attacker may spoof, tamper with, or redirect communications between the UNC provider and devices, and subsequently may be able to cause Group Policy to execute his or her programs or scripts.

MS15-014

A second vulnerability exists whereby Group Policy could fail to retrieve valid security policy settings, because one or more Security Configuration Engine configuration files (gpttmpl.inf per Group Policy Object, configured with security settings) are corrupted or otherwise unreadable when they are interpreted by the scesrv.dll part of the Security Configuration Engine.

An attacker can achieve this by modifying the responses sent by Active Directory Domain Controllers with a Man-in-the-Middle (MitM) approach. The behavior of the Group Policy Security Configuration Engine, then, is to apply default, potentially less secure, group policy settings, instead of the domain-configured settings.

The solutions

MS15-011

Microsoft introduces UNC Hardened Access to address this vulnerability. This is a new Windows feature, that provides mitigations against Man-in-the-Middle attacks for any UNC paths that host executable programs, script files or files that control security policies and improves the protection and handling of data when Windows-based devices access UNC paths.

UNC Hardened Access is available  as KB3000483. It is accompanied by KB30004375, which is installed transparently with KB3000483. It is rated as a critical update for all supported versions of Windows and Windows Server. An update is currently not available for Windows Server 2003.

MS15-014

An update is available from Microsoft that address this vulnerability, by correcting how Group Policy settings are applied when a Group Policy Security Configuration Engine policy file is corrupted or otherwise unreadable.

This update is available as KB3004361 and is rated as an important update for all supported versions of Windows and Windows Server. An update is also available for Windows Server 2003.

Call to Action

MS15-011

To introduce UNC Hardened Access and protect against UNC-based Man-in-the-Middle (MitM) attacks, install KB3000483. Then, in a Group Policy scoped for devices with the update, configure UNC Hardened Access in Computer Configuration, Administrative Templates, Network, Network Provider. Enable the Hardened UNC Path setting.

Behind the Show… button, define shares and their UNC Hardened Access behaviors:

RequireMutualAuthentication enforces Kerberos-based mutual authentication. RequireIntegrity and RequirePrivacy turn on SMB Signing.

Test both the update and the configuration in a test environment, to assess the risk and possible impact on your production environment and then, roll out this update to all devices within scope. After that, configure the additional Group Policy Settings.

MS15-014

Microsoft has not identified any mitigating factors or workarounds, so I urge you to install KB3004361 in a test environment as soon as possible, assess the risk and possible impact on your production environment and then, roll out this update to all devices within the Active Directory environment.

Related Knowledgebase articles

3000483 MS15-011: Vulnerability in Group Policy could allow remote code execution
3004361 MS15-014: Vulnerability in Group Policy could allow security feature bypass

Further reading

MS15-011 Vulnerability in Group Policy Could Allow Remote Code Execution
MS15-014 Vulnerability in Group Policy Could Allow Security Feature Bypass
MS15-011 & MS15-014: Hardening Group Policy
Security Configuration Engine Architecture

Windows 8.1 and Windows Server 2012 R2 introduced an awesome new feature, called Include command line in process creation events, a Group Policy setting that expands the Audit Process Creation policy so events in Event Viewer (eventvwr.msc) include the actual commands issued.

Last week, Microsoft introduced an update to Windows 7, Windows 8, Windows Server 2008 R2 and Windows Server 2012 to introduce the same feature to these older Windows and Windows Server versions.

It’s as good as any reason to look into it.

The situation

In many Microsoft-centered networking infrastructure environment, it is hard to troubleshoot, monitor and/or investigate security-related issues.

Audit process creation

In many of these cases, the Audit Process Creation Group Policy setting (in Computer Configuration, Policies, Windows Settings, Security Settings, Advanced Audit Configuration, Detailed Tracking is enabled for specific systems (It is not enabled by default):

This setting determines whether the Operating System generates audit events when a process is created.  Event-IDs 4688 are generated and logged in the Windows Security log.

What’s new

Now, after you apply KB3004375 to Windows 7, Windows 8, Windows Server 2008 R2 and/or Windows Server 2012, you see a new Group Policy setting in Computer Configuration, Policies, Administrative Templates, System, Audit Process Creation, named Include command line in process creation events:

When you enable this setting, the events in Event Viewer (eventvwr.msc) get expanded with the Process Command Line: information. The two screenshots below, made on a Windows Server 2012 R2 installation, show two events in Event Viewer with Event ID 4688. The left event was logged before the Include command line in process creation events Group Policy setting was enabled. The screenshot on the right shows the event with the setting enabled:

Concluding

Command line auditing can be a super useful tool for troubleshooting, monitoring and/or investigating security-related issues. It might be the missing piece of the puzzle on your Windows 7, Windows 8, Windows Server 2008 R2 and/or Windows Server 2012 installations. If it is, don’t hesitate to roll out KB3004375 (after testing).

Running Windows 8.1 and Windows Server 2012 R2 and in need for some command line auditing intelligence? Simply enable it.

Related Knowledgebase articles

3004375 Microsoft security advisory: Update to improve Windows command-line auditing: February 10, 2015

Further reading

Audit Process Creation
Security Auditing
Advanced Security Audit Policy Step-by-Step Guide
Best Practices for Securing Active Directory
How to Create an Audit Plan
Best Practices in Internal Audit
WinSecWiki – Process Creation

Raymond and I delivered two sessions at the 4th edition of the Nordic Infrastructure Conference (NIC) in Oslo, Norway.

This was my second time on stage for NIC and Raymond’s third time. Just like last year, we flew from Amsterdam Schiphol Airport (AMS) to Oslo Gardermoen Lufthavn (OSL) and upon arrival of our 2-hour flight, we took the FlyToGet to get to Oslo’s SentralStasjion within half an hour.

We were just in time to order at the gathering of MVPs at T.G.I. Fridays and put our bags in a corner so we could catch up with our friends Mark, Alex, John, Sami, Peter and Adnan.

After dinner we went outside, turned the corner and arrived at our hotel, the Clarion Christiania. Raymond and I were booked for a shared room, which was convenient for us to prepare our sessions further.

The next morning, after breakfast, we headed for the Oslo Spektrum, which is almost a straight walk of around 600m. Luckily, it wasn’t cold in Oslo, this time around. Well… just as cold as home, I suppose.

We sat down for the introduction by Michael Jacobs (General Manager for Microsoft Norway) and the Keynote No Sunny Days, but That’s Not So Bad: Clouds in 2015 by Mark Minasi.

Mark told truly wonderful stories. His economists “Half a Pizza” view on cloud nailed it. His shout-out to the speakers was well appreciated.

Raymond and I were not scheduled to present on Thursday, so we had plenty of time to catch up and share experiences. In between playing with unannounced and undocumented features in the Technical Previews of Windows 10 and Windows Server 2016, we even had time to see some sessions, like Sami’s What’s New in Windows 10.

At the end of the day, we stood and watched the Ask the Experts Panel discussion and then stayed a little for the party, featuring British cover band, The Tide. Not for long though, because we were still preparing our awesome demos. We asked Aleksandar to join us for his WMI expertise:

The next morning, Raymond and I were scheduled for the 9AM session on Running highly-sensitive Domain Controllers on Hyper-V and Azure. This is an awesome session. We had great fun on stage and the evaluations proved the audience enjoyed it as much as we did.

Our next session Join the Virtualized! was scheduled for 1:40PM, so in the time between the two sessions we tweaked the presentation a bit and wrote the demo sheet.

Some of the speakers joined in on our session and had a good time. They asked for the slides, so perhaps you’ll find them presenting WorkPlace Join and Cloud Join in a place near you very soon.

Thank you!

Related blogposts

I will be speaking at Nordic Infrastructure Conference 4th Edition
Pictures of the 2014 Nordic Infrastructure Conference
I will be speaking at NIC 2014

Active Directory Domain Controllers hold the keys to your kingdom. So how do you virtualize these castles of identity, without compromising on the requirements of your organization? In this session, Raymond Comvalius (Windows Expert – IT Pro MVP) and Sander Berkouwer (Directory Services MVP) give best practices for hardening, backing up, restoring and managing virtualized Domain Controllers. In their real-time demos, they’ll integrate with environments like yours, showing you the real world possibilities and impossibilities.

This session was presented and recorded at Nordic Infrastructure Conference (NIC) 4th Edition in Oslo, Norway on Friday February 13, 2015 between 9AM and 10AM as part of the Virtualization track. It was the first session of Day 2 at NIC.

Related blogposts

Pictures of the 2015 Nordic Infrastructure Conference
I will be speaking at Nordic Infrastructure Conference 4th Edition
Pictures of the 2014 Nordic Infrastructure Conference
I will be speaking at NIC 2014

Windows 10 brings a huge change when it comes to joining the trusted environment. How does the virtualization of the join change the security paradigm that we got so used to over the past decade. What happens to single sign-on and management of the workplace? Where are the new boundaries of the virtualized territory? How did Windows 10 just change the landscape. You’ll be surprised about the new opportunities!

This session was presented and recorded at Nordic Infrastructure Conference (NIC) 4th Edition in Oslo on Friday February 13, 2015 between 1:40PM and 2:40PM as part of the Virtualization track.

Related blogposts

Pictures of the 2015 Nordic Infrastructure Conference
I will be speaking at Nordic Infrastructure Conference 4th Edition
Pictures of the 2014 Nordic Infrastructure Conference
I will be speaking at NIC 2014

I’m seeing lots of people adopting the Technical Previews of Windows 10 and Windows Server 2016 around me, and running Virtual Machines (VMs) on the built-in Hyper-V hypervisor seems to be among the scenarios tested thoroughly.

Microsoft has issued a KnowledgeBase article detailing an update in the Integration Components (ICs) for Windows 7, Windows 8.1, Windows Server 2008 R2 and Windows Server 2012 R2 installations running as Virtual Machines on top of  Windows 10 and Windows Server 10.

Note:
Although Microsoft has not ended support on Windows 8 (Windows 8.0 RTM), they are not releasing this update for Windows 8 or Windows Server 2012. Support on Windows 8.0 ends on January 12, 2016 (24 months after the general availability of Windows 8.1)

Issues addressed

This update addresses these issues:

• Support for backing up virtual machines (VMs) that use shared virtual hard disk (VHDX).
• Better usage of Volume Shadow Copy Service (VSS) requestor.
• Provider flags not to require Auto-recovery phase.
• Stability and reliability improvements.

KB3037623

The updated Integration Components are part of KB3037623.

To install this update, you must have April 2014 update rollup for Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 (2919355) installed in Windows 8.1 or Windows Server 2012 R2. Or, install Service Pack 1 for Windows 7 or Windows Server 2008 R2.

This update replaces KB3004908 for Windows 7, Windows 8.1, Windows Server 2008 R2 and Windows Server 2012 R2 installations running as Virtual Machines on top of Windows 10 and Windows Server 10.

Concluding

This is a pretty nice update for anyone testing Hyper-V with downlevel Operating Systems in Virtual Machines in Hyper-V on Windows 10 Technical Preview and Windows Server 10 Technical Preview.

Enjoy!

Related KnowledgeBase articles

3004908 Hyper-V integration components for Windows virtual machines that are running on Windows Technical Preview hosts
3037623 Hyper-V backup integration components for VMs on Windows 10 Technical Preview or Windows Server Technical Preview hosts

In recent days, a new attack vector, called the FREAK technique, that facilitates SSL/TLS Man-in-the-Middle (MitM) attacks was in the news. Microsoft has confirmed that its implementations of SChannel in Windows and Windows Server are also vulnerable to this attack method and has released updates for all its supported Operating Systems.

About FREAK

On Tuesday, March 3, 2015, researchers announced a new way to more easily perform Man-in-the-Middle attacks using SSL/TLS vulnerability dubbed the ‘Factoring RSA Export Keys’ or FREAK technique. This way they could intercept HTTPS connections between vulnerable clients and servers and force them to use weakened encryption, which the attacker can break to steal or manipulate sensitive data.

The FREAK attack is possible when a vulnerable browser connects to a susceptible web server – a server that accepts EXPORT-grade encryption.

This EXPORT-grade encryption was issued by the U.S. government in the nineties, to avoid export of hard encryption methods. Instead, only the weaker EXPORT-grade encryption methods were allowed to be exported:

• TLS_RSA_EXPORT_WITH_RC4_40_MD5
• TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
• TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
• TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA
• TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
• TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
• TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
• TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
• TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
• TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA
• TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA
• TLS_KRB5_EXPORT_WITH_RC4_40_SHA
• TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5
• TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5
• TLS_KRB5_EXPORT_WITH_RC4_40_MD5

Rumor has it, that this enabled the U.S. government to continue spying on everyone.

Today, these export restrictions no longer apply and we shouldn’t be using or offering these weak encryption methods. But alas, by default, we still do for (m)any legacy software that needs it. Since it’s still available by default in client systems, these systems can be ‘tricked’ into accepting the EXPORT-grade RSA keys with shorter key lengths (512 bits) than the originally negotiated key lengths (1024bits and up), facilitated by the publicly disclosed FREAK technique.

Although many Operating Systems are vulnerable, in Windows and Windows Server Operating System, this vulnerability is in Secure Channel (Schannel).

KB3046049

This security update resolves the above vulnerability in Microsoft Windows and Windows Server, when using the publicly disclosed FREAK technique.

Affected Operating Systems

All Windows and Windows Server Operating Systems currently in support by Microsoft are affected by the vulnerability. Therefore, Microsoft has released a security update to resolve the vulnerability for:

• Windows Vista with Service Pack 2
• Windows Vista x64 with Service Pack 2
• Windows 7 with Service Pack 1
• Windows 7 x64 with Service Pack 1
• Windows 8
• Windows 8 x64
• Windows 8.1
• Windows 8.1 x64
• Windows RT
• Windows RT 8.1
• Windows Server 2003 with Service Pack 2
• Windows Server 2003 x64 with Service Pack 2
• Windows Server 2003 for Itanium-based Systems with Service Pack 2
• Windows Server 2008 with Service Pack 2
• Windows Server 2008 x64 with Service Pack 2
• Windows Server 2008 for Itanium-based Systems with Service Pack 2
• Windows Server 2008 R2
• Windows Server 2008 R2 for Itanium-based Systems
• Windows Server 2012
• Windows Server 2012 R2

The update is also applicable to Server Core installations, although not many admins would actually use these machines for web browsing…

Problem with previous workaround

If you applied the workaround that was documented in Microsoft Security Advisory 3046015, some internet services may no longer work. To avoid this issue, undo the workaround before you install this security update. To undo the workaround, follow these steps:

1. Start the Group Policy Object Editors. To do this, type gpedit.msc at a command prompt, and then press Enter.
2. Expand Computer Configuration, Administrative Templates, Network, and then click SSL Configuration Settings.
3. Under SSL Configuration Settings, double-click SSL Cipher Suite Order.
4. In the SSL Cipher Suite Order window, select Disabled, and then click OK.
5. Close the Group Policy Object Editor, and then restart your computer.

Concluding

Although Microsoft has identified a workaround, I urge you to install KB3046049 in a test environment as soon as possible, assess the risk and possible impact on your production environment and then, roll out this update to all devices within the networking environment.

For devices from other manufactures, like Google Android and Apple iOS-based devices, please refer to the websites of these manufacturers for updates addressing the SSL/TLS RSA-to-RSA_EXPORT vulnerability.

Additionally, when you run web servers with SSL/TLS-secured web sites, please configure them to no longer accept any of the encryption methods, or cipher suites, listed above.

Further reading

Microsoft Security Bulletin MS15-031 – Important
Microsoft Security Advisory 3046015
FREAK Attack: The Chickens of ‘90s Crypto Restriction Come Home to Roost
“FREAK” flaw in Android and Apple devices cripples HTTPS crypto protection
Attack of the week: FREAK (or ‘factoring the NSA for fun and profit’)
Microsoft: All Windows versions Vulnerable to FREAK Vulnerability
Microsoft warns Windows PCs also vulnerable to ‘Freak’ attacks
US Cert – FREAK SSL/TLS Vulnerability

Related KnowledgeBase articles

3046049 MS15-031: Vulnerability in SChannel could allow security feature bypass: March 10, 2015

While this has proven to be n interesting month with the Factoring RSA Export Keys (FREAK) technique affecting a plethora of Operating Systems, Microsoft has also issued an update to address a privately reported vulnerability in NETLOGON.

About the vulnerability

A spoofing vulnerability exists in NETLOGON that is caused when the NETLOGON service improperly establishes a secure communications channel belonging to a different machine with a spoofed computer name. To successfully exploit this vulnerability, an attacker would first have to be logged on to a domain-joined device and be able to observe network traffic. An attacker could then run a specially crafted application that could establish a secure channel connection belonging to a different device. An attacker may be able to use the established secure channel to obtain session-related information for the actual secure channel of the spoofed computer.

Domain-joined workstations and servers are primarily at risk from this vulnerability.

KB3002657

Update KB3002657 addresses the vulnerability by modifying the way that NETLOGON handles establishing secure channels.

This update is applicable on Windows Server installations configured as Active Directory Domain Controllers. It is suggested, however, that the update be applied to all affected Windows Server so that they are protected if they are promoted to Domain Controllers in the future.

Affected Operating Systems

All Windows and Windows Server Operating Systems currently in support by Microsoft are affected by the vulnerability. Therefore, Microsoft has released a security update to resolve the vulnerability for:

• Windows Vista with Service Pack 2
• Windows Vista x64 with Service Pack 2
• Windows 7 with Service Pack 1
• Windows 7 x64 with Service Pack 1
• Windows 8
• Windows 8 x64
• Windows 8.1
• Windows 8.1 x64
• Windows RT
• Windows RT 8.1
• Windows Server 2003 with Service Pack 2
• Windows Server 2003 x64 with Service Pack 2
• Windows Server 2003 for Itanium-based Systems with Service Pack 2
• Windows Server 2008 with Service Pack 2
• Windows Server 2008 x64 with Service Pack 2
• Windows Server 2008 for Itanium-based Systems with Service Pack 2
• Windows Server 2008 R2
• Windows Server 2008 R2 for Itanium-based Systems
• Windows Server 2012
• Windows Server 2012 R2

Call to action

Microsoft has not identified any mitigating factors or workarounds, so I urge you to install KB3002657 on Domain Controllers in a test environment as soon as possible, assess the risk and possible impact on your production environment and then, roll out this update to Domain Controllers and Domain Controller candidates in the production environment.

Known issues

After you install this security update, you cannot access data on EMC Isilon clusters.

Related knowledgebase articles

3002657 MS15-027: Vulnerability in NETLOGON could allow spoofing: March 10, 2015
Microsoft Security Bulletin MS15-027 – Important

Yesterday, Microsoft issued a new Knowledgebase article for the brave people, like you ant me, that run Windows 10 Technical Preview, build 10041. It fixes a bug where the user name and password box might not appear on the sign-in screen.

The situation

You run the 32bit (x86) version of Windows 10 Technical Preview build 10041 or the 64bit (x86-64) version of Windows 10 Technical Preview build 10041 on a device, or you run Windows 10 Technical Preview build 9926 configured in the slow update ring and you update to Windows 10 Technical Preview build 10041 this week.

You start the device and want to log on.

The issue

When attempting to sign into Windows 10 Technical Preview Build 10041, the user name and password box might not appear on the sign-in screen.

The solution

The solution is to install update corresponding with KB3050653 from Windows Update or from Windows Server Update Services (WSUS).

When you look at the available updates for Windows 10 Technical Preview this month,  in either Windows Update or Windows Server Update Services, you’ll notice this update accompanies three other updates:

• KB3046049 Security update to address vulnerabilities in SChannel (aka FREAK patch) 
• KB3050279 Update to address graphics artifacts and increase system reliability
• KB3050284 March Update with fixes for various issues

Please install these updates to enjoy your Technical Preview experience to the fullest.

Further reading

Windows 10 10041 preview build gets bug fixes, rolling out to Slow ring members
Security Thoughts: Vulnerability in SChannel allows security bypassing (Important, FREAK, MS15-031, CVE-2015-1637)

Related knowledgebase articles

3050653 The user name and password box might not appear on the sign-in screen in Windows 10 Technical Preview
3046049 MS15-031: Vulnerability in SChannel could allow security feature bypass: March 10, 2015
3050279 Microsoft Surface Hub Technical Preview – March Update is available
3050284 Windows Technical Preview March Update (KB3050284) is available