Category Archives: Office365

Choose a password that’s harder for people to guess

When you’ve implemented Self Service Password Reset and a cloud user (i.e. an account that only lives in the Microsoft cloud, not an on-premises Active Directory account) wants to change his password, there’s a chance the user will see the following error message:
“Choose a password that’s harder for people to guess”

pass1word-guess
The odd thing is, when the user changes his password in the SSPR it even says the user is using a strong password as shown in the following screenshot:

pass1word

Note. I tried this with several combinations, like Pass1word, P@ssW0rd and Spring2018.

A similar error message can be “Unfortunately, your password contains a word, phrase or pattern that makes it easily guessable. Please try again with a different password.” as shown in the following screenshot:

guessable

The ‘problem’ here is that the user is hitting the ‘banned password list’ in Azure Active Directory. This banned password list is a list of over 1,000 passwords that can easily be guessed, and as such vulnerable for password spray attacks. These passwords are simple words like spring, summer, autumn, winter, football, company name, qwerty, 123456, welcome, zaq1zaq1 etc etc etc. There’s a list of most common passwords on WikiPedia. Of course there are several variations of passwords, password, Pass1word, Pass!word, Passw0rd, you name it, but Microsoft is using normalization techniques to filter out all replaced characters and thus block these passwords.

Banned passwords are part of the Azure AD Password Protection feature, a feature that’s still in preview at the time of writing (October 2018). When you logon to the Azure Portal (https://portal.azure.com) and navigate to Azure Active Directory | Authentication Methods (in the security section) you’ll see the Azure AD Password Protection feature:

password_protection

The banned password list is enforced by default, there’s no way to disable it. If you have an Azure AD Premium license, you can also use a custom banned password list and maintain you own list of words or phrases that you don’t want to be used as a password.

Summary

If your users run into the Choose a password that’s harder for people to guess error message when changing their password in Azure AD or Office 365, they are hitting the banned password list as part of the Azure AD Password protect feature. A feature that’s enforced by default, and implemented by Microsoft as a means to improve security.
This feature is available for cloud users only by default, but if you have implemented self service password reset (SSPR) with password writeback it also works. The nice thing is, it can also be extended to on-premises Active Directory for password changes on-premises. Nice topic for an upcoming blog.

Improved Secure Score in Office 365 tenant

In a previous blogpost I explained about the Microsoft Secure Score and how this indicates the level of security in your Office 365 tenant.

My initial score was only 70, which is pretty low. By implementing Self Service Password Reset and MFA for Admin Acccounts the Secure Score was increased to 122. It could have been a couple of point higher when enabling MFA for all users, but not all users have licenses in Office 365.

I’m curious to see what improvements I can make in the Exchange Online part and how this will influence the Secure Score. Stay tuned 🙂

secure-score-122

Azure AD and Office 365 Password writeback

My previous blogpost was about the Self Service Password Reset (SSPR). A nice feature for cloud identities, but this doesn’t work if you have synchronized identities or federated identities. These are managed in your on-premises Active Directory, so for SSPR to work you need to implement a password writeback solution.

Luckily this feature is available, but the standard Office 365 licenses do not include password writeback functionality. You this you need an Azure AD Premium P1 or Azure AD Premium P2 license. Enterprise Mobility + Security (EMS) E3 does include Azure AD Premium P1, EMS E5 does include Azure AD Premium P2.

To implement password writeback, you need to have SSPR up-and-running. To configure password writeback you have to run the Azure AD Connect wizard.

Note. Make sure you always have the latest version of Azure AD Connect running. Even better, use the auto update feature of Azure AD Connect to make sure you’re up-to-date. At the time of writing the latest version of Azure AD Connect was 1.1.882.0 (as of Sept. 8, 2018).

Start the Azure AD Connect wizard and select the Customize Synchronization Options. Follow the wizard until you reach the Optional Features. Check the Password Writeback option as shown in the screenshot below and click Next to continue.

optional_features

Follow the wizard until the configuration is complete and click Exit to finish the wizard and store the new configuration.
The service account that’s used by Azure AD Connect needs the appropriate permissions in your on-premises Active Directory to store the new password that has been set in Azure AD.
To find out which service account is used by Azure AD Connect, start Azure AD Connect and select View Current Configuration and check the account as shown in the following screenshot:

View_Current_Configuration

The following permissions need to be granted to the service account on either the domain object, or on an OU if you want to scope the permissions:

  • Reset password
  • Change password
  • Write permissions on lockoutTime
  • Write permissions on pwdLastSet

Open Active Directory and Computers, enable Advanced Features, select the properties of the domain, click on Security, click on Advanced and click Add.

Select the service account that was retrieved earlier under Principal and in the applies to dropdown box select Descendent User Objects. Check the following options:

  • Reset password
  • Change password
  • Write lockoutTime (scroll down)
  • Write pwdLastSet (scroll down)

Click on OK to apply the changes to Active Directory and close any following pop-up boxes.

Permission_Entry

To test the password write back option, follow the same procedure as in the SSPR blogpost. After you have changed your password, it is written back to your on-premises Active Directory and the following event is written to the eventlog of the Azure AD Connect server.

EventID_31001

Summary

In this blogpost I’ve shown you how to implement password writeback in your synchronized Azure AD environment. One prerequisite is that you need to have Self Service Password Reset implemented, and you need to have an Azure AD Premium P1 or Azure AD Premium P2.

Self Service Password Reset in Office 365

One option, not only for security, but also for user convenience is Self Service Password Reset (SSPR). This feature enables cloud users to reset their own passwords in Azure Active Directory, and this way they don’t have to contact the local IT staff with reset password questions.

Note. For Self Service Password Reset you need an additional Azure AD Basic license.

To enable Self Service Password Reset, logon to the Azure Portal (https://portal.azure.com) as a Global Administrator. Select Azure Active Directory, select Password Reset and in the actions pane, select Selected or All. Using the Selected option, you can enable SSPR only to member of the security group SSPRSecurityGroupUsers for a more targeted approach. Of course, if you want to enable SSPR for all your users you should select the All option.

Password-Reset-Selected

Click Save to store your selection. Click the second option Authentication Methods to select the number of methods available to your users. In my example, I’m going to select just one, and options I select are Email and Mobile Phone.

Methods_Available

Click Save to continue. The last step is to configure the registration. This is to require users to register when signing in, and the number of days the users are asked to re-confirm their authentication information, as shown in the following screenshot:

password-reset-registration

You’re all set now.

When a (new) user logs on now, he is presented with a pop-up, asking for verification methods. As configured earlier the authentication phone and authentication email is used. The mobile phone number that’s presented here was configured earlier in Azure Active Directory when provisioning the user. Click Verify and you’ll receive a text message with a verification code.

You can chose an email address for authentication purposes, as long as it’s not an email address in your own tenant. Follow the wizard when you click Set it up now as shown in the following screenshot.

dont-lose-access

To test the SSPR, use the browser van navigate to https://passwordreset.microsoftonline.com/, enter your userID (UPN) and enter the CAPTCHA code.

You can choose to send an email to your verification account, send a text message to your mobile phone (see screenshot below) or have Microsoft call you.

Get-Back-Into-Your-Account

Enter your phone number (the phone number that’s also registered in Azure AD) and within seconds you’ll receive a verification text message. After entering this code you can enter a new password, and with this new password you can login again.

As a bonus you’ll receive an email that you password has been changed.

Summary

In this blogpost I’ve shown you how to implement the Self Service Password Reset (SSRP), a feature that’s available in the default Office 365 Enterprise licenses, so no additional Azure AD licenses are needed. You can choose to implement text messages or email messages (as shown in this blogpost) but you can also implement additional security questions.

Now this is a nice solution for cloud identities, but it does not work for synced identities or federated identities. For this to work you need to implement password write-back, a nice topic for the next blog 😊

Multi Factor Authentication MFA in Office 365 for Admin Accounts

The last thing you want to happen is when your (global) admin accounts are compromised. One easy way to avoid this is to enable multi factor authentication or MFA for you tenant admin accounts.

To achieve this, go to the Office 365 admin center and select the active users. Click More and select Multifactor Authentication setup as shown below:

Active_Users

You’ll see a list of all users in your organization that have MFA enabled. If this is the first time you’re here, most likely all users will have MFA set to disabled.

To show only the Global Administrators select Global Administrators in the View dropdown box. Select the Global Administrator and select Enable under Quick Steps.

MFA_Enable

Continue reading Multi Factor Authentication MFA in Office 365 for Admin Accounts