PassWordless Authentication with Fido 2 Keys – Part 2

This is a second part of my blog about reviewing Fido2 Keys from Feitian (PassWordless Authentication with Fido 2 Keys – Albandrod’s Memory (albandrodsmemory.com))

In this case, I am testing out the K33 and K44 products

The initial setup of the tenant is covered in my previous post, so I will skip the details of how to do it.

To configure the K33 key you will need to download the app “BioPass FIDO2 Manager” from the Windows Store:

And connect your K33 key via USB to the laptop (otherwise won’t be possible to configure), the configure your preferred PIN, and finally configure your fingerprints. The process to the K44 is similar, but in this case, I am using and Ipad, and the app to download is “iePassManager”

Once the two keys are configured, you’re ready to setup them in AzureAD MFA (https://aka.ms/setupmfa)

K33 process

I have explained the process of how to initially configure the K33 key, but I strongly recommend to follow the steps mentioned in K33_Microsoft_Services_Guide.pdf (ftsafe.com) to pair the key with your laptop.

Once the key has been paired, the process to configure it is simple, the only thing that you must take into account is that even it is Bluetooth Key, you must configure it as an USB key (but remember, it must be paired first with the device).

Authentication with K33

K44 Registration Process

Once again, it is needed to set up the PIN for the Key, in my case, it has been done with the Ipad, but the registration process, is easy as the video shows:

The sign in process is very similar as we’ve seen before, so I do not want to cover this, but as you can observe, the registration and use of Fido2 Keys is pretty simple.

Inclusion, MFA keys and particularly, Fido2 Keys from Feitian are great!! But now, something that you must consider when implementing Fido2 keys in your environment:

There’s no way to enforce PIN policy in Azure AD: Every user can set up their own PIN to use their key. There is no centralized way to manage PINs, but Windows Hello for Business blocks simple PIN codes by default.  The bad news is, if you add the key directly to your Azure AD account, these settings are overridden ☹

Feitian offers multiple options for connecting your key, so you’re sure to find one that works for you. Among the available connections are USB-A, USB-C, NFC, Bluetooth, PIN, biometrics, and more.

Biometrics requires app installation: you need to download the manufacturers’ application that enables fingerprint scanning, which is additional software that you must consider to install

Again, I want to thanks Feitian for providing the security keys to test out the use cases

Till next time!

Advertisement

My two cents for 2022

Nobody can doubt that 2021 has been the year to adopt the cloud (due to COVID of course), mostly because most of us needed to work from home. We can say that business has changed and “Probably” will never go back to was it was.

Remote work will continue growing, so in 2022 we will need to protect our assets much better, and for this, here are my predictions/concerns for the next year:

• Hacker will continue to try to breach in our systems and try to access by the weak link in supply chains. For this, we need to reduce privileges for internal and external accounts, and not forget about machine identities

• Every business needs to reduce his own Attack Surface, to reduce the blast radius of any exposure or incident. To achieve this, tools that provide visibility into identities and activities are essential, we need to be sure of what happened and respond quickly to those incidents

• Protect the data is your responsibility, try to plan and build security controls for your cloud migration roadmap

• Zero Trust will continue growing, but remember to keep in touch with all the components: network, identity, permissions, configurations… The need of tools that give visibility is essential here.

• Currently we put the focus on protecting our user identity with MFA controls, but what about machine identities? These identities and permissions are being exploited in every breach to make lateral attacks, so we will need to be aware of that during the next year.

For now, I think that it’s all, stay tuned to the blog and happy new year!

My password recommendations from the trenches

The following are recommendations and thoughts that I extracted by working with several customers, maybe you will find it obvious, but for other people could be useful. So, let’s begin:

In the identity plane, we could say that exists 2 categories:

• Resist Common attacks
• Contain successful attacks

I don’t want to enter of how to resist or contain attacks, because probably I covered some of these topics in other blog entries, but for me, there is another category which is: understand the human nature.

Nothing more that understand that almost every rule that we impose to the end users, result in degradation of security. Why? Because we force users to use long passwords, with special characters, and in the end, users tend to reuse passwords which makes easier to guess or crack passwords for malicious actors.

So, in the post I will resume some of my experiences as AntiPatterns and recommendations:

• Antipattern – Requiring long passwords: excessive length passwords (more than 10 characters) can result in a behaviour predictable, users tend to choose repeating patterns (heyholetsgoheyholetsgo) that meet the character length but clearly not hard to guess. We can say that this kind of passwords are hard to guess but lead to poor behaviours to guess the password.
  • SuperPRO Tip: You can use a long password, but in this case what I recommend is something that engineers from Microsoft do. They use a very loooooooong password, they forget it, and instead of it, they use passwordless mechanisms such as Windows Hello to sign in.

My tip: Use minimum 8 length requirement but ban common passwords with Azure AD Password Protection.

• Antipattern – Require use of multiple character sets: probably you’re not in the same line as me, but I’ve seen that this rule do more harm than good. People use patterns as substitutions such  as $ for s, @ for a, 1 for I. So keep it in mind

• Antipattern – Password expiration: Policy expiration drive users to use very predictable password (for example, the next password can be predicted on the previous password), end users do not tend to use a new password, the tend to update the old one.

My tip for the two previous points: Azure AD Password Protection + Conditional Access based on User Identity

• Recommendation – Ban common passwords: For me, the most important restriction is to ban the use of common password to reduce the possibility of brute force or password spray attacks

Tip: Look at my first tip 😊

• Recommendation – Educate end Users not to use organization credentials anywhere else: Yes I know that educate users are difficult, but you have to do it, because the tend to reuse the same password across multiple sites. It is a common practice for cyber criminals to try compromised credentials across many sites.

• Recommendation – Enforce MFA registration and enable MFA: ensure that users maintain their security information up to date, so they can respond to security challenges if needed. Doing this, I have seen that end users are more implicated concerning digital security

Enabling MFA prevents up to 99.9% of identity attacks, and if we use other controls such as user location, the better.

PRO TIP: Use Conditional access with FIDO2 security key (PassWordless Authentication with Fido 2 Keys – Albandrod’s Memory (albandrodsmemory.com))

EndUser TIP: Consider turning on two-step verification everywhere you can

• Recommendation – Enable risk-based Authentication: when the system detects suspicious activity, it challenges the user to ensure that they are the legitimate account owner. Personally, I think that this feature is great, but the only drawback that it is only included with AAD P2

Probably you will have different ones based on your experience but these are my recommendations. Till next time and stay safe!

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!

Azure Active Directory security operations guide

If you want to audit or strenght your security posture in AzureAD, OnPrem or M365, Microsoft has published a guide with which points you have to tweak in order to improve your (or your customers) security: https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/security-operations-introduction

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

PassWordless Authentication with Fido 2 Keys

This is something I wanted to test some time ago, and now thanks to Feitian I was able to do it. So let’s dig into detail what is passwordless with Fido2 Keys, how we can configure it in AzureAD, and what advantages provide as an end user. ¡Let’s begin!

But before dig in depper, let me explain the basics: A security key is a piece of hardware that you can connect to your computer or phone to verify your credentials when logging, unlike a password, it’s completely safe, because the configuration is different for each system.

So, what does Fido2 Keys? As you probably know, logging into a resource requires a username and password, and with MFA, it usually requires a username/password combination plus one other authentication factor, like a time-based one-time password. In this case, FIDO2 is a standards-based method of user authentication that is passwordless, supporting PIN and biometrics in security tokens

For starters, with FIDO you can:

• Improve security with crypto-secured passwordless authentication
• Remove the helpdesk costs associated with forgotten passwords by replacing them with a simple PIN or fingerprint
• Remove the user-experience annoyances of long passwords to create, remember and reset so that your workforce can get on with their role simply and seamlessly.

What about the preparation of AzureAD?

For IT, At high level there is only two tasks to accomplish:

• Enable the new authentication method registration on AzureAD

• Enable FIDO2 as an authentication method

Easy, isn’t it?

What about the registration for end users?

In my case, how the security Key is a biometic security Key, what i needed to do first is to register my fingerprint. Once I did this (manufacturer provide details, you’re ready to go with next steps).

In order to register the security token with AzureAD, the user will need to access to https://aka.ms/setupsecurityinfo where will be able to see all the authentication method available for them:

And once the user have selected the security key option, the process of registration will begin. In my case, I selected USB device and then… I needed to provide a PIN for the security Key:

Things that you have to keep in mind, is we user have to set up their own PIN to use their key, it cannot be enforced or centralized way to manage PIN, so is probably that your users end up using PINs like 123456.

ONce you have registered the key, it will appear in the security Info Panel:

Ok, it’s great what you’re are explaining, but how it is used?

With the following video, I want to show how the process of passwordless authentication in AzureAD is done:

As you can see, the login was done without entering any user or password. If you’re conviced, and you want to start deploying Fido2 Keys in your organization, think first about the following points:

Registration

• Control to ensure that the employee has been through sufficient identity checks to create a trusted identity.

Issuance

The organisation needs policy control over:

• The type of FIDO device used (external USB / Bluetooth)
• The organisation needs to consider the type of user verification required (Fingerprint / NFC)
• The end user needs a simple experience during registration of a FIDO credential
• The organization needs to trust the genuineness of the FIDO device being used for the FIDO credential

Lifecycle Management

• Vision of who has been assigned which FIDO Credentials
• Ability to simply revoke access to all systems accessed by the FIDO Credential
• Ability to manage lost devices / replacement devices / back up devices

Authentication

• The end user needs a simple experience to authenticate to systems, usernameless aids this process.

As you can see Fido2 Keys are great, and what is better, not only works with AzureAD, it can be used to authenticate with oter services like twitter, Instagram, etc…

Link References:

Register your key at https://aka.ms/mysecurityinfo

If you are a Microsoft 365 admin, use an interactive guide at https://aka.ms/passwordlesswizard

Messing around with AVD and AADJoin

In a previous post: Messing around with WVD, AADDS and FSLogix – Albandrod’s Memory (albandrodsmemory.com) I was talking about how AVD breaks some scenarios and how we could fix them.

In this ocassion I will talk about my experience working with the new version of AADJoin for AVD which is finally in public preview. So with this approach we can eliminate the need to have a domain controller or AADDS in place for your AVD deployment to work, but as you can imagine it has some drawbacks.

First important thing that you have to be aware of implementing this type of scenario is that when you’re adding the VMs to the HP, it is necessary to select the following option:

Also is important to check wether is we want to join the VMs to Intune or not, in my case I selected yes, and after a few moments of the VM creation, I was able to see it in the endpoint portal:

After you have created the HP, my recommendation would to configure it, you can use the following advanced RDP properties:

use multimon:i:0 which basically Determines whether the session should use true multiple monitor support when connecting to the remote computer

To access Azure AD-joined VMs using the web, Android, macOS, iOS, and Microsoft Store clients, you must add targetisaadjoined:i:1 to the HP. These connections are restricted to entering user name and password credentials when signing in to the session host.

But, what is more important for me, and it was driving me crazy at first, it was the authantication in AVD AADJoined:

The following configurations are currently supported with Azure AD-joined VMs:

• Personal desktops with local user profiles.
• Pooled desktops used as a jump box. In this configuration, users first access the Azure Virtual Desktop VM before connecting to a different PC on the network. Users should not save data on the VM.
• Pooled desktops or apps where users don’t need to save data on the VM. For example, for applications that save data online or connect to a remote database.

So, don’t break your head trying to authenticate with your current user as in WVD Joined Domain, you will need to use a Local profile for AzureAD Joined VMs, if not you will receive an error like the following which will drive you nuts:

But after using the local user in the VM you will be able to log in the VM.

Once you log in to the VM, you can check the dsregcmd to see the status:

And also how the machine is enrolled in Intune, you can check the information regarding the enterprise registration 🙂

For me AVD AADJoin, it is a pseudo Windows365 but with custom images and without paying the full license to access to the resource itself. The other things about AVD and AADJoin are pretty the same as Domain Joined, so have fun with them

Till next time!

AADConnect : Unable to connect to the Synchronization Service Manager

This is a reminder to myself, long time ago I needed to configure an ADConnect service, since today. I used other account to configure the service, but when I tried to access to the server with another account I was receiving the follwing error:

Unable to connect to the Synchronization Service.

Some possible reasons are:

1. The service is not started.
2. Your account is not a member of a required security group.

See the Synchronization Service documentation for details

Solution:

Check if the Microsoft Azure AD Sync Service is started

Check is your account is a member of the local ADSyncAdmins and/or ADSyncOperators group,if not, add the current user to this group and logoff and logon again !

Messing around with WVD, AADDS and FSLogix

In a project where WVD was involved, we needed to implement AADDS and FSlogix to the scenario. If you take a look to that scenario, it is pretty simple, but it hides some stones that we hit during the road, so I want to explain them in this post 😊

First of all, once you have deployed the AADDS, remember to check DNS settings in the VNet, it is necessary to put the DNS from the AADDS, otherwise won’t be possible to join VMs to the AADDS domain:

Once the AADDS instance was deployed it took turn for the golden image, as you probably know there is no problem to install all the programs and updates, but our stone here was once we deployed the language pack and the image was prepared, the sysprep was crashing, so we need to deep dive into the logs to solve the problem…

So the deployment begun to be fun, but after digging, we were able to solve by executing…

Remove-AppxPackage -Package Microsoft.LanguageExperiencePackes-ES_19041.17.51.0_neutral__8wekyb3d8bbwe -AllUsers

And then… boom!

Probably you will need to change your package in your case but is important to include the -allusers parameter.

Solved the golden image problem, it take turn to the deploy the host pool which process was straightforward. Our next stone was the storage account… ☹

Deploying the storage account into the AADDS was easy, but the problem was to give NTFS permission to the users, we were used to do that process in ADDS scenarios, so we know what to do, but with AADDS the procedure changes a bit…

So my piece of advice, would be to follow the instructions given in docs: Uso de Azure AD Domain Services para autorizar el acceso a los datos de archivo a través de SMB | Microsoft Docs

We were using the AAD credentials and we were stuck for a while until we read this in the documentation. Lesson learned, read documentation help.

Once you have entered to the storage account with your storage account key, you are able to give NTFS permission to the users (please follow instructions from docs xD)

Once we solved this, we were in position to configure FSLogix for the mobility of the profiles. For those who do not know FSLogix it allows to store both user profiles and applications on a centralized file share. This is extremely useful in virtual desktop environments, as the user’s profile does not have to be copied prior to boot. FSLogix will mount those profiles hosted on a file share and will make them appear local.

But again, once we have configured the entry in the VM registry:

We hit another stone… because we were logging into the WVD remote desktop and it didn’t create any profile on the Storage account, after digging and asking ourselves, we decided to go to FSLOgix logs located here: %ProgramData%\FSLogix\Logs. We checked the profile logs and found the following:

Configuration setting not found: SOFTWARE\FSLogix\Profiles\AttachVHDSDDL. Using default:
[17:33:52.257][tid:00000c4c.00000e74][INFO] Session configuration wrote (REG_SZ): SOFTWARE\FSLogix\Profiles\Sessions\S-1-5-21-1901185187-4119977032-3365905087-1004\AttachVHDSDDL = ‘D:AI(A;;GA;;;SY)(A;;GA;;;BA)(A;;GA;;;BU)(A;;GA;;;WD)(A;;GA;;;RC)(A;;GA;;;AC)S:(ML;;NW;;;LW)’
[17:33:52.273][tid:00000c4c.00000e74][INFO] Status set to 0: Success
[17:33:52.273][tid:00000c4c.00000e74][INFO] Reason set to 3: A local profile for this user exists on this system
[17:33:52.273][tid:00000c4c.00000e74][WARN: 00000003] Local profile already exists. Do nothing. (El sistema no puede encontrar la ruta especificada.)

Probably you will asking yourself what kind of error is that? It is simple, your local profile is messing with the network profile being created, so what we had to do is to remove the local profile. You can do that by going into advanced system settings and deleting the profile

We did that, and we tried again and booooooom! The profile was created in the storage account:

After doing that, we were in position to do all the test in WVD and then di all the steps to create and enterprise environment (optimization, monitoring, a “true” golden image, hide the power button, etc…).

Till nex time!