Skip to main content
Visit Freshworks.com Visit Freshworks

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 @ourcomp.com but our domain/how we login to azure/office365/sso is @ourcompany.com

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

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?



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 @ourcomp.com

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


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.

Regards,

Gautham

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.
UPN : @domain1.com

email: @domain2.com

  • If we keep the attribute mapping by default, users are added with domain1.com (upn)  in fresh and do not receive email (because it should be domain2.com) , 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 domain2.com 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 = @domain1.com (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

Regards,

M.

 

Reply


Terms of Use