Azure AD Connect: Escape to Proxy Addresses

This blog will be about some stuff you need to beware of when you are setting up Azure AD Connect. It’s a topic I haven’t written a lot about but after a discussion with a colleague, I decided I needed to write a blog about it. To give you a small hint: proxyAddresses

1. Introduction

As always, I need to explain the situation a bit to clarify what we were trying to accomplish.

Some time ago, we were called in to assess a new customer. While doing this assessment, we noticed that, luckily, this customer was already using Exchange Online.

In the past, their Data and Exchange environments were scattered around different locations with no connection between them. The company must migrate all their exchange environments to Exchange Online first. After a while, they also moved their data and legacy apps to a centralized cloud environment.

The customer is also still bound to some legacy apps they still can’t get rid of. Migrating to a cloud-only solution with multiple legacy apps could cost you some more time. Of course, they have an option to go Hybrid, but that’s not something I prefer. If anyone is interested, In the past, I wrote a huge blog about how you could transform your organization to Full Cloud without the need for Hybrid and still get SSO to your on-premises legacy apps.

To get this SSO working you could use Azure AD Connect. There are numerous other solutions that you can use to achieve this, but roughly 98% of organizations synchronizing objects and their attributes from Active Directory to Azure AD use Azure AD Connect. I guess we can all guess what was missing: Azure AD Connect.

Our first advice was to install Azure AD Connect to get rid of the evil password prompt issues with Teams. Of course, it’s also a good place to start when you want to migrate to AADJ soon!

2. Preparation

Before installing Azure AD Connect, we always need to do some preparation because you don’t want to end up with some weird issues. Luckily, Microsoft has already written some nice documentation about the prerequisites and how to start the installation.

Azure AD Connect: Prerequisites and hardware | Microsoft Docs

I am afraid to say so, but this blog isn’t going to show you a “Step By Step” guide on how to install Azure AD connect because a lot of other people have already explained this but still I want to point out some stuff and no, not the ImmutableID

Before I am going to show you the issue, I want to show you the IDFix tool.

This wonderful tool will help you to fix some possible attribute errors you could run into. As shown above, it could help you out fixing some duplicate mail attribute errors but what about the proxyAddresses?

When installing Azure AD Connect with an existing Exchange Online/ Azure AD environment you could end up with some challenges and one of them could be the proxyAddresses Attribute

3. proxyAddresses

The proxyAddresses attribute is best described as an attribute in the Active Directory. It could contain multiple values defining the primary SMTP address and possible additional SMTP addresses. In addition to the SMTP address, this attribute could also contain X500 addresses, SIP addresses, etc.

Looking at the picture above, you will notice SMTP with capital and non-capital characters. Let me explain them first

SMTP:user@domain.com  –> Primary SMTP address

smtp:user@domain.com –> Additional/Secondary SMTP address

When comparing the proxyAddresses to the mail attribute, you will immediately spot the difference!

As shown above, the mail attribute can only contain one mail address and no additional mail addresses. So, if you have a nice Exchange Environment, the proxyAddresses attribute will be filled with your additional email addresses.

4. Azure AD Connect and the Attributes

We made sure we followed all the nice step-by-step guides to set up Azure AD Connect. Those step-by-step guides tell you to check if the user’s UPN matches the Microsoft 365 username and to run the IDFix tool. After running the IDFix tool and fixing some other errors, we still needed to make sure some other important attributes were configured correctly, and you can guess which attribute.

Before we started we also made sure we created a full export of the Azure AD users and all of their attributes to manually compare them to the export we did from the Active Directory.

When opening both of the CSV exports we immediately noticed the fact that the proxyAddresses attribute on the Active Directory was missing for like 75% when comparing it with Azure AD.

I guess we have some work to do because when using Azure AD Connect, you need to make sure there aren’t any duplicate proxyAddresses attributes configured and that the proxyAddresses that are configured match the email addresses configured in Azure AD.

Normally, all attributes (including the proxyAddresses attribute) in Azure AD will be overwritten with a value from the Active Directory when Azure AD Connect is configured. Of course, every rule has an exception! When an Active Directory attribute is “Not Configured” or has a NULL value, the attribute in Azure AD will NOT be overwritten!

Let me explain with a picture to get it a little more obvious clear.

*When we have an Active Directory user with a mail attribute: rudy@wvdcloud.nl and a not configured proxyAddresses attribute the additional email addresses in Azure AD will not be overwritten. When the Azure AD user has an additional email address: info@wvdcloud.nl, that email address will still be configured

*When a user has an Active Directory mail attribute rudy@wvdcloud.nl and only 1 proxyAddresses attribute: rudy@wvdcloud.nl the additional email address in Azure AD will be removed. So when the Azure AD user has an additional email address, info@wvdcloud.nl, that additional email address will be removed, and the object will be marked as “On-premises managed.”

So, pretty please, before running Azure AD connect, please make sure everything matches. You really don’t want to end up in a situation where 75% of the Azure AD users had their additional email addresses suddenly removed

5. The PowerShell Scripts

The First PowerShell script that I am going to show you is the one we used to ensure that all of the proxyAddresses attributes match the ones configured in Azure AD.

Connect-MsolService  
$results = @()  
$onlineusers = Get-MsolUser -All  | Select-Object UserprincipalName,ImmutableID,WhenCreated,LastDirSyncTime, proxyaddresses   
foreach($user in $onlineusers){  
    foreach($proxyaddress in $user.proxyaddresses){  
    $properties = [ordered]@{  
Username = $user.UserPrincipalName  
Proxyaddress = $proxyaddress  
}  
$results  += New-Object PSObject -Property $properties
                 $upn = $user.UserPrincipalName 
                  get-aduser -filter 'userprincipalname -eq $upn' | Set-ADUser -add @{ProxyAddresses=$proxyaddress}  

   }   
  } 

The second Powershell Script will detect if any proxyAddresses attribute configured with the local domain (@domein.local) is present and, if so, remove it.

$Adusers = get-aduser -filter "*"

ForEach ($User In $Adusers){
    $proxyAddresses = $User.proxyAddresses
    ForEach ($proxyAddress In $proxyAddresses){
        If ($proxyAddress -Like '*@hosting.lan'){
            Write-Host $User.DistinguishedName `t $proxyAddress
            set-ADObject $Object -Remove @{ProxyAddresses = "$($proxyAddress)"}
        }
    }
}

Conclusion:

If all of your migrations are greenfield migrations, you are good to go, but if that’s not the case, you need to beware of some rules. If the proxyAddresses attribute is NOT configured in the Active Directory, the additional email addresses are NOT removed in Azure AD when running Azure AD Connect!