Last Thursday, Microsoft released version 1.1.647.0 of Azure AD Connect, its free Hybrid Identity bridge product to synchronize objects and their attributes from on-premises Active Directory Domain Services (AD DS) environments to Azure Active Directory.

At Microsoft Ignite, Microsoft declared Seamless Single Sign-On and Pass-through Authentication features as Generally Available, so the team doubled down on fixing some common issues with these user sign-in methods. Other fixes were also included.

Announcements

The Synchronization Service has a WMI interface that lets you develop your own custom scheduler. This interface is now deprecated and will be removed from future versions of Azure AD Connect shipped after June 30, 2018. Customers who want to customize synchronization schedule should use the built-in scheduler.

What’s New

Azure AD Connect

The team added logic to simplify the steps required to set up Azure AD Connect with Microsoft Germany Cloud. Previously, you are required to update specific registry keys on the Azure AD Connect server for it to work correctly with Microsoft Germany Cloud, as described in this article. Now, Azure AD Connect can automatically detect if your tenant is in Microsoft Germany Cloud based on the global administrator credentials provided during setup.

Azure AD Connect Sync

When troubleshooting Password Synchronization using the Azure AD Connect wizard troubleshooting page, the troubleshooting page now returns domain-specific status.

Previously, if you tried to enable Password Hash Synchronization, Azure AD Connect did not verify whether the AD Connector account had the required permissions to synchronize password hashes from on-premises Active Directory. Now, Azure AD Connect wizard will verify and warn you if the account does not have sufficient permissions.

Fixes

Azure AD Connect

The team fixed an issue in the Change user sign-in task in Azure AD Connect wizard. The issue occurs when you have an existing Azure AD Connect deployment with Password Synchronization enabled, and you are trying to set the user sign-in method as Pass-through Authentication and when you disable or enable Seamless Single Sign-on.

The team also fixed another issue in the Change user sign-in task in Azure AD Connect wizard. The issue occurs when you have an existing Azure AD Connect deployment with Password Synchronization disabled, and you are trying to set the user sign-in method as Pass-through Authentication. When the change is applied, the wizard enables both Pass-through Authentication and Password Synchronization. With this fix, the wizard no longer enables Password Synchronization., because, since Azure AD Connect version 1.1.557.0, Password Synchronization is no longer a prerequisite for enabling Pass-through Authentication.

The team fixed an issue that caused Azure AD Connect upgrades to fail with error “Unable to upgrade the Synchronization Service”. Further, the Synchronization Service could no longer start with event error “The service was unable to start because the version of the database is newer than the version of the binaries installed”. The issue occured when the administrator performing the upgrade did not have sysadmin privilege to the SQL server that is being used by Azure AD Connect. With this fix, Azure AD Connect only requires the administrator to have db_owner privilege to the ADSync database during upgrade.

The team fixed an Azure AD Connect Upgrade issue that affected customers who have enabled Seamless Single Sign-On. After Azure AD Connect is upgraded, Seamless Single Sign-On incorrectly appears as disabled in Azure AD Connect wizard, even though the feature remains enabled and fully functional. With this fix, the feature now appears correctly as enabled in the wizard.

The team fixed an issue that caused Azure AD Connect wizard to always show the Configure Source Anchor prompt on the Ready to Configure page, even if no changes related to Source Anchor were made.

When performing manual in-place upgrade of Azure AD Connect, the customer is required to provide the Global Administrator credentials of the corresponding Azure AD tenant. Previously, upgrade could proceed even though the Global Administrator credentials provided belonged to a different Azure AD tenant. While upgrade appears to complete successfully, certain configurations were not correctly persisted with the upgrade. With this change, the wizard will not allow a manual upgrade to proceed if the credentials provided do not match the Azure AD tenant.

Azure AD Connect health

The team removed redundant logic that unnecessarily restarted Azure AD Connect Health service at the beginning of a manual upgrade.

Azure AD Connect Sync

When Azure AD Connect wizard creates the AD Connector account required to synchronize changes from on-premises Active Directory, it does not correctly assign the account the permission required to read PublicFolder objects. This issue affects both Express installation and Custom installation. This change fixes the issue.

The team fixed an issue that caused the Azure AD Connect Wizard troubleshooting page to not render correctly for administrators running Azure AD Connect on Windows Server 2016.

AD FS Management

The team fixed an issue related to the use of the msDS-ConsistencyGuid as Source Anchor feature. This issue affects customers who have configured Federation with AD FS as the user sign-in method. When you execute the Configure Source Anchor task in the wizard, Azure AD Connect switches to using ms-DS-ConsistencyGuid as source attribute for immutableId. As part of this change, Azure AD Connect attempts to update the claim rules in AD FS. However, this step failed because Azure AD Connect did not have the administrator credentials required to configure AD FS. With this fix, Azure AD Connect now prompts you to enter the administrator credentials for AD FS when you execute the Configure Source Anchor task.

Version information

This is version 1.1.647.0 of Azure AD Connect.
It was signed off on on October 19, 2017.

Download information

You can download Azure AD Connect here.
The download weighs 78,6 MB.

Concluding

This release marks the General Availability of two user sign-in options, that were previously in public preview. It includes many fixes and code cleanup. It should be on the top of your ToDo list to upgrade to (if Azure AD Connect wasn’t upgraded automatically, already), when you use these user sign-in methods.

Also, if you’ve built your own scheduler for Azure AD Connect, based on the WMI calls, you should start planning on using the built-in scheduler.

For months, admins wanting to create and manage their on-premises Azure Multi-factor Authentication Server settings had to resort to the old Azure Portal, based on the Azure Service Management (ASM) model, and the PhoneFactor Web (PFWeb) portal, while the rest of Azure Active Directory moved and improved in the new Azure Portal, based on Azure Resource Manager (ARM).

Today, this divide ends.

What you needed the old portal for

Previously, you’d use the old Azure Portal, if you’d wanted to:

MFA Provider MANAGEMENT

• Create an Azure Multi-Factor Authentication Provider, specifying a name, usage model (per enabled user or per authentication), subscription and (optionally) a directory link. These providers let you enable additional security for directory users and applications that use the Multi-Factor Authentication libraries.
• Delete an Azure Multi-Factor Authentication Provider

Ironically, these actions were all performed on the MULTI-FACTOR AUTH PROVIDERS tab of the ACTIVE DIRECTORY category.

Manage service settings

Additionally, when you’d select the Azure Active Directory in the old Azure Portal, and then go to the CONFIGURE tab and under multi-factor authentication followed the Manage service settings link, you had the opportunity to:

• Allow users to create app passwords to sign in to non-browser apps
• Make specific authentication methods (Call to phone, Text message to phone, Notification through mobile app and Verification code from mobile app) available or unavailable to end-users.
• Allow users to remember multi-factor authentication on devices they trust, and specify the Days before a device must re-authenticate, between 1 and 60 days.

When performing any of the above actions in the old Azure portal, a message would appear on the bottom of the screen warning you that Azure Active Directory management is only possible from the new portal starting November 30, 2017…

To add to the injury, the old Azure Portal was not readily accessible for CSP and DreamSpark customers. They were confronted with the dreaded No subscriptions found. message, that forced them to sign up for an Azure AD-only subscription.

What you needed PFWeb for

In the old Azure Portal, when you’d click the MANAGE button in the bottom pane, you would be directed to the PhoneFactor Web (PFWeb) portal and be automatically signed into the correct MFA Provider. Here you can:

• View reports, on usage, blocked user history, bypassed user history, fraud alerts and queued requests. However, these reports are not accessible using an API.
• View server status
• Configure general settings, like the number of attempts to try for an MFA call, the time-out for two-way text messages and the Caller ID used
• Configure authentication caching settings
• Configure custom voice messages to override the default messages played during an MFA call
• Configure notifications for fraud alerts, account lockouts and one-time bypasses
• View the release notes for the latest on-premises Multi-Factor Authentication Server
• Download the latest version of the on-premises Multi-Factor Authentication Server
• Generate activation credentials to connect on-premises Multi-factor Authentication Server installations to the MFA Provider.
• Download Multi-Factor Authentication Software Development Kits (SDKs) for Perl, Ruby, PHP, Java and several versions of ASP.NET (1.1 C#, 1.1 VB, 2.0 C# and 2.0 VB)

On the left side, a pane would allow you to chose between Azure (Default) settings and MFA Server (Default) settings to divide between the two types of authentication.

Now in the new Azure Portal (in Public Preview)

All of the above functionality is now available in the new Azure Portal.

The preview Multi-Factor Authentication settings are located per Azure Active Directory. To go there, simply sign in to the Azure portal as an administrator, select Azure Active Directory from the left navigation pane and then select MFA Server. in the Security section.

However, there are some things that you need to be aware of:

1. When you create a new MFA Provider, the tenant drop-down list displays tenant IDs, not the tenant name labels.
2. Newly created MFA Providers that you’ve created in the New Azure Portal show up in the Old Azure Portal, and MFA Providers created in the Old Azure Portal show up in the new Azure Portal (as Providers in the MFA Server of Azure Active Directory).
3. The new Azure Portal points to the Microsoft Download Center to get the on-premises MFA Server bits. It specifically points to aka.ms/mfadownload.
4. Just like in the old portal, when you click on the MFA Provider, you can manage its settings, download the bits and generate activation keys. However, the following functionality is currently missing:
1. View the release notes for the latest on-premises Multi-Factor Authentication Server.
2. Currently, there is one field to enter e-mail addresses for notifications. In PFWeb, notification could be sent to different e-mail addresses for fraud alerts, account lockouts and one-time bypasses used.
5. A couple of new settings have been introduced:
1. For users who enter a PIN to authenticate, admins can now set lockout settings (Minutes until account lockout counter is reset and Minutes until account is automatically unblocked) besides the Number of MFA denials to trigger account lockout.
2. Authentication caching is now governed through cache levels (User, Application or IP address) and authentication type.
3. Fraud Alerts are now configurable through an additional setting: Automatically block users who report fraud. This setting is turned on by default. The Allow users to submit fraud alerts is turned off by default (just like in PFWeb), though. Additionally, a code to report fraud during initial greeting can be customized.
4. You can’t download the MFA Server SDK through the new portal.
6. The MFA Service settings have been and still are available through various links in the portals, pointing towards the account.activedirectory.windowsazure.com website. The easiest way to go there, I found, is by signing in to the Azure portal as an administrator, selecting Azure Active Directory from the left navigation pane and then selecting Conditional Access in the Security section. Select Named locations in the navigation blade and click the Configure MFA Trusted IPs, which will take you there. There you’ll be able to:
1. assign MFA status to individual user accounts
2. Allow users to create app passwords to sign in to non-browser apps.
3. Enable Skip multi-factor authentication for requests from federated users on my intranet and specify to Skip multi-factor authentication for requests from following range of IP address subnets.
4. Make specific authentication methods (Call to phone,
   Text message to phone, Notification through mobile
   app and Verification code from mobile app) available
   or unavailable to end-users.
5. Allow users to remember multi-factor authentication on devices they
   trust, and specify the Days before a device must
   re-authenticate, between 1 and 60 days.

Unfortunately, the link at the end of this page to manage advanced settings and view reports, still points to PFWeb…

Concluding

It’s good to see the public preview of Azure Multi-Factor Authentication in the new Azure Portal. Unfortunately, some settings () are missing, because we would love to use the new and improved settings as soon as possible and leave the old Azure Portal behind.

Another good thing is that MFA Providers that you might have created earlier are migrated over to the new Azure Portal and are available for management there. This avoids having to migrate previously deployed on-premises MFA Servers from one ASM-based MFA Provider to a new ARM-based MFA Provider.

Related blogposts

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 
Choosing the right Azure MFA authentication methods 
Creating an MFA Provider when you have CSP or DreamSpark 
Things to know about Billing for Azure MFA and Azure MFA Server

Thursday, last week, I presented a 60-minute session on achieving productivity without an on-premises infrastructure at Lowlands Unite! Belgium Edition.

I was en route pretty early, to avoid traffic jams around Rotterdam and Antwerpen. During the drive, I encountered only a little traffic, so that was good.

As the venue, Lowlands Unite! picked the Lamot brewery. This is a big venue and we occupied two of the many available rooms. The industrial edge of the building makes for an interesting atmosphere and lots of open spaces. Perfect for events, and there were some other events going on during that Thursday.

After an incredible lunch with soup and sandwiches, I presented for 60 minutes in the Cloud and Datacenter Management (CDM) track.

After my session I stayed around to chat with some of the speakers and organizers, but I soon found my way home, to enjoy a nice quiet evening with my family and prepare for some other sessions these next few weeks.

Thank you!

I just came back from San Francisco where I enjoyed the 2017 edition of Penton’s IT/DEV Connections conference.

On Saturday October 22nd, I flew out from Amsterdam Schiphol Airport to Paris Charles de Gaulle Airport, to catch a nice Air France-operated flight to San Francisco in one of their flagship Airbus A380s. My first flight in one of these planes.

All throughout my stay in San Francisco, the weather was really nice. The only clouds I saw during the week were icons in people’s presentations. I was out and about in the city with my Serbian friend Aleksandar Nikolic for two afternoons before IT/DEV Connections started and enjoyed it very much.

On Monday, IT/DEV Connections started.

On Tuesday, I participated in the Cloud & Datacenter Ask the Experts panel. It’s fun to be seated between true experts as Cameron Fuller, Bert Wolters, Dieter Wijckmans, Martyn Coupland, David o’Brien, Darren Mar’elia and John Savill. We engaged the audience with open minds and had some interesting discussions on DevOps, Azure Active Directory and Azure Site Recovery.

On Wednesday, I presented a 75-minute session on Azure Active Directory, Azure Infrastructure-as-a-Service, Azure File Sync, Azure Cloud Print, Windows Autopilot and Office 365. In my opinion, this constellation of Microsoft products enables the vast majority of organizations today to move from on-premises infrastructure to cloud with everything except end-user devices, printers and basic networking. On the other side, some organizations may already be part of the cloud, even though they’d claim to be 100% on-premises organizations…

I enjoyed the session. Luckily, the attendees allowed for an interactive, introspective and interesting session. I’m sure we addressed all of there dreams and nightmares.

After my session I prepared to go home. A couple of us had dinner at Punjab, which is an extremely nice Indian restaurant. My journey back home started on Thursday. but only after a visit to the pool at the Hilton…

Thank you!

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

I hope to see you all next year for IT/DEV Connections 2018 in Dallas, TX.

Next week, I’m joining many of my technical friends at the Hybrid Identity Protection Conference in New York, NY.

For those who attended The Experts Conference (TEC) and NetPro’s Directory Experts Conference (DEC) events previously, the Hybrid Identity Protection Conference promises to be at least as much fun as these events, where you’ve seen the likes of Gil Kirkpatrick, Sean Deuby, Darren Mar-Elia, Brian Desmond, Joe Kaplan and Jorge de Almeida Pinto.

About the Hybrid Identity Protection Conference

The Hybrid Identity Protection Conference is Semperis Inc.’s event in the spirit of The Expert Conference (TEC) to bring together the leading experts in the field of Identity and Access Management. The event offers a unique opportunity to spend two days on-site in New York with peers, whose day-to-day job is to architect, manage, and protect identity management in the hybrid enterprise.

Attendees are able to meet face-to-face with the leading experts of their field, acquire in-depth technical knowledge, and be exposed to the latest innovation.

The 2017 Hybrid Identity Protection Conference takes place on November 6th and November 7th at the famous 7 World Trade Center in New York City’s Tribeca neighborhood. Just minutes’ walk from famous landmarks, attractions, museums, and famous restaurants in Manhattan, and with astounding views of the New York skyline.

About my presentations

I’m delivering three presentations at the inaugural Hybrid Identity Protection Conference. With pride, I’m co-presenting two of my presentations with Roelf Zomerman, the only Dutch Active Directory Microsoft Certified Master (MCM):

Virtualizing Domain Controllers in Hyper-V and Azure

Monday November 6th 2017 3:40PM – 4:40PM

Active Directory Domain Controllers hold the keys to your kingdom. So how do you virtualize these castles of identity, without compromising on the requirements of your organization?

In this session I share my best practices for hardening, backing up, restoring and managing virtualized Domain Controllers on both Hyper-V, Azure Stack and in Azure Infrastructure-as-a-Service VMs, from the field, The information is based on the latest version of Azure and Windows Server 2016, like Shielded VMs, but will also show how the functionality of Windows Server 2012 and Windows Server 2012 R2 already allow for risk mitigation and availability, too, so you don’t have to upgrade everything immediately, if you can’t.

Azure AD Connect, The Dutch Connection

Tuesday November 7th 10AM – 11AM

With businesses adopting more cloud, how do you cope with the new identity challenges? How do you properly design and implement Hybrid Identity in real-world scenarios?

In this first of two demo-packed sessions, two Dutchmen, Sander Berkouwer (Microsoft MVP) and Roelf Zomerman (Microsoft Cloud Solution Architect), explain the ins and outs of Azure AD Connect, the Microsoft’s free Hybrid Identity “bridge” product.

Learn about the history of Azure AD Connect and why and what it does. See authentication scenarios supported by Azure AD Connect and how Azure AD Connect brings your colleagues and their devices to the cloud. You’ll receive useful tips and tricks to apply in your organization.

Azure AD Connect, The World is not Enough

Tuesday November 7th 11:30AM – 12:45AM

Join Roelf Zomerman (Microsoft Cloud Solution Architect) and Sander Berkouwer (Microsoft MVP) for the second session in their Azure AD Connect series, where they open the door to the world behind complex Hybrid Identity architectures. (And to people who didn’t attend the first session, of course.)

Like the Dutch explored the world, they explore the world of complex identity scenarios in multi-forest environments and alternate ImmutableID situations. Find out where errors come from and how to resolve them while we sail through the inner workings of the Azure AD Connect tool.

We’ll share the things you didn’t think were possible with Azure AD Connect, and dive deep into the tools. Are you looking to handle multi-forest scenarios, change the immutable ID or juggle with Azure AD Connects synchronization rules to cope with increasing business requirements, without losing your Microsoft support? This is your go-to session!

Join us!

There is still time to register.

For me, with the Global MVP Summit moved from the November timeframe to March, this is the opportunity to hang out with these guys and I’m looking forward to it!

The Dutch Professional Association of Information and IT Professionals (KNVI) organizes its yearly congress next week. I’m honored to be invited to co-present two sessions, together with my buddy Raymond Comvalius.

About KNVI

The Dutch Professional Association of Information and IT Professionals (KNVI) is an independent platform for sharing professional knowledge and expanding the personal networks of ICT Pros, information professionals, students and employers who want to keep their employees up to date.

KNVI organizes multiple meetings per month, publishes AG Connect both online and in print,and offers discounts to its members.

KNVI is a merged organization of several professional associations, including the Dutch Networking User Group (Ngi-NGN) and the Dutch Association for Documentary Information and Organization Administration (SOD).

About KNVI Congress

The KNVI Congress is KNVI’s largest event, organized yearly. The 2017 KNVI Congress is organized on November 9th, 2017 at the NBC Congrescentrum in Nieuwegein, Netherlands. This year’s theme is Information is Power.

This year’s event features keynotes by René ten Bos, appointed Dutch Thinker, Professor Rik Maes and Marietje Schaake, member of the European Parlement.

Our sessions

Raymond and I will present two 40-minute sessions:

Automatic D, T and A environments and Continuous Integration with Veeam and Microsoft

11:30AM – 12:10PM, Track 5: The New Datacenter, will it empower us?

Microsoft Azure changes daily. We can expect a new version of Windows Server every six months. Although Microsoft offers a wide bandwidth of supported versions, organizations expect their admins to keep up and stay within the bandwidth.

The only way we see admins keep up is by testing changes and formally accept these changed in representative test and acceptance environments. Raymond and I show the attendees how to achieve this, costeffectively and safe. We’ll also share our best practices, based on our experiences with Veeam and Microsoft technologies and products. We’ll enable their organizations to take a couple of steps forward.

How to Migrate off your on-premises environments

2:15PM – 2:55PM, Track 8: The Power of Cloud

The continuing waves in the sea of IT push us towards the cloud, today. Yesterday’s wave of virtualization and last decade’s waves of VDI and centralization might have left you wary of any new projects. But today’s news is really something and we’d like you to pay attention, because it’s easily digestible with last decade’s experience under your belt.

Raymond and I show you how to embrace the new possibilities of the cloud and potentially get rid of the square footage, cooling needs, firewalls and even your Domain Controllers. Dive into the full stack of Microsoft cloud possibilities and impossibilities with us.

Join KNVI!

It’s not too late to join KNVI Dutch.
This is a prerequisite to being able to attend the KNVI Congress.

Subscriptions to KNVI for students are free. Subscriptions for individuals start at EUR 97,50 per year for members aged 27 and below and EUR 99,99 for retirees. Other individual subscriptions set you back EUR 165 per year. Organizational subscriptions are available upon request.

Last week, I spent a long weekend in New York, NY for the inaugural Hybrid Identity Protection Conference.

I flew in on Saturday November 4 via Paris, where I boarded an Air France Boeing 777, that had its seats, at best, filled for 30%. There was ample space and I enjoyed working on a couple of designs and other documents during the 8-hour flight in. Unfortunately, I landed late and, therefore, had some trouble getting from JFK to Manhattan. By the time I arrived at the Holiday Inn, it was around midnight (6AM European time).

The next day, Roelf Zomerman and I went on a tour of the Statue of Liberty and Ellis Island. We went for a quick breakfast and then off to Battery Park, where we met our guide.

Afterwards, we met up with Tomasz Onyszko, strolled through the city to Greenwich Village and had pizza at Johns  Bleecker Street.

On Monday, the inaugural Hybrid Identity Protection Conference kicked off at 7 World Trade Center.

On Monday night, we all had drinks at the Roaring Twenties-inspired Wooley at Woolsworth Building, where we snapped a picture of all the speakers, much at the amusement of the attendees present. 

Tuesday marked Day 2 and Roelf and I had a lot of fun, explaining Azure AD Connect and its many facets during the 135 minutes we ended up with by combining our two sessions into a back to back two-fold exposé of our favourite tool.

After our sessions, I had to go check out and leave New York, to get back to the Netherlands in time to deliver yet another presentation, but not before I said goodbye to all my good DSMVP friends.

I owe a big bag of gratitude to Mickey, Guy, Sean, Darren, Gil, Brian, Christoffer, Henrik, John, Tomasz, Michael, Joe and especially Roelf and the Hybrid Identity Protection Conference attendees for making this my favourite conference next to the MVP Summit.

Let’s do this again sometime soon!

Next week, on Wednesday November 29, 2017 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 American friends, at 2PM. A webinar for Europe and Africa is slated for early next year.

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 Jeff Melnick, systems engineer at Netwrix. This way, you get the best practices from the field and expert analysis tips, directly from the guys whol 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 November 29, 2PM EDT, you can also register for viewing the webinar on-demand , after we’ve finished up.

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 October 2017:

What’s Planned

Deprecating Azure AD reports

Service Category: Reporting
Product Capability: Identity Lifecycle Management

The Azure portal provides you with:

• A new Azure Active Directory administration console
• New APIs for activity and security reports

Due to these new capabilities, the report APIs under the /reports endpoint will be retired on December 10, 2017.

What’s New

New Multi-Factor Authentication features

Service Category: Multi-Factor Authentication (MFA)
Product Capability: Identity Security & Protection

Multi-Factor authentication (MFA) is an essential part of protecting your organization. To make credentials more adaptive and the experience more seamless, the following features have been added:

• Integration of multi-factor challenge results directly into the Azure AD sign-in report, including programmatic access to MFA results
• Deeper integration of the MFA configuration into the Azure AD configuration experience in the Azure portal

With this public preview, MFA management and reporting are an integrated part of the core Azure AD configuration experience. Aggregating both features enables you to manage the MFA management portal functionality within the Azure AD experience.

terms of use

Type: New feature
Service Category: Terms of Use (ToU)
Product Capability: Governance

Azure AD terms of use provide you with a simple method to present information to end users. This ensures that users see relevant disclaimers for legal or compliance requirements.

You can use Azure AD terms of use in the following scenarios:

• General terms of use for all users in your organization.
• Specific terms of use based on a user’s attributes (ex. doctors vs nurses or domestic vs international employees, done by dynamic groups).
• Specific terms of use for accessing high business impact apps, like Salesforce.

Enhancements to privileged identity management

Service Category: PIM
Product Capability: Privileged Identity Management

With Azure Active Directory Privileged Identity Management (PIM), you can now manage, control, and monitor access to Azure Resources (Preview) within your organization to:

• Subscriptions
• Resource groups
• Virtual machines.

All resources within the Azure portal that leverage the Azure Role Based Access Control (RBAC) functionality can take advantage of all the security and lifecycle management capabilities Azure AD PIM has to offer.

access reviews

Type: New feature
Service Category: Access Reviews
Product Capability: Governance

Access reviews (preview) enable organizations to efficiently manage group memberships and access to enterprise applications:

• You can recertify guest user access using access reviews of their access to applications and memberships of groups. The insights provided by the access reviews enable reviewers to efficiently decide whether guests should have continued access.
• You can recertify employees access to applications and group memberships with access reviews.

You can collect the access review controls into programs relevant for your organization to track reviews for compliance or risk-sensitive applications.

Hiding third-party applications from My Apps and the Office 365 launcher

Service Category: My Apps
Product Capability: Single Sign-On

You can now better manage apps that show up on your user portals through a new hide app property. Hiding apps helps with cases where app tiles are showing up for backend services or duplicate tiles and end up cluttering user’s app launchers. The toggle is located on the properties section of the third-party app and is labeled Visible to user? You can also hide an app programmatically through PowerShell.

What’s Changed

Automatic sign-in field detection

Service Category: My Apps
Product Capability: Single Sign-On (SSO)

Azure Active Directory supports automatic sign-in field detection for applications that render an HTML username and password field. These steps are documented in How to automatically capture sign-in fields for an application. You can find this capability by adding a Non-Gallery application on the Enterprise Applications page in the Azure portal. Additionally, you can configure the Single Sign-on mode on this new application to Password-based Single Sign-on, entering a web URL, and then saving the page.

Due to a service issue, this functionality was temporarily disabled for a period of time. The issue has been resolved and the automatic sign-in field detection is available again.

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.