Last few weeks I'm trying to solve one BIG problem with Azure Active Directory and Oauth authorization.
Now we have Azure AD tenant and API application in that tenant. We use it for Oauth and Office 365 API. Everything is ok, except one thing - our users cant change their passwords by themselves, they have to write administrators (>10K users). We want to enable ADFS and give them ability to change password.
We tried few times to enable ADFS and change auth type from Managed to Federated, but after that users cant log in our app.
If they click "log in" in our application it opens URL like:
https://login.windows.net/common/oauth2/authorize?response_type=code&client_id=...&resource=https://outlook.office365.com/
When they try to sign in there they get error:
"User account ... from external identity provider ... is not supported for application ..."
AND!
If they sign in first in ADFS and after that sign in application - everything is ok.
So, what should we do to rnable ADFS and use API applications?
Sorry for bad description and bad english.
Related
We have a Web App secured with Azure AD B2C using custom Identity Experience Framework policies to allow users to register and sign in with social identities (Microsoft, Google, Facebook), or with an identity from another federated Azure AD instance, or with 'local' Email / Password accounts.
All the social accounts and the Federated AD work correctly. Sign up and sign in with Email/Password was working correctly, but we are now experiencing an error. We haven't knowingly made any changes to our Email/Password configuration since this was last known to be working, so we're not sure how this has happened.
The issue is: Sign Up with a new Email Address works correctly, and after the process completes, the user is correctly logged-in, and their account appears in the directory. If the user signs out, however, then any attempt to sign back in again fails:
(Email address shown is not the actual one. Error has been repeated by multiple users with new and old email/password combinations.)
Digging into the portal, the underlying error is revealed as:
70001 The application named X was not found in the tenant named Y. 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 might have sent your authentication request to the wrong tenant.
This error appears sometimes to be related to a failure to grant permissions to an application in the portal. We have tried removing and reinstating all permissions, and re-granting permissions. This has not solved the issue.
Does anyone know what could be causing this issue, and in particular why sign up / sign in works correctly, but returning sign in does not?
UPDATE:
Just to confirm that we have the IEF and Proxy IEF apps configured in the AD directory:
And we have the login-NonInteractive technical profile configured in TrustFrameworkExtensions.xml:
Having wired up Application Insights (following these instructions https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-troubleshoot-custom), we're able to get to this more detailed error:
AADSTS70001: Application with identifier
'ProxyIdentityExperienceFrameworkAppID' was not found in the directory
weapageengine.onmicrosoft.com
The only place 'ProxyIdentityExperienceFrameworkAppID' appears in any of our custom policies is shown in the XML snipped above, but this seems correct as per the documentation here: https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack/blob/3b4898fec3bf0014b320beffa6eb52ad68eb6111/SocialAndLocalAccounts/TrustFrameworkExtensions.xml#L38 - unless we are meant to update those 'DefaultValue' attributes as well?
Resolution:
As per the answer below, it is necessary to update both the Metadata and the default values with the relevant app ids. Worth noting that in the GitHub sample https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack/blob/3b4898fec3bf0014b320beffa6eb52ad68eb6111/SocialAndLocalAccounts/TrustFrameworkExtensions.xml#L38 the boilerplate values are differently cased, leading to our missing one in a replace-all:
The local account sign-in authenticates the end user against the Azure AD B2C directory and then reads the user object from it.
The local account sign-up and the social account sign-in do not authenticate the end user against the Azure AD B2C directory. The local account sign-up writes the user object to it. The social account sign-in delegates authentication to the social identity provider and then either writes the user object to the Azure AD B2C directory if the user object does not exist or reads the user object from the Azure AD B2C directory if the user object does exist.
To enable authentication of the end user by the local account sign-in against the Azure AD B2C directory, you must add the Identity Experience Framework applications to the Azure AD B2C directory and then configure these IEF applications with the login-NonInteractive technical profile.
The local account sign-up and the social account sign-in do not require these applications.
I am facing a hopefully simple problem:
I need to create a wrapper app that contains a WebViewer control and should display a page in Azure portal.
I am developing the app in VS 2017 on a virtual machine which belongs to the domain 'DEV'. I would like to achieve that if a user from 'PROD' domain starts the app on their computer in the 'PROD' domain, they will be authenticated to AAD/Office 365 via SSO and can view the page in Azure (not a site in azurewebsites.net, but a site that needs you to be authenticated - i.e. portal.azure.com!).
I was not yet able to test the app on 'PROD' domain, but according to the answer below it would work, wouldn't it?
https://stackoverflow.com/a/9593258
If not can I go through the steps in the white paper mentioned and SSO the user manually (chapter 5.3, I assume)?
EDIT
Took me while, but here it is - I got SSO working, sort of...
In the end it seems that using a WebViewer control allows SSO but it still requires you to at least once enter your user name (user#tenant.com, for example) but you don't need a password. This might not be an optimal solution, nevertheless it is OK.
Thank you Wayne Yang for your support.
For your sceanrio, the user can SSO in PROD domain if the device has AAD joined.
But this should SSO to the joined AAD tenant. I also assume that you want to SSO to Azure portal with the ADFS. So, it also needs integrate ADFS with the AAD.
Why?
First, if your application try to sign in Azure portal via pop-up a broswer, and it needs SSO. AAD join can achieve this. If a device joined AAD, it will obtain a refresh token to your device. For windows 10 , IE and Edge can use the refresh token to SSO AAD endpoint.
Second, If you want to use ADFS, you must integrate ADFS with Azure AD. In this way, AAD authentication endpoint will redirect to your ADFS to approach SSO with your local domain.
Reference:
How to configure hybrid Azure Active Directory joined devices
Federate multiple instances of Azure AD with single instance of AD FS
Azure AD Connect and federation
Hope this helps!
iam currently researching how to implement Single Sign On for our WebService.
This is what i came up with so far.
If a customer of our WebService has an AzureActiveDirectory they can log on with their active directory user account to our WebService if we provide the nessecary interfaces for SAML, Oauth2, OpenID or whatever authorization protocoll we chose and azure supports.
The customers could also have their local network Active Directory synced to their Azure AD and use their Domain accounts to log on to our WebApplication.
Customers need to use the myapps.microsoft.com portal to "wrap" authentication.
Once everything is set up correctly the Identity Provider (AzureAD) would provide use with (e.g) an authenticated User Identity.
Here is were my problem begins.
Of course i need to somehow map the identity provided by the AzureAD to a certain Account for our WebService - we cannot simply use the provided identity.
As far as i understand it, you can grant AzureAD the right to create an Account on the target WebService in the name of the user which is currently signing in.
(Its called : enabling automatic user provisioning in the azure management portal).
However, when testing this with the Box, Canvas or Google apps i failed. Either i got an error or in the case of google apps i was just promted to login with my azure AD test account and then asked for a password and username of my google account (i set up SSO as an azure AD trust relation- so this should not happen)
Can someone provide some insights on how to accomplish the following?
Once the user is authenticated by SSO I want to create an account for our WebSerivce and then save the credentials for that user only in the Active directory of that particular user.
So if the user logs in the second time we can check wether there is an account already existing and log in the user with this account.
(I was told by microsoft that this might be possible with Azure Rights Management, but i cannot really find good documentation on that)
Storing the relationship: "Microsoft AD Identity <-> our WebServiceAccount Credentials" on our side is not desired because we cannot securly encrypt the data in a way that we DONT know whats in there. (or there is , and i dont know of it yet)
"Bonus Question":
Can i support SSO for a desktop application too? (Do i need a provide proxy web application or can the desktop app do this directly?)
Please see my answer to a similar question here: asp.net azure active directory user profile data
However - I'm trying to understand if you need something different. Are you expecting your customers to already have a directory and Azure AD accounts (maybe through having Office 365 subscriptions), and use those to sign in to your web app, or does your app scenario require creation/provisioning of user accounts into your customer's Azure AD directory? Provisioning can be done through graph API (as per your link), as long as the admin of your customer grants consent to allow your app to write to their directory. You can find some samples on github, and I recommend you look through https://msdn.microsoft.com/en-us/library/azure/dn499820.aspx and https://msdn.microsoft.com/en-us/library/azure/dn646737.aspx for code samples.
HTHs,
I think, without testing it. That using the Graph API enables me to save custom data for any Directory User effectively enabling my desired functionality.
This is the documentation i found very usefull.
https://msdn.microsoft.com/en-us/library/hh974476.aspx
I am developing a web application with Windows Azure Active Directory (WAAD) authentication support. In WAAD I added a user which already has a Microsoft Account.
I use SAML 2.0 protocol for authentication request.
In my app upon accessing a protected resource, I redirect the user to:
https://login.windows.net/<id>/saml2/SAMLRequest=...&RelayState=...
This is URL I copied from the WAAD management console:
The decoded SAML token looks like:
<samlp:AuthnRequest ForceAuthn="false"
ID="b6f579bb-c7fc-49b1-a8f1-bbe2ad99da5d"
IsPassive="false"
IssueInstant="2014-07-25T06:38:11.303Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Version="2.0"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol">
<saml2p:Issuer>....onMicrosoft.com</samlp:Issuer>
<saml2p:NameIDPolicy AllowCreate="true"/>
<saml2p:RequestedAuthnContext Comparison="exact">
<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>
</saml2p:RequestedAuthnContext>
This is working great, I am redirected to
https://login.microsoftonline.com/...
https://login.live.com/...
However, upon autheticating with a Microsoft Account user (which is also imported into WAAD), I get this error message:
ACS20031: Sign-in with LiveId is not supported for this application.
What am I missing?
On the WAAD web admin console I did not see such a setting. I tried both Single Tenant / Multitenant options
Is there a possibility to login with a simple WAAD user (not LiveId) with foobar#<tenantid>.onmicrosoft.com ?
To my knowledge no.
Up to today, the only way to get users signed-in with Live ID to your Application are the following:
Use Azure Active Directory Access Control Service (or better known as ACS)
Use the LiveID Web Authentication SDK
Use the Azure Active Directory with a remark. The remark is:
** You can only use LiveID to sign-in with Azure Active directory, if you first provisioned that user in your directory tenant. Provisioning happens when you create a new user in your Azure Active Directory Tenant and in the process of adding, add it as a LiveID e-mail. Then you will have this user in your AAD but marked as "Sourced From" -> "Microsoft Account":
The type of federation you are trying to enforce currently only works for Microsoft Internal applications, and not for customers. The only federation service that currently works for Customers is the Access Control Service.
Here you can read a bit about the future of ACS and the plans to merge these federation capabilities into next versions of AAD. But we still haven't got to that future.
I'm customizing an ACS home realm discovery page and want to accommodate users who have either a "microsoft account" (aka LiveID/Passport) or a Office365/Azure Active Directory account.
In this situation, it's possible for the following workflow to happen (as far as I understand it)
User logs in using ACS custom page
User selects "Microsoft Account"
User types in their company / corporate ID
The HRD process at http://portal.microsoftonline.com redirects them to their ADFS server
Their ADFS server redirects them to their company.
Once sign-in passes (or fails) the login would cascade back to the ACS page.
What is the most efficient way (for the end user) to integrate Azure ACS, with Azure Active Directory / Office 365, with a custom HRD page that I create?
Or more plainly, is there a JSON web service that I can query to determine if a given domain or account exists within the "Microsoft Account/LiveID" world, and also check AzureAD for the same thing.
You cannot treat "microsoft accounts" (Windows Live ID / Outlook.com / hotmail / xbox /etc) the same as WAAD accounts when using ACS. When you set up your identity providers in ACS you will need to enable a Windows Live IDP and one IDP for each WAAD instance you are going to allow users to authenticate with. One thing that is not clear to me from your question is if you are needing for you users to be able to authenticate against a single WAAD tenant or from multiple. If one then you only need to configure one WAAD tenant in ACS. If you need to allow users to authenticate against multiple WAAD tenants then you will need to set up and IDP for each in ACS. For example if your web app is a SAAS application with users from companies "Contoso" and "Northwind" and you want them to be able to authenticate against their company's on-premise active directory then you will need two WAAD tenants setup. Each WAAD tenant will need to have federation configured with their given on-premise active directory. Each WAAD tenant in turn would need to be configured in ACS as an IDP. You could name those IDPs distinctly in ACS something like "Contoso WAAD" and "Northwind WAAD". Then in your custom implementation of the HRD page you can either just list all the IDPs and let the user choose, or if you want to be fancier you could parse the JSON results from the ACS endpoint that lists IDP and present them to the user (or just redirect them) based on some other selection they had made.