Tag Archives: Azure AD Connect

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.

Exchange Resource Forest and Office 365 – Part II

In my previous blog post I’ve explained more about the Exchange resource forest model where user accounts are located in a dedicated forest with only the user account (and their regular resources) and where Exchange is installed in a resource forest. There’s a forest trust between the resource forest and the account forest, and the mailboxes are configured as linked mailboxes. This is shown in the following figure:

image

In this blogpost we will add an Azure AD Connect server to enable synchronization between the on-premises Active Directories and Office 365.

Exchange Resource forest and Azure AD Connect

If we want to create a hybrid scenario with our resource forest and Exchange Online we have to implement Azure AD Connect first. Azure AD Connect will synchronize account information from the account forest, and linked mailbox information from the resource forest. To achieve this, we have to setup a multi-forest synchronization model (which is also fully supported by Microsoft).

The Azure AD Connect server will be installed in the account forest. To retrieve the information about the mailboxes from the resource forest, a service account will be used as shown in the following figure:

image

In a typical environment there’s only one Active Directory containing both user accounts and exchange servers. As such, the user accounts have the corresponding Exchange properties. In a Resource Forest scenario there are two user accounts, where the user account in the Resource Forest is disabled and this disabled account contains the Exchange properties.

The Azure AD Connect server (which is running in the Account Forest) combines the two accounts based on the objectSID and MSExchMasterAccountSid and synchronizes this ‘joined’ account information to Azure Active Directory, as shown in the following figure:

image

The prerequisites for Azure AD Connect is a Resource Forest scenario are the same as for a regular environment, so I won’t go into too much detail about this. Of course you need an internet routable domain for your accounts (i.e. don@accounts.local won’t work, so this needs to be changed to don@exchangefun.nl), your accounts need to be checked for inconsistencies with the IDFix tool and of course you have to configure your tenant in Office 365. For more information regarding the process, please check my blog Implementing Directory Synchronization. It’s a somewhat older blog, but the steps remain the same.

You can download the latest version of Azure AD Connect from the Download Azure AD Connect. I will only show the most important screenshots when running the Azure AD Connect wizard.

Azure AD Connect can be installed using an Express setup, this is the default setting and is sufficient if you have a single forest environment with less than 100,000 objects in Active Directory and where using SQL Express is sufficient. In our Resource Forest environment we have multiple Active Directory forest, so a custom setup is needed, so select Customize in the Express Settings window:

image

Continue with the wizard until you reach the User Sign-in window. Here you have to select which authentication method is used when users sign-in into Office 365. Make your selection and click Next to continue.

image

After entering the (Global) tenant administrator credentials, the forests need to be added to the Azure AD Connect wizard. In the Connect your directories window the Active Directory forest where your Azure AD Connect server resides will appear. To add this directory, click Add Directory:

image

The Add Forest Account window will appear. Here you can select if a new service account for Azure AD Connect will be created, or that an existing service account will be used. An Enterprise Admin Account will be used to create this service account, and configure Azure AD Connect for first use. It must be an Enterprise Admin account because information is written into the Configuration partition of Active Directory. Enter the credentials of the Enterprise Admin (in your Account Forest) and click OK to continue.

image

Repeat these steps for the Resource Forest, so enter the forest name, select the radio button to create a new service account and enter the Enterprise Admin credentials in the Resource Forest as shown in the following two figures:

image

image

Continue with the wizard, select the Domain/OU filtering options for both Forest and make sure you select the containers containing the user accounts in the Account Forest and the corresponding Mailboxes in the Resource Forest as shown in the following two figures:

image

image

The Uniquely identifying your users is the most important window in the Azure AD Connect wizard. This is where the user account in the Account Forest and the corresponding mailbox in the Resource Forest are tied together. In the previous blogpost I’ve explained the objectSID and the msExchMasterAccountSID, so this option is selected.

image

Continue the Azure AD Connect wizard, and in the Optional Features select the Exchange Hybrid Deployment checkbox and click Next to continue.

image

You’re now ready with the Azure AD Connect wizard. In the Ready to configure window you can chose to start the synchronization immediately, or enable the Azure AD Connect server in staging mode. In this mode it will collect all information and fill the SQL Express database with data, but it won’t write any data to Azure Active Directory until you’ve checked everything. Select the option you want and click install to finish the wizard and install/configure Azure AD Connect.

image

At the configuration complete window there are some recommendations and/or remarks for your reference, click Exit to stop the Azure AD Connect wizard.

image

Now, when you logon to the Microsoft Portal you’ll see that synchronization has occurred:

image

And when you expand the users option you’ll see which users are synchronized.

image

When you logon to the Exchange Admin Console in Exchange Online and check the Recipients | Contacts folder, you’ll see the users appear here. This makes sense, since the on-premises Mailboxes are represented as Mail-Enabled Users in Exchange Online.

image

Summary

In this blogpost I’ve showed you how to implement Azure AD Connect in an existing Exchange Resource Forest model. The Azure AD Connect server combines the user account from the Account Forest with the mailbox from the Resource Forest and synchronizes this to Azure Active Directory.

In my next blog I’ll create a hybrid environment based on the Exchange resource forest model.

Ps. a special thanks to ‘Trekveer Harry’ for his continuous brainstorm sessions and good ideas Smile

set-msoldirsyncenabled not available

Now with Microsoft moving from the old MSOL to AzureAD PowerShell commands (see my blogpost on Azure Active Directory PowerShell v2), you get new features but (unfortunately) things are starting to disappear as well.

In the past you could use Azure AD PowerShell to enable or disable directory synchronization using the Set-MsolDirSyncEnabled cmdlet. During a recent lab deployment, I found out that this cmdlet is no longer available. In fact, not a single Msol cmdlet is available anymore, try Get-Command *msol* and nothing is returned.

To get more information regarding Azure AD you can use Get-Command *Set-AzureAD*. This reveals enough information, but nothing that points to directory synchronization.

image

When logging on to the Azure Portal (of the newly created Office 365 tenant) it is obvious that Azure AD Connect sync is not enabled, as shown in the following screen shot:

image

When you dive deeper into the Azure Active Directory section of the Azure Portal, you can see that synchronization has never run, and that password sync is disabled (which makes sense at this point):

image

Nowhere can an option be found to enable directory synchronization, as you had to do previously before configuring directory synchronization. The only option you have is to download Azure AD Connect, using the following link: http://www.microsoft.com/en-us/download/details.aspx?id=47594

So, let’s give it a try….

Logon to the new Azure AD Connect server, download Azure AD Connect and start the wizard. The Express installation will perform the following steps:

  • Configure synchronization of identities in the current AD forest of <your domain>
  • Configure password synchronization from on-premises AD to Azure AD
  • Start an initial synchronization (I’ll get back on this later in this blogpost)
  • Synchronize all attributes
  • Enable auto upgrade

image

Enter the administrator credentials of your Office 365 tenant and your on-premises Active Directory and you’re ready to go:

image

One remark: I unchecked the Start the synchronization process when configuration completes option, and checked the Exchange hybrid deployment checkbox.

The reason I unchecked the synchronization process is that I do not want to synchronize all objects from my on-premises Active Directory to Azure Active Directory, but I only want to synchronize objects from the OU=Accounts container in my Active Directory domain.

If you want more information regarding the Exchange hybrid deployment and the write-back of properties from Azure AD to your on-premises Active Directory, you can visit the following Microsoft article:

Exchange Server Hybrid Deployments – https://technet.microsoft.com/en-us/library/jj200581(v=exchg.150).aspx

When the configuration is complete you can click the Exit button and you’re good. Please note that at this point no synchronization has taken place yet.

image

To make a selection based on Organizational Unit for synchronization you can start the Synchronization Service Manager (miisclient.exe) which can be found in the C:\Program Files\Microsoft Azure AD Sync\UIShell directory.

image

Click on the Connectors tab, and select the Connector (sometimes referred to as Management Agent) for your on-premises Active Directory. Click properties and select Configure Directory Partitions. Here you can select which containers should be used for synchronization to Azure Active Directory, as can be seen in the following screenshot:

image

Start the initial Azure AD synchronization using the Start-ADSyncSyncCycle -Policytype Initial command and wait for the results:

image

This will trigger the initial synchronization to Azure Active Directory, but won’t do any subsequent sychronizations. Use the Set-ADSyncScheduler -SyncCycleEnabled $true command to run periodic synchronizations.

When checking the Azure Portal, you can see that user objects are now synchronized from the on-premises Active Directory to Azure Active Directory, as shown in the following screenshot:

image

Summary

So, in short, previously you had to enable directory synchronization manually using the Set-MsolDirSyncEnabled command (or using the wizard in Office 365), but this is no longer the case. When running Azure AD Connect, directory synchronization in your tenant will automatically be enabled.

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