Tim D'Annecy

AzureAD

#AzureAD #security

The Temporary Access Pass (TAP) is a strong authentication method in Azure Active Directory that allows a user to bypass a second MFA method for a short period of time. This feature is intended to be used in both passworded environment and passwordless envrionments (FIDO2, Hello for Business). The TAP's primary use is to give users a temporary second factor for authentication while keeping your existing security controls in place. If a user knows their password, but doesn't have access to a second authentication method (new phone or phone number, network outage, travelling, etc), an Azure AD admin can generate a TAP code and relay it to them so they can sign in.

This post will discuss how to generate Temporary Access Passes in Azure AD and how users will sign in using this code.

Read more...

#PowerShell #AzureAD

After a domain migration or other large organizational change, you may need to update hundreds of staff at the same time with manager information in Azure AD.

This can be a huge pain to do it through the GUI and there's an easier way to do it with PowerShell and a CSV file.

Read more...

#Exchange #AzureAD #security

Microsoft has announced several times that they are depreciating Basic Authentication for Exchange Online soon, possibly this month (January 2023).

A recent post has information about the deprecation and how to prepare for it.

I wanted to write down how to identify any Basic Authentication usage in your environment from that post and simplify it to just a few clicks. This is a good way to identify any applications that are using Basic Authentication and need to be updated before they get blocked.

Read more...

#AzureAD #networking

I recently created a print server in Azure. The server is running PapercutMF and is syncing its user list from Azure AD using an App Registration.

We have a site-to-site VPN connection from the on-prem network to Azure with all subnets exported.

Issue

When a new user is onboarded, we want them to be able to take their new Mifare card and associate it with their account. This process we want is the following:

  1. Get new RFID badge from box and give to onboarding user
  2. User touches badge to Xerox RFID reader
  3. Xerox prompts user to type Azure AD email address and password
  4. Papercut MF associates this card number with the user's email address

Step 4 was failing, however, and the MFPs were showing an error message “Login Denied: Failed to associate card to account”:

Login Denied: Failed to associate card to account

Root cause

As explained by Papercut's support KB [A], the main issue with this workflow is that the Azure AD tenant that I created this workflow in uses Conditional Access to require MFA approval before authenticating user logins.

Papercut MF currently does not support MFA prompts and won't be able to process the login from the MFPs.

Remediation

To workaround the Conditional Access policy enforcing MFA, you need to add the print server's IP to the MFA exceptions at this link: https://account.activedirectory.windowsazure.com/usermanagement/mfasettings.aspx

You will need to add the IPv4 address of your VM or load balancer (if using VMSS) with a /32. You could also use the entire subnet:

After making that change, you can verify that this association is working by touching the badge to the reader, then logging in with Azure AD credentials. The logs on the Papercut MF dashboard at Logs > Application Logs will show a successful authentication:

Essentially, this is telling Azure AD to not require an MFA prompt when users authenticate through Papercut MF. The red herring was changing any settings related to the Papercut MF App Registration for user sync, as this does not appear to be related to user login authentication.


References: https://www.papercut.com/support/resources/manuals/ng-mf/common/topics/sys-user-group-sync-azure.html

Discuss...

#Windows #Azure #AzureAD

If you've deployed an Azure VM and did not enable the “Login with AAD credentials”, option, you can enable sign in using Azure Active Directory credentials later using Cloud Shell with this command in Azure CLI:

az vm extension set \
--publisher Microsoft.Azure.ActiveDirectory \
--name AADLoginForWindows \
--resource-group ResourceGroup \
--vm-name VMName

After running that command, you'll need to add an entry to the local group to allow interactive sign in using RDP. The extension doesn't add this permission and you will need to do it manually, running this command in a remote Powershell:

net localgroup "remote desktop users" /add "AzureAD\user@domain.com"

You will also need to add 2 lines the RDP file downloaded from the “Connect” tab so that you can connect without issues:

enablecredsspsupport:i:0
authentication level:i:2

After connecting to the VM using RDP, you will also need to disable network-level authentication from Control Panel.

In the background, the extension will change the Join Type of the VM to “Azure AD Joined” and your Devices blade will update with that information after a couple of minutes.

No need to re-create the VM.

Just putting this here for my notes.

Discuss...