Public Folder Sync–Duplicate Name Error

Posted on Leave a commentPosted in AADConnect, exchange, exchange online, Exchange Server, migration, Office 365, Public Folders

I came across this error with a client today and did not find it documented anywhere – so here it is!

When running the Public Folder sync script Sync-ModernMailPublicFolders.ps1 which is part of the process of preparing your Exchange Online environment for a public folder migration, you see the following error message:

UpdateMailEnabledPublicFolder : Active Directory operation failed on O365SERVERNAME.)365DATACENTER.PROD.OUTLOOK.COM. The
object ‘CN=PublicFolderName,OU=tenant.onmicrosoft.com,OU=Microsoft Exchange Hosted
Organizations,DC=)365DATACENTER,DC=PROD,DC=OUTLOOK,DC=COM’ already exists.
At C:\ExchangeScripts\pfToO365\Sync-ModernMailPublicFolders.ps1:746 char:9
+         UpdateMailEnabledPublicFolder $folderPair.Local $folderPair.Remote;
+         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
     + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,UpdateMailEnabledPublicFolder

This is caused because you have a user or other object in Active Directory that has the same name as the mail enabled public folder object.

In Exchange Online PowerShell if you run Get-User PublicFolderName you should not get anything back, as its a Public Folder and not a user, but where you see the above error you do get a response to Get-User (or maybe Get-Contact or any other object that is not a Public Folder. This class of object name (common name or cn) means the script can create the public folder in the cloud, but not update it on subsequent runs of the script.

The easiest fix is to rename the common name of the public folder object in Active Directory for all clashing public folders, unless you know you do not need the other object that clashes – as renaming that and letting AADConnect sync process the change is another way to resolve this.

To rename the mail public folder, in Exchange Server management shell run Set-MailPublicFolder PublicFolderName –Name NewPublicFolderName

I have changed my names to start with pf, so PublicFolderName becomes pfPublicFolderName and then the script runs without issue.

Configuring Multi Factor Authentication For Office 365

Posted on 2 CommentsPosted in MFA, Office 365

Given that Office 365 is a user service, the enabling of multi-factor authentication is very much as admin driven action – that is the administrators decide that the users should have it, or that it is is configured via Conditional Access when limiting the login for the user to certain applications and locations.

For a more security conscious user, enabling it themselves if harder! To do this, follow these steps:

  1. Go to My Apps – https://myapps.microsoft.com
  2. Click your picture icon top right and choose Profile from the menu
  3. Click Additional Security Verification from the menu to the right
  4. Select your preferred method of second factor of authentication from the first drop-down box. You need to ensure that the option you choose is enabled below.

You will now be prompted for your second authentication factor that you choose when you try to do a password change or change your verification info.

SSL Inspection and Office 365

Posted on Leave a commentPosted in Azure, Azure Information Protection, cloud, firewall, Office 365, proxy, SSL

Lots of cloud endpoint URL’s break service flow if you enable SSL Inspection on the network devices between your client and the service. My most recent example of this Enterprise State Routing in Windows 10.

Microsoft have a list of URLs for the endpoints to their service, where they are categorised as Default, Allow or Optimize. The URLs that are Allow or Optimize should avoid SSL inspection.

The endpoint list is found at https://support.office.com/en-us/article/managing-office-365-endpoints-99cab9d4-ef59-4207-9f2b-3728eb46bf9a#webservice and the JSON for this can be downloaded, as well as a PowerShell script to return the IPs and URLs.

Within this JSON file you can look for the category and if the category is Allow or Optimize then ensure the matching URLs are not SSL inspected.

Improving Password Security In the Cloud and On-Premises

Posted on Leave a commentPosted in active directory, Azure Active Directory, Azure AD, AzureAD, EM+S, enterprise mobility + security, microsoft, Office 365, password, security

Passwords are well known to be generally insecure the way users create them. They don’t like “complex” passwords such as p9Y8Li!uk%al and so if they are forced to create a “complex” password due to a policy in say Active Directory, or because their password has expired and they need to generate a new one, they will go for something that is easy to remember and matches the “complexity” rules required by their IT department. This means users will go for passwords such as WorldCup2018! and Summ3r!!. Both these exceed 8 characters, both have mixed case, both have symbols and numbers – so both are complex passwords. Except they are not – they are easy to guess. For example, you can tell the date of this blog post from my suggestions! Users will not tend to pick passwords that are really random and malicious actors know this. So current password guidance from NIST and UK National Cyber Security Centre is to have non-expiring unknown, not simple passwords that are changed on compromise. Non-expiring allows the user to remember it if they need to (though a password manager is better) and as it is unknown beforehand (or unique) means its not on any existing password guess list that might exist.

So how can we ensure that users will choose these passwords! One is end user training, but another just released feature in the Microsoft Cloud is to block common passwords and password lists. This feature is called Azure AD Password Protection. With the password management settings in Azure AD, cloud accounts have been blocked from common passwords for a while (passwords that Microsoft see being used to attempt non-owner access on accounts) but with the password authentication restrictions you can link this to block lists and implement it with password changes that happen on domain controllers.

So how does all this work, and what sort of changes can I expect with my passwords.

Well what to expect can look like this:

image

Note all the below is what I currently know Microsoft do. This is based on info made public in June 2018 and is subject to change as Microsoft’s security graph and machine learning determines change is needed to keep accounts secure.

Password Scoring

First, each password is scored when changed or set by an administrator or a user on first use. A password with a score less than 5 is not allowed. For example:

Spring2018 = [spring] + [2018] = 2 points

Spring2018asdfj236 = [spring] + [2018] + [asdf] + [f] + [j] + [2] + [3] + [6] = 8 points

This shows that common phrases (like Spring and 2018) can be allowed as part of password that also contains stuff that is hard to guess. In this, the asdf pattern is something straight from a Qwerty keyboard and so gets a low score. In addition to the score needing to exceed 5, other complexity rules such as certain characters and length are still required if you enforce those options.

Common and Blocked Lists

Microsoft provide the common password lists, and these change as Microsoft see different passwords getting used in account attacks. You provide a custom blocked list. This can contain up to 1000 words, and Microsoft apply fuzzy logic to yours and the common list. For example we added all our office locations as shown:

image

This means that both capetown and C@p3t0wn would be blocked. The @=a, the 3=e and the 0=o. So the more complex one is really not complex at all as it contains common replacements.

In terms of licences, the banned password list that Microsoft provides is licence free to all cloud accounts. You need AAD Basic if you want to add your own custom banned password list. For accounts in Windows Server Active Directory you need the Azure AD Premium (P1) licence for all synced users to allow downloading of the banned password list as well as customising it with your words so that Active Directory can apply it to all users on-premises to block bad passwords (even those users not synced to AzureAD).

Hybrid Password Change Events Protected

The checks on whether a password change should be stopped is included in hybrid scenarios using self-service password reset, password hash sync, and pass-through authentication, though changes to the custom banned password list may take a few hours to be applied to the list that is downloaded to your domain controllers.

On-Premises Changes

There is an agent that is installed on the domain controllers. Password changes are passed to the agent and it checks the password against the common list and your blocked list. The agent does the password check, and it checks it against the most recently downloaded list from Azure AD. The password for on-premises is not passed up to Azure AD, the list is downloaded from Azure AD and processed locally on the domain controller. This download is done by the Azure AD password protection proxy. The list is then downloaded once per hour per AD site to include the latest changes. If your Azure AD password protection proxy fails, then you just use the last list that was successfully downloaded. Password changes are still allowed even if you lose internet access.

Note that the Azure AD password protection proxy is not the same as the Pass-Through Authentication agent or the AAD Connect Health agent. The Azure AD password protection proxy can though be installed on the same servers as the PTA or Connect Health agent. Provisioning new servers for the proxy download service are not required.

The Azure AD password protection proxy wakes up hourly, checks SYSVOL to see the timestamp of the most recently downloaded copy and decides if a new copy is needed. Therefore if your intra-site replication is within the hour, proxy agents in other sites might not need to download the list as the latest is already available via DFSR between the domain controllers.

The Azure AD password protection proxy does not need to run on a domain controller, so your domain controllers do not need internet access to obtain the latest list. The Azure AD password protection proxy downloads the list and places it in SYSVOL so that DFSR replication can take it to the domain controller that needs it.

Getting Started

To set a custom password block list, in the Azure Portal visit the Azure AD page, click Security and then click Authentication Methods (in the Manage section). Enter your banned passwords, lower case will do as Microsoft apply fuzzy logic as described above to match your list to similar other values. Your list should include common words to your organization, such as location, office address keywords, functions and features of what the company does etc.

For Active Directory, download the agent (from the Microsoft Download Center) to one or more servers (for fault tolerance). These will download the latest list and place it in SYSVOL so that the domain controllers can process it. Two servers in two sites would probably ensure one of them is always able to download the latest copy of the list.

The documentation is found at https://aka.ms/deploypasswordprotection.

Microsoft suggests that any deployment start in audit mode. Audit mode is the default initial setting where passwords can continue to be set even if they would be blocked. Those that would fail in Enforce mode are allowed in Audit mode, but when in audit mode entries in the event log record the fact that the password would fail if enforce was turned on. Once proxy server(s) and DC agents are fully deployed in audit mode, regular monitoring should be done in order to determine what impact password policy enforcement would have on users and the environment if the policy was enforced.

This audit mode allows you to update in-house policy, extend training programs and offer password advice and see what users are doing that would be considered weak. Once you are happy that users are able to respond to an password change error because the password is too weak, move to enforce mode. Enforce mode should kick in within a few hours of you changing it in the cloud.

Installing the Proxy and DC Agent

Domain Controllers need to be running Windows Server 2012 and later, though there are no requirements for specific domain or forest functional levels. Visit the Microsoft Download Center to download both the agent and the password protection proxy. The proxy is installed and then configured on a few (two at most during preview) servers in a forest. The agent is installed on all domain controllers as password changes can be enacted on any of them.

To install the agent, run AzureADPasswordProtectionProxy.msi on the server that has internet connectivity to Azure AD. This could be your domain controller, but it would need internet access to do this.

To configure the agent, you need to run once Import-Module AzureADPasswordProtection followed by Register-AzureADPasswordProtectionProxy and then once the proxy is registered, register the forest as well with Register-AzureADPasswordProtectionForest all from an administrative PowerShell session (enterprise admin and global admin roles required). Registering the server adds information to the Active Directory domain partition about the server and port the proxy servers can be found at and registering the forest settings ensure that information about the service is stored in the configuration partition.

Import-Module AzureADPasswordProtection 
Get-Service AzureADPasswordProtectionProxy | FL
$tenantAdminCreds = Get-Credential
Register-AzureADPasswordProtectionProxy -AzureCredential $tenantAdminCreds
Register-AzureADPasswordProtectionForest -AzureCredential $tenantAdminCreds

If you get an error that reads “InvalidOperation: (:) [Register-AzureADPasswordProtectionProxy], AggregateException” then this is because your AzureAD requires MFA for device join. The proxy does not support MFA for device join during the preview – you need to disable this setting in Azure AD for the period covering the time you make these changes – you can turn it back on again (as on is recommended) once you are finished configuring your proxy servers. This setting is found at:

  • Navigate to Azure Active Directory -> Devices -> Device settings
  • Set “Require Multi-Factor Auth to join devices” to “No”
  • As shown
    image
  • Then once the registration of your two proxies is complete, reverse this change and turn it back on again.

Once at least one proxy is installed, you can install the agent on your domain controllers. This is the AzureADPasswordProtectionDCAgent.msi and once installed requires a restart of the server to take its role within the password change process.

The PowerShell cmdlet Get-AzureADPasswordProtectionDCAgent will report the state of the DCAgent and the date/time stamp of the last downloaded password block list that the agent knows about.

image

Changes In Forest

Once the domain controller the agent is installed on is rebooted, it comes back online, finds the server(s) running the proxy application and asks it to download the latest password block list. The proxy downloads this to C:\Windows\SYSVOL\domain\Policies\{4A9AB66B-4365-4C2A-996C-58ED9927332D}. Within this locations I see the AzureADPasswordProtection folder, containing three subfolders called Azure (empty), Configuration (initially empty) and PasswordPolicies (also initially empty).

In the Configuration partition at CN=Azure AD Password Protection,CN=Services,CN=Configuration,DC=domain,DC=com some settings about the service are persisted. If the domain controller has the agent installed then

CN=AzureADConnectPasswordPolicyDCAgent,CN=<DomainControllerName>,OU=Domain Controllers,DC=domain,DC=com is created.

And then on each domain controller, in the Event Viewer, you get Application and Services Logs > Microsoft > AzureADPasswordProxy with DCAgent on the DC’s and ProxyService on the proxy servers. The following EventID’s have been seen:

  • DCAgent/30016: Forest registration has not happened yet
  • DCAgent/30001: The password for the specified user was accepted because an Azure password policy is not available yet.
  • DCAgent/30009: [audit mode] The password reset was allowed, but would have been rejected as the password used was on Microsoft’s block list
  • DCAgent/10014: Password compliant with the current Azure password policy
  • DCAgent/10015: The reset password for the specified user was validated as compliant with the current Azure password policy.
  • DCAgent/10017: Password reset rejected because it did not comply with the current Azure password policy
  • DCAgent/30016: The service is now enforcing the following Azure password policy along with the date/time stamp of the policy file it is using. This entry will state if audit or enforce mode is in play as well.

 

  • ProxyService/30000: A proxy registration message was sent to Azure and a successful response was received.
  • ProxyService/30001: A new proxy certificate credential was successfully persisted.
  • ProxyService/20000: A new password block list was downloaded.

Further log IDs and meanings can be found at https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-password-ban-bad-on-premises-troubleshoot

Once the proxy starts to work, the above empty folders begin to populate. In my case in the preview it took over 2 hours from installing the proxy as well as the documented installation and configuration PowerShell cmdlets listed above to get the proxy to download anything. The above listed Configuration folder contained some cfge files and the above listed PasswordPolicies contains what I assume is the downloaded password block list, compressed as its only 12KB. This is the .ppe file and there is one of these per hour downloaded. Older versions of this download are deleted by the proxy service automatically.

Audit Mode

Using the above Event ID’s you can track the users who have changed to weak passwords (in that they are on your or Microsoft’s banned password list) when the user or admin sets (or resets) the users password. Audit mode does not stop the user choosing the password that would “normally have been rejected” but will record different Event IDs depending upon the activity and which block list it would have failed against. Event id DCAgent/30009 for example has the message “The reset password for the specified user would normally have been rejected because it matches at least one of the tokens present in the Microsoft global banned password list of the current Azure password policy. The current Azure password policy is configured for audit-only mode so the password was accepted.”. This message is a failure against Microsoft’s list on password set. The user doing a password change and the Microsoft list gets DCAgent/30010 Event ID recorded instead.

Using these two Event ID’s along with DCAgent/30007 (logged when password set but fails your custom list) and or DCAgent/30008 (password changed, fails your custom list) allows you to audit the impact of the new policy before you enforce it.

Enforce Mode

This mode ensures that password set or change events cannot have passwords that would fail the list policies. This is enabled in the password policy in Azure AD as shown:

image

Once this is enabled it takes a few hours to be picked up by the proxy servers and then for the agent to start rejecting banned passwords.

When a user changes their password in enforce mode they get the following error (different graphic depending upon Windows versions). If the admin changing the password uses a blocked password then they see the left hand graphic as well (Active Directory Users and Computers).

image or image

This is no different to the old error you get when your password complexity, length or history is not met. Therefore there is no indication to the user that the password they chose might be banned rather than not allowed for the given reasons. So though password policy with a banned list is an excellent step forward, there needs to be help desk and end user awareness and communications (even if they are just a simple notification) as the user would not be able to tell from the client error they get. Maybe Microsoft have plans to update the client error?

Password changes that fail once enforce mode is enabled get Event ID’s such as DCAgent/30002, DCAgent/30003, DCAgent/30004 and DCAgent/30005 depending upon which password list the fail happened against and the method of password set or change. For example when I used the password Oxford123, as “oxford” is in the custom banned password list, Event ID 30003 returns “The reset password for the specified user was rejected because it matched at least one of the tokens present in the per-tenant banned password list of the current Azure password policy”. As mentioned above, the sequence of 123 following the banned word is not enough to make to score more than 5 points and so the password change is rejected.

On the other hand, 0xf0rdEng1and! was allowed as England was not on my banned list an so although my new password contained a banned word, there were enough other components of the password to make it secure enough. Based on the above mentioned scoring of 5 or more is required to have a password accepted, [Oxford] + [E] + [n] + [g] + [1] + [a] + [n] + [d] + [!], a total of 9. 9 >= 5 and so the password is accepted.

Finally, when testing users, other password policies like the date that the password can next be changed and “user cannot change password” property etc. will take effect over the banned password list. For example, if you have a cannot change password for 5 days setting, and you set the users password as an administrator – that will work or fail based on the password you enter, but if you change the password as the user within that time period, that will fail as five days have not gone by and not because the user picked a guessable password.

Azure Information Protection and SSL Inspection

Posted on Leave a commentPosted in aadrm, Azure Information Protection, certificates, exchange, exchange online, IRM, Office, Office 365, rms, SSL

I came across this issue the other day, so thought I would add it to my blog. We were trying to get Azure Information Protection operating in a client, and all we could see when checking the download of the templates in File > Info inside an Office application was the following:

02-Setup RMS Menu

03-Setup RMS Menu

04-Setup RMS Menu Error

The sequence of events was File > Info, click Set Permissions. You get the “Connect to Rights Management Servers and get templates” menu item. Clicking this shows a box saying “Retrieving templates from server” (which you might not see as this step takes no real time at all) and then an error that reads “Your machine isn’t set up for Information Rights Management (IRM). To set up IRM, sign into Office, open and existing IRM protected message or document, or contact your helodesk”.

For each of these recommendations, we tried them and still got the same message.

So what was the issue?

In https://docs.microsoft.com/en-us/azure/information-protection/get-started/requirements#firewalls-and-network-infrastructure Microsoft state the the IRM client in Windows uses Certificate Pinning. This is where the client application knows what certificate it expects to see at the service it is connecting to. If it gets a different certificate it will fail to connect. Within enterprise organizations, firewalls and proxy devices that do SSL Inspection change the certificate in use so that they can see the content being sent to the service in the clear. For the IRM client in Windows, this means that IRM does not trust the certificate and so will not work.

You can test for SSL Inspection on a URL by browsing the target URL in Chrome. For example, for IRM go to https://admin.na.aadrm.com/admin/admin.svc and click the Secure banner in the address bar:

image

You will get a popup – hover over the “Certificate (Valid)” message. If the certificate is not valid then either your PC is missing some important updates or SSL inspection is happening, but not implemented correctly!

You can use this same test to check for SSL Inspection on any network.

The certificate listed when you hover over the “Certificate (Valid)” message should read (for AIP) a Microsoft CA issued certificate. It should not list your company or proxy service as the issuer. Do not terminate the TLS client-to-service connections (for example, to do packet-level inspection) to the Azure Rights Management service. Doing so breaks the certificate pinning that RMS clients use with Microsoft-managed CAs to help secure their communication with the Azure Rights Management service.

For network performance, Microsoft also have a list of URLs that they recommend you do not inspect for Office 365 services. This list of endpoints that should not be inspected are those categorised as Optimize or Allowed when you browse

https://endpoints.office.com/endpoints/O365Worldwide?ClientRequestId=GUID. Interestingly at the time of writing this lists aadrm.com as Default, which means it can be inspected – I have reported this to the team that manages the endpoint service so that this URL can be moved up in its classification.

Once you bypass SSL Inspection for *.aadrm.com you will find that the Office and RMS clients work fine (assuming everything else is enabled correctly of course).

CannotEnterFinalizationTransientException On Exchange Move Request

Posted on Leave a commentPosted in error, exchange, exchange online, Exchange Server, migration, move

Did not find a lot on the internet on this particular error, so I guess it does not happen very often, but in my case it delayed to move of the mailbox in question by a week or so until I could resolve it.

When a mailbox is moving to a different Exchange organization (cross-forest or to/from Exchange Online) the move process copies the mailbox data to the target database and then right at the end of the move updates Active Directory in both the source and target forest. In the source it changes the object type from mailbox to mailuser (or remotemailbox if Exchange Online is in play, though this is really a special form of mailuser) and in the target, updates the mailuser to become a mailbox.

This particular error occurs at this stage. The Get-MoveRequest cmdlet reports Failed as the status, and Get-MoveRequestStatistics reports FailedOther as the status. If you get the move logs (Get-MoveRequestStatistics <name> -IncludeReport | FL | Out-File <filename.txt>) then in the logs you will see CannotEnterFinalizationTransientException as the error repeated many times until the move fails.

The fix for this issue is as follows:

1. Check that the Exchange System account has permission to the Active Directory object in question. In Active Directory Users and Computers choose View > Advanced to enable the Security tab and then view the security tab on the object in question. Edit > Advanced and then check or click “Enable Inheritance” option or button (depending upon version of AD tools). If inheritance is already set to enabled there is probably no harm in disabling inheritance, copying permissions and then enabling inheritance again.

2. Move the mailbox to a different database in the source Exchange Organization (New-MoveRequest <name>) and waiting for that to complete.

3. Removing and restarting the move in the target forest. If you do not remove and restart the move in the target you will see both MailboxIsNotInExpectedMDBPermanentException and SourceMailboxAlreadyBeingMovedTransientException. The first of these is because the mailbox is not where the target move expects it to be, and the second of these is becuase the source is currently being moved and so cannot be moved to the correct target forest at the same time.

This should resolve your ultimate move request – it did for me! 

Exchange Server Object ID Error With Windows Server 2016 Domain Controllers

Posted on Leave a commentPosted in 2010, 2013, 2016, active directory, ADDS, error, Exchange Server

Saw this error the other day:

image

When you open Exchange Control Panel and view the Mailbox Delegation tab of any user account you get the following:

The object <name> has been corrupted, and it’s in an inconsistent state. The following validation errors happened: The access control entry defines the ObjectType ‘9b026da6-0d3c-465c-8bee-5199d7165cba’ that can’t be resolved..

You do not see this error on any mailboxes that you have moved to Office 365 in hybrid mode, that is you do not see it on any RemoteMailbox objects.

The issue is because ObjectType ‘9b026da6-0d3c-465c-8bee-5199d7165cba’ is the GUID of the DS-Validated-Write-Computer Control Access Right introduced in WS2016 AD DS which is new to your Active Directory upon installing your first 2016 domain controller. Exchange Server reads this access control list when you open the Mailbox Delegation tab in Exchange Control Panel or when you run Get-ADPermission on the mailbox. This error is cosmetic, but to remove it you just need to reboot all your Exchange Servers in turn (relying on your database availability groups and load balancers to maintain service). Once you have rebooted each server, the error goes away when you are connected to that server for administrative functions. There is no impact on user connectivity whilst this error is in place, though it may impact you ability to assign permissions without error.

Therefore recommend that you reboot one server as soon as you can and then use that server as your target for administration until you can reboot the remaining servers.

Copy Links and Backlinks Between Users and Shared Mailboxes (automapping)

Posted on 1 CommentPosted in cross-forest, Exchange Server, mailbox, migration, msExchDelegateListBL, msExchDelegateListLink, shared mailbox

Automap for shared mailboxes does not work across forests when moving mailboxes.

When the user is granted permission to a shared mailbox, the default behaviour of automapping means that the shared mailbox has msExchDelegateListLink set to the DN of the user, and the backlink (hidden in AD by default) on the user is populated with the DN of the shared mailbox. Whenever the link attribute is updated, the backlink is automatically updated as well. For more on back links see https://neroblanco.co.uk/2015/07/links-and-backlinks-in-active-directory-for-exchange/

That is, is UserMailbox is granted full access to SharedMailbox you will see the following in Active Directory (Advanced View) > Attribute Editor > msExchDelegateListLink = “CN=UserMailbox,OU=etc” (on the SharedMailbox). And for the UserMailbox in Active Directory (Advanced View) > Attribute Editor > msExchDelegateListBL = “CN=SharedMailbox,OU=etc”.

When you migrate mailboxes across forests you make use of Prepare-MoveRequest.ps1 to copy all the attributes. The msExchDelegateListLink is not part of this attribute set and the msExchDelegateListBL is auto populated so we can ignore it for now – if msExchDelegateListLink was copied and updated to the new forest name, then msExchDelegateListBL would be filled in automatically.

So how do we copy the msExchDelegateListLink value for each user and then write it to the mail user object in the target forest before the mailbox is migrated (or if you have already done your migration and found this property missing and so automapping of shared mailboxes having failed (though the permissions have been copied fine), how can you grab the data from the old source forest and apply it to the mailboxes in the target?

Using PowerShell and the ActiveDirectory module is how.

First you need to export a list of all the automapped shared mailboxes each user has (this is the msExchDelegateListBL values for the user mailboxes you have migrated). There are two cmdlets to run here, the first does the entire source directory and the second filters the output to an OU and its child OU’s (so you can export a subset of data) using SearchBase. Only one of these two cmdlets is needed.

This code is PowerShell and needs to be run from any domain joined computer.

Import-Module ActiveDirectory
Get-ADUser -Properties msExchDelegateListBL,msExchDelegateListLink -LDAPFilter "(msExchDelegateListBL=*)" | Select name,DistinguishedName,@{Name='SharedMailbox';Expression={$_.msExchDelegateListBL -Join ";"}} | Export-csv automap-userlist.csv -NoTypeInformation -NoClobber -Encoding UTF8
Get-ADUser -Properties msExchDelegateListBL,msExchDelegateListLink -LDAPFilter "(msExchDelegateListBL=*)" -SearchBase 'OU=Sales,DC=domain,DC=local' | Select name,DistinguishedName,@{Name='SharedMailbox';Expression={$_.msExchDelegateListBL -Join ";"}} | Export-CSV automap-userlist.csv -NoTypeInformation -NoClobber -Encoding UTF8

These cmdlets return a CSV file listing each mailbox that has an automapping to a shared mailbox and what that shared mailbox is.

The CSV file then needs copying to the target AD forest, and as the target forest is very unlikely to contain the same OU structure and domain names, the DN of each object in the CSV file needs updating. This can be done with Find/Replace in Excel or Notepad quite easily.

For example, in a CSV I might see:

“name”,”Distinguishedname”,”SharedMailbox”

“First User”,”CN=First User,OU=Sales,DC=domain,DC=local”,”CN=SharedMailbox,CN=Users,DC=domain,DC=local CN=AnotherSharedMailbox,OU=Shared Mailboxes,OU=Exchange,DC=domain,DC=local”

“Second User”,”CN=Second User,CN=Users,DC=domain,DC=local”,”CN=Sales,OU=Shared Mailboxes,OU=Exchange,DC=domain,DC=local”

In this I have the DN of the mailbox and the DN of the shared mailbox in the source forest. Use Find and Replace to change all the source DN’s (or the OU/DC bits) to suit the location of the matching object in the target forest. For example, my above “second user” was as shown, but after updating the DN might be “CN=Second User,OU=Migrated,DC=target,DC=forest”. So in that case I find/replace “CN=Users,DC=domain,DC=local” for “OU=Migrated,DC=target,DC=forest”.

For my examples that follow on from here, I have saved the edited CSV file as automap-userlist-target-dn-updated.csv

Once I have the CSV file updated for the values in the target forest, I need to split each row where a user has more than one shared mailbox listed into multiple rows. This is simple with PowerShell:

Import-Csv -Path automap-userlist-target-dn-updated.csv |
% {$row = $_; $_.SharedMailbox.split(";")} |
% {$row.SharedMailbox=$_; $row} |
Export-Csv automap-userlist-target-dn-updated-split.csv -NoClobber -NoTypeInformation -Encoding UTF8

Now that I have a row in the CSV for each Shared Mailbox to User Mailbox mapping, I can set the msExchDelegateListLink value on each shared mailbox for the DN of the user that has access to it. This will update the msExchDelegateListBL on the user object automatically.

Import-Module ActiveDirectory
Import-CSV "automap-userlist-target-dn-updated-split.csv" | % {
Write-Host Add $_.DistinguishedName to $_.SharedMailbox
Get-ADUser -identity $_.SharedMailbox | Set-ADUser -Add @{msExchDelegateListlink=$_.DistinguishedName} 
}

In terms of errors in the above, if you get “get-aduser : Directory object not found” then the DN value for the Shared Mailbox is wrong, and if you see “set-aduser : The name reference is invalid” then the DN value for the user who has access to the shared mailbox is wrong (the DistinguishedName column in the CSV). The script can be run multiple times, so you are safe to fix the CSV file and import the entire list again. It will only add a given DN once in total per shared mailbox.

If your target (or source) forest has more than one domain, run the script from a server in the correct domain or use “-Server DC-name” in both the Get-ADUser and the Set-ADUser cmdlets.

Anonymous Emails Between On-Premises and Exchange Online

Posted on 1 CommentPosted in Authentication, EOP, exchange, exchange online, Exchange Online Protection, Exchange Server, hybrid, smtp, spam

When you set up Exchange Hybrid, it should configure your Exchange organizations (both on-premises and cloud) to support the fact that an email from a person in one of the organizations should appear as internal to a recipient in the other organization. In Outlook that means you will see “Display Name” at the top of the message and not “Display Name” <email address>. An email from the internet is rightly treated as anonymous and so should appear as “Display Name” <email address> but when it comes from your on-premises environment or your cloud tenant it should be authenticated.

In the email headers you should see a header called AuthAs that reads internal. The SCL (Spam Confidence Level) should always be –1 and you should not have a header called X-CrossPremisesHeadersFilteredBySendConnector visible on internal emails.

Your hybrid setup can be incorrectly configured and cause this, and depending upon what Exchange Server version you are running and when you last ran the hybrid wizard you can end up with different results.

Lets take a quick view to some of the settings you should see:

  1. Exchange Server 2010 (with or without Edge Server 2010)
    1. Hybrid wizard will use Remote Domains to control internal vs external and authentication state. You should have a Remote Domain for tenant.mail.onmicrosoft.com that shows TNEFEnabled, TrustedMailOutboundEnabled, TargetDeliverDomain, and IsInternal all set to True on-premises
    2. TrustedMailnboundEnabled attribute is set to True on Get-RemoteDomain domain.com in the cloud
    3. The AllowedOOFType, which controls Out Of Office is set to InternalLegacy
  2. Exchange Server 2013 and later
    1. Your “Outbound to Office 365” send connector on-premises should have CloudServicesMailEnabled set to True
    2. The Remote Domains matter for Out of Office and moderated emails/voting buttons, but not for authentication as mentioned in #1 above
    3. The Inbound Connector for “Inbound from GUID” should have CloudServicesMailEnabled set to True
  3. Exchange Server 2010 with Exchange Server 2013 or later Edge (no 2013 on-premises, only Edge)
    1. The setting CloudServicesMailEnabled needs to be True, but 2010 does not support this setting, so you need to edit the directory using ADSIEdit and change the msExchSmtpSendFlags on the send connector from 64 to 131136. All this does is tell the 2013 or later Edge to enable CloudServicesMailEnabled
    2. See https://support.microsoft.com/en-us/help/3212872/email-sent-from-an-on-premises-exchange-2013-edge-transport-server-to for the steps to do this
  4. As #3 but with 2010 and 2013 on-premises – run the cmdlets and hybrid wizard from the 2013 server and not connected to the 2010 server!

Azure AD Single Sign-On Basic Auth Popup

Posted on Leave a commentPosted in AADConnect, AADSync, Azure Active Directory, Azure AD, AzureAD, conditional access, microsoft, modern authentication, SSO

When configuring Azure AD SSO as part of Pass-Through Authentication (PTA) or with Password Hash Authentication (PHA) you need now (since March 2018) to only configure a single URL in the Intranet Zone in Windows. That URL is https://autologon.microsoftazuread-sso.com and this can be rolled out as a registry preference via Group Policy. Before March 2018 there was a second URL that was needed in the intranet zone, but that is no longer required (see notes).

So this short blog post is how to fix SSO when you do see a popup for this second URL though it is no longer required. The popup looks like:

image

It has OK and Cancel on it as well, but my screengrab I made when I saw the issue was not brilliant, so I “fixed” the bottom of the image so its approx. correct!

The URL is aadg.windows.net.nsatc.net. Adding this to Local Intranet Zone even though it is not needed does not fix the issue. The issue is caused because on Windows 10 (version 1703 and maybe others) someone has enabled Enhanced Protected Mode. Azure SSO does not work when Enhanced Protected Mode is enabled. This is not a setting that is enabled on client machines by default.

Enhanced Protected Mode provides additional protection against malicious websites by using 64-bit processes on 64-bit versions of Windows. For computers running at least Windows 8, Enhanced Protected Mode also limits the locations Internet Explorer can read from in the registry and the file system.

It is probable that Enhanced Protected Mode is enabled via Group Policy. It will either have the value Isolation (or Isolation64bit) set to a value of PMEM at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main or HKEY_CURRENT_USER\SOFTWARE\Microsoft\Internet Explorer\Main or the policy equivalent at  HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Internet Explorer\Main or HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Internet Explorer\Main when set via GPO settings.

This issue is listed in the Azure AD SSO known issues page at https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-troubleshoot-sso. The reason why Enhanced Protected Mode does not work with Azure AD SSO is that whilst Enhanced Protected Mode is enabled, Internet Explorer has no access to corporate domain credentials.

Send-On-Behalf Permissions in Exchange Online

Posted on 2 CommentsPosted in exchange, exchange online, Exchange Server, hybrid, permissions, send-on-behalf

This document is up to date as of March 2018 and is therefore unlike many earlier documents on this issue as this feature set is in the process of changing.

First, Send-On-Behalf is changing so that it is supported across a hybrid Exchange Server to Exchange Online connection. At the time of writing this is in the process of being rolled out, so it might well be in your tenant by the time you read this.

But even if the config for this is enabled in the cloud, there is config that is needed on-premises. In Exchange Server 2013 you need to be on the latest CU and then run Set-OrganizationConfig  -ACLableSyncedObjectEnabled $True (as mentioned in https://technet.microsoft.com/en-us/library/mt784505%28v=exchg.150%29.aspx). For Exchange 2010, this is not an option (and the ACL sync needs to be done manually) and for Exchange 2016 this cmdlet is enabled already. [Note, discovered April 2018 that this is not true, and Exchange Server 2016 needs treating in the same way as Exchange Server 2013 regardless of what the Microsoft article says at the time of writing]

So what does -ACLableSyncedObjectEnabled $True do – well it changes Exchange Server so that all MoveRequests completed after the change leave behind a RemoteMailbox object where msExchRecipientDisplayType is -1073741818. For reference before the change to the OrganizationConfig this value on a RemoteMailbox was -2147483642.

msExchRecipientDisplayType Value
SyncedMailboxUser

-2147483642

ACLableSyncedMailboxUser

-1073741818

An ACLableSyncedMailboxUser is one that can have Send-On-Behalf permissions set or maintained across on-premise and the cloud – that is once your tenant is  updated as well.

This though leaves a few issues – the main one is that the RemoteMailbox left behind by the MoveRequest is only set to -1073741818 where the RemoteMailbox is made by a MoveRequest. If once you have moved all your users you start provisioning users directly in the cloud, then New-RemoteMailbox or Enable-RemoteMailbox will not set msExchRecipientDisplayType to -1073741818.

Therefore provisioning of users directly into the cloud with –RemoteMailbox will need the addition of Set-ADUser to update the msExchRecipientDisplayType after the RemoteMailbox is created. The cmdlet for this is the same cmdlet that you need to run if you are using Exchange 2010. This cmdlet is Get-AdUser <Identity> | Set-AdObject -Replace @{msExchRecipientDisplayType=-1073741818}

This  cmdlet would need to be added to your provisioning scripts, and if you don’t have scripts to provision users in AD and have a mailbox in the cloud, then now is the time to look at this as the number of moving parts is growing.

If you do not do the msExchRecipientDisplayType change then some of your remote mailboxes in Exchange Online will be able to be granted permissions for Send-On-Behalf and other permissions as they are added to the cloud, as they are ACLable (as in we can set them in Access Control Lists, ACLable!), and others users will not be. To make these changes you need to change the msExchRecipientDisplayType on-premises to -1073741818 and wait for this to sync to Azure AD and then wait for that to sync from Azure AD in the Forward Sync process to your Exchange Online directory.

New Underlying Search Functionality in Exchange Online

Posted on Leave a commentPosted in bing, exchange online, search

Mentioned during Microsoft Ignite 2017, there is a new search functionality in place within Exchange Online. Not all mailboxes are able to make use of the new functionality, such as hit highlighting and search results being shown in-line with the results highlighted in context with the results. The reason that the functionality is not available is that the feature has not been rolled out to all mailboxes in the service. At Microsoft Ignite, a percentage of enabled mailboxes was announced, and of course this will change over time. So how can you tell if the functionality is enabled on your mailboxes.

The answer is to use Get-MailboxStatistics via Exchange Online Remote PowerShell. The Get-MailboxStatistics cmdlet returns two sets of values, one starting with BigFunnel, which is the new search functionality code name and also values returned starting MCDB, which is the new MetaCache Database feature also announced at Microsoft Ignite.

 

image

PS> Get-MailboxStatistics email@address| fl *funn*,*mcdb*
BigFunnelIsEnabled                             : False
BigFunnelUpgradeInProgress                     : False 
BigFunnelMaintainRefiners                      : False 
BigFunnelFilterTableTotalSize                  : 0 B (0 bytes) 
BigFunnelFilterTableAvailableSize              : 0 B (0 bytes) 
BigFunnelPostingListTableTotalSize             : 0 B (0 bytes) 
BigFunnelPostingListTableAvailableSize         : 0 B (0 bytes) 
BigFunnelLargePOITableTotalSize                : 0 B (0 bytes) 
BigFunnelLargePOITableAvailableSize            : 0 B (0 bytes) 
BigFunnelTotalPOISize                          : Unlimited 
BigFunnelMessageCount                          : 
BigFunnelIndexedSize                           : Unlimited 
BigFunnelPartiallyIndexedSize                  : Unlimited 
BigFunnelNotIndexedSize                        : Unlimited 
BigFunnelCorruptedSize                         : Unlimited 
BigFunnelStaleSize                             : Unlimited 
BigFunnelShouldNotBeIndexedSize                : Unlimited 
BigFunnelIndexedCount                          : 
BigFunnelPartiallyIndexedCount                 : 
BigFunnelNotIndexedCount                       : 
BigFunnelCorruptedCount                        : 
BigFunnelStaleCount                            : 
BigFunnelShouldNotBeIndexedCount               : 
BigFunnelMailboxCreationVersion                : 
MCDBBigFunnelFilterTablePercentReplicated      : 
MCDBBigFunnelLargePOITablePercentReplicated    : 
MCDBBigFunnelPostingListTablePercentReplicated : 
MCDBMessageTablePercentReplicated              : 
MCDBBigFunnelFilterTablePercentReplicated      : 
MCDBBigFunnelLargePOITablePercentReplicated    : 
MCDBBigFunnelPostingListTablePercentReplicated : 

In the above BigFunnelIsEnabled shows if the feature is on, and then the rest of the values will contain information such as the size of the index within the mailbox (as the index is stored within the mailbox and not separate as it is with Exchange Server 2013/2016 and how it was in Exchange Online before this feature).

The MetaCache Database is SSD based storage within Exchange Online and where the index s read from – so the MCDB* results show things like the replication status of the database across the servers in Exchange Online.

420 4.2.0 RESOLVER.ADR.Ambiguous; ambiguous address

Posted on Leave a commentPosted in active directory, exchange, exchange online, Exchange Server, migration, smtp

This error can turn up in Exchange Server when Exchange Server is trying to resolve the object that it should deliver a message to. Exchange queries Active Directory and expect that if the object exists in the directory, that the object exists only once. If the object exists more than once, this is the error – as Exchange does not know who to deliver the email to.

The error is visible when running Get-Queue in Exchange Management Shell, and seeing that there are lots of emails in the Submission Queue. If you run Get-Message –Queue servername\Submission | FT Identity,FromAddress you can pick one to look at, and for that one run Get-Message server\submission\ID | FL where server\submission\ID is the Identity value from Get-Message cmdlet. Here you will see LastError and Recipients showing the ambiguous address error.

There are a number of articles on the internet covering this issue, but I came across a unique one today.

The easy way to search for the issue is to find the address that is in duplicate. This will be listed in Event Viewer under MSExchangeTransport as the source and Event ID 9217. The Task Category will be Categorizer, as the job of working out who is going to get the message is the role of the Categorizer.

image

An example of this error is shown.

So the fix. Often suggested is to do a custom AD query for “proxyaddress=smtp:name@domain.com” where name@domain.com is the email address shown in the event log error. If this returns two or more recipients, and this will be across all the domains in the forest, then you need to decide which is the primary one and carefully delete the rest.

By carefully I mean that you want to leave either one contact, or one mail user or one mailbox etc. If the duplicate is two contacts, then find the one with the most correct information on it and carefully delete the other. If you find two mailboxes, work out which the user is actually logging into and has email in it – and carefully delete the other etc.

And by carefully, here I also mean that on the object you are going to delete, copy the legacyExchangeDN value and then delete the object. Then find the real correct object and add a new x500 email address to the proxyAddresses attribute of the correct user. The value of the x500 address will be the legacyExchangeDN that you copied from the deleted contact.

This will ensure that users who have previously emailed the now deleted contact before, will still be able to email the remaining object.

But what is unique about that? At the customer I am working on at the moment the issue was that doing the proxyaddresses=smtp:name@domain.com search only returned one object across the entire forest – what is duplicate about that? Well in my case, the user had user@domain.com added to their proxyaddresses twice – they were the duplicate object to themselves.

image

Opening this user via the search results as shown above, and with Advanced Features enabled from the View menu, you can see the Object tab:

image

Opening the object value directly, redacted in the picture above, I can change to the Attribute Editor tab and open proxyAddresses attribute. Here i saw the following:

name@domain.com

name@mail.domain.com (used as a target for forwarding emails from another system)

smtp:name@old-company.com

SMTP:name@domain.com

x500:legacyExchangeDN from Exchange 2007 migration

Note that the name@domain.com value, the one in error in the logs, appears twice but not starting SMTP (primary address) or smtp (secondary address) but without an address protocol at all!

Querying the user in Exchange Administration Console returned:

image

And also then opening the user in Exchange Management Console showed that the address without the smtp: value was shown with it.

Remove one of the two addresses and within ten minutes the emails queued to this user in the submission queue will be delivered. Restarting the transport service will also kick start the submission queue as you cannot use Retry-Queue against this queue.

Exchange Online Migration Batches–How Long Do They Exist For

Posted on 5 CommentsPosted in exchange, exchange online, Exchange Server, hybrid, microsoft, migration, Office 365

When you create a migration batch in Exchange Online, the default setting for a migration is to start the batch immediately and complete manually. So how long can you leave this batch before you need to complete it?

As you can see from the below screenshot, the migration batch here was created on Feb 19th, which was only yesterday as I write this blog.

image

The batch was created on the morning of the 19th Feb, and set to manual start (rather than the default of automatic start, as did not want to migrate lots of data during the business day) and then it was started close to 5:30pm that evening. By 11:25pm the batch had completed its initial sync of all 28 mailboxes and there were no failures. There were other batches syncing at the same time, so this is not indicative of any expected or determined migration performance speeds.

So what happens next. In the background a new mailbox move request was created for each mailbox in the batch, and each individual mailbox was synced to Exchange Online and associated with the synced Mail User object created in the cloud by the AADSync process. When each move reached 95% complete, the move was suspended. It will be resumed around 24 hours later, so that each mailbox is kept up to date once a day automatically.

If you leave the migration running but not completed you will see from the migration batch status above that the batch will complete in 7,981 years (on the 31st Dec 9999 and one second before the next millennium bug hits). In the meantime the migration batch sync will stop doing its daily updates after two months.

After two months of syncing to the cloud and not being completed, Exchange Online assumes you are still no closer to migrating and they stop keeping the mailbox on-premise and the mailbox in the cloud in sync. You can restart this process by interacting with the migration batch before this time, or if it does stop by just clicking the Resume icon, and this will restart it for a further period of time.

Office 365 Retention Policies and Hybrid Public Folders

Posted on Leave a commentPosted in exchange online, Exchange Server, hybrid, Office 365, Public Folders, retention, retention policies

If you create an Office 365 Retention Policy (in the Security and Compliance Center) that applies to all Exchange Online content then you might find that after the retention policy has been deployed (a day or so later usually) that the policy is in error and there is a message at the top of the retention policy pane that shows “1 distribution result(s) found”.

image

The “Notify support” link does nothing but help you call support, and a post on the Microsoft Tech Community implies that that does not help.

The place to look for the answer is in a Security and Compliance Remote PowerShell session. Here you can run Get-RetentionCompliancePolicy -DistributionDetail | fl Name,Distribution* to return the name of each of your retention policies along with the DistributionStatus (which will be “Error”) and DistributionResults.

In my example I found I had a DistributionResults message of “{[Exchange]AllPublicFolderUnderRoot:Recipient not found: }”.

image

In the example that I was trying to resolve this issue for, the Exchange Online organization was utilizing on-premises Public Folders for Exchange Online mailboxes. That is, in Exchange Online, the PublicFoldersEnabled property of Get-OrganizationConfig was set to remote and we had a few RemotePublicFolderMailboxes (aka mailboxes that proxy the online mailboxes connection to the on-premises organization).

image

Therefore there seems to be an error in Office 365 Retention Policies where the retention policy distribution fails when you set it to archive public folders, but your public folder infrastructure is still on-premises.

So what can you do – either you ignore the error, after all it is telling you that your retention does not include objects that do not yet exist – but when you do have public folders in Exchange Online, the retention policy should take effect without you doing anything else.

The other thing you could do is to to remove public folders as a retention source, not forgetting to enable it again when you have moved your public folders to the cloud.

image