KnowledgeBase: Logging in to the Intune Company Portal App results in an error “Could not sign in” on Android phones with Chrome 56, and up

AndroidThis morning I read a blogpost by John Arnold on the Intune Support TechNet Blog on a strange Intune-related error on Android Phones when accessing the Company Portal app.

As it turned out, this is an Active Directory Federation Services (AD FS)-related certificate issue, so I thought I’d share it here as well.

 

The situation

When you use Microsoft Intune, end users in your organization can use the Intune Android Company Portal app to install apps, check compliance and retire devices among other things. It’s a helpful resource for organizations looking to adopt a Shift Left strategy to lower support cost by enabling end users to solve common IT problems themselves.

In Hybrid Identity implementations, all authentication requests to Microsoft Online Services, including the Company Portal and apps, can be redirected to an organizations Active Directory Federation Services (AD FS) implementation.

Devices running current versions of Android are configured to automatically update apps. Under the hood, the Android Company Portal app on Android leverages the built-in Chrome browser.

 

The issue

When an Android device has (automatically) upgraded its browser to Chrome version 56 (and up), and the end user for an organization that leverages Hybrid Identity using Active Directory Federation Services (AD FS), opens the Android Company Portal app, the app shows an error:

Error
Could not sign in. You will need to sign in again. If you see this message again, please contact your IT admin.

 

After pressing OK, the error persists.
Of course, IT admins are swamped with calls, this way.

 

The cause

The error is caused by the Active Directory Federation Services (AD FS) implementation using a service communications certificate that utilizes the SHA-1 hashing algorithm.

Starting with Chrome 56, Google enforces its policy to stop support for certificates that utilizes the SHA-1 hashing algorithm.

 

The solution

The   service communications certificate for the Active Directory Federation Services (AD FS) implementation needs to be replaced by a certificate that utilizes the SHA-2 hashing algorithm.

Note:
Certificates for intermediate Certification Authorities (CAs) and Root Certification Authorities (CAs) may, for now, remain SHA-1 certificates.

The links below walk you through creating a certificate request for a future-proof AD FS service communications certificate.

 

Concluding

It’s time to say goodbye to your SHA-1 certificates.

Further reading

AD FS Certificates Best Practices, Part 1: Hashing Algorithms
AD FS Certificates Best Practices, Part 2: Key size
AD FS Certificates Best Practices, Part 3: CNG-generated Private Keys
AD FS Certificates Best Practices, Part 4: Token Signing and -Decrypting Cert lifetime

0  

How not to offer Guest Wi-Fi

Nearly all men can stand adversity, but if you want to test a man’s character, give him a horrible internet connection.

– Loosely based on a quote by Abraham Lincoln

 

Some jobs are worse than others. Some environments are more toxic than others. Some things can just annoy the heck out of you. On the top of my list of annoyances is definitely horrible Internet access at customers.

I won’t go into the details, but this customer had decided not to provide me with a workstation, user account or regular network connection, yet wanted me to completely overhaul their Active Directory. Communication was solely possible using mail or SharePoint, since their workstation only allowed a specific type of USB-devices.
You could call it a highly-secure environment.

In this scenario, an Internet connection is key for exchanging information. Luckily, guest Wi-Fi was offered. Every day, at the reception I could ask for a standardized piece of paper with a 12h passcode.

The passcode system was a horrible experience. Here’s why:

  • The Wi-Fi network itself had a WPA2 key. This adds secondary security, but since the signal is also receivable from the parking lot, the network is heavily used and the WPA2 key was never changed, it adds almost zero security. Yet, it resulted in numerous It’s taking longer to connect messages when reconnecting.
  • The Wi-Fi network issued an authentication portal. Good. Microsoft Internet Explorer’s default page wasn’t treated as a page were you’d be welcomed with the authentication portal, so after I successfully connected to the Wi-Fi network, I needed to enter a well-known, non-https URL in the address bar of my browser, before getting access to the authentication portal.

Note:
It appears this is a common issue with Cisco-powered guest networks. Horrible.

  • The Wi-Fi network issued an authentication portal. Good. Except for the fact that the portal used a self-signed or otherwise publicly untrusted SSL/TLS certificate that made me first have to click through my browser’s Are you sure you want to access this page? warning page. “How hard is it to issue a publicly trusted TLS certificate, right!?
  • The authentication portal allowed me to enter the passcode, consisting of a username and a password. Both values needed to be entered in the authentication portal and the portal did not allow copying or pasting from or to these two fields. Yet, the values one needs to enter to gain access, included characters beyond the word characters, heavily relying on keyboard lay-out. Without being able to see the entered password, or copy pasting it from the visible username field, this is a hassle with different keyboard lay-outs and Caps lock.
  • After the authentication page, a page with terms and conditions was shown. A radio button I accept was offered and a Continue button would then light up green. Every first time I accepted the terms and conditions and hit the Continue button, I was redirected back to the authentication page, where subsequent authentications and acceptances of the terms worked flawlessly. Being taught to read the terms and conditions, this took quite some time. Having employees tell you that the second time you accept, you give away your soul wasn’t helpful either.
  • After clearing the authentication portal, the browser would always be redirected to the customer’s website. After all the hassle it took to enter an address they accepted as a valid target, after seeing it being carried through the authentication portal in the url string, it just gets chopped off at the end. I guess it’s one way to improve your Alexa scores…
  • Every two hours, the session would expire. Sometimes the authenticated session would expire. At other times the IPv4 address lease would expire. It would not pop-up anywhere, the networking connection would just show up Limited. In the middle of an Outlook Sync, in the middle of a down- or upload.
  • When the IPV4-address lease would break, I could not simply disconnect and reconnect the Wi-Fi network. I needed to either restart my (Windows-based) device (which did not always work) or temporarily connect to a different network.
  • Wi-Fi band 1 was actively blocked. This is the default band for most phones, including my Windows Phone for Internet connection sharing. Tethering was not an option, and connecting to it as an alternative network only worked every once in a while.
  • Yes, this Wi-Fi only offered IPv4 addressing. No IPv6, although the Internet provider, providing the actual bandwidth and such, advertises with the fact that they offer IPv6 now.
  • The piece of paper did not include any support information. There was no-one to share my issues with or find a better solution. The customer had an incident report system, but since I didn’t have an account, I couldn’t log any incidents of support questions for my situation…

Going through this process several times for roughly 40 working days, eventually added up to me wanting to punch someone in the face.

Please, if you provide Guest Wi-Fi, make it a less horrible experience as depicted above.

Thank you.

0  

Join me for an Active Directory 101 webinar, in cooperation with Veeam

Active Directory 101

This year, as a Veeam Vanguard, I’m hosting a series of three Active Directory Domain Services webinars, together with Timothy Dewin and hosted by Veeam.

The first webinar in the series is the Active Directory 101 webcast on February 21, 2017.

I’m very excited for this session, because for me it is a way to return to basics with Active Directory. Starting at absolute zero, I’ll explain the logical and physical components of Active Directory, so you can hop on to this technology with ease.

For every beginning Active Directory admin, but also for experienced admins who are only just starting managing Active Directory, this is the webinar to start off. If this is you, please join me. Glimlach

You can join the EMEA session at 2 PM CET, or you can join the Americas session at 1 PM EDT. Both sessions are (nearly) identical. Sign up for these webinars for free here.

 

About the Veeam Active Directory Webinars

The Active Directory Deep Dive series of webcasts consists of three Active Directory Domain Services-oriented webinars, that I’m hosting together with Timothy Dewin and Veeam.

February 21: Active Directory 101

Get into Active Directory basics and best practices, including:

  1. Deep dive into specifics of Active Directory service roles
  2. Domain Controllers deploying, grouping and interaction with DNS and DHCP services
  3. Proper configuration of AD

March 7: Active Directory and Virtualization

Deep dive into the latest changes of Active Directory, including:

  1. Challenges and recommendations with virtualizing Domain Controllers
  2. How Domain Controller Cloning saves your bacon
  3. Five key enhancements in Active Directory security in Windows Server 2016

March 21: Active Directory Backup and Restore

Do you know how many people couldn’t restore their ADs due to bad configuration?
Learn how to:

    1. Accordingly configure your backup jobs
    2. Avoid fails at restores
    3. Verify the recoverability of every Active Directory backup

Each webinar is repeated on the same day, to accommodate attendees around the globe. The first session is scheduled for 2PM CET. The second session is scheduled for 1PM EDT.

0  

Things to know about Billing for Azure MFA and Azure MFA Server

moneyjarOur friends at Microsoft have embraced the cloud as a way to give us the benefits of Pay-per-Use for our licensing needs. This is good news for any person, responsible for billing in an organization that relies heavily on Microsoft products.

When thinking about Azure Multi-Factor Authentication (MFA), as a service for, for instance, Azure Admins, it makes sense to be billed per billing period, or even to pay per 10 authentications.

This seems well-documented on the Microsoft documentation website for the Azure Multi-Factor Authentication Service (the cloud-only variant). However, for Azure Multi-Factor Authentication (MFA) Server (the on-premises variant, leveraging the same cloud-based Azure Multi-Factor Authentication engine as the cloud-only variant), it’s not that obvious.

So let’s dive into it.

 

Billing details for Azure MFA

According to Microsoft’s documentation on Azure Multi-Factor Authentication Pricing, the following Questions & Answers (Q&A) provide all the information you need:

How does Multi-Factor Authentication billing work?

The ‘per user’ or ‘per authentication’ billing/usage model is chosen when creating a Multi-Factor Auth Provider in the Microsoft Azure classic portal. It is a consumption-based resource that is billed against the organization’s Azure subscription, just like virtual machines, websites, etc.

Does the ‘per user’ billing model charge based on the number of users enabled for Multi-Factor Authentication or the number of users who perform the verifications?
Billing is based on the number of users enabled for Multi-Factor Authentication.

We’ve done a bit of research and found, that when using the Per-User license model, user objects have the following characteristics:

  • A (synchronized) user object can have any of the following values for the StrongAuthenticationRequirement attribute:
    • clear
    • When the attribute is clear, the user object is not configured or enrolled for Azure Multi-Factor Authentication.
    • enabled
      When enabled, a user object is configured for Azure Multi-Factor Authentication and enrolls the first time, a policy enforcement point (PEP) is passed that requires multi-factor authentication.
    • enforced
      When enforced, a user object is enabled and has passed a policy enforcement point (PEP) that requires or required multi-factor authentication, and the user object is enrolled (configured) for Azure Multi-Factor Authentication.

A Per-User license for Azure Multi-Factor Authentication is billed, when the user object’s StrongAuthenticationRequirement attribute reads either enabled or enforced.

However, user objects may already be assigned an Azure MFA license. No separate Azure MFA license is billed for the user object when any one of the following license is assigned, since these licenses contain the Azure MFA sublicense:

  • Azure AD Premium (P1)
  • Azure AD Premium P2
  • Enterprise Mobility + Security (EM+S) E3
  • Enterprise Mobility + Security (EM+S) E5
  • Secure Productive Enterprise (SPE) E3 (previously Enterprise Cloud Suite, or ECS)
  • Secure Productive Enterprise (SPE) E5

If no applicable license is assigned, Microsoft attaches the Azure MFA per-user license.

Tip!
You might want to check for user objects that are enabled vs. enforced to prevent license costs for user objects that never pass a multi-factor authentication-enabled policy enforcement point (PEP). The script I previously shared to get to know the colleagues using Azure Multi-Factor Authentication provides this information, albeit more focused on the method used.

Tip!
You might want to check for user objects that are enforced, but are also configured with the BlockCredential attribute. This is the attribute that is filled with $true when a synchronized Azure AD user object falls out of scope of Azure AD Connect’s synchronization rules, for instance because it is disabled in the on-premises Active Directory Domain Services environment.

 

Billing details for MFA Server

Now, of course, when an organization wants the full functionality of Azure MFA (except for App Passwords), they’ll implement the on-premises Azure Multi-Factor Authentication Server.

Licensing for Azure MFA Server is interesting, and most closely resembles the Per-User licensing module of the Azure MFA Cloud variant: An Azure MFA license is needed for every enabled user in the PhoneFactor.pfdata database, used to store the multi-factor authentication information on all (synchronized) user objects by the Azure MFA Server(s) on-premises.

Note:
The default setting when you manually add a user object to the PhoneFactor.pfdata database or synchronize a user object from Active Directory or an Oracle LDAP directory, is Enabled, if a phone number is provided.

Again, for user objects that have an Azure AD Premium P1, Azure AD Premium P2, EM+S E3, EM+S E5, SPE E3 and/or SPE E5 license assigned, no separate Azure MFA license is billed for the user object; all these licenses have Azure MFA included as a sublicense. If no applicable license is attached, Microsoft attaches the Azure MFA per-user license.

When multiple Azure MFA Servers are part of the same Azure MFA Server Group, the PhoneFactor.pfdata file is replicated amongst all Azure MFA Servers in the group and the user object is only billed once.

Microsoft states it sends information to the cloud-based Azure Multi-Factor Authentication engine to perform multi-factor authentication (by asking it to place a phone call, sending and receiving text messages and/or pushing a notification). However, as part of this information, the license state is also sent per user, along with information to uniquely identity the user object between the Azure MFA variants.

Tip!
You might want to pay close attention to Enabled users in the Azure Multi-Factor Authentication Server Management User Interface, that have no multi-factor authentication information, like a phone number. These user objects are billed, but cannot perform multi-factor authentications.

AzureMFAUserList

The Filter User List link on top of the Users list in the Azure Multi-Factor Authentication Server Management User Interface, can be followed to expand the filtering option. This provides the opportunity to select Enabled, so only enabled user objects are shown in the list, temporarily. Sorting on the Phone column, then, provides a quick overview.

 

Concluding

Billing for Azure MFA and Azure MFA Server is straightforward, but there’s a couple of gotchas to be aware of.

0  

I’m a 2017 Veeam Vanguard

Today, Veeam updated their Vanguard page. This marks the end of the 2017 Veeam Vanguard Nomination and Renewal processes.

For me, it means I successfully renewed my 2016 Veeam Vanguard Award. I still remain one of the three Dutch Veeam Vanguards, together with Joep Piscaer and Arne Fokkema.

I feel honored.

 

About Veeam Vanguards

The Vanguard program is led by the Veeam Technical Product Marketing & Evangelism team and supported by the entire company. It’s a program around the community of Veeam experts that truly get Veeam’s message, understand Veeam’s products and are Veeam’s closest peers in IT.

Veeam Vanguard represent Veeam’s brand to the highest level in many of the different technology communities. These individuals are chosen for their acumen, engagement and style in their activities on and offline.

There’s a full list of Veeam Vanguards here.

0  

Supported Azure MFA Server Deployment Scenarios and their pros and cons

Just like Microsoft is able to differentiate between different sizes and maturity levels of customers in its licensing, so is Microsoft’s on-premises Azure Multi-Factor Authentication (MFA) Server product.

Azure MFA Server allows for four Microsoft-supported deployment scenarios:

  1. Simple Deployment
    One All-in-one Multi-Factor Authentication Server implementation
  2. Redundant Deployment
    Two All-in-one Multi-Factor Authentication Servers with replication
  3. Stretched Deployment
    A back-end Multi-Factor Authentication Server hosting the Management UI, the PhoneFactor.pfdata database and the MFA Web Service SDK and a front-end webserver running the MFA User Portal and (optionally) the MFA Mobile Portal
  4. Complete Deployment
    Stretched deployment with multiple back-end and multiple front-end servers, using load-balancing, throughout.

 

Simple Deployment

In the Simple Deployment scenario, you’d place one Azure Multi-Factor Authentication Server on the internal network, and be done.

This server would be configured with the core Azure Multi-Factor Authentication components; the MFA Management UI and the PhoneFactor.pfdata database.

Optionally, the MFA User Portal can be installed, if the organization wants to enable end-user self-service for MFA (changing their phone numbers, their method, fallback questions and/or wants to delegate admin privileges to service desk personnel or other stakeholders within the organization. This feature needs IIS.

Optionally, the MFA Mobile Portal can be installed, if the organization wants to enhance the end-user MFA experience with the Microsoft Authenticator app. This feature needs IIS.

MFA Simple Deployment Scenario

Pros

The Simple Deployment scenario offers a quick implementation. It can be achieved under an hour, depending on the Internet speed available, and only requires one Windows Server.

It is not a complex implementation to maintain, once implemented. In one relatively simple maintenance window, you can perform an in-place upgrade of all the functionality and revert back to the previous version, if need be, the entire server at once. You don’t have to work together with other admins that have exclusive rights on web servers, for instance.

Cons

The Simple Deployment scenario does not offer high availability. When the server becomes unavailable, authentication stops. When the database gets mangled, a backup needs to be restored, or a new implementation needs to be performed.

The Simple Deployment does not offer the additional security, the more advanced deployment models offer, since all of the functionality is combined in one server on an internal network; Database and web functionality are not separated. In the unlikely event of a successful exploitation of vulnerabilities in the User Portal, other websites running on the same server or other applications hosted on the same server, the database could be compromised or deleted. Reasoning the other way around, traffic between the User Portal and the database (server) cannot be restricted or monitored.

This deployment model does not scale.

 

Redundant Deployment

To address the issue of not offering high availability, two MFA Servers can be implemented, as part of an MFA Server Group in the Redundant Deployment scenario. This way, replication is established between MFA Servers in the group for the authentication settings and preferences, stored in the PhoneFactor.pfdata database.

While the MFA Server core components themselves and RADIUS authentication do not require it, a load balancer should be used for the MFA Web Service SDK, the User Portal and the Mobile Portal to be made highly-available (and thus any components communicating to these, like the MFA AD FS Adapter).

MFA Redundant Deployment Scenario

PROS

In contrast to the Simple Implementation scenario, this scenario offers redundancy. If one server fails, the other server still holds the authentication settings and preferences.

Note:

Special care should be given to the Master Server role placement and the server(s) running the Directory Integration synchronization task.

This model scales. You can add additional servers. By default, additional servers become Slave servers to the initial Master server, but you can switch the Master server role to any server, if need be. Only the Azure MFA Server Master server has read/write access to the PhoneFactor.pfdata database. After changes, replication between the Azure MFA Servers distributes these changes to all servers.

CONS

High Availability (HA) comes at a price. Unless you’re merely using RADIUS or IIS authentication with a two-server setup, a load balancing solution is necessary.

This model scales, but it does so in per-server steps. When the bottleneck is with a particular Azure MFA Server component, the scale for the particular component cannot be increased without increasing the scale of all the other components in the deployment model, too.

Like the Simple Deployment, the Redundant Deployment does not offer the additional security, the more advanced deployment models offer, since all of the functionality is combined into All-in-one servers on an internal network; Database and web functionality are not separated.

 

Stretched Deployment

To address the security of the deployment, the MFA Server components can be divided between a back-end and a front-end server:

  • MFA Back-end Server
    The back-end server runs the Azure MFA Server core components, like the MFA Management GUI, logging, Directory Synchronization. To allow communication with the front-end server, it also features the MFA Web Service SDK within IIS. The back-end server is placed on an internal network, or, when security policies dictate, on a separate network, only allowing the intended traffic with the front-end server, directory servers, DNS, time sources and MFA-enabled applications.
  • MFA Front-end Server
    The front-end server is configured with IIS and offers the MFA User Portal and MFA Mobile Portal. This server is placed in a perimeter network and optionally configured as a Server Core installation. When you use MFA Server with AD FS, it makes sense to publish the MFA User Portal and MFA Mobile Portal through the Web Application Proxies.

A detailed description of the MFA Server components and their traffic flows is available on 4Sysops.com as part of my MFA Server series there.

MFA Stretched Deployment Scenario

Pros

The Stretched Deployment scenario offers, as its name suggests, a more secure implementation by separating the database and the web functionality. The traffic between the components can be monitored. Additionally, when there is a security incident with either/both the User Portal and Mobile Portal, its publishing can be disabled, without affecting the core Azure MFA Server functionality. In terms of security, we prefer to enable mutual authentication on the connection between the application and database tier, allowing ONLY connections from the web application.

When you have an IIS-based webserver in a perimeter network, you can reuse that server as the server hosting the MFA User Portal and MFA Mobile Portal.

Cons

The Stretched Deployment scenario does not offer high availability. When the server becomes unavailable, authentication stops. When the database gets mangled, a backup needs to be restored, or a new implementation needs to be performed.

 

Complete Deployment

In the Complete Deployment scenario, multiple back-end servers and multiple front-end servers work together to offer an highly-available secure deployment of the Azure MFA Server functionality.

Just like in the Redundant Deployment scenario, two or more back-end MFA Servers can be implemented, as part of an MFA Server Group in the Redundant Deployment scenario. This way, replication is established between MFA Servers in the group for the authentication settings and preferences, stored in the PhoneFactor.pfdata database.

Load balancing is utilized for both the webservers running the MFA User Portal and (optionally) MFA Mobile Portal, and the back-end servers running the MFA Web Service SDK. The MFA Server core components themselves and RADIUS authentication do not require load balancers.

MFA Complete Deployment Scenario

Pros

The Complete Deployment offers high-availability. Each MFA Server component may endure a failure in its tier, without it affecting the MFA Server functionality, as long as special care is given to the Master Server placement in combination with Directory Synchronization.

The Complete Deployment offers a secure implementation by separating the database and the web functionality. It is recommended to install the UserPortal and MobilePortal on the same web server. We additionally prefer to implement mutual authentication and monitoring of the connections between the tiers, after allowing only the traffic needed between the components.

The Complete Deployment scenario offers a platform for capacity management, by enabling admins to scale each of the components relatively independent of other components.

The Complete Deployment scenario offers the right implementation strategy to cope with the absence of a true MFA IIS Plug-in.

Cons

The Complete Deployment scenario can be hard to troubleshoot, due to its relative complexity, compared to the other deployment scenarios. It’s also more time-consuming to set up and (way) more costly.

 

Concluding

Implementing an authentication verification measure, like Microsoft’s on-premises Azure MFA Server, requires some thought to do right.

Choose the right scenario, to meet the requirements of your organization.

Related blogposts

Azure Multi-Factor Authentication features per license and implementation
Choosing the right Azure MFA authentication methods
Azure Multi-Factor Authentication Server version 7.2.0.1 adds Oracle LDAP Support (among other features)

Further reading

Azure Multi-Factor Authentication – Part 1: Introduction and licensing
Azure Multi-Factor Authentication – Part 2: Components and traffic flows
Azure Multi-Factor Authentication – Part 3: Configuring the service and server
Azure Multi-Factor Authentication – Part 4: Portals
Azure Multi-Factor Authentication – Part 5: Settings
Azure Multi-Factor Authentication – Part 6: Onboarding
Azure Multi-Factor Authentication – Part 7: Securing AD FS
Azure Multi-Factor Authentication – Part 8: Delegating Administration

0  

Pictures of the 2017 Nordic Infrastructure Conference in Oslo last week

Last week, on Thursday February 2 2017, Raymond Comvalius and I were scheduled to present on Azure Active Directory Business to Business (B2B) and Azure Active Directory Business to Consumer (B2C) at the 2017 Nordic Infrastructure Conference (NICConf) in the Oslo Spektrum.

We were both really looking forward to this event, because it is our third time presenting at Norway’s biggest IT Pro conference. Looking at our schedules in advance, though, revealed some challenges. We both have challenging engagements with customers at the moment and I’m also doing a Dutch identity tour for my employer. We decided to schedule flights to fly in to Oslo Gardemoen Airport (OSL) in the morning and then fly back to Amsterdam Schiphol Airport (AMS) in the afternoon. Fortunately our favorite airline accommodates such a schedule.

That gave us sufficient time to go through the slides one more time, meet with speakers and attendees, do some interviews and answer any questions people might have after our session.

I drove off from home at 4:00 AM, heading towards Raymond in Hoofddorp. While waiting for Raymond, I noticed the Azure Active Directory team released a refresh of Azure AD B2B. We took the early train from Hoofddorp to Schiphol and then checked in. Slightly behind on schedule we departed for an uneventful flight to Oslo, during which we went through all the new features announced a mere six hours earlier.

Checking during the flight (click for larger photo)

At the airport, we bought tickets for the Flytoget train to Oslo Sentralstasjion. Without looking at signs or using navigation software we found our way to the Oslo Spektrum, where we were greeted by the reception with speaker badges.

Oslo Spektrum for NIC (click for larger photo)Speaker badges (click for larger photo)

Although we needed to figure out the new functionality, the first hour at NIC were scheduled for interviews by CQURE Academy.

Paula In The Middle (click for larger photo, by CQURE)Jakub filming the interviews (click for larger photo)

Raymond and I took turns and we both had a great time chatting with Paula Januszkiewicz and her angels. Paula delivered an great session on PowerForensics
check it out
.

We went to the speaker room in the Bistro, where we met with Sami Laiho, Adnan Hendricks, Alex de Jong, Andy Malone, and John Craddock. We had a great time and prepared to deliver an awesome session where the new Azure AD B2B features were demoed publicly for the first time internationally!

We went for lunch and found delicious sushi at the Microsoft booth.

The 2017 NIC Exposition Hall (click for larger photo)Sushi! (click for lerger photo) 

After lunch we went to Room 4 where Morgan Simonsen delivered his Conditional Access and Identity Protection session. A must see! We prepared and then definitely rocked our session.

The Broken Wheel of Identity Repositories (click for larrger photo, by Paula)Partner Shadow IT (click for larger photo)Raymond demoing (click for larger photo)

After the session we answered a couple of questions, received some valuable feedback from John and Paula, who both attended our session and went to mingle in the Exposition Hall.

Meeting with Alexander Solaat Rødland (click for larger photo)

After an hour or so, we took the train back to the airport and then a flight back to Amsterdam. Raymond and I went our separate ways, Raymond attending a concert in Amsterdam, and me attending the Microsoft Certified Trainer (MCT) New Year Drinks at Microsoft Netherlands.

I finally, but happily, drove home at around 10 PM.

We enjoyed Norway again! Glimlach

 

Thank you to the Nordic Infrastructure Conference organization and attendees. We hope to see you again next year.

Further reading

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 
Tips for Travelling to Tech Conferences, Part 8

0  

Azure Multi-Factor Authentication Server version 7.2.0.1 adds Oracle LDAP Support (among other features)

This morning, I received a notice of a new version of Microsoft’s on-premises Azure Multi-Factor Authentication Server product.

According to the release notes, this version includes a new feature, logging improvements and a bug fix that might plague your Azure Multi-Factor Authentication implementation.

 

What’s New

Version 7.2.0.1 of the Azure Multi-Factor Authentication Server adds the following additional functionality:

  • Directory integration support for Oracle LDAP
  • Fixed a bug with trusted IP addresses in the Multi-Factor Authentication User Portal, when selectable authentication methods are used
  • Web Service SDK Logging
  • Reduce MultiFactorAuthSvc.log authentication entries

Known Issues

Version 7.2.0.1 of the Azure Multi-Factor Authentication Server does not support Windows Authentication for Terminal Services for Windows Server 2012 R2.

 

Upgrade Considerations

All other features and components are backwards-compatible with all previous versions.

 

Download

Version 7.2.0.1 of the on-premises Azure Multi-Factor Authentication (MFA) Server can be downloaded via the old-fashioned Azure Management Portal or straight from the MFA Management Portal:

  1. Log on to the Azure Portal.
  2. In the column on the left that lists all the available items and services, scroll down until you reach ACTIVE DIRECTORY.
  3. In the main pane, select the default directory.
  4. Just above the list of directories, click the text MULTI-FACTOR AUTH PROVIDERS.
  5. Click the Multi-Factor Authentication Provider that you’ve configured for your organization and is marked as Active in the STATUS column.
  6. Click MANAGE in the bottom pane on the general settings for the Multi-Factor Authentication Provider.
  7. This will redirect you to your tenant view of the PhoneFactor Portal.
  8. In the main pane of the portal click on the Downloads header.
  9. Click the Download link below the list of supported platforms.

Save MultiFactorAuthenticationServerSetup.exe to a network location where you can use it from each of the Windows Servers that have Azure Multi-Factor Authentication installed.

 

Concluding

Version 7.2.0.1 of Azure MFA Server provides new functionality.
When your organization hungers for the new and improved features, please install this version. Otherwise, you might want to hold off on installing and check for any misconfigurations on the Azure Multi-Factor Authentication forum.

Related blogposts

Azure Multi-Factor Authentication Server version 7.0.2.1 is here 
Azure Multi-Factor Authentication Server reaches version 7.0.0.9
Knowledgebase: You receive a “Web Service Requests must be protected by authentication” error when activating a Multi-Factor Auth app
KnowledgeBase: Users in Azure Multi-Factor Authentication Server 6.3.x and up can not select One-Way OTP or PIN options in the User Portal
KnowledgeBase: Azure MFA Portal shows error “Error communicating with the local Multi-Factor Authentication service. Please contact your administrator.”
Choosing the right Azure MFA authentication methods

0  

I’m speaking at the 2017 Nordic Infrastructure Conference

banner

After a year of absence, Raymond Comvalius and I have been invited back to the Nordic Infrastructure Conference (NICConf).

 

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.

The event has a strong practical educational focus and offers a wide-range of technical training on Microsoft and other leading third-party products, tools and services including best practice debates, expert demonstrations and troubleshooting clinics.

NICConf will be hosted for the sixth time from February 1 to February 3, 2017. Its location will be the Oslo Spektrum in the heart of Oslo, Norway, again.

NICConf attracts the top speakers on its topics; Cloud & Virtualization, Management & Automation and Server & Client Platform. No wonder, you’ll run into Alex de Jong, Sami Laiho, Andy Malone, Johan Arwidmark, Morgan Simonsen, John Craddock, Mikael Nyström, Aleksander Nikolic and Paula Januszkiewicz.

 

About our session

We will be delivering one one-hour session:

Azure AD B2B and Azure AD B2C in the real world

Room 4, February 2nd 1:20 PM – 2:20 PM

Productivity is moving to the cloud at a pace that is even faster than most companies are able to merge with other companies. Execution of an Active Directory Domain Services (AD DS) consolidation project or taking care of the required Active Directory Federation Services (AD FS) implementation to work together based on Relying Party Trusts (RPTs) just takes too much time. Many organizations face challenges along these lines. Others have (Active Directory) trust issues.

Azure Active Directory B2B brings born-in-the-cloud native collaboration to these organizations, for both on-premises and cloud-based productivity solutions. Collaboration, regardless of resource locations or authentication methods used, although it does help to have resources in the cloud. For collaboration with even smaller companies and individuals, Azure Active Directory B2C offers functionality to work together with people using Facebook, Twitter, Microsoft and Microsoft LinkedIn accounts.

Join this session to find out how to collaborate with other organizations efficiently and effectively. Find out if your organization(s) can do away with Active Directory trusts, scrap the dreaded Active Directory consolidation project(s) and/or avoid implementing AD FS altogether. But, also find out the right solution for your organization’s collaboration needs, how to do it right, avoid common pitfalls and be the claims hero of your organization!

 

Join us! Glimlach

Further reading

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

0  

Getting to know the colleagues using Azure Multi-Factor Authentication

PhoneFactorOn this blog, and in several other places, I’ve shared my experiences with Azure Multi-Factor Authentication. While this information meanly focuses on the on-premises Azure Multi-Factor Authentication Server, I did encounter the occasional implementation of the cloud-based Azure Multi-Factor Authentication.

For one such implementation, I had the pleasure of migrating it from the cloud to the on-premises Azure Multi-Factor Authentication Server. Without proper monitoring, an overview of who was using it with what method was completely missing. So we decided to create a report to get snapshots of the Azure Multi-Factor Authentication configuration, using Windows PowerShell.

 

About Azure Multi-Factor Authentication

As I’ve described over on 4Sysops, several flavors of Multi-Factor Authentication exist. They are targeted at different use cases, but all share Microsofts cloud-based Multi-Factor Authentication engine.

  • Office 365 Multi-Factor Authentication is aimed at colleagues consuming Office 365 resources and works through the enabled-means-enforced model.
  • Azure Multi-Factor Authentication is aimed at colleagues authenticating towards Azure Active Directory and can be granularly applied to any Azure Active Directory-integrated resource.
  • Azure Multi-Factor Authentication Server is the on-premises endpoint for all Multi-Factor Authentication needs enterprises and large organizations might have. It supports multi-factor authentication on all common protocols and extensive exception management, like one-time bypasses and admin delegation.

For a comparison of the features per solution, take a look at the Azure Multi-Factor Authentication features per license and implementation.

 

About the Azure MFA Inventory script

The script below performs two functions:

  1. It provides a total of the amount of user objects in an Azure Active Directory tenant that have Azure Multi-Factor Authentication configured, compared to the total amount of user objects in the Azure Active Directory tenant. The script saves this information in a .txt file.
  2. It provides a table of the user objects in an Azure Active Directory tenant that have Azure Multi-Factor Authentication configured, with their preferred method, their configured phone numbers, and all the other Azure Multi-Factor Authentication information available as part of the strongauthenticationdetails array for the object. The script saves this information in a .csv file.

Note:
The script fetches information on people from Azure Active Directory. This information is sensitive. The script should be run by an administrator with proper clearance within your information and only shared with the right people within the organization. Information you don’t want to see, can be omitted from the output by commenting the lines for the property in the script, twice.

Requirements

  • Running the script requires the Global Admin role in the Azure Active Directory tenant.
  • The script requires the Azure AD PowerShell Module to be installed.

 

Putting the script to good use

You can use this script in several ways.

What we did, is we took the .csv file and opened it in Microsoft Excel. This way, we were quick in providing several graphs on the Multi-Factor Authentication method distribution (pie-chart), the amount of people enrolled in Azure Multi-Factor Authentication without being enforced (pie-chart) and the last enrollment date.

The graphs we ended up with, look like this:
(click for larger screenshots)

Graph showing colleagues using Azure MFA being enforced vs. non-enforced (click for original graph)Graph showing colleagues using Azure MFA and their default verification method  (click for original graph)Graph showing the last proofuptime (enrollment date) for colleagues using Azure MFA (click for original graph)

Additionally, the phone numbers in the file gave us an opportunity to contact the colleagues and in some cases walk them through the migration from Azure Multi-Factor Authentication to Azure Multi-Factor Authentication Server, for instance deleting their mobile app registration in Azure Active Directory and reregistering at the Azure Multi-Factor Authentication Servers Mobile Portal.

Another use we’re seeing for this script is to avoid the challenge we’ve come to refer to as the ‘double prompt’ challenge.

 

Azure MFA Inventory script

The script is displayed below for your review:

#Connect to Azure AD environment
Import-Module MSOnline
$Credential = Get-Credential
Connect-MSOLService –credential
$Credential 

#Create new object with requested information of the users.
$Data = New-Object PSObject
$Data | Add-Member -MemberType NoteProperty -name UserPrincipalName -value NotSet
$Data | Add-Member -MemberType NoteProperty -name Enforced -value NotSet
$Data | Add-Member -MemberType NoteProperty -name Default -value NotSet
$Data | Add-Member -MemberType NoteProperty -name AlternativePhoneNumber
value NotSet
$Data | Add-Member -MemberType NoteProperty -name Emailvalue NotSet
$Data | Add-Member -MemberType NoteProperty -name PhoneNumbervalue NotSet
$Data | Add-Member -MemberType NoteProperty -name ProofupTimevalue NotSet

#Get all users total
$AllUsers
= Get-MSOLuser –all | Measure
$AllUsers = $AllUsers.Count

#Retrieve all enabled MFA users
$RawData = Get-MsolUser | Where{$_.StrongAuthenticationMethods -ne $null} | select UserPrincipalName,StrongAuthenticationMethods,
StrongAuthenticationPhoneAppDetails,StrongAuthenticationRequirements,
StrongAuthenticationUserDetails

#Get MFA User Total
$AllAzureMFAUsers = $Rawdata | Measure
$AllAzureMFAUsers = $AllAzureMFAUsers.
Count

#Fill results object $Data with requested information
$Data = ForEach($User in $RawData){

    #Create new object for passing back the required information
$Result = New-Object PSObject
$Result | Add-Member -MemberType NoteProperty –name UserPrincipalName
    –value Notset
    $Result | Add-Member -MemberType NoteProperty –name Enforced –value
NotSet

$Result | Add-Member -MemberType NoteProperty –name Default –value NotSet
$Result | Add-Member -MemberType NoteProperty –name
AlternativePhoneNumber
–value NotSet
$Result | Add-Member -MemberType NoteProperty –name Email –value NotSet
$Result | Add-Member -MemberType NoteProperty –name PhoneNumber –value
NotSet

$Result | Add-Member -MemberType NoteProperty –name ProofupTime –value
NotSet

    #Fill the UserPrincipalName
  $Result.UserPrincipalName = $User.UserPrincipalName

    #Move object information one level up.
    $Temp = $User.StrongAuthenticationRequirements

    #Fill the value if the MFA is enforced.
    $Result.Enforced = $Temp.State

    #Move object information one level up.
    $Temp = $User.StrongAuthenticationMethods

    #Get preferred method and place it in $Temp.
    $Temp = $Temp | Where{$_.IsDefault -eq “True”} | Select MethodType

    #Fill the Preferred method to value Default
    $Result.Default = $Temp.MethodType

    #Move object information one level up.
    $Temp = $User.StrongAuthenticationUserDetails

    #Fill the values with retrieved information.
    $Result.AlternativePhoneNumber = $Temp.AlternativePhoneNumber
    $Result.Email = $Temp.Email
    $Result.PhoneNumber = $Temp.PhoneNumber

    #Convert last enrollment date
    $Result.Proofuptime = [datetime]($User.StrongAuthenticationProofupTime)

    #Passback the object to data
    $Result
}

#Create output string with user totals
$OutputUsers = “Total users in AzureAD: $AllUsers
Total users enabled for Azure MFA: $AllAzureMFAUsers

#Output information to file
$OutputUsers | Out-File -FilePath “.\Result_Enabled_AzureMFA_Users.log”
$Data | export-csv -Path “.\Result_Enabled_AzureMFA_Users.csv” -delimiter “;”

 

Alternatively, you can download the Query_AAD_AzureMFA_Users script here (zipped). 

Have fun!

 

Hat tip

My colleague Bas wrote the script, updated it several times to meet my creeping scope, and made it work like a charm! Glimlach

2