Tag Archives: Azure AD

Implementing Active Directory Federation Services step-by-step part II

In the previous blog (Implementing Active Directory Federation Services step-by-Step) I have showed you how to install and configure Active Directory Federation Services (ADFS) in your internal network and DMZ, capable of handling Office 365 authentication request. In this blog I’ll show you how to configure Office 365 and how to test it.

Federated Domains

In a typical managed domain, the user accounts and password hashes are synchronized to Azure Active Directory. Office 365 uses Domain Controllers in Azure AD to authenticate the users and grant them access to the resources in the cloud.

In a federated domain, the user accesses the Office 365, but access is denied, and the request is redirected to Azure Active Directory. There, the home realm (the user’s domain) is discovered and the request is redirected to the ADFS server based on the home realm. If my user account is j.wesselius@exchangelabs.nl, my home realm is exchangelabs.nl and the request is redirected to the federation server that was created earlier, and that was used to configure the domain in Azure Active Directory.

I did a session on this at IT Dev Connections in 2017 (in San Francisco), the following is one animated slide that can be downloaded which shows the flow between a client, Office 365, Azure AD and the on-premises ADFS and Domain Controller:

ADFS Federation Flow

To get this working, the domain in Azure Active Directory needs to be converted to a federated domain so that Azure AD knows any authentication request needs to be redirected to the on-premises ADFS environment.

When adding a domain to Azure Active Directory it is automatically created as a managed domain. As said before, authentication takes places against Domain Controllers in Azure AD. You can check a domain using the Get-MsolDomain -DomainName exchangelabs.nl PowerShell command as shown in the following screenshot:

Get-MsolDomain

To convert this to a federated domain, start a PowerShell command (with elevated privileges) and enter the following commands:

[PS] C:\> Connect-MsolService

[PS] C:\> Set-MsolADFSContext -Computer ams-adfs01.labs.local

[PS] C:\> Convert-MsolDomainToFederated -DomainName Exchangelabs.nl

Note. Use the FQDN of the local first ADFS server with the Set-MsolADFSContext command, not the federation URL

This will connect the existing on-premises infrastructure to Azure AD, and convert the domain to a federated domain. Now, when checking the domain in Azure AD using the same command as before you’ll see it now is a federated domain:

Set-MsolAdfsContext Exchangelabs

In in the ADFS Management Console you’ll a new Relying Party Trust (RPT) for use with Office 365:

ADFS Relying Party Trust

To get more into detail in Azure AD about the federation settings, you can use the Get-MsolDomainFederationSettings command which shows more information:

Get-MsolDomainFederationSettings

Clearly visible are the Logon, Issuer and LogOffUri, which point to our on-premises ADFS implementation. Even more information can be retrieved using the Get-MsolFederationProperty command as shown in the following screenshot:

Get-MsolFederationProperty

To test the new configuration, navigate to the Microsoft Online Portal and login using an account with the domain we just configured, i.e. j.wesselius@exchangelabs.nl:

Microsoft Online Portal

When selecting this account, Azure AD determines the home realm (exchangelabs.nl) and redirect to the on-premises URL as found in the federation settings in Azure AD. You’ll see this happen on the fly in your browser:

Taking you to your organizations sign-in page

And a few seconds later we are redirected to our on-premises ADFS environment:

ADFS Federation Sign-in page

Clearly visible is the Federation Service display Name which was configured with the first ADFS server in the previous blogpost.

Enter your password, and how wonder, MFA is still working as well (which was a pleasant surprise for me 😊):

ADFS Exchangelabs MFA

Another interesting test is using the Remote Connectivity Analzyer ( (https://aka.ms/exrca) which has a Single Sign-On test. Navigate to the Remote Connectivity Analyzer, click the Office 365 tab and select the Office 365 Single Sign-On test radio button.

Enter username and password, do the verification code test and await the results. You’ll see something similar as the following screenshot:

Remote Connectivity Analyzer Single Sign-On Test

The logon attempt was successful, but more interesting is that you can expand all test steps to see what’s going on under the hood and try to understand how ADFS works.

Summary

In the previous two blogposts I demonstrated how to install and configure ADFS in your on-premises infrastructure. I installed only one ADFS server and one WAP proxy, which is far from a high available environment. Why high available? Without the ADFS server it is no longer possible to logon to any Office 365 service, so a high available infrastructure is a requirement for any ADFS implementation.

But customers are moving to the cloud to decommission their on-premises solutions, and with ADFS we’re building an on-premises solution for authenticating cloud solutions. But for compliancy reasons it might be needed to authenticate against local domain controllers (no passwords in the cloud for example). On the other hand, you can use Pass Through Authentication (PTA, see my blogpost Azure AD Connect Pass-through authentication) for this as well. PTA doesn’t offer as much possibilities as ADFS yet, but it is improving.

Is ADFS future proof? Some people say it isn’t, but as long as I find articles like What’s new in Active Directory Federation Services for Windows Server 2019 on the Microsoft website I don’t see too many issues with that.

More information

Block creation of Office 365 Groups

I’m an old school IT guy, in my world provisioning is done via the IT department or via a provisioning tool. What I don’t want is that regular users create all kinds of objects in my environment, whether it be Active Directory, Azure Active Directory or Office 365.

In Office 365 everything is different, multiple services (Outlook, Teams, Planner, SharePoint, PowerBI and others) are using Office 365 Groups under the hood. So, when users create a new plan in Planner or a new team in Teams, they also create an Office 365 Group in Azure Active Directory.

I’m currently working in a 12,000-user environment, and the last thing I want to happen is 12,000 users randomly creating all kinds of groups, ending up in a total mess where nobody can find information and where it is impossible to delete anything without hurting other people.

The solution for this is to assign the creation of new Office 365 to a security group in Azure Active Directory (this can be a cloud object or a synchronized object). To create a new security group in Azure Active Directory you can use the following PowerShell command:

New-AzureADGroup -DisplayName "O365 Group Creators" -SecurityEnabled:$True -MailEnabled:$False -MailNickName "Nothing"

New-AzureADGroup

Note. It is also possible to create a security group in the Azure AD Portal.

The next step is to assign the permission to create Office 365 Groups to this new security group. This can only be achieved using PowerShell and the Azure AD Preview Module, using the following script:

$GroupName = "O365 Group Creators"
$AllowGroupCreation = "False"
Connect-AzureAD
$settingsObjectID = (Get-AzureADDirectorySetting | Where-object -Property Displayname -Value "Group.Unified" -EQ).id
if(!$settingsObjectID)
{
  $template = Get-AzureADDirectorySettingTemplate | Where-object {$_.displayname -eq "group.unified"}
  $settingsCopy = $template.CreateDirectorySetting()
  New-AzureADDirectorySetting -DirectorySetting $settingsCopy
  $settingsObjectID = (Get-AzureADDirectorySetting | Where-object -Property Displayname -Value "Group.Unified" -EQ).id
}
$settingsCopy = Get-AzureADDirectorySetting -Id $settingsObjectID
$settingsCopy["EnableGroupCreation"] = $AllowGroupCreation
if($GroupName)
{
  $settingsCopy["GroupCreationAllowedGroupId"] = (Get-AzureADGroup -SearchString $GroupName).objectid
}
Set-AzureADDirectorySetting -Id $settingsObjectID -DirectorySetting $settingsCopy
(Get-AzureADDirectorySetting -Id $settingsObjectID).Values

When you run this script, you will see a similar output:

GroupCreators

The first box corresponds to the objectID of the security group we’ve created in the first step, just compare with the ObjectID shown in the first screenshot.

The second box shows $false for the EnableGroupCreation property, indicating no other groups are allowed to create Office 365 Groups.

All members of the security group we just created are allowed to create Office 365 groups. There are some exceptions though, Exchange admins, SharePoint admins, Teams admins and User Management admins are by default allowed to create Office 365 groups as well, but typically these are not regular users.

This way you can control who is able to create Office 365 Groups in your environment, and make sure group creation doesn’t explode in your tenant.

More information

Office 365 Group Based Licensing

If you have a smaller organization and you want to assign Office 365 licenses that’s no big deal. Open the user properties in the Microsoft Online Portal and assign the proper license. If needed you can assign only specific services without too much hassle. Besides using the Portal it is also possible to use PowerShell to assign licenses as discussed in an old blog: https://jaapwesselius.com/2014/09/04/assign-office-365-license-via-powershell/

For larger organizations this can be cumbersome and prone to error. Also, when using a dedicated provisioning solution it can be tricky. An interesting solution is to use Group based licensing. You can assign Office 365 licenses to a security group and when a user is added to this group, the user automatically gets the assigned licenses.

In this example we’re going to implement Group based licensing. First we are going to create a baseline where only the basic features of Office 365 E3 are implemented. Next we are going to create another option where additional features are added.

  • Labs_O365_E3_Base
  • Labs_O365_E3_TeamsAndPlanner

License Security Group Active Directory

After synchronization these groups will show up in Azure Active Directory:

License Security Group Azure Active Directory

The next step is to assign the licenses to these security groups.

In the Azure Portal, select Azure Active Directory | Licenses | Office 365 E3 and click + Assign. In the Users and Groups box select the first group (Labs_O365_E3_Base in this example) and in the Assignment Options box select the options you want to assign to this group:

License Options

Use the same steps to assign additional options to the second group:

additional license options

When you create a new user in Active Directory and add this user to the base security group, you’ll see that the user will receive only the licenses assigned to the group. If you want to assign more license options, just add the user to the additional group. This way you are very flexible in assigning licenses, and chances on errors are minimized.

Note. You can assign licenses directly on the user object or using security groups, it is not possible to combine both. So, if you use groups to assign licenses it is not possible to add additional licenses directly on the users object in the Office 365 Portal.

More information

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