I attempted to implement the custom policy to allow phone authentication while setting up Azure ADb2c for my application and tried to follow the instructions present here - https://learn.microsoft.com/en-us/azure/active-directory-b2c/phone-authentication
I completed the prerequisites and believe I have everything setup correctly, but when i try to run the custom policy B2C_1A_SignUpOrSignInWithPhone, I receive a message to my phone number (based out of india) with the verification code, but when I enter the verification code into the browser, i receive an HTTP 400 with too many requests and I'm not sure why. How do I ensure that this feature will be functional if I implement it into my application. Has anyone else faced this issue ? (tried incognito as well)
SOLVED:
Looks like the file "Phone_Email_Base.xml" needed to be edited to include the tenant name in the two and tags. This was not mentioned in the tutorial and therefore took a bit of time to figure out why. I will be forwarding this to microsoft so that they can fix in their documentation.
Related
I am struggling to create and configure an Azure Enterprise Application.
I have been trying to accomplish this task via PowerShell. I attempted to create an enterprise application by making use of the tags an application registration can have by following this github post, which essentially boils down to adding this tag to the service principal:
$tags = #("WindowsAzureActiveDirectoryIntegratedApp")
From there, I seem to be having problems with adding an identifier uri to the application. Here is the error:
Values of identifierUris property must use a verified domain of the organization or its subdomain
This error does occur to me whether I try this using PowerShell or Terraform.
I think it might be possible to resolve this error by adding the url as a custom domain, but the weird thing is that this url is used by the enterprise application that is setup manually, so I'm a little confused by this error and think the problem might be more than just adding the url as a custom domain.
I would like to note that at this point if I remove the identifierUris the application registration and service principal are both created, but if I were to go to SAML section of the service principal, there does not seem to be a way to manually upload a SAML metadata file (via PowerShell only - it does work in Terraform, interestingly enough).
This brings me to the other issue that I face for configuration: SSO configuration, specifically via SAML. I would like to programmatically upload a SAML metadata file and then modify some of the fields in the SAML section of the service principal from the result of that upload. However, I have been unable to find a way to do this or find an equivalent workaround.
EDIT: Turns out you can upload a token certificate to the service principal via Terraform - for more info on the command see here. You will need to transform your data into an accepted value format (I would recommend .pem if you are coming from a .xml file). I am not 100% sure if this command works yet, as I am left with this message under the SAML Certificates section:
**Token signing certificate**
A certificate has been successfully created. Please reload the page to make it active.
And reload doesn't seem to be working yet...
Issues still left to address:
Identifier uri (previously mentioned)
How to edit the Attributes & Claims fields
EDIT 2:
So I was able to uncover this resource, which offers a step by step guide for automating away SAML-based single sign-on via MS Graph.
Still testing it - and there are some parts that can only be done on Windows (creating a custom certificate) - but this seems very helpful.
Based on my early testing, the only problem I have found with this method so far tis that might not edit the Attributes and Claims section of SAML SSO. However, I believe by creating your own application template this method solves the identifier issue I was running into.
So, the MsGraph tutorial largely covers most of what I needed for my usecase. A few things of difference that I would note:
I used a template application that suited my needs better*.
Attributes and claims are fixed by following the tutorials points on creating and assigning a claims mapping policy. You will not be able to see this through the GUI. Additionally, getting the updated service principal also does not display this configuration**.
If you have difficulty updating your logoutUrl I would see this github post - you can configure it via az rest, PATCH, and this endpoint: "https://graph.microsoft.com/v1.0/applications/$($app_id)".
Tying it all together is a little annoying via PowerShell as it seems that some of the commands take longer to process than others. As a result, I would recommend implementing some sort of retry into your script and even calling Start-Sleep so that future cmdlets recognize resources created by the ones that have already been called.
*Note the process of finding a template that works best for you can be a bit tricky if you do not already have one in mind. I ended up selecting the template that matched the enterprise application I was using when doing this process manually. I am unsure if every enterprise application available has a template that matches it.
**The only way to get a confirmation that a new claims mapping policy worked is to see this message (under the Edit section of Attributes & Claims, which is in the SSO section of the service principal): "This configuration was overwritten by a claims mapping policy created via Graph/PowerShell. Learn More.".
I am trying to use sendgrid on azure, but when I am creating the account, it gives me an error saying:
The portal is having issues getting an authentication token. The experience rendered may be degraded.
Additional information from the call to get a token:
Extension: SendGrid_EmailService
Details: code: 500, statusText: error, message: There was an error processing your request. Please try again in a few moments., stack:
It has been giving me this since morning, pretty annoyed. And also it disables two fields, and marks them as loading:
Screenshot of the two fields marked as loading (For a very long time)
Since sendgrid wasnt working I thought I'd try and use SparkPost- The signup was successful, but its been taking hours to deploy.
Then I thought of manually configuring the smtp settings so the host and user and stuff could be sendgrid, but I wasnt able to find a way to do so.
Could someone help me out please! Thanks in advance!!
EDIT: This problem has been solved by the Microsoft Team.
Looks like SendGrid has some technical problems. You should check first SendGrid official support website if this is the issue. I was using SendGrid for a while, but I had to move to another solution. When you are registering SendGrid account via Azure you getting standard SendGrid plan. That means that you are sending your mails through shared SendGrid IPs. This is probably ok for marketing emails, but if you intend to send any transactional emails like password reset, bills etc you will end up eventually with tearing your hair off the head, because shared SendGrid IPs are in most existing spam blacklists out there.
SendGrid app status
I was able to enter to SendGrid using the following steps from Aaryaman Maheshwari in this comment:
Steps from Aaryaman's answer:
Step 1: In order to find ur username for SendGrid, first, go to the
SendGrid resource and then click properties. Now copy the resource id.
Step 2: Now, in the azure online shell, open bash and type the
following command: az resource show --ids [THE COPIED RESOURCE ID]
Make sure to replace [THE COPIED RESOURCE ID] with the resource Id you
copied in step 1
Step 3: In the json string that the terminal outputs, look for the
username property and note that down
Step 4: After you do that you can manually go to sendgrid.com and then
enter the username you just retrieved and then the password which you
used to sign up with.
Thanks Aaryaman Maheshwari
In order to incresase security, Sendgrid has recently requested to enable 2 factors authentication to connect to your account (it started one or two weeks ago).
Since this moment, the "automatic" connection from Azure to Sendgrid stopped to succes, and we have the same 500 error.
Also, "basic authentication" (username / password) will stop to work (starting from 10 decemeber I believe) in your api.
I'm not sure this is the reason, but it happens at the same time ;)
Just to update:
There was bug identified on Azure Portal and our product engineering team have fixed the issue.
Provisioning SendGrid account via https://portal.azure.com/ and managing works as expected.
The alternate https://rc.portal.azure.com/ URL was shared during the impact and is no longer required to be used.
We had a discussion on Q&A thread. Once again apologies for all the inconvenience. Much appreciate the follow-up and great collaboration.
I have several days trying to customize the email verification of my project but it's been impossible to change anything.
I followed many times:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/custom-policy-get-started
https://learn.microsoft.com/en-us/azure/active-directory-b2c/custom-email-sendgrid
https://learn.microsoft.com/en-us/azure/active-directory-b2c/custom-email-mailjet
I uploaded the new custom policies B2C_1A_TrustFrameworkBase and B2C_1A_TrustFrameworkExtensions with all the changes described in the manual, but I still don't know why I can't even generate an application error and the default Microsoft email verification keeps working normally, is there any way to track what I might be missing?
You can refer to the troubleshoot documentation about turning the B2C engine into developer mode and tracking the B2C engine itself.
There is a separate documentation and technical profiles explaining how to use application insights to track user behavior during user journeys. You can discover more about this here: https://learn.microsoft.com/en-us/azure/active-directory-b2c/analytics-with-application-insights
I have created three B2C applications:
TestWebApp
TestApiOne
TestApiTwo
Both API applications were created the exact same way. Web API access is enabled, reply URLs have been specified, an App ID URL has been assigned, and keys have been generated. Both APIs have an additional read and write scope.
In TestWebApp API access, I am able to add TestApiOne with all three scopes without an issue.
When trying to add TestApiTwo to the TestWebApp API access list, the operation fails with the following error.
Failed to add the API access. Reason: The B2C service has an internal
error. If you created this B2C directory just now, please try again
after couple of minutes. If the problem persists, please contact
Support
(https://azure.microsoft.com/en-us/documentation/articles/active-directory-b2c-support/).
If you do not have a B2C directory you can refer
https://azure.microsoft.com/en-us/documentation/articles/active-directory-b2c-get-started/
I thought maybe there is a limit of one API per application. To test, I created a temporary application "TempApp". I received the same error displayed above while trying to add API access for both TestApiOne and TestApiTwo.
Has anyone else experienced this issue?
There's not a limit of one API per application. I have done research and it works fine by my side.
Please have a look at the guide and check your steps.
I have tried to replicate the issues that you are facing by putting diff redirect reply url domains and also by making one application to be native and one normal web app but it doesn't help.
Could you try to delete all the webapps and try making 1 and then adding another to it.
Then create the 3rd one.
Please check this or if you can share some screen shots. That would be helpful.
You can definitely add multiple web apps to api access of one web app.
I am trying out the Azure AD-B2C. The user signup/sign in is fine when the MFA is turned off. But when I turn it on, and the user tries to sign in and provides the phone number, and requests a text message by clicking "send code", I get the Http 400 error: size of request headers is too long. Anybody else have this issue?
The error HTTP 400: Size of header request is too long generally happens because there's too many cookies.
Azure AD B2C's login goes through login.microsoftonline.com, as does almost every Microsoft service (O365, Azure, etc). So if you've got several accounts that you've signed in to across these services, you're accumulating cookies that will cause this problem.
Clearing the cookies should resolve this problem. If this is happening on a recurring basis, you should edit your question to include details about the request and cookies in order to best figure out what's bloating the request and how to reduce it.
Short answer: The file with the custom UI was not found by Microsoft login service. After getting shipped around it resulted in the error.
I had the same error with AAD B2C but "cookies" was not the problem. In my case I got the error while testing in the Azure B2C portal checking the policies and the custom UI pages. We use Azure Blob storage to hold custom login setup, its fast and it scales without our attention. The problem was found by using my test website using the B2C service. I put a stop/break on the Account controller's "public Task OnRemoteFailure(RemoteFailureContext context)" method. The debugger message gave me the full context of the error, an http 404 error and it gave the file name it was trying to find. Blob storage is case sensitive. The setup configuration used to configure B2C has camelCase names. The group who created the actual UI customization uses all lower case names. It took someone with access to all the assets to find the simple case name issue. Errors in distributed systems can be difficult.