Azure Active Directory is Microsoft’s Identity Management-as-a-Service solution, offering seamless access, easy collaboration, efficiency in IT processes and improved security and compliance. In its Release Notes for Azure Active Directory, Microsoft communicated the following new functionality for Azure Active Directory for November 2017:

What’s Planned

Retiring ACS

Service Category: ACS
Product Capability: Access Control Service

Microsoft Azure Active Directory Access Control (also known as Access Control Service or ACS) will be retired in late 2018. Further information, including a detailed schedule & high-level migration guidance, will be provided in the next few weeks. In the meantime, leave comments on this page with any questions regarding ACS, and a member of our team will help to answer.

Restrict browser access to the Intune managed browser

Service Category: Conditional Access
Product Capability: Identity Security & Protection

With this behavior, you will be able to restrict browser access to Office 365 and other Azure AD-connected cloud apps using the Intune Managed Browser as an approved app. Today, access is blocked when using this condition. When the preview of this behavior is available, all access will require the use of the managed browser application.

New approved client apps for Azure AD app-based conditional access

Service Category: Conditional Access
Product Capability: Identity Security & Protection

The following apps are planned to be added to the list of approved client apps:

• Microsoft Kaizala
• Microsoft StaffHub

What’s New

Terms of Use support for multiple languages

Service Category: Terms of Use (ToU)
Product Capability: Governance/Compliance

Administrators can now create new terms of use (ToU) that contains multiple Portable Document Format (PDF) documents. You can tag these documents with a corresponding language. Users that fall in scope are shown the PDF with the matching language based on their preferences. If there is no match, the default language is shown.

Real-time password write-back client status

Service Category: Self-service Password Reset (SSPR)
Product Capability: User Authentication

You can now review the status of your on-premises password write-back client. This option is available in the On-premises integration section of the Password reset blade in the Azure Portal.

Azure AD app-based conditional access

Service Category: Azure AD
Product Capability: Identity Security & Protection

You can now restrict access to Office 365 and other Azure AD-connected cloud apps to approved client apps that support Intune App Protection policies using Azure AD app-based conditional access. Intune app protection policies are used to configure and protect company data on these client applications.

By combining app-based with device-based conditional access policies, you have the flexibility to protect data for personal and company devices.

Managing Azure AD devices in the Azure portal

Service Category: Device Registration and Management
Product Capability: Identity Security & Protection

You can now find all your devices connected to Azure AD and the device-related activities in one place. There is a new administration experience to manage all your device identities and settings in the Azure portal.

Support for macOS as device platform for Azure AD conditional access

Service Category: Conditional Access
Product Capability: Identity Security & Protection

You can now include (or exclude) macOS as device platform condition in your Azure AD conditional access policy. With the addition of macOS to the supported device platforms, you can:

• Enroll and manage MacOS devices using Intune
• Ensure MacOS devices adhere to your organization’s compliance policies defined in Intune
• Restrict access to applications in Azure AD to only compliance MacOS devices

NPS Extension for Azure MFA

Service Category: MFA
Product Capability: User Authentication

The Network Policy Server (NPS) extension for Azure MFA adds cloud-based MFA capabilities to your authentication infrastructure using your existing servers. With the NPS extension, you can add phone call, text message, or phone app verification to your existing authentication flow without having to install, configure, and maintain new servers.

Restore or permanently remove deleted users

Service Category: User Management
Product Capability: Directory

In the Azure AD admin center, you can now:

• Restore a deleted user
• Permanently delete a user

You are no longer required to use PowerShell to this purpose.

What’s Changed

New approved client apps for Azure AD app-based conditional access

Service Category: Conditional Access
Product Capability: Identity Security & Protection

The following apps have been added to the list of approved client apps:

• Microsoft Planner
• Microsoft Azure Information Protection

Ability to ‘OR’ between controls in a conditional access policy

Service Category: Conditional Access
Product Capability: Identity Security & Protection

The ability to ‘OR’ (Require one of the selected controls) conditional access controls has been released. This feature enables you to create policies with an OR between access controls. For example, you can use this feature to create a policy that requires a user to sign in using multi-factor authentication OR to be on a compliant device.

Aggregation of real-time risk events

Service Category: Identity Protection
Product Capability: Identity Security & Protection

To improve your administration experience, in Azure AD Identity Protection, all real-time risk events that were originated from the same IP address on a given day are now aggregated for each risk event type. This change limits the volume of risk events shown without any change in the user security.

The underlying real-time detection works each time the user logs in. If you have a sign-in risk security policy setup to MFA or block access, it is still triggered during each risky sign-in.

It feels like only a couple of months ago, but actually only half a year ago, Microsoft released a version of Azure AD Connect that fixed a critical security vulnerability related to password resets. Yesterday, Microsoft released a new version of Azure AD Connect that does the same thing, but actually in a different feature.

The vulnerability was reported to Microsoft by Preempt, who also disclosed information on the vulnerability on their own blog. Their information details stealthy privileged accounts, the adminCount attribute and how the way Microsoft setup the sync account in Active Directory Domain Services (AD DS) when you use Express Settings in Azure AD Connect.

Microsoft responded in three complementing ways:

1. Microsoft issued a security advisory.
2. Microsoft released a script to set the right attributes for the sync account.
3. Microsoft released a new version of Azure AD Connect.

This way, organizations can secure their Hybrid Identity setup, and check if any damage has been done.

Escalation of Privilege vulnerability

The vulnerability in the way Azure AD Connect provisions a service account in Active Directory Domain Services (AD DS) finds its source in the fact that the adminCount property isn’t set on the account, and, subsequently, the account is not protected by the AdminSDHolder process. This specific process makes sure that sensitive accounts cannot be configured to have their password reset right delegated, among other sensitive operations.

Typically, the adminCount attribute is set to accounts that become a member of the Domain Administrators and Enterprise Administrators groups, but also to other well-known groups like Account Operators and Print Operators.

Is your Hybrid Identity setup vulnerable?

Of course, the first question you might ask yourself is if your Hybrid Identity setup is vulnerable or not. To answer this question, we first have to look at the two different ways Azure AD Connect can be installed.

Express Settings and Custom Settings

Many customers have opted to install Azure AD Connect with Express Settings. This four-click setup has a couple of advantages to the more elaborate Custom Settings installation options:

The fourth column depicts whether you can change the setting after initial installation and subsequent configuration runs. Your mileage may vary on the outcome, though.

As you can see, the Custom Settings installation option allows you to optionally reuse a (managed) service account. This option was added to Azure AD Connect version 1.1.443.0, back in March 2017.

In two scenarios, the vulnerability may exist in your organization’s Hybrid Identity setup:

1. You’ve setup Azure AD Connect using the Express Settings installation option.
2. You’ve setup Azure AD Connect using the Custom Settings installation option, but you have not opted to reuse a pre-created service account, managed service account (MSA) or group managed service account (gMSA).

How do I fix it?

In my experience, many setups are vulnerable. That’s OK, because there are two easy ways to fix it:

• Install Azure AD Connect new, using version 1.1.654.0, or up.
  This scenario is particularly useful for organizations that have not yet gone to production with their Hybrid Identity setup, are still using DirSync, still using Azure AD Sync or are using a deprecated version of Azure AD Connect. Additionally, organizations that may want to benefit from the use of a (g)MSA for Azure AD Connect should choose this scenario, when they want to get rid of the service account, based on a normal user object.
• Run the PowerShell script that Microsoft has made available.
  This scenario is useful for organizations that run Azure AD Connect, and are happy with their configuration and want nothing else to change, except for the vulnerability to disappear.

What does the PowerShell script do?

The PowerShell script tightens the settings on the service account to remove the vulnerability to the below values:

• Disable inheritance on the specified object
• Remove all ACEs on the specific object, except ACEs specific to SELF. We want to keep the default permissions intact when it comes to SELF.
• Assign specific permissions.

How do I run the script?

Since the script is on the Microsoft PowerShell Gallery, it can be easily run, by using the following two lines of PowerShell:

New-Item “C:\Program Files\WindowsPowerShell\Modules\ADSyncConfig” -Type Directory

Copy-Item “C:\Users\administrator\downloads\adsyncconfig.psm1″ -Destination “C:\Program Files\WindowsPowerShell\Modules\ADSyncConfig\ADSyncConfig.psm1” -Force

New-ModuleManifest -Path  “C:\Program Files\WindowsPowerShell\Modules\ADSyncConfig\ADSyncConfig.psd1” -RootModule ADSyncConfig.psm1

Import-module ADSyncConfig

Set-ADSyncRestrictedPermissions -ObjectDN “CN=AAD_eabcdefg123,CN=Users,DC=dirteam,DC=com” -Credential $credential

Assuming you’d download the PowerShell Module and storing the download in the Downloads folder, you’d change the grey fields, to make $ObjectDN (the Active Directory account whose permissions need to be tightened) and $Credential (the credential used to authenticate the client when talking to Active Directory. This is generally the Enterprise Admin credentials used to create the account whose permissions needs tightening) appropriate for your environment.

How do I check if the vulnerability has been misused?

Since the escalation of privilege vulnerability lies in the ability for an attacker to reset the password of the Azure AD Connect service account, checking if the vulnerability has been misused, is easy as checking the pwdLastSet attribute of the account.

Additionally, the Active Directory event log contains information for the password reset event in case you find an unexpected timestamp.

Call to Action

If you haven’t configured your Azure AD Connect installation(s) with group Managed Service Accounts (gMSAs), yet, this is a good time to install Azure AD Connect as a Staging Mode server, and then, after due diligence, making it the actively synchronizing Azure AD Connect server.

Managed Service Accounts (MSAs) and group Managed Service Accounts  (gMSAs) are the way forward for service accounts in Microsoft-based environments.

Since version 1.1.443.0, you can use Azure AD Connect with a group Managed Service Account (gMSA) as its service account. I thought it was time to show you how to configure Azure AD Connect with a gMSA.

The problem with service accounts

We all use service accounts in our environments. These accounts allow us to run a service with the right amount of privileges. It also allows us to change the passwords for normal accounts, like built-in Administrator accounts since these are not abused to run services.

However, there is also a downside to service accounts, when you repurpose an Active Directory user object as a service account. Problems with this type of service accounts include:

• Service account password changes are a nightmare and they tend to break stuff. Nonetheless, it is a best practice to change these passwords regularly.
• Passwords for service accounts are stored in plain text in registry. Sure, the passwords are protected, but still accessible if you know how to work the DPAPI.
• The Scope of service accounts is not easily set or monitored. Service accounts can often be used outside the intended scope, for instance to set up VPN connections or send mail through the (authenticated) SMTP gateway.
• You can configure service accounts to not allow interactive logons and implement other information security measures, but in true Plan-Do-Check-Act fashion, you’ll also need to create reports of these settings still applying throughout the environment.

It’s a pain.

The problem with vSAs

Version 1.1.484.0, and above, of Azure AD Connect use a virtual Service Account (vSA), by default, instead of a service account, based on a user object in Active Directory Domain Services (AD DS), unless you install Azure AD Connect on a Domain Controller. While documentation is sparse on this feature, its aim is to automate regular password changes.

To this purpose, a virtual Service Account (vSA) is a local account to the Windows (Server) installation. It does not live in Active Directory Domain Services, but can best be seen as a subordinate to the Network Service on Windows 7 installations (and up) and Windows Server 2008 R2 installations (and up).

Problems with this type of service account include:

• The scope of the virtual Service Account is limited to one Windows (Server) installation.
• The name of the virtual Service Account needs to be identical to the name of the service. If your organization utilizes a strict naming convention, the virtual Service Account will not comply.
• The virtual Service Account is part of the Windows (Server) installation and does not live in Active Directory Domain Services. When your organization requires you to centrally manage service accounts in Active Directory, the virtual Service Account will not comply.
• The virtual Service Account inherits the same security context as the Network Service.

The benefit of using a virtual Service Account (vSA) instead of a  service account based on a user object then, typically, is limited to automatic password changes without breaking services. In a worst case scenario, a sniffed or intercepted (and decoded) password(hash) can only be used for a limited amount of time when you use a vSA.

The benefits of gMSAs

In Windows Server 2008 R2, Microsoft introduced the concept of a Managed Service Account (MSA), and improved on the concept by introducing the group Managed Service Account (gMSA) in Windows Server 2012.

When used in an Active Directory environment that runs the Windows Server 2008 R2 Domain Functional Level (DFL), or up, and using the Active Directory Domain Services Remote Server Administration Tools (AD DS RSAT) on at least Windows Server 2012 or Windows 8, gMSAs offer these benefits:

• The gMSA object type (msDS-ManagedServiceAccount) is derived from the computer account object and lives in the Managed Service Accounts container under the domain root. Therefore;
• It cannot be used to logon interactively
• It cannot be (easily) delegated permissions to, or on
• Additionally, because it acts like a computer object, it’ll automatically try to change its password every 30 days. In a worst case scenario, a sniffed or intercepted (and decoded) password(hash) can only be used for a limited amount of time.
• By default, gMSAs don’t apply to any hosts. You’ll have to explicitly grant a gMSA access to a (group of) host(s), before you can configure it as a service account for a service on the host.
• gMSAs use Kerberos Constrained Delegation (KCD). This means that when you rename the host on which you installed the gMSA, the service configured with the gMSA will remain operable without problems.

gMSAs with Azure AD Connect

Azure AD Connect’s Service Accounts

Azure AD Connect uses three service accounts:

1. A local account on the Windows Server installation runing Azure AD Connect, used to run the he Microsoft Azure AD Sync service
2. An account in the Azure Active Directory tenant
3. One account per Active Directory Domain Services environment in scope for Azure AD Connect.

You can use a group Managed Service Account (gMSA) for the first account to run the service on the Windows Server(s) where you’ve installed and configured Azure AD Connect to synchronize objects and attributes between your on-premises Active Directory Domain Services (AD DS) environment(s) and your Azure Active Directory tenant.

This service account is not used to authenticate or communicate to Azure AD (2), and it is also not used to authenticate and communicate to the Active Directory Domain Services environment (3). Therefore, using Azure AD Connect with a gMSA is not the solution to the recent vulnerability that as fixed in Azure AD Connect version 1.1.654.0, and up.

Staging Mode

Azure AD Connect offers Staging Mode functionality, so its high-availability weaknesses are addressed somewhat. While the High Availability aspect of any Azure AD Connect implementation should be considered, Staging Mode is best suited for lifecycle management of Azure AD Connect to cope with other downsides in the way Microsoft releases and supports Azure AD Connect.

When you’re implementing an additional Azure AD Connect installation in Staging Mode, you could reuse the group Managed Service Account (gMSA) you created for the active Azure AD Connect installation, but be sure to create an additional service account, too. Following the recommended practice in this blogpost, this would mean an additional gMSA per additional Azure AD Connect installation.

(Optional) Migration steps

You can’t reconfigure an existing Azure AD Connect installation to use a gMSA. So, if you’re using Azure AD Connect currently with a repurposed user object as its service account, the proper way to change this is by:

1. Implementing an additional Azure AD Connect installation in Staging Mode with the group Managed Service Account (gMSA) as its service account.
2. Recreate any changes you’ve made to the rules and other configuration items. If you haven’t documented these, I recommend to use the Azure AD Connect Configuration Documenter Free to search for differences in the configuration between the two installations.
3. Test to make sure that both Azure AD Connect installations perform the same operations in the metaverse when you make changes to objects in scope.
4. Configure the active Azure AD Connect installation as an additional Staging Mode server and then configure the Staging Mode Azure AD Connect installation as the active Azure AD Connect server .

Optionally, you can check the Relying Party Trust (RPT) between your Active Directory Domain Services environment(s) and your Azure Active Directory tenant, using the Reset Azure AD and AD FS Trust option, and then the Verify AD FS Login option in the Azure AD Connect wizard. I recommend this step when there is a three month gap (or more) between the two Azure AD Connect installations used in the migration.

Implementation steps

To configure Azure AD Connect with a group Managed Service Account (gMSA) as its service account, perform these steps, right before you install and configure Azure AD Connect:

Note:
For this step, the Windows Server installation on which you want to install and configure Azure AD Connect needs to be setup and joined to the domain.

In Active Directory Domain Services

Using the Active Directory Domain Services Remote Server Administration Tools (AD DS RSAT) on at least Windows Server 2012 or Windows 8, create the service account for the Windows Server that will run Azure AD Connect, using the following PowerShell one-liners:

Import-module ActiveDirectory

Add-KdsRootKey -EffectiveImmediately

New-ADServiceAccount -Name gMSA1 -Description “Service account for Azure AD Connect installation 2” –DNSHostName aadc2.domain.tld -PrincipalsAllowedToRetrieveManagedPassword AADC2$ -Passthru

The above lines of code are an example. Substitute gMSA1, domain.tld and AADC2 and the description with values that are appropriate to your environment and comply with any naming conventions for objects your organization might have.

On the Azure AD Connect server

On the Azure AD Connect Server, run the following PowerShell one-liner in an elevated PowerShell window:

Install-ADServiceAccount -Identity gMSA1

Then, start the installation of Azure AD Connect, by double-clicking the Azure AD Connect installer.

In the Welcome to Azure AD Connect screen, select the I agree to the license terms and privacy notice option and, then, click Continue.

In the Express Settings screen, click Customize.

In the Install required components screen, select the Use an existing service account option. Then, select the Managed Service Account option.

For the SERVICE ACCOUNT NAME enter DOMAIN\gMSA1$ where you’d replace DOMAIN with the NetBIOS name of the Active Directory domain and replace gMSA1 with any other name you might have given your gMSA using the above PowerShell one-liners). You don’t have to enter a password, because this is a gMSA.

Now, configure the Azure AD Connect installation as you would normally. If you don’t want to configure a custom installation location, use an existing SQL Server or want to specify custom sync groups, press Install in the Install required components screen.

Concluding

Since version 1.1.443.0, you can use Azure AD Connect with a group Managed Service Account (gMSA) as its service account. With the recent vulnerability in the way Azure AD Connect creates its service account, it’s the best thing to do. We’ve been designing and implementing Azure AD Connect with gMSAs since version 1.1.443.0 to meet requirements to change the passwords for service accounts regularly.

gMSAs are the way forward for service accounts. Implement yours today.

Further reading

New features in AD DS in Windows Server 2012, Part 8: Group MSAs (gMSAs) Applicability of Managed Service Accounts (MSAs) and group Managed Service Accounts (gMSAs)
Azure AD Connect v1.1.443.0 is here
Azure AD Connect version 1.1.654.0 addresses a critical security vulnerability

The post Using Azure AD Connect with a gMSA appeared first on The things that are better left unspoken.

Azure Active Directory is Microsoft’s Identity Management-as-a-Service solution, offering seamless access, easy collaboration, efficiency in IT processes and improved security and compliance. In its Release Notes for Azure Active Directory, Microsoft communicated the following new functionality for Azure Active Directory for December 2017:

What’s New

Review of Terms of use in the access panel

Service Category: Terms of Use
Product Capability: Governance/Compliance

End users now have the ability to go to access panel and view the terms of use that they have previously accepted.

Add configuration to require the TOU to be expanded prior to accepting.

Service Category: Terms of Use
Product Capability: Governance

Microsoft has now added an option for admins to require their end users to expand the terms of use prior to accepting the terms.

Select either on or off for Require users to expand the terms of use. If this is set to on, end users will be required to view the terms of use prior to accepting them.

New Azure AD sign-in experience

Service Category: Azure AD
Product Capability: User Authentication

As part of the journey to converge the Azure AD and Microsoft account identity systems, Microsoft has redesigned the UI on both systems so that they have a consistent look and feel. In addition, Microsoft has paginated the Azure AD sign-in page so that Microsoft collects the user name first, followed by the credential on a second screen.

Fewer login prompts: A new “Keep me signed in” experience for Azure AD login

Service Category: Azure AD
Product Capability: User Authentication

Microsoft has replaced the Keep me signed in checkbox on the Azure AD login page with a new prompt that shows up after the user successfully authenticates.

If a user responds Yes to this prompt, the service gives them a persistent refresh token. This is the same behavior as when the user checks the Keep me signed in checkbox in the old experience. For federated tenants, this prompt will show after the user successfully authenticates with the federated service.

Scoped activation for eligible role assignments

Service Category: Privileged Identity Management
Product Capability: Privileged Identity Management

Scoped activation allows you to activate eligible Azure resource role assignments with less autonomy than the original assignment defaults. Scoping your activation may reduce the possibility of executing unwanted changes to critical Azure resources.

New federated apps in Azure AD app gallery

Service Category: Enterprise Apps
Product Capability: 3rd Party Integration

In December 2017, Microsoft has added the following new apps in the App gallery with Federation support:

• EFI Digital Storefront
• Vodeclic
• Accredible
• FactSet
• MobileIron Azure AD Integration
• IMAGE WORKS
• SAML SSO for Bitbucket by resolution GmbH
• SAML SSO for Bamboo by resolution GmbH
• Communifire
• MOBI
• Reflektive
• CybSafe
• WebHR
• Zenegy Azure AD Integration
• Adobe Experience Manager

What’s Changed

Pass-through Authentication – Skype for Business support

Service Category: Authentications (Logins)
Product Capability: User Authentication

Pass-through Authentication (PTA) now supports user sign-ins to Skype for Business client applications that support modern authentication, including Online and Hybrid topologies.

Approval workflows for Azure AD directory roles

Service Category: Privileged Identity Management
Product Capability: Privileged Identity Management

Approval workflow for Azure AD directory roles is generally available (GA).

With approval workflow, privileged role administrators can require eligible role members to request role activation before they can use the privileged role. Multiple users and groups may be delegated approval responsibilities. Eligible role members receive notifications when the approval is complete and their role is active.

Updates to Azure Active Directory Privileged Identity Management (PIM) for Azure RBAC (preview)

Service Category: Privileged Identity Management
Product Capability: Privileged Identity Management

With the Public Preview Refresh of Azure Active Directory Privileged Identity Management (PIM) for Azure RBAC, you can now:

• Use Just Enough Administration (JEA)
• Require approval to activate resource roles
• Schedule a future activation of a role that requires approval for both AAD and Azure RBAC Roles

The post What’s New in Azure Active Directory for December 2017 appeared first on The things that are better left unspoken.

With the release of version 13.1 of its BIG-IP software, F5 Networks enables you to make your F5 BIG-IP series appliances and F5 Virtual Edition (VE) appliances to act as ful-fledged Web Application Proxies in combination with Windows Server 2012 R2 and/or Windows Server 2016-based Active Directory Federation Services (AD FS) Servers using MS-ADFSPIP.

About MS-ADFSPIP

The Microsoft Active Directory Federation Services and Proxy Integration Protocol (MS-ADFSPIP) integrates Active Directory Federation Services (AD FS) with an authentication and application proxy to enable access to services located inside the boundaries of the corporate network for clients that are located outside of that boundary.

Version 6.0 of MS-ADFSPIP’s documentation, as defined on December 1, 2017, details the protocol documentation in terms of transport, data types, messages, events, and the conceptual data organization. This way, it describes the intended functionality of the system and how the protocols in this system interact.

Using this documentation, any organization that would like to upgrade their appliances to full-fledged AD FS Web Application Proxies, can do so.

About F5 Networks’ BIG-IP

F5 Networks help connect organizations to their customers and/or apps in a secure, always-on way. While F5 Networks offers a portfolio of products, including its BIG-IQ and Herculon products, its BIG-IP appliances, are the best-known products, available both as on-premises physical and virtual appliances, as well as cloud appliances.

BIG-IP appliances are port-based, multilayer switches that supports virtual local area network (VLAN) technology. The BIG-IP appliances’ multilayer capabilities enable them to process traffic at other OSI layers. BIG-IPs can perform IP routing at Layer 3, as well as manage TCP, UDP, and other application traffic at Layers 4 through 7.

Version 13.1 of the BIG-IP software, released on December 19, 2017, adds support for MS-ADFSPIP to F5’s Access Policy Manager (APM), as announced by Microsoft and F5 Networks during Microsoft Ignite 2017 in Orlando, Florida.

Version 13.1 of the BIG-IP software can be used to transform the following F5 appliances to full-fledged Web Application Proxies:

• BIG-IP 6900 FIPS, 6900-NEBS (D104)
• BIG-IP 11000 (E101)
• BIG-IP 11050, 11050 NEBS (E102)
• BIG-IP 2000 Series (C112)
• BIG-IP 4000 Series (C113)
• BIG-IP 5000 Series (C109)
• BIG-IP 7000 Series (D110)
• BIG-IP 10050 Series (D112)
• BIG-IP 10000 Series (D113)
• BIG-IP 12000 Series (D111)
• BIG-IP i2000 Series (C117)
• BIG-IP i4000 Series (C115)
• BIG-IP i5000 Series (C119)
• BIG-IP i7000 Series (C118)
• BIG-IP i10000 Series (C116)
• VIPRION B2100 Blade (A109)
• VIPRION B2150 Blade (A113)
• VIPRION B2250 Blade (A112)
• VIPRION B4300, B4340N Blade (A108, A110)
• VIPRION B4450 Blade (A114)
• VIPRION C2200 Chassis (D114)
• VIPRION C2400 Chassis (F100)
• VIPRION C4480, C4480N Chassis (J102, J103)
• VIPRION C4800, C4800N Chassis (S100, S101)
• Virtual Edition (VE) (Z100)
• vCMP Guest (Z101)

Note:
Although F5 Networks’ Azure offerings still include version 13.0.x of the BIG-IP software, you may expect to see version 13.1.x-based offerings soon.

Concluding

If your organization utilizes F5 appliances on the network edge and also run or contemplate on implementing Windows Server-based Web Application Proxies, you might benefit from this new functionality. You might be able to do away with Windows Server installations on the perimeter network, with their cumbersome patching and backup procedures.

Since the MS-ADFSPIP documentation is open, any vendor is able to create and provide the software to transform their devices into full-fledged Web Application Proxies. I guess F5 Networks is merely the first in a line of many vendors that will do so.

Further reading

F5 BIG-IP Release Notes 13.1.0
[MS-ADFSPIP]: Active Directory Federation Services and Proxy Integration Protocol

The post Use your F5 BIG-IP Appliance as Full-Fledged AD FS Web Application Proxy appeared first on The things that are better left unspoken.

On Wednesday January 24, 2018 I’m co-presenting a webinar on tracking changes in Hybrid Identity environments, based on Active Directory Domain Services (AD DS) and Azure AD. The session is sponsored by Netwrix, who I think have a stellar solution for tackling this challenge.

This expert webinar is scheduled for a convenient time for my European and African friends, at 3PM CET. This is a rerun of the previous webinar with Netwrix.

About Netwrix

Netwrix is a private IT security software company, which offers IT auditing solutions for systems and applications across your IT infrastructure. Netwrix  specializes in change, configuration and access auditing software with its Netwrix Auditor solution. Netwrix is a partner of Microsoft, VMware, EMC, NetApp and HP ArcSight.

If you’ve worked in highly-secure highly-regulated IT environments, you’re probably familiar with the Netwrix brand, because their Active Directory auditing solution is one of the best out there.

About the webinar

For many organizations, Active Directory is the cornerstone of their network infrastructure. However, as cloud adoption among businesses increases IT teams are posed with more and more security challenges by these hybrid environments. It’s a daunting struggle to manage both Active Directory and Azure AD, let alone ensure the security of such deployments. How can you monitor critical changes? Or comply with the certifications your organizations need?

In this webinar, you’ll learn how you can monitor privileged account activity, stay on top of critical changes and a slew of security threats in hybrid environments with Netwrix Auditor. You will get an abundance of ready-to-go recommended practices, so you’ll be able to start with Netwrix Auditor 9.5 the right way, immediately.

I’m co-presenting the webinar with Russell McDermott, systems engineer at Netwrix. This way, you get the best practices from the field and expert analysis tips, directly from the guys who build the Netwrix Auditor product.

Join me!

The webinar is offered free of charge.
You only need to register in advance to become part of the fun!

Of course, if you can’t make January 24, 2017 3PM CET, you can also register for viewing the webinar on-demand , after we’ve finished up.

The post I’m co-presenting a second webinar on tracking changes in Hybrid Identity appeared first on The things that are better left unspoken.

Per this week, Azure Active Directory is no longer available in the ‘Old’ Portal experience. Previously, I’ve shared with you how to download, install and configure Microsoft’s on-premises Multi-Factor Authentication Server, while using the old Portal Experience. Now, let me show you how to download, install and configure it with the ‘New’ Portal.

In this blogpost, we’ll follow the Simple Deployment scenario.

Step 1 Create an MFA Provider

Log onto the Azure Portal.

In the left navigation menu, click Azure Active Directory.

In the navigation menu of your Azure AD tenant (just to the right of the main navigation menu) scroll down until you reach MFA Server in the SECURITY area.

Click MFA Server.

In the MFA Server blade, click on Providers in the feature’s navigation menu.

Click + Add.

In the Add Provider blade, fill in the values for:

• Name
  This is the name for the Multi-factor Authentication Provider. This is only shown in the Azure Portal. Make sure to create a name that corresponds to your organization’s naming convention.
• Usage Model
  Choose between Per Enabled User or Per Authentication. The usage model cannot be changed after the Multi-Factor Authentication Provider is created. For more information, refer to Option 3 in the How to Get Azure MFA section of the What is Azure Multi-factor Authentication documentation.
• Subscription
  Select the subscription you want to have your authentications or enabled users to be billed to.

When done, click the Add button at the bottom of the blade.

You have now successfully created the MFA Provider.

Step 2 Download MFA Server

Double-click the MFA Provider you just created.

In the MFA Provider’s navigation menu, click Server Settings.

Click the Download link.

The Download page for Multi-Factor Authentication Server opens in a new tab, by default. Click the Download button on the page and save MultiFactorAuthenticationServerSetup.exe to disk.

Do not close the web browser, just yet.

Step 3 Install MFA Server

After you downloaded MultiFactorAuthenticationServerSetup.exe, open it.
Walk through the prerequisites and screens to install Multi-Factor Authentication Server.

In the Welcome screen, click Next >.

In the Activate screen, we need to enter the activation credentials. You generate the activation credentials in the Azure Portal, so let’s switch back to the Azure Portal in our web browser:

Click the Generate link.

This will show two more fields below the link, consisting of an e-mail address and a password. Copy these two values in the Multi-Factor Authentication Server’s Activate screen. Click Next > and close the browser screen.

In the Join Group screen, click Next >.

In the Enable Replication Between Servers screen, click Next >.

In the Select Applications screen, select the applications, services and protocols you want the Multi-Factor Authentication Server to provide. At least one application needs to be selected. Click Next > when done and walk through the steps to configure the application, protocol or service.

In the Finish screen, click Finish.

You have now successfully installed and configured Multi-Factor Authentication Server.

Concluding

Many people I talked to about the transition of the old PhoneFactor Web Portal (PFWEB) and the old Microsoft Azure Management Portal to the new Azure Portal, were worried about not being able to select the Per Authentication licensing option, or reusing their previously configured MFA Provider settings.

The above steps show that all these options are still available.

Although Multi-Factor Authentication Server has been ‘renamed’ in the Azure Portal and the Microsoft Forums, the latest version of the product still refers to itself as the Windows Azure Multi-Factor Authentication Server… Let’s name it MFA Server, from now on.

Further reading

Marching into the future of the Azure AD admin experience: retiring the Azure AD classic portal

Related blogposts

Azure Multi-Factor Authentication is now in the new Azure Portal (in Public Preview)
Ten Things you need to know about Azure Multi-Factor Authentication Server
Azure Multi-Factor Authentication Server 7.3.0.3 with lots of improvements
Azure Multi-Factor Authentication features per license and implementation
Azure Multi-Factor Authentication Methods per Supported Protocol
Connecting to Azure MFA Server’s Web Service SDK using certificate authentication
Things to know about Billing for Azure MFA and Azure MFA Server
Supported Azure MFA Server Deployment Scenarios and their pros and cons

The post Installing Multi-Factor Authentication Server with the new Portal Experience appeared first on The things that are better left unspoken.

For its seventh edition, the theme for the annual Nordic Infrastructure Conference (NICConf) is Future Edition. Raymond Comvalius and I are delivering sessions again. It’s our fourth edition of this fantastic event and we’re looking forward to it!

About the Nordic Infrastructure Conference

The Nordic Infrastructure Conference (NICConf) provides IT and business professionals with unmissable networking and learning experiences from the leading Global IT experts.

NIC is the industry’s foremost collaboration and learning event offering global best in class content and structure, delivered by some of the leading technical IT speakers in the world. The main focus is on Cloud technology, automation & management, security, client & server, collaboration and productivity & analytics.

NICConf will be hosted for the seventh time from January 31 to February 2, 2018. Its location will be the Oslo Spektrum in the heart of Oslo, Norway, again. James Whittaker, Microsoft Distinguished Engineer and Tech Evangelist, is scheduled to deliver the keynote on February 1.

About our sessions

Raymond and I deliver two 60-minute sessions:

Azure Multi-Factor Authentication: Who do you think you are?

February 2, 2018 8:30AM – 9:30AM, Room 8

Passwords have been introduced to solve the authentication problems decades ago. Today, we have different challenges and we need more in-depth solutions for authentication assurance. Office365- and Azure Multi-Factor Authentication (MFA) offer this solution for both your organizations’ cloud and on-premises resources. Your organization will no longer be in the dark on the person on the other side of the line: it’s really you and you’ve got the means to prove it!

With several large and complex Azure MFA implementations and upgrades under their belts, Sander Berkouwer (Directory Services and Enterprise Mobility MVP) and Raymond Comvalius (Windows IT Pro MVP) share their experiences with these products, their licensing, on-premises deployment scenarios, end-user expectations and the inner workings of the product line-up, including MFA Server, the Security Graph and Azure AD Identity Protection.

Looking for your next-generation identity primer? Look no further!

Achieving productivity without an on-premises infrastructure: Mission Impossible?

February 2, 2018 2PM – 3PM, Room 4

The daily announcements from Microsoft on cloud-based opportunities for organizations, might give you the idea that your organization might be able to achieve productivity without an on-premises infrastructure, too. How do you, as a system administrator for a large organization, embrace these new possibilities and get rid of the square footage, cooling needs, firewalls and even your Domain Controllers? Can you go 100% cloud?

Dive into the full stack of Microsoft cloud possibilities and impossibilities with Sander Berkouwer (Directory Services and Enterprise Mobility MVP) and Raymond Comvalius (Windows IT Pro MVP). With their ‘Trust, but verify’ view on these items, they’ll share their real-life experiences with bringing organizations to the cloud, embracing a dual cloud provider strategy and the often-overlooked exit strategies you’ll need to have.

Find out why Group Policies, VPNs and typical file servers are rapidly becoming remnants of a long gone era in systems management and productivity. In the process, gain an end-to-end overview, featuring the latest and greatest Windows and Azure technologies to achieve the goals on your organizations horizon.

Related blogposts

Pictures of the 2017 Nordic Infrastructure Conference in Oslo last week
I’m speaking at the 2017 Nordic Infrastructure Conference
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
My Cybersecurity Talk interview with CQURE Academy is now available

The post I’m speaking at NIC Future Edition appeared first on The things that are better left unspoken.

In this blogpost, I’ll explain how to install and configure Active Directory Federation Services (AD FS) and Azure AD Connect to achieve Hybrid Identity with Azure Active Directory, based on Windows Server 2016.

The implementation outlined in this blogpost is relevant for one on-premises datacenter and an Active Directory Domain Services environment, consisting of one Active Directory domain. We’ll try to keep this as simple as possible, so we’ll make the following choices:

• We won’t deploy the AD FS Servers in a redundant/high-available fashion
• We’ll use Windows Internal Database (WID) to host the AD FS Configuration database
• We wont deploy the Web App Proxies in a redundant/high-available fashion
• We’ll use an AD FS service communications certificate issued by a publicly-trusted Certification Authority (CA).

Before you begin

Before you begin, you should have access to the following information:

• The DNS domain name of your organization’s Active Directory Domain Services (AD DS) environment
• Credentials for an Enterprise Admin account in the AD DS environment
• Credentials to access the DNS zone of the DNS Domain Name of your organization

Of course, it’s a good idea to make a back-up of your Domain Controllers and test one of the backups in a separate networking environment to make sure you’re able to restore.

Requirements

Before you can implement Hybrid Identity, based on Windows Server 2016, your environment needs to comply with these requirements:

• The Active Directory schema needs to be at least Windows Server 2016.
• Your organization needs at least one Windows Server 2012-based (or up) Active Directory Domain Controller
• The Active Directory Domain Services Domain Functional Level needs to be at least Windows Server 2008 R2.

Overview

In the blogpost, we’ll implement the following:

Step 1: Configuring Active Directory

Service Accounts

Before we can setup Hybrid Identity, we need to create a service accounts. We’ll use a group Managed Service Accounts (gMSAs) for AD FS, because it offers the best security.

Run these two elevated PowerShell one-liners:

Add-KdsRootKey –EffectiveTime (Get-Date).AddHours(-10)

New-ADServiceAccount ADFSgMSA –DNSHostName adfs1.domain.tld

DNS Records

Next up, we’ll configure the internal DNS records for the AD FS Farm Name:

Add-DNSServerResourceRecordA –IPv4Adddress 10.0.0.5 -Name sts -ZoneName domain.tld

Step 2: Setting up the AD FS Server

About AD FS

Active Directory Federation Services (AD FS) can be seen as an add-on to Active Directory Domain Services (AD DS). AD DS offers single sign-on for on-premises functionality like file servers and printer servers, leveraging protocols like NTLM and Kerberos. AD FS also offers single sign-on, but based on standards like WS-Federation, SAML, Oauth2 and SCIM. AD FS can be used to provide single sign-on to (web) applications on-premises, but it is particularly useful for cloud-based (web) applications.

The AD FS server is the component that performs the security translation between the ‘old’ protocols and the new standards. In the RFCs, it is referred to as a Security Token Service (STS).

Windows Server 2016

We’ll start with a fresh Windows Server 2016 installation, located on the internal network. Of course, the server will be properly setup for updates, backups, monitoring, and anti-malware, according to your organization’s requirements, before we proceed with installing and configuring AD FS.

The server needs to be joined to the domain and subsequently restarted. Log on with a domain account afterwards.

AD FS Role

To install the AD FS role, run the following Windows PowerShell one-liner in an elevated PowerShell window:

Install-WindowsFeature ADFS-Federation -IncludeManagementTools

AD FS Service Communications certificate

AD FS requires a certificate.

On a Windows or Windows Server installation, simply create a certificate request for a certificate with the following DNS subjects:

• CN=sts.domain.tld
• DNS=sts.domain.tld
• DNS=enterpriseregistration.domain.tld
• DNS=certauth.sts.domain.tld

Make sure you create a certificate request for a certificate with the SHA-2 hashing algorithm, a 2048-bit key length (or longer) and a legacy key pair.

You can use any Certificate Authority (CA) you’d like, but I recommend certificates issued by Let’s Encrypt for the AD FS service communications certificate. Let’s Encrypt is a free, automated, and open Certificate Authority (CA).

Submit your certificate request, pass the validation checks and then receive a perfectly valid TLS certificate for free.

I installed the certificate on the box where I requested it. Then I exported it and protected the key material with a password. I copied it the hard disk of the AD FS Server where I stored it as C:\sts.pfx. This allowed me to run the following PowerShell one-liner to import the certificate:

Import-PfxCertificate -FilePath C:\sts.pfx -Password (ConvertTo-SecureString –String “YourPasswordHere” –AsPlainText -Force) –CertStoreLocation cert:\LocalMachine\My

After the role is installed and the certificate is installed, we can configure AD FS, using the following PowerShell one-liners:

$Thumb = (Get-ChildItem -path cert:\LocalMachine\My | Where-Object {$_.Subject -match “sts.domain.tld“}).Thumbprint

Install-AdfsFarm -CertificateThumbprint $thumb -FederationServiceName sts.domain.tld -GroupServiceAccountIdentifier domain.tld\ADFSgMSA$

Restart-Computer

The AD FS Server is setup after it comes online.

Step 3: Setting up the Web Application Proxy

About the Web Application Proxy

To use AD FS with Azure Active Directory, we need to publish it publicly, or at least to Microsoft. Microsoft recommends to use the Web Application Proxy role to publish AD FS publicly. Yes, you could make the previously configured AD FS Server to the Internet, but this is not recommended.

Windows Server 2016

We’ll start with a fresh Windows Server 2016 installation for the Web Application Proxy, too. This time, however, it’s located on a perimeter network, if your organization has any.

The server will be properly setup for updates, backups, monitoring, and anti-malware, according to your organization’s requirements, before we proceed with installing and configuring it as a Web Application Proxy.

Log on as a local admin and copy the certificate over to this server.

Then, install the role, using the  following Windows PowerShell one-liner in an elevated PowerShell window:

Install-WindowsFeature Web-Application-Proxy -IncludeManagementTools

I copied the exported certificate to the hard disk of the Web Application Proxy where I stored it as C:\sts.pfx. This allowed me to run the following PowerShell one-liner to import the certificate:

Import-PfxCertificate -FilePath C:\sts.pfx -Password (ConvertTo-SecureString –String “YourPasswordHere” –AsPlainText -Force) –CertStoreLocation cert:\LocalMachine\My

Now that the role is installed and the certificate is installed, we can configure the Web Application Proxy, using the following two PowerShell one-liners:

$Thumb = (Get-ChildItem -path cert:\LocalMachine\My | Where-Object {$_.Subject -match “sts.domain.tld“}).Thumbprint

Install-WebApplicationProxy –CertificateThumbprint $Thumb -FederationServiceName sts.domain.tld

Enter the credentials of a local administrator account on the AD FS Server at the login screen and then, the Web Application Proxy is setup.

Step 4: Setting up Azure Active Directory

About Azure Active Directory

Azure Active Directory is Microsoft’s cloud-based Identity Management as-a-Service solution. It offers single sign-on access to Office 365 and over 2800 other cloud apps and services from the likes of Google and Amazon.

Setup the Azure AD tenant

We’ll configure a new Azure Active Directory tenant, by leveraging the Office 365 trial wizard. This wizard allows you to create an Azure Active Directory tenant without the need of a credit card.

Follow the link above and register the tenant. Do not forget to write down the password for the built-in tenant administrator account somewhere safe.

Connect to the tenant

Next, let’s connect to the tenant. Use an elevated PowerShell session and type the following one-liner to install the Azure Active Directory PowerShell Module:

Install-Module AzureAD

Press Yes twice. Now, Let’s put it to action to log into our tenant using the bootstrap/fallback admin account we created when we created the tenant:

Connect-AzureAD

In the pop-up authentication window, type your username and press Next. Then, in the password stage, enter the password and press Sign in.

Configure your DNS domain name

Next, configure your DNS domain name:

New-AzureADDomain -Name domain.tld -IsDefault $true

Your Azure AD Tenant is now ready to go.

Step 5: Setting up Azure AD Connect

About Azure AD Connect

Azure AD Connect is Microsoft’s free bridge between Active Directory Domain Services (AD DS) and Azure Active Directory. It helps organizations make themselves known towards Microsoft as a tenant by synchronizing objects and attributes and configuring synchronization and sign-in options.

Windows Server 2016

We’ll start with a fresh Windows Server 2016 installation, located on the internal network. Of course, the server will be properly setup for updates, backups, monitoring, and anti-malware, according to your organization’s requirements, before we proceed with downloading, installing and configuring Azure AD Connect.

The server needs to be joined to the domain and subsequently restarted. Log on with a domain account afterwards.

Download Azure AD Connect

Use a browser to download the latest version of Azure AD Connect to disk.

Install and configure Azure AD Connect

Double-click the AzureADConnect.msi file.

After the initial installation, you will begin configuring Azure AD Connect, automatically. In the Welcome to Azure AD Connect screen, select the I agree to the license terms and privacy notice option and click Continue.

In the Express Settings screen, click Customize.

Note:
When we would’ve used Express Settings, one of the configuration outcomes would have been PAssword Hash Synchronization (PHS) as the Sign-in option.

Click Install on the Install required components screen.

In the User sign-in screen select Federation with AD FS as the sign on method.
Click Next.

In the Connect to Azure AD screen, enter the username and password for the Azure AD bootstrap/fallback account. Click Next when done.

In the Connect your directories screen, click the Add Directory button. In the AD Forest account pop-up window, specify a user account with at least Domain Admin credentials for the Active Directory domain you want to add, or a user account with at least Enterprise Admin credentials, when you want to add an entire Active Directory forest. Press OK when done. Then, press Next on the Connect your directories screen.

In the Azure AD sign-in configuration screen, click Next to accept the userPrincipalName attribute as the on-premises attribute to use as the Azure AD username.

Press Next in the Domain and OU filtering screen to accept synchronizations of all domains and organizational units (OUs) within the connected Active Directory.

Note:
Some objects will not be synchronized by default, like the built-in Administrator account and other privileged accounts when these privileges stem from memberships to well-known privileged groups, like the Domain Admins and Account Operators groups.

In the Uniquely identifying your users screen, click Next.

In the Filter users and devices screen, click Next. to Synchronize all users and devices instead of creating a pilot group for synchronization.

In the Optional features screen, click Next.

In the Domain Administrator Credentials screen, enter the username and password of a user account in the Active Directory Domain Services environment where AD FS will be managed with Domain Admin privileges. Click Next when done.

In the AD FS farm screen, select Use an existing AD FS farm. In the SERVER NAME field, enter adfs1.domain.tld, or use the Browse button to select the AD FS server from Active Directory. Click Next when done.

In the Azure AD Domain screen, select the DNS domain name that you wish to federate from the dropdown list.

Now, we face the challenge of verifying our DNS Domain Name. In your external DNS zone, implement the following DNS records:

• The above TXT or MX record as shown in Azure AD Connect
• An A record for sts.domain.tld, pointing to the external IPv4 address of your Web Application Proxy server
• An A record for enterpriseregistration.domain.tld, pointing to the external IPv4 address of your Web Application Proxy server.

Also, this is a good time to make sure traffic is allowed from the Internet to the Web Application Proxy, using TCP 443. Open up this firewall port when you haven’t yet. The time this takes makes sure the DNS records are populated and visible, as this tends to take some time at some DNS providers…

Then, click the green Verify Domain button, next to the DNS domain name.

Eventually, you’ll receive the message that your DNS Domain name is now a managed domain that will be converted into a federated domain. Click Next.

On the Ready to configure screen, click Install.

On the Configuration complete screen, click Next.

On the Verify federation configuration screen, select the I have created DNS A records that allow clients to resolve my federation service from both the intranet and the extranet. option. Then, click Verify to verify name resolution of the AD FS Farm using external DNS and access to the AD FS Farm using TCP 443.

After successful verification, click the Exit button.

You can now use Azure Active Directory with Single Sign-On.

Concluding

Congratulations!

You have setup Hybrid Identity using Active Directory Federation Services (AD FS) as the sign-in option. Now you can use this new piece of infrastructure to rollout Microsoft Intune, give your colleagues access to Microsoft Office 365 or over 2800+ applications that are ready to integrate with Azure Active Directory, all without the hassle of logon prompts and disparate passwords between solutions.

Note:
For the AD FS Server and the Web Application Proxy, you can use Windows Server version 1709 or other Server Core installations, too, even though the above blogpost only mentions Windows Server 2016.

The post Performing a simple Hybrid Identity implementation with AD FS on-premises appeared first on The things that are better left unspoken.

Last week, I showed you how to perform a simple Hybrid Identity implementation with AD FS on-premises. While this scenario is easy and fast to deploy, it also has a couple of downsides. One of them is the risk of ‘AD FS Unavailability’ and the inability to authenticate to cloud resources when the on-premises environment is unreachable from the Internet.

My weapon of choice to mitigate that risk is Azure Traffic Manager.

In this blog post I share how I see Azure Traffic Manager play its role in making Active Directory Federation Services (AD FS) on Windows Server 2016 and Windows Server version 1709 highly available through geo-redundancy and, thus, failing over between multiple locations if need be.

Introduction to Azure Traffic Manager

Azure Traffic Manager is a Azure-based user traffic load-balancing solution. It can direct user traffic between and/or to IP-addresses associated with endpoints for Azure Virtual Machines, Azure (cloud and app) services, and on-premises networks.

Traffic Manager uses the Domain Name System (DNS) to direct client requests to the most appropriate endpoint in its configuration, based on the traffic-routing method of your choice and the health of the endpoints. It provides automatic failover.

The three ways Azure Traffic Manager helps AD FS

Azure Traffic Manager is capable of helping make Active Directory Federation Services (AD FS) on multiple locations highly available in all of its four routing methods. Let’s look at these methods using real-life examples:

1. Failover / Priority
   Your organization has deployed AD FS in both Azure IaaS and on-premises. Traffic Manager allows you to direct user authentication traffic from Internet-based clients to your organizations’ Azure Infrastructure-as-a-Service-based AD FS implementation, only if the on-premises AD FS implementation fails or becomes unreachable from the Internet.
2. Performance
   Your organization has multiple offices worldwide with corresponding datacenters. Traffic Manager can direct user authentication traffic from Internet-based clients to endpoints in different geographic locations. Azure Traffic Manager directs them to the “closest” endpoint in terms of the lowest network latency.
3. Geographic
   Your organization has deployed AD FS in multiple Azure regions. Like the ‘Performance’ method, Traffic Manager can direct user authentication traffic from Internet-based clients to endpoints in different geographic locations. This time it’s not based on the lowest latency, but the actual geographic location.
4. Weighted / Round-Robin
   You have multiple AD FS deployments, but they vary in compute power and bandwidth. Traffic Manager can distribute user authentication traffic from Internet-based based to any combination of Azure and non-Azure endpoints using weights your organization defines. You could use this method to direct 20% of the traffic to the on-premises AD FS implementation on your first datacenter, 20% to your other datacenter and the rest of the traffic to your organizations Azure Infrastructure-as-a-Service-based AD FS implementation.

While all four traffic manager methods have their pros and cons, my customers mainly prefer the Priority method. They chose to implement AD FS initially, because they need to be in reach of the auditing data to prove they are in control of the authentication mechanisms. The choice for on-premises AD FS comes from the wish to take advantage of the x-ms-client-ip, insidecorporatenetwork claimtypes and/or automatic Workplace and/or Azure AD Join, based on domain membership.

However, recently, I configured the Performance routing method for a customer, so we’ll use it for this example, because it’s way more exiting. Here’s an overview

Before you begin

Overview

Building on top of the simple Hybrid Identity implementation where I showed you how to implement AD FS, the end result of this blogpost looks like this:

Networking

Microsoft’s Hybrid Identity Required Ports and Protocols document doesn’t list the requirement to allow TCP 80 (HTTP) for Web Application Proxies.

In addition to the network traffic depicted in that document, we need to take care of  the ability of our Web Application Proxies to communicate plain HTTP towards the Internet (or at least the Azure Traffic Manager probing IP address ranges).

Name resolution

Normally, we’d point DNS to the external IP address of the load balancer on the edge of the perimeter network featuring the Web Application Proxies. However, since Azure Traffic Manager leverages DNS, we’ll need to create a CNAME record for our sts.domain.tld AD FS Farm name in external DNS Zones towards Azure Traffic Manager. For instance, we’ll create a CNAME record for sts.domain.tld to domainsts.traffficmanager.net.

Next, we’ll need to configure proper name resolution. Azure Traffic Manager uses DNS records to locate the endpoints, so the external IP addresses for the Web Application Proxies you’d want to integrate with Azure Traffic Manager will need to have a fully-qualified Domain name (FQDN) attached.

My suggestion is to use the same naming convention used for the AD FS farm name, but add a location or region to it. This way, an sts.domain.tld farm name would feature EastUsSTS.domain.tld and WestEuropeSTS.domain.tld endpoints, for example.

Step 1: Configuring the second AD FS server

In contrast to the simple deployment scenario, we’ll deploy more than one Active Directory Federation Services (AD FS) server. We don’t have to worry about the scope of the group Managed Service Account (gMSA), because the AD FS server takes care of that.

Deploy a new server running Windows Server 2016 or Windows Server 1709, join it to the Active Directory domain as adfs2.domain.tld and import the AD FS service communications certificate.

Then, run the following PowerShell one-liners:

Install-WindowsFeature ADFS-Federation

$Thumb = (Get-ChildItem -path cert:\LocalMachine\My | Where-Object {$_.Subject -match “sts.domain.tld“}).Thumbprint

Add-AdfsFarmNode -CertificateThumbprint $thumb -PrimaryComputerName adfs1.domain.tld -GroupServiceAccountIdentifier domain.tld\ADFSgMSA$

Restart-Computer

Step 2: Configuring the second Web App Proxy

Configuring additional Web Application Proxies to an AD FS Farm is not different than adding the first.

In the scenario of multiple datacenters, however, you might want to pay specific detail to the contents of the HOSTS file on the Web Application Proxies to point them to the closest AD FS server, instead of the AD FS server in the other datacenter.

The following PowerShell one-liner provides a good way to add a line to the HOSTS file using an elevated PowerShell (ISE) session:

Add-Content “C:\windows\system32\drivers\etc\hosts” “`nsts.domain.tld 10.4.0.5“

Then, import the certificate and run the PowerShell one-liner to add the Web Application Proxy to the AD FS farm:

$Thumb = (Get-ChildItem -path cert:\LocalMachine\My | Where-Object {$_.Subject -match “sts.domain.tld“}).Thumbprint

Install-WebApplicationProxy -CertificateThumbprint $thumb –FederationServiceName sts.domain.tld

Enter the credentials of a local administrator account on the AD FS Server at the login screen and then, the Web Application Proxy is setup.

Step 3: Configuring both Web App Proxies

For optimum load-balancing, we’ll need proper probes. We need to probe the infrastructure for something that is available only when the infrastructure is up and the functionality (the service) is running properly. A mere ping won’t suffice.

While you’d need to install KB2975719 on Windows Server 2012 R2 to enable the /adfs/probe endpoint, in Active Directory Federation Services (AD FS) on Windows Server 2016, this endpoint is available and enabled, by default.

Note:
You won’t see the /adfs/probe/ endpoint in the list of endpoints in AD FS Management (.msc), under Service, Endpoints.

However, the /adfs/probe/ endpoint is not available by default on Web Application Proxies, so we’ll need to perform a manual action to allow it through its Windows Firewall.

To this purpose, create the following Windows Firewall rule using Windows PowerShell on each of the Web Application Proxy servers you want to be probable by Azure Traffic Manager. Log onto each Web Application Proxy with an account with local admin privileges, start an elevated PowerShell (ISE) window and issue the following lines of code:

Import-Module NetSecurity

New-NetFirewallRule -Name Allow_HTTP -DisplayName “AD FS HTTP Services” -Protocol HTTP -Enabled $True -Profile Any -Action Allow

Note:
You should be aware that this rule allows Azure Traffic Manager to probe the status of each of the Web Application Proxies, and, thus, the availability of the connection and running services on these servers, but not the AD FS services on the AD FS Servers. For the purpose of geo-redundancy, however, this should be sufficient.

Step 4: Adding DNS records

Internal DNS

When you want your AD FS farm name to be available for users on-premises, add another DNS A record for the second AD FS server in the internal DNS zone:

Add-DNSServerResourceRecordA -IPv4Adddress 10.4.0.5 -Name sts -ZoneName domain.tld

Since we’re creating A records, Active Directory site awareness takes care of pointing internal clients to the nearest AD FS server.

External DNS

For the external DNS zone, we’ll need the following DNS changes:

sts.domain.tld CNAME domainsts.trafficmanager.net

EastUsSTS.domain.tld A <ExternalIPAddressinDatacenter1>

WestEuropeSTS.domain.tld A <ExternalIPAddressinDatacenter2>

Step 5: Configuring Azure Traffic Manager

Now, all we need to do is configure Azure Traffic Manager, itself:

• Log onto the Microsoft Azure Portal.
• If you have multiple tenants, choose the right tenant by clicking on your name or e-mail address in the top right corner. Select the tenant you want to use from the bottom of the context menu.
• Click on the green big plus sign in the left navigation menu to add products and services to your tenant.
• In the Search the Marketplace field, search for Traffic Manager Profile. by beginning to type its name. When Azure suggests it to you, click on it, or use the down cursor to go to it and then press Enter.
• A new blade appears named Traffic Manager Profile. It contains information on what Traffic Manager does, information on its publisher and help links. Click on the Create button on the bottom of the blade.
• A new blade appears, labeled Create Traffic Manager profile.

• Type and select the following information:
  • Type the DNS name of your Traffic Manager profile, for instance DomainSTS. This will be appended by trafficmanager.net to become the FQDN your external DNS zone has a CNAME for: DomainSTS.trafficmanager.net.
  • Select a Routing method from the drop-down list. We’ll choose Performance.
  • Select a Subscription from the drop-down list.
  • Create a new Azure Resource Manager (ARM) Resource group, or if you already have a resource group for Traffic Manager profiles and other load-balancing/high-availability resource, reuse that, by selecting it from the drop-down list.
  • Select a Resource group location from the drop-down list, when you create a new Resource group, otherwise continue with the next step.
• Select the Pin to dashboard option for your convenience.
• Click Create on the bottom of the blade.
• You will be redirected back to the Azure Portal dashboard, where you’ll see the profile be provisioned. After that, you’ll be taken into the configuration of your freshly created Azure Traffic Manager profile. If not, click it’s tile on the dashboard to continue.
• In the left navigation blade, click on Configuration under SETTINGS.
• In the Configuration blade that appears, click on the Path field under Endpoint monitor settings. Change it to /adfs/probe/.

• Click Save on the top of the blade.
• In the left navigation blade, click on Endpoints.
• Follow the + Add link on the top of the blade.
• A new blade appears, labeled Add endpoint.

• From the Type drop-down list, select External endpoint.
• Type something meaningful as the name. This makes for a good opportunity to exercise the organization’s naming convention. You might also just opt to type the hostname of the Web Application Proxies.
• For the Fully-qualified Domain Name (FQDN) enter the DNS name you assigned to the external IP address of the load balancer of Web Application Proxy in the particular location.
• Select a Location from the drop-down list. This determines the end-user device locations to be directed to this particular endpoint.
• Click OK.

Now, add any additional endpoints you’d like to include in the Azure Traffic Manager profile, like EastUsSTS.domain.tld. After that, your Endpoints overview should look like this:

Concluding

Azure Traffic Manager is a cost-effective, relatively easy to set up, robust service in Microsoft’s Azure datacenters to add geo-redundancy to your Active Directory Federation Services (AD FS) implementations.

Further reading

Azure Traffic Manager & ADFS 2012r2
Configure the Web Application Proxy Infrastructure
How to install and configure Web Application Proxy for ADFS
Web Application Proxy Server in 2012 R2
Overview of Traffic Manager

The post Configuring Geo-Redundancy for AD FS on-premises with Azure Traffic Manager appeared first on The things that are better left unspoken.

Azure Active Directory is Microsoft’s Identity Management-as-a-Service solution, offering seamless access, easy collaboration, efficiency in IT processes and improved security and compliance. In its Release Notes for Azure Active Directory, Microsoft communicated the following new functionality for Azure Active Directory for January 2018:

What’s New

New Federated Apps available in Azure AD App gallery

Service category: Enterprise Apps
Product capability: 3rd Party Integration

In January 2018, the following new apps with federation support were added in the Azure AD App gallery :

• IBM OpenPages
• OneTrust Privacy Management Software
• Dealpath
• IriusRisk Federated Directory
• Fidelity NetBenefits

“Sign-in with additional risk detected”

Service category: Identity Protection
Product capability: Identity Security & Protection

While Azure AD Premium P2 provides the most detailed information about all underlying insights for detected risk events, the information is also provided to organizations with Azure AD Premium P1 licenses. For these organizations, detections that are not covered by their license appear as the risk event “Sign-in with additional risk detected”.

Hide Office 365 applications from end user’s access panels

Service category: My Apps
Product capability: Single Sign-On (SSO)

You can now better manage how Office 365 applications show up on your user’s access panels through a new user setting. This option is helpful for reducing the amount of apps in a user’s access panels if you prefer to only show Office apps in the Office portal. The setting is located in the User Settings and is labeled Users can only see Office 365 apps in the Office 365 portal.

Seamless sign into apps enabled for Password SSO directly from the app’s URL

Service category: My Apps
Product capability: Single Sign-On (SSO)

The My Apps browser extension is now available for Edge, Chrome and Firefox.
This tool gives you the My Apps single-sign on capability as a shortcut in your browser. After installing it, users will see a waffle icon in their browser that provides them quick access to apps. Additionally, login pages for Azure AD-integrated apps are recognized and mention the ability to seamlessly sign in using the browser extension.

What’s Deprecated

Azure AD administration experience in Azure classic portal has been retired

Service category: Azure AD
Product capability: Directory

As of January 8, 2018, the Azure AD administration experience in the Azure classic portal has been retired. This took place in conjunction with the retirement of the Azure classic portal itself. Going forward, you should use the Azure AD admin center for all your portal-based administration of Azure AD.

Phonefactor Web administration experience has been retired

Service category: Azure Multi-Factor Authentication
Product capability: Azure Multi-Factor Authentication

As of January 8, 2018, the PhoneFactor web portal (PFWEB) has been retired. This portal was used for the administration of MFA server, but those functions have been moved into the Azure portal at portal.azure.com.

The MFA configuration is located at: Azure Active Directory > MFA Server

DeprecateD Azure AD reports

Service category: Reporting
Product capability: Identity Lifecycle Management

With the general availability of the new Azure Active Directory Administration console and new APIs now available for both activity and security reports, the report APIs under “/reports” endpoint have been retired as of end of December 31, 2017.

However, two new APIs are available for retrieving Azure AD Activity Logs. The new set of APIs provide richer filtering and sorting functionality in addition to providing richer audit and sign-in activities. The data previously available through the depracted reports can now be accessed through:

• The Azure Active Directory reporting API
• The Identity Protection risk events API in Microsoft Graph

The post What’s New in Azure Active Directory for January 2018 appeared first on The things that are better left unspoken.

Last week, Crayon organized the 7th Nordic Infrastructure Conference (NIC), labeled the Future Edition. Raymond Comvalius and I presented two sessions. In this blogpost I share our pictures and most memorable moments.

On Thursday February 2, Raymond and I were scheduled for the early flight from Amsterdam Schiphol airport to Oslo Gardermoen airport. It meant we had to get out of bed early. It also meant we had front row seats to an amazing view of the moon.

Gardermoen airport was cold and snowy. We had an uneventful, yet delayed, flight due to the snow, that caused limited capacity at the airport. Since this is our fourth visit to Oslo for NIC, we know our way around. We boarded the FlyToGet train to Oslo SentralStasjon and made our way to the Oslo Spektrum in a new record time.

Raymond and I spent Thursday fine tuning our slides and demos. We also sat in some sessions that we found interesting and showed up at Andy Malone’s book signing at the GlassPaper booth. Of course, we also checked out the rooms for our sessions.

For diner, Raymond and I joined Andy Malone, Alexander Nikolic and John Craddock at Brugata Landhandleri, where we enjoyed some delicious lamb shanks.

Friday morning, Raymond and I were scheduled for an 8:30 AM session on Microsoft Multi-Factor Authentication (MFA). This session was scheduled in room 8, which was one of the two suspended stages…

We shared the specifics for MFA Server, Azure MFA and Office 365, as well as some real-world tips and tricks. We had a lot of fun!

Our 2PM session focused on Microsoft’s cloud offerings as an alternative to on-premises datacenters, identity and productivity.

At the end of the session, our audience was unanimous in their opinion if the Microsoft Cloud is ready for prime-time productivity.

After our session, we took the train back to Oslo Gardermoen airport, where we enjoyed diner in the airport lounge with Andy and Sami Laiho, before flying back to Amsterdam.

Thank you!

A big ‘Thank You!’ to all NIC attendees, sponsors, speakers and staff for making the past week such an enjoyable experience!

I hope to see you all next year for NIC 2019.

The post Pictures of NIC Future Edition appeared first on The things that are better left unspoken.

When you get serious about security in Hybrid Identity implementations, you would opt to implement AD FS servers and Web Application Proxies as Server Core installations. However, this poses a slight problem with the Azure AD Connect Health Agent for AD FS, because at first glance, you can’t configure it on Server Core installations of Windows Server.

I have the Azure AD Connect Health Agent for AD FS working on my Server Core-based Active Directory Federation Services (AD FS) servers and my Web Application Proxies. I’ve gone back and forth and have successfully used the method below on AD FS Servers and Web Application Proxies running:

• Server Core installations of Windows Server 2012 R2
• Server Core installations of Windows Server 2016
• Installations of Windows Server version 1709

Let me show you how:

About Azure AD Connect Health

Azure AD Connect Health helps administrators monitor and gain insights into their Hybrid Identity implementations. It enables you to maintain a reliable connection to Office 365 and Microsoft Online Services by providing monitoring capabilities for your key identity components:

• Azure Active Directory Connect installations
• Active Directory Federation Services (AD FS) servers
• Web Application Proxies
• Active Directory Domain Controllers

Azure AD Connect Health makes the key data points about these components easily accessible in the Azure AD Connect Health portal so performance monitoring, usage analysis, troubleshooting and gaining other important insights becomes easy.

Azure AD Connect Health agent for AD FS

To monitor Active Directory Federation Services (AD FS) servers
and Web Application Proxies you can install the Azure AD Connect Health agent for AD FS on these servers.

After installation, the agent needs to be configured to communicate to the Azure Active Directory tenant, that is part of the Hybrid Identity implementation. During configuration, the agent, therefore, asks for global admin credentials.

When communicating to the Azure AD Connect Health service, the Azure AD Connect Health agent for AD FS communicates to several endpoints and sets up outgoing connections, based on TCP 80, TCP443 and TCP5671.

Configuring the Azure AD Connect Health Agent for AD FS on Server Core

Step 1. Download the Azure AD Connect Health AD FS Agent

The first thing we need to do is get our hands on the installer for the Azure AD Connect Health Agent for AD FS. To this purpose, we perform these steps on any Windows installation:

• Go to the Microsoft Azure Portal using your favorite browser.
• Log on with credentials of an account in the Azure Active Directory tenant with Global Admin (Company Administrator) privileges. Perform multi-factor authentication, when prompted.
• In the left navigation pane, click on Azure Active Directory.
• In Azure Active Directory’s navigation pane, click on Azure AD Connect.
• In the main pane for Azure AD Connect, click on the Quick Start tile.
• In the new pane, in the Get Tools section, click the link Download Azure AD Connect Health Agent for AD FS.

• Save the AdHealthAdfsAgentSetup.exe to an easy accessible location.

Step 2. Getting the installer on the Server Core installations

There are several ways to get the installer for Azure AD Connect Health Agent for AD FS onto Server Core installations. While some prefer the file share method, this is not particularly useful in scenarios where the Web Application Proxies are placed in a strictly managed perimeter network, where you’d have RDP access, at best.

There’s a little trick I use to get the files I need onto Server Core installations, making clever use of the built-in functionality of RDP and Notepad.

While you could get fooled into believing you don’t have File Explorer-like functionality on Server Core installation, Notepad actually offers this functionality as part of its File, Open dialogue screens.

I perform these steps:

• On the Windows installation where you previously downloaded the installer for Azure AD Connect Health Agent for AD FS, select the installer by left-clicking it. Then, right-click it and select Copy from the context menu.
• Log on to the Server Core installation using RDP with default settings, using the Remote Desktop Connection (mstsc.exe)
• On the Server Core’s command line, type Notepad.exe.

• In Notepad, click on File in the menu bar, and then click Open.
• In the Open dialogue window, select the option All Files instead of the default Text Documents (.txt) for Files of type:.
• Navigate to a folder where you can easily access the installer from the command line. As I prefer short command lines, I usually place installers in the root of the C:\ drive.
• Click in an empty space in the folder where you’d want to place the installer, and type Ctrl and V at the same time, to paste the installer in the location.

• Verify the file was pasted into the location and then click Cancel in the Open dialogue window.
• Close Notepad.

Note:
For security purposes, disable the clipboard ability for Remote desktop sessions on the Server Core-based Web Application Proxies, when you’re done configuring.

Step 3. Installing the Azure AD Connect Health AD FS Agent

To start the installation of  the Azure AD Connect Health Agent for AD FS, simply run the following command on the command line of the Server Core installation:

C:\AdHealthAdfsAgentSetup.exe

In the Azure AD Connect Health AD FS Agent window, click the Install button.

After the Installation succeeds, click the Configure Now button.

The Azure AD Connect Health Agent for AD FS configuration will fail, stating the following error:

Register-AzureADConnectHealthAgent: The type initializer for ‘Microsoft.identityModel.Clients.ActiveDirectory.Internal.

WindowsFormsWebAuthenticationDialogBase’ threw an exception.

This is expected.

A log file is created. When you go through the log file, you’ll notice a line stating

Unable to load DLL ‘IEFRAME.dll’: The specified module could not be found. (Exception from HRESULT: 0x8007007E)

Here is the cause of the failure. Internet Explorer is not availabile on Server Core installations and the Azure AD Connect Health Agent for AD FS tries to leverage Internet Explorer to display the login prompt for Azure Active Directory, using the Azure Active Directory Authentication Libraries (ADAL) experience.

Step 4. Configuring the Azure AD Connect Health AD FS Agent

Luckily, the Azure AD Connect Health Agent for AD FS provides information how to solve this situation. To solve this issue, we are advised to run the Register-AzureADConnectHealthADFSAgent PowerShell Cmdlet manually.

Now, of course, strictly running it results in the same error. Therefore, we run it slightly different, in a way that consists of two lines of PowerShell code:

$cred = Get-Credential

Register-AzureADConnectHealthADFSAgent -Credential $cred

After the first line of PowerShell, we are prompted for credentials. We need to enter the userPrincipalName and password for an account in Azure Active Directory with Global Admin (Company Administrator) privileges in the Azure AD Tenant and does not have multi-factor authentication enabled.

Note:
Enforcing multi-factor authentication on privileged accounts in Azure Active Directory is a best practice, and actually free for admins. However, in this case, we need to temporarily use an account without multi-factor authentication.

After the second line of PowerShell code, the Azure AD Connect Health Agent for AD FS will be successfully configured and communicating to the Azure AD Connect Health endpoints, reporting:

Agent registration completed successfully.

Concluding

You can get the Azure AD Connect Health Agent for AD FS working on Server Core installations.

However, you can’t configure it, when using a privileged Azure Active Directory account that has multi-factor authentication enforced.

The post Configuring the Azure AD Connect Health Agent for AD FS on Server Core appeared first on The things that are better left unspoken.

Most Microsoft-based Hybrid Identity implementations use Active Directory Federation Services (AD FS) Servers, Web Application Proxies and Azure AD Connect installations.

These components have requirements of Active Directory Domain Services (AD DS) in terms of the schema, the Windows Server versions on the Domain Controllers an organization runs, the Domain Functional Level (DFL) and the Forest Functional Level (FFL).

The requirements and the information on the features you gain when you run certain Active Directory Domain Services constellations is scattered over the Internet, so I decided to create one blogpost with all this information in seven scenarios that may depict your organization’s specific Active Directory characteristics:

1. Everything on Windows Server 2003
2. Using Windows Server 2008 Domain Controllers, but 2003 functional levels
3. Everything on Windows Server 2008
4. Everything on Windows Server 2008 R2
5. Running the Windows Server 2012 R2 schema, and a minimum Operating Systems of Windows Server 2008 R2 on your Domain Controller, for your Domain Functional Level and Forest Functional Level
6. Running the Windows Server 2016 schema, and a minimum Operating Systems of Windows Server 2008 R2 on your Domain Controller, for your Domain Functional Level and Forest Functional Level
7. Running the Windows Server 2016 schema, and at least one Windows Server 2016-based Domain Controller in your environment and functional levels defined as Windows Server 2008 R2, or up.

Legend

In the above tables, the colors represent the inability to deploy Domain Controllers with an Operating System (on the row labeled ‘Active Directory Domain Controllers’) in red, the possibility but not necessity to deploy Domain Controllers with an Operating System, raise the Domain Functional Level or raise the Forest Functional Level in orange, and the requirement to meet to unlock certain Hybrid Identity features in green.

Scenario 1: Everything Windows Server 2003

Although we all know Windows Server 2003 is no longer supported unless you have an extended support contract with Microsoft, there are still organizations out there, that have Windows Server 2003-based Domain Controllers.

In this scenario, you gain the following functionality:

Active Directory Federation Services

AD FS functionality you can use:

• You can add AD FS Servers running AD FS 2.0 and AD FS 2.1
• You can add AD FS Servers running Windows Server 2012 R2

AD FS functionality you cannot use:

• You cannot add Windows Server 2016-based AD FS Servers to an AD FS Farm running Windows Server 2012 R2.
• You cannot use client certificate authentication if the certificate is explicitly mapped to a user’s account in Active Directory Domain Services (AD DS).
• You cannot use a group Managed Service Account (gMSA) as the AD FS service account.
• Although you can implement Windows Server 2012 R2-based AD FS servers, you cannot deploy Workplace Join through the Device Registration Service.
• Since you cannot implement AD FS Servers running Windows Server 2016 you cannot have the built-in Azure MFA adapter, device compliance claims, Windows Hello for Business (also known as Passport for Work), per-Relying Party Trust (RPT) branding, and/or streamlined auditing.
• Since you cannot implement AD FS Servers running Windows Server 2016 you cannot federate applications using Open ID Connect, SCIM or SAML 2.0 eGov.
• In multi-forest environments, Active Directory forests with user accounts in scope for federation will need 2-way trusts with the Active Directory forest where the AD FS Farm is joined to.

Web Application Proxies

Device authentication will use TCP port 49443 for device authentication on Web Application Proxies running Windows Server 2012 R2.

Azure AD Connect

Azure AD Connect features you can use:

• You can use Azure AD Connect with Federation and Password Hash Sync as sign-in method.

Azure AD Connect features you cannot use:

• You cannot use the Device Write-back feature.
• You cannot use the Password Write-back feature, unless:
  • You add at least one Windows Server 2008-based Active Directory Domain Controller to the environment and install hotfix KB2386717 to the intended server running Azure AD Connect
  • You add at least one Windows Server 2008 R2-based Active Directory Domain Controller (or up) to the environment.
• You cannot use a group Managed Service Account (gMSA) as the service account.
• You cannot use the Active Directory Recycle Bin feature. Azure AD Connect recommends this feature and will notify you when you run the Azure AD Connect wizard.

Scenario 2: Windows Server 2008 Mixed

Now, many organizations have upgraded their Active Directory Domain Controllers to Windows Server 2008 in the past years. Some organizations, though, may have forgotten to also raise the Active Directory Domain Functional Level (DFL) and Active Directory Forest Functional Level (FFL).

In this scenario, the following functionality is available:

Active Directory Federation Services

AD FS functionality you can use:

• You can add AD FS Servers running AD FS 2.0 and AD FS 2.1
• You can add AD FS Servers running Windows Server 2012 R2
• You can add AD FS Servers running Windows Server 2016 to Windows Server 2012 R2-based AD FS Farms, however, you cannot setup new AD FS Farms with Windows Server 2016 AD FS Servers only.

AD FS functionality you cannot use:

• You cannot use client certificate authentication if the certificate is explicitly mapped to a user’s account in Active Directory Domain Services (AD DS).
• You cannot use a group Managed Service Account (gMSA) as the AD FS service account.
• Although you can implement AD FS Servers running Windows Server 2016, you cannot use Workplace Join through the Device Registration Service, the built-in Azure MFA adapter, device compliance claims, Windows Hello for Business (also known as Passport for Work), per-Relying Party Trust (RPT) branding, and/or streamlined auditing. These features require you to upgrade the AD FS Farm Behavioral Level (FBL) to Windows Server 2016.
• Although you can implement AD FS Servers running Windows Server 2016, you cannot federate applications using Open ID Connect, SCIM or SAML 2.0 eGov. These protocols require you to upgrade the AD FS Farm Behavioral Level (FBL) to Windows Server 2016.
• In multi-forest environments, Active Directory forests with user accounts in scope for federation will need 2-way trusts with the Active Directory forest where the AD FS Farm is joined to.

Web Application Proxies

Device authentication will use TCP 49443 for device authentication on Web Application Proxies running Windows Server 2012 R2 and Windows Server 2016.

Azure AD Connect

Azure AD Connect features you can use:

• You can use Azure AD Connect with Federation and Password Hash Sync as sign-in method.
• You can use the Password Write-back feature, but you will need to install hotfix KB2386717 to the intended server running Azure AD Connect.

Azure AD Connect features you cannot use:

• You cannot use the Device Write-back feature.
• You cannot use a group Managed Service Account (gMSA) as the service account.
• You cannot use the Active Directory Recycle Bin feature. Azure AD Connect recommends this feature and will notify you when you run the Azure AD Connect wizard.

When compared to the previous scenario, your organization effectively gains the ability to add Windows Server 2016-based AD FS Servers to existing Windows Server 2012 R2-based AD FS farms, but cannot take advantage of the Windows Server 2016 AD FS Farm Behavioral Level. In addition, you can now take advantage of Password Write-back through Azure AD Connect.

Scenario 3: Everything Windows Server 2008

When you’ve implemented Active Directory Domain Services using Windows Server 2008 as the Operating System for all Domain Controllers, the Active Directory Domain Functional Level (DFL), the Active Directory Forest Functional Level (FFL) and the Active Directory schema, you are part of this scenario.

In this scenario, the following functionality is available:

Active Directory Federation Services

AD FS functionality you can use:

• You can add AD FS Servers running AD FS 2.0 and AD FS 2.1
• You can add AD FS Servers running Windows Server 2012 R2
• You can add AD FS Servers running Windows Server 2016, however, you cannot setup new AD FS Farms with Windows Server 2016 AD FS Servers only.
• You can use client certificate authentication if the certificate is explicitly mapped to a user’s account in Active Directory Domain Services (AD DS).

AD FS functionality you cannot use:

• You cannot use a group Managed Service Account (gMSA) as the AD FS service account.
• Although you can implement AD FS Servers running Windows Server 2016, you cannot use Workplace Join through the Device Registration Service, the built-in Azure MFA adapter, device compliance claims, Windows Hello for Business (also known as Passport for Work), per-Relying Party Trust (RPT) branding, and/or streamlined auditing. These features require you to upgrade the AD FS Farm Behavioral Level (FBL) to Windows Server 2016.
• Although you can implement AD FS Servers running Windows Server 2016, you cannot federate applications using Open ID Connect, SCIM or SAML 2.0 eGov. These protocols require you to upgrade the AD FS Farm Behavioral Level (FBL) to Windows Server 2016.
• In multi-forest environments, Active Directory forests with user accounts in scope for federation will need 2-way trusts with the Active Directory forest where the AD FS Farm is joined to.

Web Application Proxies

Device authentication will use TCP 49443 for device authentication on Web Application Proxies running Windows Server 2012 R2 and Windows Server 2016. This feature require you to upgrade the AD FS Farm Behavioral Level (FBL) to Windows Server 2016.

Azure AD Connect

Azure AD Connect features you can use:

• You can use Azure AD Connect with Federation and Password Hash Sync as sign-in method.
• You can use the Password Write-back feature, but you will need to install hotfix KB2386717 to the intended server running Azure AD Connect.

Azure AD Connect features you cannot use:

• You cannot use the Device Write-back feature.
• You cannot use a group Managed Service Account (gMSA) as the service account.
• You cannot use the Active Directory Recycle Bin feature. Azure AD Connect recommends this feature and will notify you when you run the Azure AD Connect wizard.

Effectively, your organization gains the ability to perform client certificate authentication when certificates are explicitly mapped to users’ accounts in Active Directory Domain Services (AD DS).

Scenario 4: Everything Windows Server 2008 R2

When you’ve implemented Active Directory Domain Services using Windows Server 2008 as the Operating System for all Domain Controllers, the Active Directory Domain Functional Level (DFL), the Active Directory Forest Functional Level (FFL) and the Active Directory schema, you are part of this scenario.

Note:
Although Windows Server 2008 R2 allows you to revert the Active Directory functional levels, when you enable the Active Directory Recycle Bin feature, it cannot be reverted back to a lower functional level.

In this scenario, the following functionality is available:

Active Directory Federation Services

AD FS functionality you can use:

• You can add AD FS Servers running AD FS 2.0 and AD FS 2.1
• You can add AD FS Servers running Windows Server 2012 R2
• You can add AD FS Servers running Windows Server 2016, however, you cannot setup new AD FS Farms with Windows Server 2016 AD FS Servers only.
• You can use client certificate authentication if the certificate is explicitly mapped to a user’s account in Active Directory Domain Services (AD DS).
• You can use a group Managed Service Account (gMSA) as the AD FS service account on Windows Server 2012 R2-based AD FS Servers and Windows Server 2016-based AD FS Servers.

AD FS functionality you cannot use:

• Although you can implement AD FS Servers running Windows Server 2016, you cannot use Workplace Join through the Device Registration Service, the built-in Azure MFA adapter, device compliance claims, Windows Hello for Business (also known as Passport for Work), per-Relying Party Trust (RPT) branding, and/or streamlined auditing. These features require you to upgrade the AD FS Farm Behavioral Level (FBL) to Windows Server 2016.
• Although you can implement AD FS Servers running Windows Server 2016, you cannot federate applications using Open ID Connect, SCIM or SAML 2.0 eGov. These protocols require you to upgrade the AD FS Farm Behavioral Level (FBL) to Windows Server 2016.
• In multi-forest environments, Active Directory forests with user accounts in scope for federation will need 2-way trusts with the Active Directory forest where the AD FS Farm is joined to.

Web Application Proxies

Device authentication will use TCP 49443 for device authentication on Web Application Proxies running Windows Server 2012 R2 and Windows Server 2016. This feature require you to upgrade the AD FS Farm Behavioral Level (FBL) to Windows Server 2016.

Azure AD Connect

Azure AD Connect features you can use:

• You can use Azure AD Connect with Federation and Password Hash Sync as sign-in method.
• You can use the Password Write-back feature, but you will need to install hotfix KB2386717 to the intended server running Azure AD Connect.
• You can use a group Managed Service Account (gMSA) as the service account.
• You can use the Active Directory Recycle Bin feature.

Azure AD Connect features you cannot use:

• You cannot use the Device Write-back feature.

Effectively, your organization gains the ability to use group Managed Service Accounts (gMSAs) for Active Directory Federation Services and Azure AD Connect, and benefit from the Active Directory Recycle Bin.

Scenario 5: The Magic of the Windows Server 2012 R2 Schema

When you’ve implemented Active Directory Domain Services using Windows Server 2008 as the Operating System for all Domain Controllers, the Active Directory Domain Functional Level (DFL), the Active Directory Forest Functional Level (FFL) and the Active Directory schema, you can optionally upgrade the Active Directory schema to Windows Server 2012 R2.

Note:
Although Windows Server 2008 R2 allows you to revert the Active Directory functional levels, when you enable the Active Directory Recycle Bin feature, it cannot be reverted back to a lower functional level.

In this scenario, the following functionality is available:

Active Directory Federation Services

AD FS functionality you can use:

• You can add AD FS Servers running AD FS 2.0 and AD FS 2.1
• You can add AD FS Servers running Windows Server 2012 R2
• You can add AD FS Servers running Windows Server 2016, however, you cannot setup new AD FS Farms with Windows Server 2016 AD FS Servers only.
• You can use client certificate authentication if the certificate is explicitly mapped to a user’s account in Active Directory Domain Services (AD DS).
• You can use a group Managed Service Account (gMSA) as the AD FS service account on Windows Server 2012 R2-based AD FS Servers and Windows Server 2016-based AD FS Servers.
• You can deploy the Device Registration Service on AD FS servers running Windows Server 2012 R2.

AD FS functionality you cannot use:

• Although you can implement AD FS Servers running Windows Server 2016, you cannot use its Workplace Join through the Device Registration Service, the built-in Azure MFA adapter, device compliance claims, Windows Hello for Business (also known as Passport for Work), per-Relying Party Trust (RPT) branding, and/or streamlined auditing. These features require you to upgrade the AD FS Farm Behavioral Level (FBL) to Windows Server 2016.
• Although you can implement AD FS Servers running Windows Server 2016, you cannot federate applications using Open ID Connect, SCIM or SAML 2.0 eGov. These protocols require you to upgrade the AD FS Farm Behavioral Level (FBL) to Windows Server 2016.
• In multi-forest environments, Active Directory forests with user accounts in scope for federation will need 2-way trusts with the Active Directory forest where the AD FS Farm is joined to.

Web Application Proxies

Device authentication will use TCP 49443 for device authentication on Web Application Proxies running Windows Server 2012 R2 and Windows Server 2016, by default. This feature require you to upgrade the AD FS Farm Behavioral Level (FBL) to Windows Server 2016.

Azure AD Connect

Azure AD Connect features you can use:

• You can use Azure AD Connect with Federation and Password Hash Sync as sign-in method.
• You can use the Password Write-back feature, but you will need to install hotfix KB2386717 to the intended server running Azure AD Connect.
• You can use a group Managed Service Account (gMSA) as the service account.
• You can use the Active Directory Recycle Bin feature.
• You can use the Device Write-back feature.

You can use all of Azure AD Connect features.

Effectively, your organization gains the ability to use the Device Registration Service on Windows Server 2012 R2-based AD FS Servers. Azure AD Connect offers the ability to perform Device Write-back, too.

Scenario 6: Unlock most features with the Windows Server 2016 Schema

When you’ve implemented Active Directory Domain Services using Windows Server 2008 as the Operating System for all Domain Controllers, the Active Directory Domain Functional Level (DFL), the Active Directory Forest Functional Level (FFL) and the Active Directory schema, you can optionally upgrade the Active Directory schema to Windows Server 2016.

Note:
Although Windows Server 2008 R2 allows you to revert the Active Directory functional levels, when you enable the Active Directory Recycle Bin feature, it cannot be reverted back to a lower functional level.

In this scenario, the following functionality is available:

Active Directory Federation Services

AD FS functionality you can use:

• You can add AD FS Servers running AD FS 2.0 and AD FS 2.1
• You can add AD FS Servers running Windows Server 2012 R2
• You can add AD FS Servers running Windows Server 2016, and even setup new AD FS Farms with Windows Server 2016 AD FS Servers only.
• You can use client certificate authentication if the certificate is explicitly mapped to a user’s account in Active Directory Domain Services (AD DS).
• You can use a group Managed Service Account (gMSA) as the AD FS service account on Windows Server 2012 R2-based AD FS Servers and Windows Server 2016-based AD FS Servers.
• You can deploy the Device Registration Service and use Workplace Join.
• When your organization runs the Windows Server 2016 AD FS Farm Behavioral Level (FBL) (by either adding Windows Server 2016-based AD FS Servers to a Windows Server 2012 R2-based AD FS Farm, removing the Windows Server 2012 R2-based AD FS servers and raising the FBL, or by starting a new AD FS Farm using Windows Server 2016-based AD FS Servers, only), your organization can use the built-in Azure MFA adapter, device compliance claims, per-Relying Party Trust (RPT) branding, streamlined auditing, and/or federate applications using Open ID Connect, SCIM or SAML 2.0 eGov.
• In multi-forest environments, Active Directory forests with user accounts in scope for federation no longer need 2-way trusts.

AD FS functionality you cannot use:

• Although you can implement AD FS Servers running Windows Server 2016, you cannot use Windows Hello for Business (also known as Passport for Work).

Web Application Proxies

Device authentication will use TCP 443 for device authentication for AD FS Farms running the Windows Server 2016 Farm Behavioral Level (FBL) when you add the certauth.sts.domain.tld Subject Alternative Name (SAN) to the AD FS Service Communications Certificate.

Azure AD Connect

You can use all of Azure AD Connect features.

Effectively, your organization gains the ability to deploy new AD FS Farms using Windows Server 2016 with all its great features and upgrade existing Windows Server 2012 R2-based AD FS Farms to do the same. Azure AD Connect offers all its functionality.

Scenario 7: Unlock Windows Hello for Business with a Windows Server 2016 Domain Controller

Regardless of the Active Directory Domain Functional Level (DFL), the Active Directory Forest Functional Level (FFL), you can unlock all current Hybrid Identity features when you run the Windows Server 2016 Active Directory schema and deploy at least one Domain Controller running Windows Server 2016.

Note:
Although Windows Server 2008 R2 allows you to revert the Active Directory functional levels, when you enable the Active Directory Recycle Bin feature, it cannot be reverted back to a lower functional level.

In this scenario, the following functionality is available:

Active Directory Federation Services

You can use all of the features of Active Directory Federation Services.

Web Application Proxies

Device authentication will use TCP 443 for device authentication for AD FS Farms running the Windows Server 2016 Farm Behavioral Level (FBL) when you add the certauth.sts.domain.tld Subject Alternative Name (SAN) to the AD FS Service Communications Certificate.

Azure AD Connect

You can use all of Azure AD Connect features.

Effectively, your organization gains the ability to use Windows Hello for Business (also known as Passport for Work).

Concluding

While Hybrid Identity doesn’t require the most recent Active Directory functional levels, it does depend on the latest Active Directory schema.

My advice will always be to upgrade the schema to the latest version of Windows Server, whenever you extend the schema for anything else, like Exchange Server, Skype for Business or the Local Administrator Password Solution (LAPS).

When you’re running the Windows Server 2008 R2 Active Directory Functional Levels you’ll be fine, with the exception of the Windows Hello for Business feature, that requires at least one Windows Server 2016-based Domain Controller.

Resources

I’ve used these official Microsoft Documentation resources to create the lists above:

AD FS Requirements for Windows Server 2012 R2
AD FS Requirements for Windows Server 2016
Prerequisites for Azure AD Connect
Azure AD Connect: Enabling device Write-back
What’s New in AD DS: Active Directory Recycle Bin

The post Hybrid Identity features per Active Directory Domain Services Domain Controller Operating System, Domain Functional Level, Forest Functional Level and Schema version appeared first on The things that are better left unspoken.

Last week, Microsoft announced the latest Windows Server Insider Preview build, nicknamed Build 17093, referencing its 10.0.17093.1000 version number. This Windows Server version was released to Windows Server Insiders on February 13, 2018.

About Windows Server Preview Build 17093

This build is a preview build of the next Semi-Annual Channel (SAC) release of Windows Server.

Microsoft uses two release channels:

1. The Long-term Servicing Channel (LTSC)
2. The Semi-annual Channel (SAC)

The Long-term Servicing Channel is the release channel most IT Pros are familiar with. Windows Server 2016 is Microsoft latest LTSC-released Windows Server version.

The Semi-annual Channel is the new release channel. Windows Server, version 1709 was Microsoft first SAC-release. Microsoft intends to release SAC-releases twice per year (hence the name). SAC releases differ from LTSC releases in several ways, beyond their intended shorter release schedules: SAC releases don’t have graphical interfaces and SAC releases have shorter support cycles.

Windows Server Preview Build 17093 is only available as Server Core installation and Nano Server. Windows Server Preview Build 17093 will stop working on July 2, 2018.

Known issue for Domain Controllers

The Known Issues section of the blogpost titled Announcing Windows Server Insider Preview Build 17093 and Project Honolulu Technical Preview 1802 by Donna Sarkar on February 3, 2018 mentions:

In-place OS upgrade: Domain Controllers

During an in-place OS upgrade, Active Directory (AD) Domain Controllers (DC) might not be upgraded correctly. Back up any AD DCs before performing an in-place OS upgrade.

Further reading

Known issues with Windows Server Build 17093
Microsoft Announces Windows Server 17093 Preview

The post In-place upgrading an Active Directory Domain Controller to Windows Server build 17093 might fail appeared first on The things that are better left unspoken.

Azure Active Directory is Microsoft’s Identity Management-as-a-Service solution, offering seamless access, easy collaboration, efficiency in IT processes and improved security and compliance. In its Release Notes for Azure Active Directory, Microsoft communicated the following new functionality for Azure Active Directory for February 2018:

What’s New

Availability of sign-ins and audit reports in Azure in China

Service category: Sovereign Clouds
Product capability: Monitoring & Reporting

Azure AD Activity log reports are now available in the Azure in China sovereign instance (codename “Mooncake”). The following logs are included:

• Sign-ins activity logs – Includes all the sign-ins logs associated with your tenant.
• Self service Password Audit Logs – Includes all the SSPR audit logs.
• Directory Management Audit logs – Includes all the directory management related audit logs like User management, App Management, and others.

With these logs, you can gain insights into how your environment is doing. The provided data enables you to:

• Determine how your apps and services are utilized by your users.
• Troubleshoot issues preventing your users from getting their work done.

Use the “Report Reader” role to view Azure AD Activity Reports

Service category: Reporting
Product capability: Monitoring & Reporting

As part of customers feedback to enable non-admin roles to have access to Azure AD activity logs, we have enabled the ability for users who are in the “Report Reader” role to access Sign-ins and Audit activity within the Azure Portal as well as using our Graph APIs to this purpose.

EmployeeID claim available as user attribute and user identifier

Service category: Enterprise Apps
Product capability: SSO

You can configure EmployeeID as the User identifier and User attribute for member users and B2B guests in SAML-based sign-on applications from the Enterprise application UI.

Simplified Application Management using Wildcards in Azure AD Application Proxy

Service category: App Proxy
Product capability: User Authentication

To make application deployment easier and reduce your administrative overhead, we now support the ability to publish applications using wildcards. To publish a wildcard application, you can follow the standard application publishing flow, but use a wildcard in the internal and external URLs.

New Windows PowerShell Cmdlets to support configuration of Application Proxy

Service category: App Proxy
Product capability: Platform

The latest release of the AzureAD PowerShell Preview module contains new cmdlets that allows customers to configure Application Proxy Applications using PowerShell.

The new cmdlets are:

• Get-AzureADApplicationProxyApplication
  
• Get-AzureADApplicationProxyApplicationConnectorGroup
  
• Get-AzureADApplicationProxyConnector
  
• Get-AzureADApplicationProxyConnectorGroup
  
• Get-AzureADApplicationProxyConnectorGroupMembers
  
• Get-AzureADApplicationProxyConnectorMemberOf
  
• New-AzureADApplicationProxyApplication
  
• New-AzureADApplicationProxyConnectorGroup
  
• Remove-AzureADApplicationProxyApplication
  
• Remove-AzureADApplicationProxyApplicationConnectorGroup
  
• Remove-AzureADApplicationProxyConnectorGroup
  
• Set-AzureADApplicationProxyApplication
  
• Set-AzureADApplicationProxyApplicationConnectorGroup
  
• Set-AzureADApplicationProxyApplicationCustomDomainCertificate
  
• Set-AzureADApplicationProxyApplicationSingleSignOn
  
• Set-AzureADApplicationProxyConnector
  
• Set-AzureADApplicationProxyConnectorGroup

What’s Changed

Applications supporting Intune App

Protection policies added for use with Azure AD application-based conditional access

Service category: Conditional Access
Product capability: Identity Security & Protection

We have added more applications that support application-based conditional access. Now, you can get access to Office 365 and other Azure AD-connected cloud apps using these approved client apps.

The following applications will be added by the end of February

• Microsoft PowerBI
• Microsoft Launcher
• Microsoft Invoicing

Terms of Use update to mobile experience

Service category: Terms of Use
Product capability: Governance

When the terms of use are displayed, you can now click Having trouble viewing? Click here. Clicking this link opens the terms of use natively on your device. Regardless of the font size in the document or the screen size of device, you can zoom and read the document as needed.

What’s Planned

Improved navigation for managing users and groups

Service category: Directory Management
Product capability: Directory

The navigation experience for managing users and groups will be streamlined.
You can navigate from the directory overview directly to the list of all users, with easier access to the list of deleted users. You can also navigate from the directory overview directly to the list of all groups, with easier access to group management settings. And also from the directory overview page, you can search for a user, group, enterprise application, or app registration.

The post What’s New in Azure Active Directory for February 2018 appeared first on The things that are better left unspoken.

Windows Server 2016’s January 2018’s Cumulative Quality Update, bringing the OS version to 14393.2034, offers several fixes for Certification Authorities (CAs) running Active Directory Certificate Services (AD CS).

About Windows Server 2016 Updates

Microsoft issues two major updates each month for Windows Server 2016, as outlined in the Patching with Windows Server 2016 blogpost.

On the second Tuesday of each month (Patch Tuesday) Microsoft issues a cumulative update that includes security and quality fixes for Windows Server 2016. Being cumulative, this update includes all the previously released security and quality fixes.

In the second half of each month (generally the 3rd week of the month) Microsoft releases a non-security / quality update for Windows Server 2016.  This update, too, is cumulative and includes all quality and security fixes shipped prior to this release. 

Active Directory Certificate Services Fixes

Windows Server 2016’s January 2018’s Cumulative Quality Update addresses two issues with Active Directory Certificate Services (AD CS).

NDES cannot match issuer and serial number

The first fix addresses an issue where retrieving the Certificate Revocation List (CRL) from the Certification Authority (CA) using the Simple Certificate Enrollment Protocol (SCEP) fails. Users see event ID 45, which says, “NDES cannot match issuer and serial number in the device request with any Certification Authority (CA) Certificate”.

Invalid OCSP response for expired certificate

The second fix addresses an issue where, if the Online Certificate Status Protocol (OCSP) renewal date comes after the certificate expiration date, the OCSP-stapled response is used until the renewal date, even though the certificate has expired.

Call to action

When you experience any one of these issues, you are invited to install Windows Server 2016’s January 2018’s Cumulative Quality Update (KB4057142) on your Certification Authorities (CAs) running Active Directory Certificate Services to resolve them.

Known Issues

After installing this update, servers where Credential Guard is enabled may experience an unexpected restart with the error, “The system process lsass.exe terminated unexpectedly with status code -1073740791. The system will now shut down and restart.” This issue can be resolved by disabling Credential Guard.

Editing some group policies using GPMC or AGPM 4.0 may fail with error “The data present in the reparse point buffer is invalid. (Exception from HRESULT: 0x80071128)” after installing this update on a domain controller. This issue is resolved in KB4074590.

After installing this update, some users may experience issues logging into some websites when using third-party account credentials in Microsoft Edge. This issue is resolved in KB4074590.

The post Windows Server 2016’s January 2018 Quality Update fixes several AD CS issues appeared first on The things that are better left unspoken.

Windows Server 2016’s January 2018’s Cumulative Quality Update, bringing the OS version to 14393.2034, offers several fixes for Secure Token Servers (STSs) running Active Directory Federation Services (AD FS).

About Windows Server 2016 Updates

Microsoft issues two major updates each month for Windows Server 2016, as outlined in the Patching with Windows Server 2016 blogpost.

On the second Tuesday of each month (Patch Tuesday) Microsoft issues a cumulative update that includes security and quality fixes for Windows Server 2016. Being cumulative, this update includes all the previously released security and quality fixes.

In the second half of each month (generally the 3rd week of the month) Microsoft releases a non-security / quality update for Windows Server 2016.  This update, too, is cumulative and includes all quality and security fixes shipped prior to this release. 

Active Directory Federation Services Fixes

Windows Server 2016’s January 2018’s Cumulative Quality Update addresses four issues with Active Directory Federation Services (AD FS).

Showing the HRD page for Oauth groups with one IDP

The first fix addresses an issue where AD FS incorrectly displays the Home Realm Discovery (HRD) page when an identity provider (IDP) is associated with a relying party (RP) in an OAuth Group. Unless multiple IDPs are associated with the RP in the OAuth Group, the user isn’t shown the HRD page. Instead, the user is navigated directly to an associated IDP for authentication.

PKeyAuth-based device authentication sometimes fails

The second fix addresses issue where PKeyAuth-based device authentication sometimes fails in Internet Explorer and Microsoft Edge when AD FS returns a context that exceeds the request limits for URL length. Event 364 is logged in the AD FS 2.0 Admin log with the following exception details:

System.Security.Cryptography.CryptographicException: The signature is not valid. The data may have been tampered with….

MSISConext cookies overflow the headers’ size limit

The third fix addresses an issue in AD FS where MSISConext cookies in request headers can eventually overflow the headers’ size limit. This causes authentication failure with the HTTP status code 400:

Bad Request – Header Too Long.

MFA Event 1200 doesn’t contain UserID information

The fourth fix addresses an issue where AD FS produces an MFA Event 1200 log that doesn’t contain UserID information.

Call to action

When you experience any one of these issues, you are invited to install Windows Server 2016’s January 2018’s Cumulative Quality Update (KB4057142) on your AD FS Servers to resolve them.

Known Issues

After installing this update, servers where Credential Guard is enabled may experience an unexpected restart with the error, “The system process lsass.exe terminated unexpectedly with status code -1073740791. The system will now shut down and restart.” This issue can be resolved by disabling Credential Guard.

Editing some group policies using GPMC or AGPM 4.0 may fail with error “The data present in the reparse point buffer is invalid. (Exception from HRESULT: 0x80071128)” after installing this update on a domain controller. This issue is resolved in KB4074590.

After installing this update, some users may experience issues logging into some websites when using third-party account credentials in Microsoft Edge. This issue is resolved in KB4074590.

The post Windows Server 2016’s January 2018 Quality Update fixes several AD FS issues appeared first on The things that are better left unspoken.

Windows Server 2016’s February 2018’s Cumulative Quality Update, bringing the OS version to 14393.2097, offers a fix you might be experiencing with empty values for Attribute in EventID 5136 for Directory Services Changes on Windows Server 2016-based Active Directory Domain Controllers.

About Windows Server 2016 Updates

Microsoft issues two major updates each month for Windows Server 2016, as outlined in the Patching with Windows Server 2016 blogpost.

On the second Tuesday of each month (Patch Tuesday) Microsoft issues a cumulative update that includes security and quality fixes for Windows Server 2016. Being cumulative, this update includes all the previously released security and quality fixes.

In the second half of each month (generally the 3rd week of the month) Microsoft releases a non-security / quality update for Windows Server 2016.  This update, too, is cumulative and includes all quality and security fixes shipped prior to this release.

The situation

You enable auditing policies to monitor changes to a directory service object on Windows Servers running the Active Directory Domain Services (AD DS) role and configured as Active Directory Domain Controllers.

An EventID 5136 is added to the security event log after a change to the directory service object occurs.

EventID 5136 should contain the following values:

• When a successful modify operation is performed on an attribute, AD DS logs the previous and current values of the attribute. If the attribute has more than one value, only the values that change as a result of the modify operation are logged.
• If a new object is created, values of the attributes that are populated at the time of creation are logged. If the user adds attributes during the create operation, those new attribute values are logged. In most cases, AD DS assigns default values to attributes (such as samAccountName). The values of such system attributes are not logged.
• If an object is moved, the previous and new location (distinguished name) is logged for moves within the domain. When an object is moved to a different domain, a create event is generated on the domain controller in the target domain.
• If an object is undeleted, the location where the object is moved to is logged. In addition, if the user adds, modifies, or deletes attributes while performing an undelete operation, the values of those attributes are logged.

The issue

When you inspect EventID 5136, the Value field under the Attribute item is empty. This means you cannot monitor the details of the directory service change.

The cause

This occurs when you modify an attribute of an object on Windows Server 2016 Domain Controllers. This problem may occur if you use PowerShell commands (Add-ADGroupMember or Set-ADGroup) to add a user account to a group using the user account’s security identifier (SID) instead of the Distinguished Name.

The solution

When you experience this issue, you are invited to install Windows Server 2016’s February 2018 Cumulative Quality Update (KB4077525) on the Active Directory Domain Controllers running Windows Server 2016 to resolve it.

Known issues

Because of an issue that affects some versions of antivirus software, this fix applies only to computers on which the antivirus ISV updated the ALLOW REGKEY. Contact your antivirus manufacturer to verify that their software is compatible and that they have set the REGKEY.

Further reading

February 22, 2018—KB4077525 (OS Build 14393.2097)
The Value field under the Attribute item for event ID 5136 is empty in Windows Server
AD DS Auditing Step-by-Step Guide

The post Windows Server 2016’s February 2018 Quality Update fixes empty Attribute value in EventID 5136 for Directory Services Changes appeared first on The things that are better left unspoken.

Windows Server 2016’s February 2018’s Cumulative Quality Update, bringing the OS version to 14393.2097, offers several fixes for Secure Token Servers (STSs) running Active Directory Federation Services (AD FS) and Web Application Proxies.

About Windows Server 2016 Updates

Microsoft issues two major updates each month for Windows Server 2016, as outlined in the Patching with Windows Server 2016 blogpost.

On the second Tuesday of each month (Patch Tuesday) Microsoft issues a cumulative update that includes security and quality fixes for Windows Server 2016. Being cumulative, this update includes all the previously released security and quality fixes.

In the second half of each month (generally the 3rd week of the month) Microsoft releases a non-security / quality update for Windows Server 2016.  This update, too, is cumulative and includes all quality and security fixes shipped prior to this release. 

Active Directory Federation Services Fixes

Windows Server 2016’s February 2018’s Cumulative Quality Update addresses four issues with Active Directory Federation Services (AD FS).

Web Application Proxy failed to authenticate the user

The first fix addresses an issue where an HTTP 500 error occurs when an ADFS farm has at least two servers using Windows Internal Database (WID). In this scenario, HTTP basic pre-authentication on the Web Application Proxy (WAP) server fails to authenticate some users. When the error occurs, you might also see the Microsoft Windows Web Application Proxy warning Event ID 13039 in the WAP event log. The description reads:

Web Application Proxy failed to authenticate the user. Pre-authentication is ‘ADFS For Rich Clients’. The given user is not authorized to access the given relying party. The authorization rules of either the target relying party or the WAP relying party are needed to be modified.

AD FS ignores the ‘prompt=login’ parameter

The second fix addresses issue in which AD FS can no longer ignore prompt=login during authentication. A Disabled option was added to support scenarios in which password authentication is not used. For more information, see AD FS ignores the “prompt=login” parameter during an authentication in Windows Server 2016.

‘Prompt=login’ with WIA fails

The third fix addresses an issue in AD FS where Authorized Customers (and relying parties) who select Certificate as an authentication option will fail to connect. The failure occurs when using prompt=login if Windows Integrated Authentication (WIA) is enabled and the request can do WIA.

Error code 0x03000008 occurs when using Remote Desktop

The fourth fix addresses an issue where some Remote Desktop Protocol (RDP) clients that used an absolute URI (instead of a relative URI) were blocked by the Web Application Proxy (WAP) server from connecting to the Remote Desktop Gateway. This affected RDP clients on iOS, Mac, Android, and the Windows modern RDP client app. The error is:

We couldn’t connect to the gateway because of an error. If this keeps happening, ask your admin or tech support for help. Error code: 0x03000008.

Call to action

When you experience any one of these issues, you are invited to install Windows Server 2016’s February 2018’s Cumulative Quality Update (KB4077525) on your AD FS Servers and Web Application Proxies to resolve them.

Known Issues

After installing this update, servers where Credential Guard is enabled may restart unexpectedly. The error is “The system process lsass.exe terminated unexpectedly with status code -1073740791. The system will now shut down and restart.” In this case, disable Windows Defender Credential Guard. Microsoft is working on a resolution and will provide an update in an upcoming release.

The post Windows Server 2016’s February 2018 Quality Update comes highly recommended for AD FS Servers and Web Application Proxies appeared first on The things that are better left unspoken.