We maintain separate Microsoft 365 identities for each employee: a regular account synchronized from on-premises Active Directory, an on-premises elevated account, and a cloud-only elevated account used for administrative single sign-on to other services. The elevated cloud accounts intentionally do not have Exchange licenses or mailboxes, mainly to reduce phishing risk and licensing costs.
Some external services assume that the SSO username, UPN, and email address are the same, so we added SMTP aliases for the elevated accounts to the users' regular mail-enabled accounts. This works for most users, but three accounts fail synchronization with a duplicate proxy address 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 are unsure whether retention or compliance data could prevent cleanup. What is the correct way to identify and remove the conflicting addresses, and is there a better design for receiving mail or satisfying services that require an email-shaped identifier without licensing every privileged account?
4 Answers
For services that accept it, Exchange Online plus addressing can provide an address such as user+admin@domain and deliver mail to the normal mailbox without creating another mailbox. It is simple and scales well, but some vendors reject addresses containing a plus sign. In those cases, an identity-provider claim transformation or a normal-looking forwarding alias may be needed.
First check the on-premises proxyAddresses attribute on both objects, including deleted or previously used accounts. The duplicate value may still exist in Active Directory even if it no longer appears obvious in the cloud portal. Remove or change the conflicting address at the authoritative source, allow synchronization to complete, and only then add it to the intended object. Deleting and recreating an object can work, but it should be a last resort after confirming what is holding the address.
From a security perspective, keeping privileged accounts separate from synchronized user accounts and without mailboxes is reasonable, especially when licensing is expensive. Use just-in-time elevation such as PIM rather than permanent privileges, keep break-glass accounts available, and consider using a tenant domain for emergency administrative identities so access is not dependent on the custom domain. Forwarding or a shared mailbox can handle the few cases where administrators genuinely need to receive mail.
A common alternative is to license the elevated account, convert its mailbox to a shared mailbox, and grant the regular account access or configure forwarding. That avoids assigning the elevated address as an alias on the regular account, although it does not eliminate licensing and administrative overhead. Also be aware that shared-mailbox details may not be emitted in the SAML or OIDC claims automatically, so the service may need its mail attribute set explicitly.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures