Dec 25 2018
12:17 AM
- last edited on
Jan 14 2022
05:21 PM
by
TechCommunityAP
Dec 25 2018
12:17 AM
- last edited on
Jan 14 2022
05:21 PM
by
TechCommunityAP
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
Dec 25 2018 02:43 PM
What is the SAML error, can it not find the user? Can you post the SAML trace?
Dec 26 2018 03:32 PM
Hello,
Saleforce integration can be tricky, have you checked the following?
Configure Salesforce for automatic user provisioning
https://docs.microsoft.com/en-us/azure/active-directory/saas-apps/salesforce-provisioning-tutorial
Hope this helps!
Jan 06 2019 02:28 PM
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.
Jan 06 2019 04:05 PM
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.
If you’ve found this post helpful, please click the Like button.
Jan 06 2019 06:37 PM
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
Jan 10 2019 09:38 AM
Have you tried user.userprincipalname as suggested?
Jan 10 2019 11:23 AM
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’ |
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:
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: