search

MicrosoftDocs / azure-docs

Open source documentation of Microsoft Azure
https://docs.microsoft.com/azure
Creative Commons Attribution 4.0 International
10.2k stars 21.36k forks source link

Claims needed for Sage Intacct SSO tutorial #35432

Closed jimmymcpeter closed 5 years ago

jimmymcpeter commented 5 years ago

The tutorial for Intacct needs some updates to state the following 3 Claims are needed:

Here is picture I made of the Claim mappings. The other fields, like first and last name, on the Intacct User record don't necessarily need to match. image

We were also acquired by Sage, so the product is now called Sage Intacct if you don't mind updating that too 😃

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

jimmymcpeter commented 5 years ago

It also may be worth noting that the Company > User Access Log in Sage Intacct contains helpful SSO debug info

image

shashishailaj commented 5 years ago

@jimmymcpeter Thank you for taking time to provide detailed explanation . We will engage the content authors to take this forward.

jimmymcpeter commented 5 years ago

One more comment in step 4 it mentions to use the pattern of https://<companyname>.intacct.com/ia/acct/sso_response.phtml for the Reply URL. We do not have sub-domains by company name. It should just be https://www.intacct.com/ia/acct/sso_response.phtml as the Reply URL.

jeevansd commented 5 years ago

@chetansriv and @v-viinde Can you please make these changes in the doc as suggested here?

chetansriv commented 5 years ago

@jimmymcpeter We have updated the article as per suggestion, please review.

please-close

shadowkiller3 commented 3 years ago

@jimmymcpeter Do you know if I can map firstname initial full lastname to the user principal name on Azure. The Sage Intacct user ids were created using firstname initial full lastname format which does not match our mail prefix format (firstname.lastname) and I cant change the user id on intacct once created.

Thanks

jimmymcpeter commented 3 years ago

You will likely need to store the Intacct User ID as an attribute on the user in Active Directory since I don't see a substring claim transformation available. You could try putting the Intacct User ID in an unused field, or may need to go down the route of making it an extension in the Microsoft Graph. I haven't been able to test the custom graph extension out yet so you're in uncharted waters.

If you ever plan to change UPN which is possible, you might want to look at using the user.objectid instead for the Unique User ID.

image image

shadowkiller3 commented 3 years ago

@jimmymcpeter Thanks for the quick response. Here is a screenshot of the claims I currently have:

current setup

I used the Employee ID field to store the Intacct user ID though did not work and kept getting the same error code.

I have a feeling the error I keep getting has nothing to do with how my attributes are mapped (as it should show user not found or something similar) but I might be wrong.

Thanks!

jimmymcpeter commented 3 years ago

Are you part of multiple orgs with your account? I think I ran into this error when I was trying to use service provided initiated login (the Intacct login page) and I hadn't switched my org context from https://myapplications.microsoft.com

shadowkiller3 commented 3 years ago

@jimmymcpeter I'm not part of multiple orgs. We have a single tenant with 2 domains.

pwebendorfer commented 2 years ago

@jimmymcpeter I am pulling my hair out, trying to get this to work. I have created the additional claims, per your instructions and it still isn't working. What should the Required Claim be? Error:
AADSTS650056: Misconfigured application. This could be due to one of the following: the client has not listed any permissions for 'AAD Graph' in the requested permissions in the client's application registration. Or, the admin has not consented in the tenant. Or, check the application identifier in the request to ensure it matches the configured client application identifier. Or, check the certificate in the request to ensure it's valid. Please contact your admin to fix the configuration or consent on behalf of the tenant. Thank you! Paul

jeevansd commented 2 years ago

@pwebendorfer Your error message state that you have not correctly configured the application in Azure AD. Please look at the SAML Request coming from the app and copy SAML Issuer value in the request and then use that same value in the Azure AD Identifier property. That should solve your issue here.

jeevansd commented 2 years ago

You can use the SAML tracer plugin from the Chrome or Firefox browser. They can detect and decode the SAML request and Response easily.

pwebendorfer commented 2 years ago

Thank you so much for your guidance, but we have started from scratch and now I am getting this error:

Message: AADSTS700016: Application with identifier 'https://xxxxxxxxxxxxxxxx' was not found in the directory 'xxxxxxxxx'. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You may have sent your authentication request to the wrong tenant.

shadowkiller3 commented 2 years ago

@pwebendorfer I had the same error. You need to add the application identifier as the Entity ID on the SSO settings on Azure.

pwebendorfer commented 2 years ago

Thanks @shadowkiller3 - I have verified that I have the correct Entity ID in the Basic SAML Configuration settings and the Azure test works fine. However, every time I try to log in through the Sage site, I enter my credentials and it tries to authenticate through Azure, but then I get the error above. This is maddening.

jimmymcpeter commented 2 years ago

However, every time I try to log in through the Sage site, I enter my credentials and it tries to authenticate through Azure, but then I get the error above. This is maddening.

I think you should try identity provider initiated login from https://myapplications.microsoft.com instead of service provided initiated login (from the Sage login page). Last I checked Intacct didn't play nice with SP initiated and Azure.

You might also check the Company menu > Access Log from Intacct. This includes some helpful debugging on the Intacct side.

pwebendorfer commented 2 years ago

Thanks, Jimmy. We found some other documentation that started us down the IdP path too. That seems more and more like the root of the problem, which will probably result in us abandoning this effort. Appreciate all the feedback from the group.