I'm working on automating the creation of an Azure AD B2C tenant in Terraform, I can get many parts of it set up in Terraform but some parts I realize I can't, specifically Identity Experience Framework Custom Policies. I decided I would use PowerShell to upload these XML documents. I see that AzureAD is being deprecated this year, so I shouldn't use that PowerShell Module. Microsoft says that we should be using MgGraph now instead of AzureAD, and references the conversion documentation to go from AzureAD to MgGraph. The problem is that the exact functionality I need does not seem to be in MgGraph, specifically functions referenced in this SO answer, Get-AzureADMSTrustFrameworkPolicy, Set-AzureADMSTrustFrameworkPolicy which is now obsolete. (Referencing the most recent answer).
QUESTION
So how do people automate the addition/removal of Custom Policies in Identity Experience Framework in a way that isn't going to be deprecated this year?
I really want to avoid needing to manually create these policies and the associated secrets. It seems like it should be straightforward to just upload a document and create a key, so hoping I'm just missing something obvious.
cmdlet mapping AzModule to MgGraph:
https://learn.microsoft.com/en-us/powershell/microsoftgraph/azuread-msoline-cmdlet-map?view=graph-powershell-1.0
MSGraph REST API Docu:
https://learn.microsoft.com/en-us/graph/api/overview?view=graph-rest-1.0
The API Calls for your specific need:
https://learn.microsoft.com/en-us/graph/api/resources/trustframeworkpolicy?view=graph-rest-beta
switch to beta api
select-mgprofile -name beta
cmdlet to interact with the API:
invoke-MgGraphRequest
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 realize this is probably a "noob" question but I am trying to follow this guide to enable our users to sign in to Microsoft Azure AD using their email address instead of their UPN.
Some background: Our org uses a UPN scheme that is different from a users email address. Our UPN's follow the format abc12d#organization.com while user's email is firstname.last#organization.com. This enables us to have unique UPN's no matter how big our org scales. I am new to Azure AD but I've managed to integrate most of our 3rd party systems with Azure.
The problem: I mapped the user email field as the UPN for one of our services (Apple Business Manager) and now when a user tries to sign in to their Apple ID, it tries to sign them into Azure with firstname.last#organization.com instead of Azure UPN abc12d#organization.com. Because we have not enabled Microsoft's Sign-in using email as an alternate ID feature, the sign in window tries to sign them into an account that doesn't exist.
What I've tried: I know the simple solution would be to just change the mapping in Apple Business Manager to use the users true UPN from Azure but most of our sign-in's now use the users email so I really don't want to create confusion. I have tried to follow the guide mentioned above, which I assume is referring to using PowerShell in Azure and not your on-prem AD DS service (but it does not specify). Every time I attempt to follow the guide, I get an error message on step 3 in PowerShell that says Get-AzureADPolicy: The term 'Get-AzureADPolicy' is not recognized as a name of a cmdlet, function, script file, or executable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
I have tried reading though various online forms but am yet to encounter anyone who is encountering this error for this specific use case. No other online documentation has helped me resolve the problem. In my mind, it is probably user error and limited experience with Azure and PowerShell cloud.
Any help would be greatly appreciated! I am happy to provide more information as needed.
Get-AzureADPolicy is under Azure Active Directory PowerShell 2.0-preview.
You need to install the preview release using:
Install-module AzureADPreview
Don't forget to import it:
Import-Module AzureADPreview
Note that you cannot install both the preview version and the GA version on the same computer at the same time.
Reference here. If it still doesn't work, running UnInstall-Module AzureAD before you install preview version may be helpful.
Can anyone help me clarify the benefit(s) (if any) of creating a SendGrid Account thru the Azure Portal as opposed to creating one thru SendGrid.com?
In other words, I’ve seen a few articles where they simply add the SendGrid Nuget Package, then create an account on SendGrid.com obtain an API Key and use it while creating a new SendGridClient(apiKey);
And then…I see a bunch of articles talking about having to create a SendGrid resource inside the Azure Portal. Once created, click Manage (which redirects you to the SendGrid.com website) to obtain an API Key and use it while creating a new SendGridClient(apiKey);
I agree that there are many ways to skin a cat, but I still don’t understand what’s the reason or benefit of creating a SendGrid Account resource in Azure (especially if all I really care about is an API key to be used within my SendGridClient).
What am I missing?
The only thing I can think of right now is if I plan on having a Logic App that will send emails, then I suppose I could use that SendGrid Account created thru Azure for that right?
Anyway...if anyone could help me understand why is there a need to create a SendGrid Account thru Azure that would be great!
Sincerely
Vince
The difference is mainly the benefits you get from the Martket Place one. There is a partnership with Microsoft which provides certain benefits to the end users. One of the highlight benefit is that,
As part of the initial sign up, we are including a free package with
25,000 free emails each month.
Following up another question, but from different point of view.
In AzureADPreview powershell module, there is a parameter -PreAuthorizedApplications for Set-AzureADApplication. But neither the cmdlet help nor the documentation page has been updated to detail all these, it was also mentioned here.
I was just wondering, that maybe someone happened to know how to use it and what's the syntax to set the list of preAuthorizedApplication resource type?
Summarize my comment：
The command Set-AzureADApplication essentially calls the Azure AD Graph API, but in Azure AD Graph API, the application object does not have the preAuthorizedApplications property, it is just existing in the Microsoft Graph API, which means the feature is not implemented.
Some information you should know:
The old Azure AD Graph API appears to have been abandoned, Microsoft is no longer updating this content of AAD Graph regularly. You can find it in this link.
So you will find this is contradictory to the new feature -preAuthorizedApplications in the AzureADPreview. A solution for this is to let the AzureAD PowerShell to call the Microsoft Graph, someone has posted this idea in the azure feedback, you could vote it.
https://feedback.azure.com/forums/169401-azure-active-directory/suggestions/35362639-update-azuread-powershell-module-to-use-microsoft
Where can I find a list of all supported Azure AD B2C Custom Policy Claims Transformation Methods?
I have searched Google, Bing, DuckDuckGo and GitHub for such list, but can't find it.
And TrustFrameworkPolicy_0.3.0.0.xsd schema doesn't contain it.
https://github.com/Azure-Samples/active-directory-b2c-advanced-policies/blob/master/Documentation/Features%20part%206.md - does have an outdated list - some of methods like AddParameterToStringCollection can't be used - policy can't be imported when I use it.
No such list exists at this time. You should request it via the Azure AD B2C feedback forum.
Your best bet is to go through all the starter packs and see which transformations are included in those. While there might be others, if they are not referenced in the starter packs or docs, they are unsupported and not recommended for broad use.
Update!
We have released a full documentation of the schema here:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/claimstransformations
All elements of custom policies for b2c, also known as Identity Experience Framework or IEF are published.