Tag Archives: Azure AD

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 😊

Ignite 2018 – Azure AD and security sessions

A little later than originally planned because of an unexpected visit of the Massachusetts General Hospital in Boston on my way…. In my previous postings I blogged about the start of the conference and some of the Exchange sessions I attended in the first two days. Now how much I do love Exchange, most of my clients are moving towards Office 365 and Exchange Online, so what else is important here?

Yes, authentication! Azure Active Directory, Identity and Access Management and security around these solutions. And this happens to be important for Exchange and Exchange Online as well, so….

Secure access to Office 365/Azure Active Directory with new features in AD FS in Windows Server 2019 and Azure AD Password Protection

Sessions “BRK3226 – Secure access to Office 365/Azure Active Directory with new features in AD FS in Windows Server 2019 and Azure AD Password Protection” is all about authentication in Azure AD. It explains the traditional password hash sync as well as the ADFS options (more that 71 million users are actively using ADFS). But there are also 1.29 billion authentications blocked in August 2018 and 81% of all security breaches are because of weak, default or stolen passwords.

securing-resources

Common passwords used in (Azure) AD are Password, Spring, Summer, Autumn, Winter, 2018, 1234, your favorite football team etc. And these in turn are used in password spray attacks! Also vulnerable are passwords where number and letters are changed, for example “I” becomes “!”, “O” becomes “0” etc. And now you wonder, how many of my users are doing this? Password protection in Azure AD also includes normalization of the password, so these changes are automatically blocked. The good thing is, Azure AD password protection is coming to on-premises AD as well!

You can find the presentation on Youtube https://youtu.be/DC4cyF_JEgw and the presentation can be found here https://mediusprodstatic.studios.ms/presentations/Ignite2018/BRK3226.pptx

Azure Active Directory best practices from around the world

The title of the session was renamed to “Azure AD: Do’s and Don’ts”, but this is a more ‘notes from the field’ session with a lot of practical information around Azure AD, legacy authentication, modern authentication, Hybrid Azure AD Joine (HAADJ, I hate 3 letter acronyms, let alone 5 letter versions 😊) and what to do to get a better and more safe authentication experience.

legacy-authentication

Interesting in this presentation is that is also discusses what step you need to take to move from legacy authentication to modern authentication, and also the pitfalls you might encounter, including links to more information (found in the presentation).

associating-devices

You can see the presentation on Youtube https://youtu.be/wGk0J4z90GI and you can find the presentation here https://mediusprodstatic.studios.ms/presentations/Ignite2018/BRK3408.pptx

Scott Schnoll’s Exchange and Office 365 tips and tricks

I don’t know how many times Scott Schnoll has delivered this session, but it still is an awesome session and contains so much practical information around Exchange and nowadays Exchange Online.

scott-schnoll

I tried to make some pictures with Office Lens, but I think the color of the slides and text are not identified correctly so they are horrible. The slides aren’t available (yet), so you have to check the presentation on Youtube: https://youtu.be/0WNMX8EKYZk

Topics include anti-virus exclusions, DMARC enhancements, decommission on-premises Exchange in (or after) hybrid, changes to EOP IP ranges, migrating DL’s to Office 365 (including a script to do so), a license administrator in Office 365 (preview), DLP and credit card numbers and Mail Flow Insights, a new tool/dashboard that is currently being developed. Scott is doing a demo on this at the end of his presentation. Very cool, very promising, very useful!

Summary

So, after 5 days (well, four and a half days) we can say it was a very successful event. It is so huge, approx. 30,000 attendees from 5,000 organizations. So many sessions, break-out, theatre, workshop, hands-on, almost too much. And the sheer size of the location, I guess one can walk between 6 and 7 miles every day between the various locations. Would I go again? Sure, next year, again in Orlando, November 4-8. Hope to see you there!

More information/sessions

And some more interesting sessions to view online….

BRK2407 – Windows 10 and Office 365 ProPlus lifecycle and servicing update (CONDENSED)

https://mediusprodstatic.studios.ms/presentations/Ignite2018/BRK2407.pptx  https://youtu.be/t9Bs55czc1E

BRK3234 – An IT pros guide to Open ID Connect, OAuth 2.0 with the V1 and V2 Azure Active Directory endpoints (very informative, but not available online yet I’m afraid)

BRK3397 – Protect and control your sensitive emails with Office 365 Message Encryption

https://mediusprodstatic.studios.ms/presentations/Ignite2018/BRK3397.pptx

https://youtu.be/Ld4b4pFua0g

BRK3408 – Azure Active Directory best practices from around the world

https://mediusprodstatic.studios.ms/presentations/Ignite2018/BRK3226.pptx

https://youtu.be/wGk0J4z90GI

BRK3146 – What’s amazing and new in calendaring in Outlook!

https://youtu.be/-ZrNTylawOA

THR3024 – How to add MFA to your Exchange Online/on-premises mailboxes in 20 minutes or less

https://youtu.be/7hoEmEwV8Rk

BRK3081 – Implementing a modern network architecture to get the most out of Office 365

https://youtu.be/FGMzS_MjuPY

BRK3145 – Deploying Outlook mobile securely in the enterprise

https://youtu.be/4mHlxdJMh1Q

THR3036 – Azure Active Directory hybrid identity and banned password detection

https://youtu.be/kuVkfIiapI4

 

 

 

Single Sign-On and Azure AD Connect Pass-Through Authentication

In my previous blogpost I discussed Azure AD Connect Pass-Through Authentication (PTA), how it works and how it can be configured. In that blogpost I did not enable Single Sign-On (SSO) and that was also the first comment I got, within one or two days. Enabling SSO and how it works it this blogpost’s topic.

Authentication flow

I already explained the authentication flow when using PTA. When accessing a service in Office 365 you are redirected to Azure AD, you enter your credentials and the credentials are placed in the Azure Service Bus. The Azure AD Connect server retrieves these credentials from the Service Bus and presents them to the on-premises Domain Controller. The result is returned to the service bus and you’re granted access, or denied when something is wrong of course.

image

So, what happens if you enable SSO in the Azure AD Connect wizard? Enabling SSO is just a matter of checking the Enable single sign-on checkbox in the Azure AD Connect wizard:

image

Note. I skipped most of the configuration steps since this is identical to the configuration steps in the previous blogpost.

During the Azure AD Connect wizard you also must enter your on-premises administrator credentials, these are needed to configure your on-premises Active Directory to enable SSO with PTA.

To be fair, it’s not true SSO as with federation (through ADFS), but it is seamless Single-Sign On (sSSO). When enabling SSO in the Azure AD Connect wizard, users only need to enter their logon name when accessing services in Office 365, for example with Outlook Web App:

image

When you are on a domain joined workstation that has access to a Domain Controller, you only have to select the appropriate user account. The password is automatically returned to Azure AD and if all is well you are granted access to Outlook Web App.

If you don’t want to select or enter a logon name you can also use domain hints. In combination with Outlook Web App you would use a URL like https://outlook.office.com/owa/contoso.com. If you do so your current credentials (again, on a domain joined workstation that has access to a Domain Controller) are automatically passed through and you are granted access.

Seamless Single-Sign On under the hood

But how does this sSSO actually work under the hood.

When enabling SSO in the Azure AD Connect wizard you have to enter your on-premises domain administrator account. This is used to create an additional computer object in Active Directory called AZUREADSSOACC.

image

This computer account is used to create a shared Kerberos key between your on-premises Active Directory and Azure Active Directory, needed for creating the sSSO experience.

During logon in this scenario, the following 8 steps occur:

image

  1. The client accesses a service in the Microsoft cloud, for example OWA via https://outlook.office.com/owa.
  2. The request is redirected from Office 365 to Azure Active Directory.
  3. Access is denied, and a 401 error is returned to the client.
  4. The client accesses a local Domain Controller and requests a Kerberos token.
  5. A Kerberos session ticket is returned to the client.
  6. The session ticket is presented to Azure Active Directory. Since Azure Active Directory has a shared ticket with your on-premises Active Directory is can generate a Kerberos token for the client to use.
  7. The Kerberos token is returned to the client
  8. The Kerberos token is presented to Office 365 and access is granted. The user can now start using OWA.

As you can see this only works for domain joined clients that have access to a local Domain Controller. If they don’t have access to a local Domain Controller the regular PTA process as shown in the beginning of this blogpost (and previous blogpost) is followed.

Note. For the client to automatically pass the credentials, the Azure AD endpoints must be in the intranet zone

image

Tip. Use GPO to change this for all clients in your network.

If you use your browser and navigate to Exchange Online you will still be prompted to enter your username (or select a username when used previously) but you are not required to enter your password:

image

If you use a domain hint in your URL like https://outlook.office.com/owa/inframan.nl, then the account is automatically logged on. One small but strange note, this is supported by Microsoft Internet Explorer, but not by the Microsoft Edge browser (at least not at the moment of writing, early November 2017). This might change in the future though.

To get this working with Outlook 2016 (or fully patched Outlook 2013 that supports Modern Authentication) we need to enable OAuth on a tenant level. To achieve this, logon use Remote PowerShell in Exchange Online using the following commands:

$Cred= Get-Credential 'administrator@contoso.onmicrosoft.com'
$Session= New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/PowerShell-LiveID -Credential $Cred -Authentication Basic -AllowRedirection
Import-PSSession -Session $Session

And when logged in enter the following command:

Set-OrganizationConfig -OAuth2ClientProfileEnabled:$TRUE

image

Next time you start Outlook you will see that it will automatically logon to Exchange Online (whereas it didn’t when Oauth was not enabled).

Note. As outlined earlier in this post there’s a shared key between the computer account in your on-premises Active Directory and Azure Active Directory. It is strongly recommended to roll-over these keys every 30 days. For more information check the Microsoft FAQ on this: https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso-faq

Summary

You can use Pass-through authentication if you have a requirement to keep all user passwords on-premises (and thus not store them in the Microsoft cloud). When using Pass-through authentication you can also enable seamless Single-Sign On or sSSO. This way domain joined clients (that have access to a Domain Controller) can use Kerberos authentication to access services in the Microsoft cloud.

A number of issues to be aware of: not all clients do support PTA or sSSO as outlined in this article. For example, Internet Explorer does support it, but the Edge browser doesn’t. Outlook 2013/2016 do support it (modern authentication) but Outlook 2010 does not. Also, the Lync/Skype for business clients do not support this at all. I expect this to change in the (near) future, and when it does I will update this article.

More information

Azure Active Directory Seamless Single Sign-On: Frequently asked questions – https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso-faq

Azure AD Connect Pass-Through Authentication

At Ignite 2017 it was announced that Pass Through Authentication (PTA) has reached General Availability (GA) so it is a fully supported scenario now.

But what is PTA? If Office 365 there are Cloud Identities, Synced Identities and Federated Identities. The first two are authenticated in Azure Active Directory, the last one is authenticated against on-premises Domain Controllers. For this to happen you need an ADFS infrastructure, consisting of multiple internal ADFS servers and multiple WAP (Windows Application Proxy) servers in the DMZ acting as ADFS proxies. Oh, and all servers need to be load balanced as well to provide redundancy and scalability.

PTA on the other hand is built on top of Azure AD Connect, and as such an interesting extension of the Synced Identities. PTA installs an agent on the Azure AD Connect server (AuthN agent) which accepts authentication requests from Azure AD and sends these to on-premises Domain Controllers. The advantage of authentication against on-premises Domain Controllers is that no passwords (or password hashes to be more precise) are stored in Azure Active Directory.

My first thought was how an authentication mechanism based on an asynchronous replication tool (Azure AD Connect synchronizes accounts every 30 minutes, and passwords within 2 minutes) ever be a reliable and safe solution. The last thing you want to happen is that you cannot authenticate to any service in the Microsoft cloud, because your Azure AD Connect server is busy doing other stuff (like automatically updating its engine for example ).

My second thought was how secure this could be. There’s no inbound connection to the Azure AD Connect server, there’s only an outbound connection on ports 80 (only used for SSL certificate revocation lists) and 443. And the communication itself should be secured as well, so…. But now that PTA is generally available more information becomes available, and things become clearer.

Authentication flow

For authentication to happen PTA uses a ‘service bus’ in Azure. The service bus is a standard Azure solution where application can store system messages in the service bus and where other applications can use these system messages. Using a service bus, you can create an asynchronous but reliable communication mechanism.

When logging to an Office 365 service the credentials are requested by Azure Active Directory, nothing new here. The credentials are encrypted and stored in the service bus. The AuthN agent on the Azure AD Connect server has a persistent connection to Azure AD and to the service bus, and retrieves the encrypted credentials from the service bus, decrypts them and presents them to the on-premises Domain Controller. The Domain Controller response (success, failure, password expired or user locked out) is returned to the AuthN agent and stored it on the service bus. Azure AD picks up this response and the user can continue working (or not of course, depending on the Domain Controller response).

image

Continue reading Azure AD Connect Pass-Through Authentication

Azure Active Directory PowerShell v2

Maybe you’ve already heard about Microsoft Graph and the Graph API. Microsoft Graph is the way resources in the Microsoft cloud are connected to each other. The Graph API is an API you can use to access Microsoft Graph, and browse (or traverse) through all the resources.

image

You can use the Graph API when building your own applications, but Microsoft is moving all their apps, tools etc. to the Graph API as well.

Azure Active Directory PowerShell v2 is moving from the Azure AD API’s to the Graph API as well. This automatically implies that Azure AD PowerShell v2 comes with new cmdlets and new options. The output of these cmdlets should be similar of course (creating a new domain, group or user in Azure Active Directory), but that these cmdlets are in no way compatible with the old Azure AD PowerShell.

Unfortunately, you have no choice then moving to Azure AD PowerShell v2. The existing PowerShell v1 will of course be supported for quite some time as it is impossible for everyone to convert their processes, cmdlets, scripts etc. from one version to another.

Note. We’ve seen similar when Microsoft moved from Azure ASM to Azure ARM. It has been taken years for Microsoft to move everything to ARM, so no worries for end-of-support scenarios anytime soon.

Installing Azure AD PowerShell v2 is easy, just install the module using the Install-Module command. This will download the module from the PowerShell repository.

Install-Module AzureAD

When executed you will receive a notification about an untrusted repository. Click [Y] or [A] to continue. The module will be downloaded and installed.

image

image

image

You can use the following commands to store the credentials of your Office 365 and/or Azure tenant administrator account and use it to login to Azure Active Directory:

$AzureADCred = Get-Credential &lt;your tenant admin&gt;<p>Connect-AzureAD -Credential $AzureADCred

image

You’ve now installed the Azure Active Directory PowerShell v2 module and are logged on to your tenant. If you want to retrieve a list of all new v2 PowerShell commands use can use the Get-Command command:

Get-Command *AzureAD*

image

In future blogposts I will continue with the Azure AD PowerShell v2 module.

More information

<updated on March 21, 2018>