Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community

AzureAD sharepoint SAML integrattion

Copper Contributor

Hi All,

 

We are trying to federate salesforce to use AzureAD for authentication. I did some testing in a sandpit in salesforce. Did all the configuration and it all works when i use the microsoft account i.e a trial account in azure. However, when I create a new user in Azure AD and try and login as that user in salesforce, I keep getting a SAML error. I do get redirected to login.microsoft webpage for auth but the moment i enter the credentials of the user it doesnt work. I used the email-id as federation-id so if the user.

 

What I have gathered is that when the federation works when I use the MS account but not as a user in AAD.  Can someone please explain the reason behind this?

 

Regards,

AR

8 Replies

What is the SAML error, can it not find the user?  Can you post the SAML trace?

 

Hello,

 

Saleforce integration can be tricky, have you checked the following?

 

  1. You have licensed Saleforce accounts that correspond to your Azure AD accounts - "shadow accounts" that sit in the Salesforce iDP.
  2. The Salesforce accounts FederationIdentifier matches your Azure AD accounts UserPrincipalName.
  3. If you haven’t setup account provisioning referenced above, please follow the following tutorial

Configure Salesforce for automatic user provisioning

https://docs.microsoft.com/en-us/azure/active-directory/saas-apps/salesforce-provisioning-tutorial

 

Hope this helps!

 

 

 Salesforce.png

hi Peter ,

 

Happy new year and apologies for the delay in responding.

thanks for your email. Below is what i have found in the trace.

 

SAMLtrace for working user which is a microsoft online account

 

<NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">maverick1@hotmail.com</NameID>

 

you can see that azure is passing the email address which is used as federatedID between azure and salesforce

 

SAMLtrace for non-working user which is a user account in the directory 

<NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">F8xKa2JIpxTCFjO66gjj-9TrfpXfOnyxOHogR8s1PA4</NameID>

 

As  you can see from above that the email address is not being passed as federationID for the user in the directory . So , it only seems to work with the MS online account.

 

your help would be appreciated.

Hello,

 

Please check your Saleforce claim mappings, nameidentifier should map to user.mail or user.userprincipalname. These values should be identical to the Saleforce account FederationID.

 

If you’re using user.mail, please check the accounts have the mail attribute using the Azure AD PowerShell cmdlets for cloud accounts or sync'd, Active Directory Users and Computers.

1.png

2.png

If you’ve found this post helpful, please click the Like button.

Hi ThinkSync,

 

They are correctly set to user.mail.  The thing that I am stuck is that it works for the microsoft account i.e the account I login to the azure tenant with. However, it doesn't work with users that are in the AAD.

 

 

Thanks 

AR

hi thinksync,

any ideas?

Regards
AR

Have you tried user.userprincipalname as suggested?

Hello,

 

Sorry for the delay.

 

Firstly, I recommend making sure the following attributes match. This reduces administrative overhead and provides the best user experience.

 

Setting

Azure AD Attribute Name

SIP

ProxyAddresses – denoted with a prefix of uppercase ‘SMTP’

Primary SMTP (default send from address)

ProxyAddresses – denoted a prefix ‘SIP’

Mail

WindowsEmailAddress (Exchange), Mail (Graph API)

User Principal Name (AzureAD login name)

UserPrincipalName

Alternative ID (**avoid if possible)

 

 

** I hear you On-prem Active Directory admins, yes, it’s a lot of work but these changes will save you a world of pain :smiling_face_with_smiling_eyes:

 

With reference to your problem, the mail attribute “user.mail”, isn’t used by Exchange or sending email, and is often out of date or not set at all. Now in saying that, Azure AD has some interesting rules which in some cases populate the mail attribute:

https://support.microsoft.com/en-gb/help/3190357/how-the-proxyaddresses-attribute-is-populated-in-az...

 

Personally, I wouldn’t rely on Azure AD updating synchronised accounts. Please manage the mail attribute using On-Prem AD to avoid ambiguity.

 

So how does this help me? :smiling_face_with_smiling_eyes:

 

Check one of your problematic users using the Graph API explorer, unless you connect to Exchange Online, mail attribute isn't exposed:

  1. Login to the graph api explorer - https://developer.microsoft.com/en-us/graph/graph-explorer#
  2. Paste the following query into the query window and add you users UPN
  3. https://graph.microsoft.com/v1.0/users/[UPNHere]AD.png