SSO When Azure Domain & Email Are Different

  • 17 April 2020
  • 2 replies

I've opened a support ticket on this, but I'm posting here in case anyone might have dealt with this before

We're a hybrid local AD / Azure AD environment.

We want to use the AD probe to import requesters, as most of our requesters won't ever login to the support portal, they'll just call us on the phone.

However, if they DO want to login to the support portal I want them to be able to do it via SSO.

The catch is that our email addresses are but our domain/how we login to azure/office365/sso is

So, the probe pulls our users in via AD with the email address of When the go to login to SSO they login as and it says they don't exist since <>

I've tried creating a custom uesr field mapping and pulling in userPrincipalName instead of email from the local AD, but that doesn't seem to work.

Anyone dealt with similar? Any ideas for a possible work-around?

2 replies

Hi Justin,

In Freshservice, the email address is the primary identifier of any agent/requester and the login is also based on the same.

  • When the Probe fetches the users from the AD and creates them as requesters, their profiles have the

  • When the requesters sign in using their Microsoft credentials via the SSO configured with Azure, new requester profiles will be created with the domain,, if their email address in Azure has the domain,

This is how we have designed the creation of requester profiles in Freshservice. Are new user profiles being created when they login through Azure SSO or are there restrictions there?

Freshservice does not prevent creation of requesters unless Domain Whitelisting is enabled, and the requester does not belong to the whitelisted domains. (Admin -> Support Channels -> Portals -> Domain Whitelisting)

For further investigation, we’ll create a support ticket on your behalf and follow up on the same.



Hi there,
Any news on this request?

We are in the same situation. 2 different domains (UPN & email) and devices managed on Intune linked to the Users UPN.


  • If we keep the attribute mapping by default, users are added with (upn)  in fresh and do not receive email (because it should be , but in asset, we can see that imported devices are attached to the user( because of the correct upn)
  • If we change the attribute mapping to match AAD email with username/email in fresh, users are added with in fresh and receive the mail to connect. But in Asset, device are not imported because the Fresh username/email do not match the upn. Asset inventory is looking for email = (our upn).

Why does Fresh force the Login to be the AAD mail attribute? It doesn’t make sense as many company use a different domain for upn and email. Fresh should use the AAD upn as primary key