OATH Hardware Tokens for AzureAD

As you probably have been reading in my previous posts, I’ve been talking about FIDO2 keys, and how it can be used as a secondary authentication when signing in AzureAD.

PassWordless Authentication with Fido 2 Keys – Part 2

PassWordless Authentication with Fido 2 Keys

Today, I want to talk about OATH hardware Tokens, known as Time-based One Time Password Tokens as well.

As you are aware, some authentication methods can be used as the primary factor when you sign in to an application or device, such as using a FIDO2 security key or a password. Other authentication methods are only available as a secondary factor when you use Azure AD Multi-Factor Authentication or SSPR.

The following table outlines when an authentication method can be used during a sign-in event:

But, OATH TOTP is an open standard that specifies how one-time password (OTP) codes are generated. OATH TOTP can be implemented using either software or hardware to generate the codes. OATH TOTP hardware tokens typically come with a secret key, or seed, pre-programmed in the token.

In this post, I will show you how the OTP C200 token from Feitian can be configured in Azure AD and how it works.

First of all, what you have to do is to register the key in Azure AD, in order to do this, you will need the Serial Number from the Key, and the secret key provided by the manufacturer, and then you need to create a CSV file with all the information:

Once you have done this, these keys must be input into Azure AD: Multifactor authentication – Microsoft Azure

Upload the file, and activate the key in the portal, once it is have been done, it will show you a screen like the following:

If you have any error during the upload, it will be shown in the portal itself:

You must consider that you can activate a maximum of 200 OATH tokens every 5 minutes.

Also, as you probably figure out, users may have a combination or OATH Hardware tokens, Authenticator App, FiDO Keys, etc…

Be aware that users con configure their default sign in method in the security info web: My Sign-Ins | Security Info | Microsoft.com

So, once the key has been configured for the user, which is the flow to access to the account?

I have compared the Authentication flow with the Fido2 Key Flow, the difference that you can appreciate is with FiDO2 Keys is not necessary to include my password

Finally, check out the following table from Microsoft, where you can see different persona cases and which passwordless technology can be used for each one of them

IMHO, FiDO Keys are great, but thinking as an end user they have problem: the first setup: We must rely on end user about how they configure the key and associate it with azure AD (remember the previous table). FiDO keys has the advantage to be able to be used to sign in instead of using a password in the computer.

In the other hand, OAUTH keys are great, because you as an administrator, can configure the keys in the AAD Portal, and once have been activated provide them to end users, without necessity to do any other action from the end user perspective, and the most important part, are very easy to use

Thanks to Feitian for providing such amazing tokens

Advertisement

Secure your AzureAD Identity infrastructure

In the Global Azure I had the oportunity to talk about how to secure our Azure AD. Now Microsoft has published a new link about how to protect our AzureAD: https://docs.microsoft.com/en-us/azure/security/fundamentals/steps-secure-identity

So now, we have official documentation to support my recommendations 🙂

The mystery of non-access to DevOps

This history began with a new dev project, we needed to be included in a DevOps Project inside the customer organization.

We were first invited to the Teams group to collaborate, upload the documentation and so on, so our users were first created in the AAD of the customer, till here, no problem.

But then, the customer created the DevOps project, and he invited us to collaborate in the project, we received the mail, but when we tried to access, we were receiving the following error message:

We were pretty sure, that we had access to the project, we were checking with the customer the access, and we were having access, we waited some time to replicate the permissions change, but nothing, so where was the problem?

The error page shows that we do not have access, so after digging a while with the problem, I realized that when I tried to navigate to the organization URL, in Edge was showing the error message that could lead us to something:

So, the problem is that guests are not allowed to access to the organization (TF909091), so how we can solve that problem?

Pretty simple, we need to ask the customer, to go to the organization settings and modify the security policies:

Also, to check if in the policies of the project, the check was allowed:

After doing that, we were able to access to the DevOps project, and start working

Problem and mystery solved!

Licensing Changes for Azure AD External Identities

Do you want to check out my last collaboration with the spanish magazine “CompartiMOSS“, I’am talking about the changes in licensing for Azure AD External Identities

I hope you enjoy it!

Duplicated users in AzureAD

Sometimes it happens, users syncronized from OnPrem to AzureAD, are not being soft matched, and it’s necessary to do a hard match, in this post I will explain the basic steps to do it:

1. Disable the sync for that particular object, my recommendation would be to create a OU in your AD which is not being selected to be synchronized
2. Execute a Sync Delta in your ADConnect Start-ADSyncSyncCycle -PolicyType Delta
3. Check that the bogus user has been deleted, and delete it from Recycle bin withRemove-MsolUser -UserPrincipalName <user> -RemoveFromRecycleBin
4. Find the users ObjectIDldifde -d "CN=username,CN=Users,DC=domain,DC=local" -f C:\user.txt
5. Find objectGUID:: in c:\user.txt
6. If you don’t like the previous step, you can search for the sourceanchor in the metaverse of AADConnect,
7. Update AzureID, setting the object ID to sync with toSet-MsolUser -UserPrincipalName <upn> -ImmutableId <objectGUID>
8. Now, sync withStart-ADSyncSyncCycle -PolicyType Initial

With this, what we are doing id a hard match for the user, once is done, you’re ready to go

Does my organization need Azure AD Conditional Access?

Consider how the authentication process has traditionally worked: Organizations require users to supply a user ID and password. Then, the user can go on to access all the data, applications and other resources they’ve been granted permissions for. But what about if an attacker has stolen a user’s credentials? How can we reduce these risks? It is where Conditional access takes place 🙂

But the question is, do I really need it? It depends your case or scenario 😛 but let’s dig in depending in what you’re using:

• Security Defaults: To help organizations establish a basic level of security, Microsoft makes security defaults available to everyone at no extra cost. This feature automatically enforces the following policies:

1. All Users must register for AzureAD MFA
   1. Users must complete MFA challenge when they authenticate using a new device or application
   2. Administrators must complete an MFA step every time they sign in. This policy applies to nine key Azure AD roles, including Global Administrator, SharePoint Administrator, Exchange Administrator, Conditional Access Administrator and Security Administrator.
   3. Any user trying to access the Azure portal, Azure PowerShell or the Azure CLI must complete additional authentication
   4. All authentication requests made using older protocols are blocked

• Azure AD COnditional Access: But as you can imagine, in some organizations these security defaults are not enough, they want to have more fine-grained controls, so to do this we need Conditional Access, which allows us to:

• create a policy to require administrators — but not regular business users — to complete an MFA step
  • Use the user location and the type of protocol being used to restrict the access
  • Deny all requests that comes from a particular country, and require MFA for the rest
  • As you can see, you can create multiple policies that work together to put guardrails in place exactly where you need them

Azure AD Conditional Access is an extremely valuable tool for helping you implement a Zero Trust model, protecting the three cores of the strategy:

• Least privilege — Helps to grant the right access at the right time to only those who need it by enabling trusted locations and IP ranges, implement stronger controls for privileged users, and control access to sensitive applications and content.
• Verify explicitly — Continually verify identities as users move around the network by requiring MFA when users appear on new devices and from new locations.
• Assume breach — Weak passwords, password spraying and phishing all but guarantee malicious actors are inside your network. It allows to block legacy authentication and putting stronger access controls in front of your most valuable resources.

As you can see, Azure AD Conditional Access is a powerful tool for strengthening security and ensuring regulatory compliance

Take care!

Authentication methods in AzureAD: Security Questions

Security questions

I’ve been searching some information about Security Questions in AzureAD, and one of the fisrt conclusiones that I came, is that Security Questions are only available for users that use, SSPR.

Taking this into considerations, you have to be aware of the following, when using security questions:

• Azure stores security questions privately and in a security-enhanced manner on a user object in the directory. Only users can answer the questions and only during registration. An administrator can’t read or change a user’s questions or answers.
• Azure provides 35 predefined questions, all translated and localized based on the browser locale.
• You can customize the questions by using the administrative interface; however, Azure displays them in the language entered. The maximum length is 200 characters.

Authentication methods in AzureAD

Have you been struggling in how and what to configure in AzureAD in order to set your authentication methods? With the following table, you will be able to see th different authentication methods that we have available, and which services can use them.

Authentication method	Services
Password	Azure AD MFA and SSPR
Security questions	SSPR
Email address	SSPR
Microsoft Authenticator app	Azure AD MFA and SSPR
OATH hardware token	Azure AD MFA and SSPR
Text message	Azure AD MFA and SSPR
Voice call	Azure AD MFA and SSPR
App passwords	Azure AD MFA in certain cases

Using the forceDelete option in AzureAD

This is something that I have discovered while reading documentation, to it could be useful to help to reset a tenant and recover an initial situation:

You can ForceDelete a domain name in the Azure AD Admin Center or using Microsoft Graph API. These options use an asynchronous operation and update all references from the custom domain name like “user@contoso.com” to the initial default domain name such as “user@contoso.onmicrosoft.com.”

To call ForceDelete in the Azure portal, you must ensure that there are fewer than 1000 references to the domain name, and any references where Exchange is the provisioning service must be updated or removed in the Exchange Admin Center. This includes Exchange Mail-Enabled Security Groups and distributed lists. Also, the ForceDelete operation won’t succeed if either of the following is true:

• You purchased a domain via Microsoft 365 domain subscription services
• You are a partner administering on behalf of another customer organization

The following actions are performed as part of the ForceDelete operation:

• Renames the UPN, EmailAddress, and ProxyAddress of users with references to the custom domain name to the initial default domain name.
• Renames the EmailAddress of groups with references to the custom domain name to the initial default domain name.
• Renames the identifierUris of applications with references to the custom domain name to the initial default domain name.

An error is returned when:

• The number of objects to be renamed is greater than 1000
• One of the applications to be renamed is a multi-tenant app

What is really PIM?

Currently in all project were I’m involved I’m trying to used Best Practices of Security, including the use of PIM.  Privileged Identity Management it is a service that is available in Azure AD and is part of Azure AD Plan 2, it is used for all admin related tasks, where no employee has standing access within the company, reducing the surface of an attack.

PIM makes it possible to give a user the privilege to elevate his or her access rights for a preset amount of time to a higher role such as User Administrator or SharePoint Administrator.

PIM gives access to huge quantity of roles in Office 365 and Azure resources where the user is by default a reader and can elevate it to be an owner of a resource (group) for a specific amount of time (which is great!)

Enabling a PIM role is done by going to the Azure Portal and select the role you want to elevate. You need to do this for every role separately.

For example, imagine that you have members that need to elevate their account daily to be a SharePoint and User administrator, so they need to do this daily. After enabling they need to sign out and sign in again to make sure the roles are activated.

No more to give the role to a user and forget which role we give to them…