We use separate Microsoft 365 identities for regular work and privileged administration. The regular accounts are synchronized from on-premises Active Directory, while the elevated cloud-only accounts are used for Entra SSO with services that perform administrative functions. The elevated accounts do not have Exchange licenses or mailboxes, but some external services assume the sign-in name, UPN, and email address are the same.
To handle that, we added each elevated account's SMTP address as an alias on the corresponding regular mailbox. This works for most users, but three accounts fail synchronization with a duplicate proxyAddress attribute error. We suspect those elevated accounts previously had Exchange licenses or mailboxes, and that old proxy addresses are still attached somewhere. Litigation hold is disabled, but we're unsure whether another Microsoft 365 retention feature could be preserving the addresses.
What is the safest way to find and remove the conflicting proxy addresses? Would deleting and recreating the accounts help, or is there a better design for receiving mail for privileged identities without licensing every account?
5 Answers
First, inspect the on-premises AD objects in Attribute Editor and search the entire directory for every conflicting value in proxyAddresses. A duplicate can exist on another object, including a deleted or previously converted account. Remove the stale value from the correct source object, let synchronization complete, and verify the result in Microsoft 365. Recreating accounts should be a last resort, since it can leave behind more orphaned objects and identifiers.
The larger design concern is that privileged accounts should be isolated from the regular identity. Keep them cloud-only where possible, use just-in-time elevation through PIM rather than permanent roles, and maintain an independently controlled break-glass account. Some organizations also use an onmicrosoft.com address for emergency or highly privileged identities so access to the custom domain is not a single point of failure. Avoiding mailboxes reduces phishing exposure, but it means the identity and notification workflow needs to be designed deliberately.
If the external services accept it, Exchange Online plus addressing can provide a distinct-looking sign-in address that routes to the normal mailbox, such as a tagged version of the user's address. It avoids creating a mailbox or maintaining lots of aliases, but some SAML/OIDC providers reject addresses containing a plus sign. In that case, set the appropriate mail claim or attribute transformation in the identity provider instead of relying on the account's actual mailbox address.
A common approach is to license the privileged identity, convert its mailbox to a shared mailbox, and grant the regular account access. You can then forward or otherwise process messages without assigning a full user mailbox license, subject to the service's licensing and mailbox limits. This avoids putting the privileged address directly on the regular user's mailbox, although it does not completely eliminate the security and administration tradeoffs.
Forwarding from a licensed admin mailbox to the regular mailbox is another straightforward option, but it gives up the license-saving goal. Whatever method you choose, make sure the address emitted in the SSO claims matches what each provider expects, rather than assuming username, UPN, and email will automatically be interchangeable.
Plus addressing works well when the service accepts it, but compatibility needs to be tested because some providers validate the address format too strictly.