Tag: Azure AD

Transitioning to Azure cloud authentication – Part 1

This series of articles is to document steps to be taken to transition from an on-premise Active Directory footprint, and migrate the workloads to Azure AD.

A typical migration has the following stages:

  • Discovery: Find out what is currently in the environment
  • Pilot: Deploy new cloud capabilities to a small subset of users, applications, and devices
  • Scale Out: Expand the pilot to complete the transition
  • Cut-over: Stop using the on-premises authentication

Users and Groups

Microsoft highly recommends a passwordless environment, due to as is depicted in the following graphic, is both highly secure, and convenient.

In my experience, users correctly following secure practices either make or break security initiatives, thus, in my opinion, convenience is crucial

Industry authentication standards rely on one of the following:

  • Something you Know:
    • Passwords are great, but unless a vault is used, it is common to use the same, or variation for many personal accounts. Highly vulnerable in modern times, as environments are often compromised, with credentials getting exposed to public sites. The equivalent of writing credentials down on paper and other people finding it.
  • Something you Have:
    • Removes the problem of forgetting something you know, but is vulnerable to the object being lost or stolen.
  • Something you Are:
    • Much harder to lose a fingerprint than a wallet, however, while this is getting better, historically, biometric sensors can be fairly expensive (cost and support) and have accuracy issues.

Due to the fact each authentication methods have their vulnerabilities, a combination of them is much stronger, hence the modern term “Multi-Factor Authentication” (MFA)

Here’s an example of using the Authenticator App as a convenient multi-factor authentication option in addition to a password.

The Authenticator App turns any iOS or Android phone into a strong, passwordless credential. Users can sign in to any platform or browser by getting a notification to their phone, matching a number displayed on the screen to the one on their phone, and then using their biometric (touch or face) or PIN to confirm.

Passwordless authentication using the Authenticator app follows the same basic pattern as Windows Hello for Business. It’s a little more complicated as the user needs to be identified so that Azure AD can find the Authenticator app version being used:

  1. The user enters their username.
  2. Azure AD detects that the user has a strong credential and starts the Strong Credential flow.
  3. A notification is sent to the app via Apple Push Notification Service (APNS) on iOS devices, or via Firebase Cloud Messaging (FCM) on Android devices.
  4. The user receives the push notification and opens the app.
  5. The app calls Azure AD and receives a proof-of-presence challenge and nonce.
  6. The user completes the challenge by entering their biometric or PIN to unlock private key.
  7. The nonce is signed with the private key and sent back to Azure AD.
  8. Azure AD performs public/private key validation and returns a token.

Password Self-Service

Until an MFA environment is in place, migrating to Azure’s password self-service (SSPR) gives users the capability of managing their own password resets, which not only greatly helps with the “convenience” point I made above, but in most cases, tremendously decreases help desk support calls.

The following authentication methods are available for SSPR:

  • Mobile app notification
  • Mobile app code
  • Email
  • Mobile phone
  • Office phone (available only for tenants with paid subscriptions)
  • Security questions

Users can only reset their password if they have registered an authentication method that the administrator has enabled.

On-premises integration

With a hybrid environment, first install and configure the sync agent to be capable of enabling password writeback, once that is complete, you can configure Azure AD Connect to write password change events back from Azure AD to the on-premises directory.

In addition, the following options are available:

  1. Users can unlock accounts without resetting their password
  2. Password filters for on-premises Active Directory

Logon failure with Azure AD DS based services

Fix a madding “Invalid password” error when trying to use an Azure service that uses Azure AD DS as it’s authentication

I hope this helps someone fix a madding “Invalid password” error when trying to use an Azure service that uses Azure AD DS as it’s authentication with a synced account from on-premise AD.

With a recent implementation of Windows Virtual Desktop, and interesting failure occurred with a set of users that were synchronized to Azure AD from an on-premise AD environment.

The environment was one where there was no longer an Azure AD Connect configuration in place, in fact, the on-premise AD environment was no longer available. All users were using Office 365 services without any issues, and Azure AD Domain Services was implemented for new Azure services, one of them being WVD.

All WVD services were tested with the admin account that created the resources, and some test users created in Azure AD, however, when the group that needed to use the service tried to use it with their accounts, around half the necessary users could not log into the VM image.

After verifying all permissions were correctly assigned, and checking to see if there were any relevant differences between the accounts that were able to log on vs. the ones that were not, I noticed that all accounts were able to log on to the web URL, however after the initial logon to the service, the originally synced accounts were failing with an “invalid password” error, whereas the ones that were directly created in Azure succeeded. – Aha! This pointed me to the fact that the accounts seemed to be having some sort of Azure ADDS failure, as 365 services were not dependent on that.

Quite a few articles were read all over the place, with none being any help, so I went back to the basics, and went over the Azure AD to Azure AD DS synchronization guide much more methodical than I previously had.

I’ll cut to the chase, in the middle of that guide, the following statement is made: When a user is created in Azure AD, they’re not synchronized to Azure AD DS until they change their password in Azure AD.