Disable all phone and text options for MFA

Impact of Removing SMS As an MFA Method In Azure AD

Posted on 2 CommentsPosted in 2FA, Azure Active Directory, Azure AD, MFA, security, self-service password reset, smartphone, sms, text message

There are a number of general recommendations that SMS (text messages) as an MFA method is not a good idea (mainly to do with the ease of porting or moving devices the number is associated with). You should always be looking at MFA with an app (Microsoft Authenticator or other) or hardware device. But the default in Azure AD is to include SMS as an option – so if we turn off text messaging as a second factor what is the impact to our user base who might have already registered their phone number.

My previous article on MFA end user experiences covered the different options available for the different registration wizards (legacy and the new combined MFA/SSPR wizard), what happens if you have SSPR enabled (and what happens if you do not). Each of the scenarios in that article allowed the user to register a phone number and then to have a text message sent at login.

If the user registered with the legacy authentication wizard (which is the default setting as of the time of writing) then there are three options by default – authentication phone, office number (set by the admin and not by the user) and mobile app (and phone is the selected option). Using SMS for second factor is therefore automatically set up unless the user chooses “office number” or “mobile app” whilst registering. The registration page looks as follows:

Legacy Auth for MFA with Phone Selected

So in scenarios where the user followed the defaults they get an MFA prompt at login that looks like this:

MFA via Phonecall dialog

Notice that they have an option to “sign in another way” for scenarios where the user maybe cannot receive a phone call but would be able to receive a text message (if you are in a location where you can receive neither, then you need to register the app as well in advance). If the user clicks “sign in another way” then they see the following where they can choose to receive a text message as the second factor proof:

Second factor proof select phone or text

To disable SMS/text as an MFA method you need to be in the Azure AD portal > MFA > Additional cloud-based MFA settings (or click Multi-Factor Authentication in the Users page of the same portal). You will see the below once you click the Service Settings tab:

Classic MFA Service Settings

This dialog includes the “skip multi-factor authentication…” box which you only have if you have Azure AD P1 or P2 licence. The four options at the bottom include the “Text message to phone” – uncheck that to stop SMS as a second factor.

So if SMS/text is removed as an option – what changes for the users who has already got a phone number stored as a MFA method? First change is that “sign in another way” message is now missing. A user who previously got a phone call with the option to change to another option will find that they cannot change options anymore (unless they have also registered a different method such as office number or mobile app:

MFA by Phone with SMS disabled

Therefore if there is not enough mobile signal to manage a call (and there might be for a text message) then the user cannot authenticate.

What about users who when they registered for MFA set SMS as their default? Setting text message as a default is not a obvious setting – but the default is whatever you initially choose to register with – so in the registration wizard if you select “send me a code by text message” then your default is SMS:

SMS as default MFA method

Once the admin disables SMS as a valid second factor, those users with phone as their default (or app) are not impacted – but users who set text message as their default are required to re-register. In the registration they are told their organization needs further information, that “call me” is the only available option, but their previously registered telephone number is shown in the registration wizard. This is shown in the following series of images:

More information required
Registration for MFA - Call only as a phone option
Registration for MFA steps
Registration for MFA steps 2

Once the users settings are saved, the user clicks Finish and their registration for phone authentication is updated to remove text message as a valid option. Enabling texts again in the admin portal does not allow this user to use texts again unless they register again or they update their additional security verification settings (Office 365 browser app > click photo > My account > Manage security & privacy > Additional security verification > Update your phone numbers used for account security (go to https://aka.ms/mfasetup as a shortcut to avoid all these steps)

If you remove both phone and text as a registration option as shown then users who previously only had phone and/or text registered will be required to register again.

Disable all phone and text options for MFA

This time registration will default to “mobile app” – where the user can select “code” or “notification” as their new default:

MFA Registration - phone and text disabled

In scenarios where you have enabled the new registration wizard (see my previous article on MFA end user experiences for more on this) then the default registration option is to use the app and not phone or text, though phone numbers are collected if you also turn on two or more options for requiring a password reset with SSPR. So in these scenarios you will probably find that the user has lots of registered options and so turning off SMS is not an issue.

So to disable SMS is only a problem in Azure AD for the user – and it means that at the next login they need to register again (so not a real problem). I had previously seen in 2018 that if the admin disabled text messages then users could not login if this was their only method! So that issue is clearly fixed now.

So as a call to action from this article – consider turning off text messages as a second factor and noting that the only impact is some users will either need to register again or you can ask them to go to https://aka.ms/mfasetup beforehand to change their default setting.

Register For Azure AD MFA From On-Premises Or Known Networks Only

Posted on 8 CommentsPosted in Azure Active Directory, Azure AD, conditional access, enterprise mobility + security, Office 365, security, self-service password reset, sspr

A long request within Azure AD/Office 365 has been the request to be able to register your security info from a known location or only on certain other conditions. Well it looks like this has appeared in Azure AD in the last few days!!

Its visible under Azure AD > Conditional Access > New/Existing Policy > Cloud Apps or Actions:

image

So, what does this look like in practice? Lets put this preview to the test.

Create the Conditional Access Policy for User Actions

Open the Azure AD portal at https://aad.portal.azure.com and click Enterprise Applications

From here click Conditional Access (this is also accessible under Azure AD > Security as well)

Click Add Policy and give the policy a name. I have chosen “Register Security Information On-Premises” for here

Click Users and Groups. I have selected “Users and Groups” rather than “All Users” as I plan to test this out first! I have picked the group that I use for testing Conditional Access changes. Eventually I will change this to All Users so that no-one can register security info apart from when on a trusted location. Note that this would also I think include guest users – I need to test that! Guest users are by their very nature not on my network but I might have MFA required for them – so they need to register, but I don’t want to apply the below to them

image

Select Cloud Apps or Actions (this was recently renamed to support this functionality we are describing here)

Select User Actions in the slider and check the option for Register Security Information (Preview)

Select Conditions and select the conditions you want to apply when users are registering security information. Its probably location based, so I will set that up here.

Select Locations, click Yes under Configure and select Any Location under Include and then under Exclude select Trusted Locations. Note that you need to have set up trusted locations in Conditional Access as well – I’m going to assume the public IP of all your offices is added and marked as trusted.

This setting will ensure that all locations other than trusted locations cannot register security information – note that this is the reverse of what you might expect. We need to block the locations we don’t want to access the MFA/SSPR registration process rather than the reverse. This is because we are required to add a control to the rules

image

With Azure AD P2 licences you could user a sign-in risk condition, ensuring that registration does not happen on medium or high risk sign-ins!

Click Done to bring you back to the first blade of settings and set Enable Policy to On to turn on this feature

Under Access Controls, click Grant and choose Block Access – be very careful here – don’t block all your access to everything!

image

Click Done

This takes us back to the first blade in the Conditional Access settings.

Click On in the Enable Policy slider

Now the Create button is available – this is not available if you do not create the reverse of what you might expect to do – block unknown locations rather than allow trusted locations!

image

Click Create

You will get your notification – you can test this in a few minutes:

image

Enable The New Combined MFA/SSPR Registration Page

Though I noticed that this conditional access restriction works against the older MFA registration page, Microsoft have said in their release blog article for this feature that it will only work against the new MFA/SSPR combined registration page. Therefore you should turn this on for your users impacted by the above policy – initially for your pilot users and then for all users.

See https://techcommunity.microsoft.com/t5/Azure-Active-Directory-Identity/Cool-enhancements-to-the-Azure-AD-combined-MFA-and-password/ba-p/354271 for more on setting up the combined MFA/SSPR registration page.

Testing Register Security Information (Preview)

In an in-private browser session on the Wi-Fi of your favourite coffee company, browse to https://aka.ms/mfasetup (as this is not a trusted location!)

After logging in you would expect to be take to the registration page for MFA and SSPR – but you are not!

image

Repeat your test from on-premises, and you will get the MFA and SSPR registration pages (or both if you have the new combined MFA+SSPR wizard enabled):

Note that for a brand new user where you have SSPR enabled, they are required to register by default every 180 days. This will mean they have to register at first login – therefore first login needs to be from a trusted network (in this example) – you could use Trusted Device as the only place to register from, but adding a user to a trusted device requires MFA by default, so watch out for an issue here and if you want to do this, test it very well.

I have not had the opportunity to test this with the 180 day refresh of your settings – presumably that should work from any location and only changing them would be blocked, but this is something that needs to be tried out.

Improving Password Security In the Cloud and On-Premises

Posted on 1 CommentPosted in active directory, Azure Active Directory, Azure AD, AzureAD, EM+S, enterprise mobility + security, microsoft, Office 365, password, security

Passwords are well known to be generally insecure the way users create them. They don’t like “complex” passwords such as p9Y8Li!uk%al and so if they are forced to create a “complex” password due to a policy in say Active Directory, or because their password has expired and they need to generate a new one, they will go for something that is easy to remember and matches the “complexity” rules required by their IT department. This means users will go for passwords such as WorldCup2018! and Summ3r!!. Both these exceed 8 characters, both have mixed case, both have symbols and numbers – so both are complex passwords. Except they are not – they are easy to guess. For example, you can tell the date of this blog post from my suggestions! Users will not tend to pick passwords that are really random and malicious actors know this. So current password guidance from NIST and UK National Cyber Security Centre is to have non-expiring unknown, not simple passwords that are changed on compromise. Non-expiring allows the user to remember it if they need to (though a password manager is better) and as it is unknown beforehand (or unique) means its not on any existing password guess list that might exist.

So how can we ensure that users will choose these passwords! One is end user training, but another just released feature in the Microsoft Cloud is to block common passwords and password lists. This feature is called Azure AD Password Protection. With the password management settings in Azure AD, cloud accounts have been blocked from common passwords for a while (passwords that Microsoft see being used to attempt non-owner access on accounts) but with the password authentication restrictions you can link this to block lists and implement it with password changes that happen on domain controllers.

So how does all this work, and what sort of changes can I expect with my passwords.

Well what to expect can look like this:

image

Note all the below is what I currently know Microsoft do. This is based on info made public in November 2018 and documented at https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-password-ban-bad and is subject to change as Microsoft’s security graph and machine learning determines change is needed to keep accounts secure.

Password Scoring

First, each password is scored when changed or set by an administrator or a user on first use. A password with a score less than 5 is not allowed. For example:

spring2018 = [spring] + [2018] = 2 points

spring2018asdfj236 = [spring] + [2018] + [asdf] + [f] + [j] + [2] + [3] + [6] = 8 points

This shows that common phrases (like Spring and 2018) can be allowed as part of password that also contains stuff that is hard to guess. In this, the asdf pattern is something straight from a Qwerty keyboard and so gets a low score. In addition to the score needing to exceed 5, other complexity rules such as certain characters and length are still required if you enforce those options. Passwords are also “normalized”, which lower cases them and compares them in lower case – so spRinG2018 is as weak as spring2018. Normalization also does common character replacesments such as $=s, so $PrinG2018 is the same as spring2018 and also just as weak!

You name is not allowed in any password you set and the logic applies to an edit distance of 1 character – that is if “spring” is a blocked word then “sprinh” would also be blocked, h being one character away from g.

Common and Blocked Lists

Microsoft provide the common password lists, and these change as Microsoft see different passwords getting used in account attacks. You provide a custom blocked list. This can contain up to 1000 words, and Microsoft apply fuzzy logic to yours and the common list. For example we added all our office locations as shown:

image

This means that both capetown and C@p3t0wn would be blocked. The @=a, the 3=e and the 0=o. So the more complex one is really not complex at all as it contains common replacements.

In terms of licences, the banned password list that Microsoft provides is licence free to all cloud accounts. You need AAD Basic if you want to add your own custom banned password list. For accounts in Windows Server Active Directory you need the Azure AD Premium (P1) licence for all synced users to allow downloading of the banned password list as well as customising it with your words so that Active Directory can apply it to all users on-premises to block bad passwords (even those users not synced to AzureAD).

Hybrid Password Change Events Protected

The checks on whether a password change should be stopped is included in hybrid scenarios using self-service password reset, password hash sync, and pass-through authentication, though changes to the custom banned password list may take a few hours to be applied to the list that is downloaded to your domain controllers.

On-Premises Changes

There is an agent that is installed on the domain controllers. Password changes are passed to the agent and it checks the password against the common list and your blocked list. The agent does the password check, and it checks it against the most recently downloaded list from Azure AD. The password for on-premises is not passed up to Azure AD, the list is downloaded from Azure AD and processed locally on the domain controller. This download is done by the Azure AD password protection proxy. The list is then downloaded once per hour per AD site to include the latest changes. If your Azure AD password protection proxy fails, then you just use the last list that was successfully downloaded. Password changes are still allowed even if you lose internet access.

Note that the Azure AD password protection proxy is not the same as the Pass-Through Authentication agent or the AAD Connect Health agent. The Azure AD password protection proxy can though be installed on the same servers as the PTA or Connect Health agent. Provisioning new servers for the proxy download service are not required.

The Azure AD password protection proxy wakes up hourly, checks SYSVOL to see the timestamp of the most recently downloaded copy and decides if a new copy is needed. Therefore if your intra-site replication is within the hour, proxy agents in other sites might not need to download the list as the latest is already available via DFSR between the domain controllers.

The Azure AD password protection proxy does not need to run on a domain controller, so your domain controllers do not need internet access to obtain the latest list. The Azure AD password protection proxy downloads the list and places it in SYSVOL so that DFSR replication can take it to the domain controller that needs it.

Getting Started

To set a custom password block list, in the Azure Portal visit the Azure AD page, click Security and then click Authentication Methods (in the Manage section). Enter your banned passwords, lower case will do as Microsoft apply fuzzy logic as described above to match your list to similar other values. Your list should include common words to your organization, such as location, office address keywords, functions and features of what the company does etc.

For Active Directory, download the agent (from the Microsoft Download Center) to one or more servers (for fault tolerance). These will download the latest list and place it in SYSVOL so that the domain controllers can process it. Two servers in two sites would probably ensure one of them is always able to download the latest copy of the list.

The documentation is found at https://aka.ms/deploypasswordprotection.

Microsoft suggests that any deployment start in audit mode. Audit mode is the default initial setting where passwords can continue to be set even if they would be blocked. Those that would fail in Enforce mode are allowed in Audit mode, but when in audit mode entries in the event log record the fact that the password would fail if enforce was turned on. Once proxy server(s) and DC agents are fully deployed in audit mode, regular monitoring should be done in order to determine what impact password policy enforcement would have on users and the environment if the policy was enforced.

This audit mode allows you to update in-house policy, extend training programs and offer password advice and see what users are doing that would be considered weak. Once you are happy that users are able to respond to an password change error because the password is too weak, move to enforce mode. Enforce mode should kick in within a few hours of you changing it in the cloud.

Installing the Proxy and DC Agent

Domain Controllers need to be running Windows Server 2012 and later, though there are no requirements for specific domain or forest functional levels. The Proxy software needs to run on a Windows Server 2012 R2 or later server and be running .NET 4.6.2 or later. Visit the Microsoft Download Center to download both the agent and the password protection proxy. The proxy is installed and then configured on a few (two at most during preview) servers in a forest. The agent is installed on all domain controllers as password changes can be enacted on any of them.

To install the agent, run AzureADPasswordProtectionProxy.msi on the server that has internet connectivity to Azure AD. This could be your domain controller, but it would need internet access to do this.

To configure the agent, you need to run once Import-Module AzureADPasswordProtection followed by Register-AzureADPasswordProtectionProxy and then once the proxy is registered, register the forest as well with Register-AzureADPasswordProtectionForest all from an administrative PowerShell session (enterprise admin and global admin roles required). Registering the server adds information to the Active Directory domain partition about the server and port the proxy servers can be found at and registering the forest settings ensure that information about the service is stored in the configuration partition.

Import-Module AzureADPasswordProtection
Get-Service AzureADPasswordProtectionProxy | FL
$tenantAdminCreds = Get-Credential
Register-AzureADPasswordProtectionProxy -AzureCredential $tenantAdminCreds
Register-AzureADPasswordProtectionForest -AzureCredential $tenantAdminCreds

If you get an error that reads “InvalidOperation: (:) [Register-AzureADPasswordProtectionProxy], AggregateException” then this is because your AzureAD requires MFA for device join. The proxy did not support MFA for device join during the early preview but that should now be resolved – make sure you are using the latest download of the agent and proxy code. you need to disable this setting in Azure AD for the period covering the time you make these changes – you can turn it back on again (as on is recommended) once you are finished configuring your proxy servers. This setting, should you need to disable it, is found at:

  • Navigate to Azure Active Directory -> Devices -> Device settings
  • Set “Require Multi-Factor Auth to join devices” to “No”
  • As shown
    image
  • Then once the registration of your two proxies is complete, reverse this change and turn it back on again.

Once at least one proxy is installed, you can install the agent on your domain controllers. This is the AzureADPasswordProtectionDCAgent.msi and once installed requires a restart of the server to take its role within the password change process.

The PowerShell cmdlet Get-AzureADPasswordProtectionDCAgent will report the state of the DCAgent and the date/time stamp of the last downloaded password block list that the agent knows about.

image

Changes In Forest

Once the domain controller the agent is installed on is rebooted, it comes back online, finds the server(s) running the proxy application and asks it to download the latest password block list. The proxy downloads this to C:\Windows\SYSVOL\domain\AzureADPasswordProtection. Older versions of the proxy and agent used a folder called
{4A9AB66B-4365-4C2A-996C-58ED9927332D} under Policies folder. These versions of the agent stop working in July 2019 and need to be updated to the latest release.

In the Configuration partition at CN=Azure AD Password Protection,CN=Services,CN=Configuration,DC=domain,DC=com some settings about the service are persisted. If the domain controller has the agent installed then

CN=AzureADConnectPasswordPolicyDCAgent,CN=<DomainControllerName>,OU=Domain Controllers,DC=domain,DC=com is created.

And then on each domain controller, in the Event Viewer, you get Application and Services Logs > Microsoft > AzureADPasswordProxy with DCAgent on the DC’s and ProxyService on the proxy servers. The EventID’s are documented at https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-password-ban-bad-on-premises-monitor.

The monitoring Event ID will cover things like user password change differently than admin password set. This allows you to audit who (end user or service desk) is setting weak passwords.

Once the proxy starts to work, the above folder starts to get content. In my case in the preview it took over 2 hours from installing the proxy as well as the documented installation and configuration PowerShell cmdlets listed above to get the proxy to download anything. The above listed Configuration folder contained some cfge files and the above listed PasswordPolicies contains what I assume is the downloaded password block list, compressed as its only 12KB. This is the .ppe file and there is one of these per hour downloaded. Older versions of this download are deleted by the proxy service automatically.

Audit Mode

Using the above Event ID’s you can track the users who have changed to weak passwords (in that they are on your or Microsoft’s banned password list) when the user or admin sets (or resets) the users password. Audit mode does not stop the user choosing the password that would “normally have been rejected” but will record different Event IDs depending upon the activity and which block list it would have failed against. Event id DCAgent/30009 for example has the message “The reset password for the specified user would normally have been rejected because it matches at least one of the tokens present in the Microsoft global banned password list of the current Azure password policy. The current Azure password policy is configured for audit-only mode so the password was accepted.”. This message is a failure against Microsoft’s list on password set. The user doing a password change and the Microsoft list gets DCAgent/30010 Event ID recorded instead.

Using these two Event ID’s along with DCAgent/30007 (logged when password set but fails your custom list) and or DCAgent/30008 (password changed, fails your custom list) allows you to audit the impact of the new policy before you enforce it.

Enforce Mode

This mode ensures that password set or change events cannot have passwords that would fail the list policies. This is enabled in the password policy in Azure AD as shown:

image

Once this is enabled it takes a few hours to be picked up by the proxy servers and then for the agent to start rejecting banned passwords.

When a user changes their password in enforce mode they get the following error (different graphic depending upon Windows versions). If the admin changing the password uses a blocked password then they see the left hand graphic as well (Active Directory Users and Computers).

image
image

or

This is no different to the old error you get when your password complexity, length or history is not met. Therefore there is no indication to the user that the password they chose might be banned rather than not allowed for the given reasons. So though password policy with a banned list is an excellent step forward, there needs to be help desk and end user awareness and communications (even if they are just a simple notification) as the user would not be able to tell from the client error they get. Maybe Microsoft have plans to update the client error?

Password changes that fail once enforce mode is enabled get Event ID’s such as DCAgent/30002, DCAgent/30003, DCAgent/30004 and DCAgent/30005 depending upon which password list the fail happened against and the method of password set or change. For example when I used the password Oxford123, as “oxford” is in the custom banned password list, Event ID 30003 returns “The reset password for the specified user was rejected because it matched at least one of the tokens present in the per-tenant banned password list of the current Azure password policy”. As mentioned above, the sequence of 123 following the banned word is not enough to make to score more than 5 points and so the password change is rejected.

On the other hand, 0xf0rdEng1and! was allowed as England was not on my banned list an so although my new password contained a banned word, there were enough other components of the password to make it secure enough. Based on the above mentioned scoring of 5 or more is required to have a password accepted, [Oxford] + [E] + [n] + [g] + [1] + [a] + [n] + [d] + [!], a total of 9. 9 >= 5 and so the password is accepted.

Finally, when testing users, other password policies like the date that the password can next be changed and “user cannot change password” property etc. will take effect over the banned password list. For example, if you have a cannot change password for 5 days setting, and you set the users password as an administrator – that will work or fail based on the password you enter, but if you change the password as the user within that time period, that will fail as five days have not gone by and not because the user picked a guessable password.

Forcing Transport Level Secure Email With Exchange Online

Posted on Leave a commentPosted in EOP, exchange online, Exchange Online Protection, Exchange Server, Office 365, security, starttls, TLS

In Exchange Online there are a few different options for forcing email to require an encrypted connection. These depend upon the level of licence you have, and some of them are user based (Office 365 Message Encryption for example), but there are two ways to force TLS (transport layer security) for the email between when the message leaves Office 365 and arrives with the recipient email system.

The first of these is a Mail Flow rule, and the second of these is a Conditional Connector. Only the second of these works!

The first, just for clarity, appears to work but it is not 100% reliable and will end up with stuck emails unless you configure the rule 100% correct. The second option is the recommended option ongoing.

For completion, we will also look at forcing TLS inbound to Exchange Online

Force TLS with Mail Flow Rules

This option relies on a Transport Rule (or mail flow rule) setting called “Require TLS”. This below example shows a UK Government requirement that states that emails to certain government departments (by domain name) should enforce the use of TLS:

image

This rule uses the condition “if the recipient address includes” and the list of UK Government domains that should be secured. This list is found at https://www.gov.uk/guidance/set-up-government-email-services-securely#configure-cloud-or-internet-based-email-services and for test purposes I have added my own domains to the list. The action for this rule is “to require TLS encryption”.

As mentioned above, this rule is not 100% reliable, and the the issue is when you have a Hybrid Exchange Online environment back to on-premises Exchange, though that connector back to on-premises uses TLS, the rule to force TLS conflicts and the email stays in Exchange Online in a pending state and is never delivered.
To avoid this issue, an exception is required to the rule to exempt it for your on-premises domains.

Force TLS with Conditional Connectors

This is the recommended route for forcing TLS. It requires two settings created. The first is a Conditional Connector as shown:

image

You must select “Only when I have a transport rule set up that redirects messages to this connector” on the connector use page.

image

MX delivery is the most likely option, and then either any digital certificate or issued by a trusted third party depending upon your requirements.

image

If you have more than one domain to force TLS to, then do not enter the end certificate info here, as it will be different for each domain.

Now that you have the connector in place, which will only be used is rules route the emails to that connector, you can create the rule.

image

We have purposely excluded the domains we had an issue with when using “Require TLS”, but Microsoft say that workaround should not be needed – I will update this post once I know that for sure! Also, as the rule shown in the screenshots adds a disclaimer so that we can check that the rule is being executed.

Inbound Required TLS with Connectors

To force inbound TLS requirements, so that email from given domains are rejected if they do not open a TLS session with your organization to send an email you create a Partner to Office 365 connector. This connector will force TLS or reject the email inbound if that cannot happen:

image

image

image

And then choosing “Reject email messages if they aren’t sent over TLS” as part of the connector conditions:

image

image

Securing Your Windows 10 Login With Yubikey

Posted on 5 CommentsPosted in MFA, MVP, security, yubikey

The Yubikey is a small USB connected hardware device that can generate a variety of security codes. Being virtually indestructible and easy to clip to a key ring (Yubikey 4) or leave inside your only device (Yubikey 4 Nano) you can now use this token to login to Windows. Once you have got your token from Yubico (via Amazon or other resellers) for around £40 you start the very simple Windows Hello authentication registration process by downloading the Yubikey app from Windows App Store.  Signing in after a restart requires full credentials (password or PIN), which means a stranger who steals your PC and the YubiKey can’t use it to access your device

Open the Store app, search for Yubikey and click the logo for the app.

image

Click the Get button to install the app then then launch to start it. In a corporate environment you can push the app to your devices with MDM solutions like Intune.

Launch the app. You will need to have a PIN login enabled for the device to work and so you will see a warning if you do not have this enabled.

image

If you need to set up a PIN then close the Yubikey app and type “PIN” in the search box in Windows and choose “Setup PIN sign-in”

image

Scroll down and click Add under PIN. You will need to reenter your password so other people cannot set up a PIN on your behalf.

Enter a PIN and confirm the same PIN

image

You will now be able to use a PIN to sign in. The PIN setup process will continue and you will be asked to confirm your PIN again. You can now use your PIN to sign into your computer, which as it is tied to the computer hardware, is more secure than your password. But we are not stopping there – we can now restart the Yubikey app. Either launch it from the Store app, from the search box on the Start Menu or From the Start menu, select All Apps >Start > YubiKey for Windows Hello

image

Click Register to start the process of pairing your Yubikey to your computer

image

Insert your Yubikey into any USB port on the PC and press Continue

image

Name the Yubikey, as at login it will ask you to insert this named key. Click Continue once you have a name

image

At this point it should register the device and all is good!

If you find that Windows Companion Devices are disabled then you will get this error:

image

It reads “Oh no! An error occurred during registration. Windows companion devices are disabled on this system. Contact your system administrator”. This is because the local security policy on your computer or network via your Active Directory and IT driven polices does not allow companion devices. On systems running Windows Pro or Windows Enterprise systems, you must enable the option to Allow companion device for secondary authentication in the Local Security Policy. If your organization manages your security policy, contact your IT administrator and request this change before installing this app. You cannot change local security policy on systems running Windows Home, however this option is enabled by default. Note that you will also get this on domain joined systems as well, as secondary auth is not supported on domain joined machines (even for individual users) at this time.

To modify local security policy

  1. Open the Local Group Policy Editor. To do this, press the Windows key, type R, and then type gpedit.msc.
  2. In the Local Group Policy Editor, from the top level Local Computer Policy, navigate to Computer Configuration > Administrative Templates > Windows Components > Microsoft Secondary Authentication Factor.
  3. In the right pane, click the link to Edit policy setting. (You can also double-click the setting to Allow companion device for secondary authentication.) The default state is Not configured.
  4. In the setting screen, select the option for Enabled, and click OK. If this option is already selected, your policy is set and you can click Cancel.
  5. Exit the Local Group Policy Editor and the Management Console.