Skip to main content
Visit Freshworks.com Visit Freshworks

We are just setting up our Freshservice (FS) instance.  I installed the “Azure Active Directory Provisioning (SCIM)” app in FS and configured the “Freshservice Provisioning” enterprise app in Azure per the instructions using my local FS agent account. Then I configured SAML SSO. I target a small group of users that have everyone we want to be agents.  All these users that were automatically provisioned by AAD provisioning can sign in using the SSO except me.  Even though my local FS Agent profile is currently syncing fine with Azure, when I try to sign in with the SSO, FS creates a new Requester account for me.  I figured this was due to it being created as a local account, so changed my local account to a different email address, “forgot” (deleted) the Requester account FS created for me on login with the SSO and let AAD Provisioning create a new account for me.  I can successfully sign in to the SSO and use this account.  So I convert this AAD/SSO account to an Agent but now I’m using two of my Agent seats --- one with the local account and one with the AAD/SSO account. I convert my local account to a Requester and discovered that AAD provisioning quits working because the account is running as is no longer an agent. Ugg.  I uninstall/reinstall the AAD provisioning app in FS with my AAD/SSO account and update the AAD provisioning app in the Azure portal with the new secret token. The next time AAD provisioning cycle runs it says it updated all user accounts!? And now everyone that tries to logon using the SSO get a new FS Requester account rather than signing in to their already established Agent accounts, including me! 

Seems like the only way to get this working is to burn an Agent seat just to run AAD provisioning!!!

Any ideas?

 

 

For us this works totally fine.

We also connected multiple AADs for SSO.


It looks there might be a configuration error in the information you give via the Single Sign On.

We use the user.mail as the Unique User Identifier.

 

The same might be the problem for the Provisioning.

 

Otherwise I would advise reaching out to the Developers of the Provisioning app: support@effy.co.in

 

Hopefully this helps.

@nickstelzer , thanks for the reply.  Some attributes from the SSO needed to be tweaked (I’m not sure which as there’s another team that handles it) so that the agent email provisioned by Azure in FS aligns with what the SSO returns.  Still seems strange that Requesters work fine but Agents didn’t.

We still need to utilize an extra agent seat as a service account so the provisioning process doesn’t run as me or another agent.  There’s another thread about this from a little over a year ago about this issue and that FS was working on storing the API key centrally rather than in an agent profile:
Grant Extra License for Integrations Requiring API Key | Freshworks Community

@CoNative great that that helped.

Yeah about the API Keys, that is a whole thing, we are also looking forward to eventually getting this, there were different threads popping up here and there.

I also upvoted the idea, completely forgot to mention it here 😊

Reply


Terms of Use