P2P Server app in Azure Portal
HI Everyone, Does any one has any idea about P2P Server app in azure portal? I just noticed this app in App registration. Should i delete it as it looks supecious. look at scopes of this app? How can i analyze this app what this app has been doing ? should i delete it?
AADSTS50011: The reply URL specified in the request doesn't match registered the reply URLs
Is this a common occurrence; does anyone know how to get around this issue? "AADSTS50011: The reply URL specified in the request does not match the reply URLs configured for the application: 'my application client id'. " I've followed the directions explicitly in these two documents, and reviewed others to see if I was missing anything. Reviewing responses to others' issues with the same problem did not resolve the failed auth issue. https://docs.microsoft.com/en-us/azure/app-service/configure-authentication-provider-aad https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-configure-app-access-web-apis#add-redirect-uris-to-your-application I have an Azure Web App that has been registered. I can go to Azure Portal Home >> App registrations >> My App >> Endpoints, add all of the OAuth endpoints under the Redirect URIs and still cannot get fully logged in. I tried the <app-url>/.auth/login/aad/callback redirect format from one of the above articles with no success. I've tried https://myapplicationname.azurewebsites.net/.auth/login/aad/callback, https://login.microsoftonline.com/mytenantid/oauth2/v2.0/authorize (as well as the three other endpoints with this format), https://login.microsoftonline.com/common/oauth2/v2.0/authorize (same with other three endpoints), etc. When I run in debug on my localhost:44321/ the web app launches, prompts for authentication, and is successful each time, however, always fails with the same subject error any time I deploy the build to Azure. My localhost addresses are listed in the Redirect URIs, so that makes sense the local deployment is successful but I cannot figure out why the deployed web app always fails when it goes live. I've tried everything that I could possibly think of with different combinations, but no luck getting past the auth error so any insights would be greatly appreciated.
How to host moodle on azure
Hello everyone, I am here for help, I am an IT specialist my employer asked me to host a Moodle LMS on azure to be accessible for our program, I have no idea how to do it because I don't have experience on hosting websites and Azure as well. I am willing to learn about azure and how to use to make Moodle available to our benfieries. could you please give me a detailed guideline about that? I am having a free azure subscription right now but I will purchase other packages later once I got a clear idea how to use it. I am looking for your kind answers. Thanks, BarzanWith custom security attributes and conditional access, enforce MFA for web apps!
Dear Microsoft Azure Friends, The use of multifactor authentication (MFA) has become indispensable in today's world. With the help of conditional policies (CA), we can set up MFA in a very targeted manner. But what about when a new web app is set up and deployed? Does it now need a new CA every time? In this article I will show you the custom security attributes with an example where exactly this scenario is addressed. But what exactly are custom security attributes? From Microsoft Documenation: "Custom security attributes in Azure Active Directory (Azure AD) are business-specific attributes (key- value pairs) that you can define and assign to Azure AD objects. These attributes can be used to store information, categorize objects, or enforce fine-grained access control over specific Azure resources." What are custom security attributes in Azure AD? (Preview) https://learn.microsoft.com/en-us/azure/active-directory/fundamentals/custom-security-attributes-overview However, before you can work with or create custom security attributes, you need the necessary permissions. You can find all the necessary information in the above mentioned article. At this point it is worth mentioning that not even a "Global Admin" by default has the right to create the attributes. The ingenious thing is that the roles are divided. One person can create the attributes, another person does the assignment. Now we navigate to Azure Active Directory to the custom security attributes. Here you can create an attribute set and specify the key values. Then, in Enterprise Applications, find your app and assign the custom security attributes. Now we can create the conditional access policy. After you have selected the name, you can now select for whom the policy should apply. I have used a group named "Bitcoin" for this example. This group includes the Tina Muff. Now comes the exciting part. In "Cloud apps or actions", we do not select a specific app in "include" but use the filter function. This function is on the preview and first you need to set the switch to configured. After that you can select your custom security attributes. At this point, use exactly the same key value pair that you selected for your enterprise app. Next, you can define how the access should take place at "Access controls". I have selected that access is allowed but only with multifactor authentication. Now when Tina Muff calls the WebApp, she will be prompted to apply MFA (this account is a test account, so the MFA setup has not been done). Sorry it's in german ;-). So what's the point of all this effort? If you now continue to set up and provide WebApps in the future. You simply have to assign your custom security attributes to the WebApp again with the corresponding key value pair, and you already have to work with MFA when you call the app because the CA is already present. I realize that this was not necessarily spectacular. It was simply important for me to share my experience with you. Nevertheless, I hope that this article was helpful. Thank you for taking the time to read the article. Best regards, Tom Wechsler P.S. All scripts (#PowerShell, Azure CLI, #Terraform, #ARM) that I use can be found on github! https://github.com/tomwechslerBest Practices for API Error Handling: A Comprehensive Guide
APIs (Application Programming Interfaces) play a critical role in modern software development, allowing different systems to communicate and interact with each other. However, working with APIs comes with its challenges, one of the most crucial being error handling. When an API encounters an issue, it's essential to handle errors gracefully to maintain system reliability and ensure a good user experience. In this article, we'll discuss best practices for API error handling that can help developers manage errors effectively. Why is API Error Handling Important? API error handling is crucial for several reasons: Maintaining System Reliability: Errors are inevitable in any system. Proper error handling ensures that when errors occur, they are handled in a way that prevents them from cascading and causing further issues. Enhancing User Experience: Clear, informative error messages can help users understand what went wrong and how to resolve the issue, improving overall user satisfaction. Security: Proper error handling helps prevent sensitive information from being exposed in error messages, reducing the risk of security breaches. Debugging and Monitoring: Effective error handling makes it easier to identify and debug issues, leading to quicker resolutions and improved system performance. Best Practices for API Error Handling 1. Use Standard HTTP Status Codes HTTP status codes provide a standard way to communicate the outcome of an API request. Use status codes such as 200 (OK), 400 (Bad Request), 404 (Not Found), and 500 (Internal Server Error) to indicate the result of the request. Choosing the right status code helps clients understand the nature of the error without parsing the response body. 2. Provide Descriptive Error Messages Along with HTTP status codes, include descriptive error messages in your API responses. Error messages should be clear, concise, and provide actionable information to help users understand the problem and how to fix it. Avoid technical jargon and use language that is understandable to your target audience. 3. Use Consistent Error Response Formats Maintain a consistent format for your error responses across all endpoints. This makes it easier for clients to parse and handle errors consistently. A typical error response may include fields like status, error, message, code, and details, providing a structured way to convey error information. 4. Avoid Exposing Sensitive Information Ensure that error messages do not expose sensitive information such as database details, API keys, or user credentials. Use generic error messages that do not reveal internal system details to potential attackers. 5. Implement Retry Logic for Transient Errors For errors that are likely to be transient, such as network timeouts or service disruptions, consider implementing retry logic on the client side. However, retries should be implemented judiciously to avoid overwhelming the server with repeated requests. 6. Document Common Errors Provide comprehensive documentation that includes common error codes, messages, and their meanings. This helps developers quickly identify and troubleshoot common issues without needing to contact support. 7. Use Logging and Monitoring Implement logging and monitoring to track API errors and performance metrics. Logging helps you understand the root cause of errors, while monitoring allows you to proactively identify and address issues before they impact users. 8. Handle Rate Limiting and Throttling Implement rate limiting and throttling to protect your API from abuse and ensure fair usage. Return appropriate error codes (e.g., 429 - Too Many Requests) when rate limits are exceeded, and provide guidance on how users can adjust their requests to comply with rate limits. 9. Provide Support for Localization If your API serves a global audience, consider providing support for localization in your error messages. This allows users to receive error messages in their preferred language, improving the user experience for non-English speakers. 10. Test Error Handling Finally, thoroughly test your API's error handling capabilities to ensure they work as expected. Test various scenarios, including valid requests, invalid requests, and edge cases, to identify and address potential issues. Conclusion Effective error handling is essential for building reliable and user-friendly APIs. By following these best practices, you can ensure that your API handles errors gracefully, provides meaningful feedback to users, and maintains high availability and security. Implementing robust error handling practices will not only improve the reliability of your API but also enhance the overall user experience.Protecting your Identities from attacks like consent phishing
Hi Cloud Friends, Today, developers build apps by integrating user and enterprise data from cloud platforms to enhance and personalize experiences. These cloud platforms are rich in data, but in turn have attracted malicious actors who attempt to gain unauthorized access to that data. One such attack is consent phishing, in which attackers trick users into granting a malicious app access to sensitive data or other resources. Instead of trying to steal the user's password, an attacker asks for permission for an app controlled by the attacker to access valuable data. These apps are often named to mimic legit apps, such as “0365 Access” or “Newsletter App”. Here is one way to counteract these attacks. 1. Restricting users from registering new apps to Azure AD: 2. Preventing the users for giving consents to apps: When you make these settings you need to know that as an administrator you will have to make the apps available to the users. So this means that you as an administrator will have more work. As an administrator for the respective app (enterprise application), you should configure the consent for the necessary permissions on behalf of the user. But really do not flip the "big switch" that all users can give consent of permissions for ALL apps. Enormously important is also the training for the users. In many cases, such apps are not described correctly, or the spelling is wrong. Training your users regularly is another way to counter these attacks. I hope this article was useful. Best regards, Tom Wechsler
Cannot add Apple Business Manager from Azure AD admin center
I cannot add Apple Business Manager from Azure AD admin center > Enterprise applications. I can find the app, but if I clicks on it, there is only the button "Sign up for Apple Business Manager". After clicking on it, there is a site from Apple and I cannot add the app there. The prerequisites from the article below are fulfilled: Tutorial: Configure Apple Business Manager for automatic user provisioning with Azure Active Directory | Microsoft DocsConnect an Azure App (with an Connection String) to an Azure Storage Account (with the PowerShell)!
Hi Azure friends, I used the PowerShell ISE for this configuration. But you are also very welcome to use Visual Studio Code, just as you wish. Please start with the following steps to begin the deployment (the Hashtags are comments): #The first two lines have nothing to do with the configuration, but make some space below in the blue part of the ISE Set-Location C:\Temp Clear-Host #So that you can carry out the configuration, you need the necessary cmdlets, these are contained in the module Az (is the higher-level module from a number of submodules) Install-Module -Name Az -Force -AllowClobber -Verbose #Log into Azure Connect-AzAccount #Select the correct subscription Get-AzContext Get-AzSubscription Get-AzSubscription -SubscriptionName "your subscription name" | Select-AzSubscription # Generates a Random Value $Random=(New-Guid).ToString().Substring(0,8) # Variables $ResourceGroup="MyResourceGroup$Random" $AppName="webappwithStorage$Random" $StorageName="webappstorage$Random" $Location="WestEurope" # Create a Resource Group New-AzResourceGroup -Name $ResourceGroup -Location $Location # Create an App Service Plan New-AzAppservicePlan -Name WebAppwithStoragePlan -ResourceGroupName $ResourceGroup -Location $Location -Tier Basic # Create a Web App in the App Service Plan New-AzWebApp -Name $AppName -ResourceGroupName $ResourceGroup -Location $Location -AppServicePlan WebAppwithStoragePlan # Create Storage Account New-AzStorageAccount -Name $StorageName -ResourceGroupName $ResourceGroup -Location $Location -SkuName Standard_LRS # Get Connection String for Storage Account $StorageKey=(Get-AzStorageAccountKey -ResourceGroupName $ResourceGroup -Name $StorageName).Value[0] # Assign Connection String to App Setting Set-AzWebApp -ConnectionStrings @{ MyStorageConnStr = @{ Type="Custom"; Value="DefaultEndpointsProtocol=https;AccountName=$StorageName;AccountKey=$StorageKey;" } } -Name $AppName -ResourceGroupName $ResourceGroup #Check the result in the portal Now you have used the PowerShell to create an Azure Storage Account and an Azure App (with an connection string)! Congratulations! #Delete all resources (when you no longer need it) Remove-AzResourceGroup -Name myResourceGroup -Force I hope this article was useful. Best regards, Tom Wechsler P.S. All scripts (#PowerShell, Azure CLI, #Terraform, #ARM) that I use can be found on github! https://github.com/tomwechslerUsing PowerShell in Azure Active Directory to inspect App Service Principals!
Hi Azure friends, In this article I would like to share with you some experiences I have made with Azure Active Directory App Service Principals. Really nothing spectacular but I didn't want to keep it from you. I used the PowerShell ISE for this configuration. But you are also very welcome to use Visual Studio Code, just as you wish. Please start with the following steps to begin the deployment (the Hashtags are comments): #The first two lines have nothing to do with the configuration, but make some space below in the blue part of the ISE Set-Location C:\Temp Clear-Host #We need the cmdlets Install-Module -Name AzureAD -AllowClobber -Force -Verbose #Sometimes the module must be imported Import-Module AzureAD #Lets connect to the Azure Active Directory Connect-AzureAD #Get a List of the apps Get-AzureADApplication #A bit more info Get-AzureADApplication -Filter "DisplayName eq 'twdemoapp'" | Format-List * #Let's create a variable $sp = Get-AzureADServicePrincipal -Filter "displayName eq 'twdemoapp'" $sp.ObjectId #Azure AD App role assignments using objectId of the Service Principal $assignments = Get-AzureADServiceAppRoleAssignment -ObjectId $sp.ObjectId -All $true #Remove all users and groups assigned to the application $assignments | ForEach-Object { if ($_.PrincipalType -eq "User") { Remove-AzureADUserAppRoleAssignment -ObjectId $_.PrincipalId -AppRoleAssignmentId $_.ObjectId } elseif ($_.PrincipalType -eq "Group") { Remove-AzureADGroupAppRoleAssignment -ObjectId $_.PrincipalId -AppRoleAssignmentId $_.ObjectId } } #Get Azure AD App role assignments again $assignments = Get-AzureADServiceAppRoleAssignment -ObjectId $sp.ObjectId -All $true | Where-Object {$_.PrincipalType -eq "User"} #Let's check $assignments #Delegated permissions for the service principal $spOAuth2PermissionsGrants = Get-AzureADOAuth2PermissionGrant -All $true| Where-Object { $_.clientId -eq $sp.ObjectId } #Remove all delegated permissions $spOAuth2PermissionsGrants | ForEach-Object { Remove-AzureADOAuth2PermissionGrant -ObjectId $_.ObjectId } #All delegated permissions again $spOAuth2PermissionsGrants = Get-AzureADOAuth2PermissionGrant -All $true| Where-Object { $_.clientId -eq $sp.ObjectId } #Let's check $spOAuth2PermissionsGrants #Application permissions for the service principal $spApplicationPermissions = Get-AzureADServiceAppRoleAssignedTo -ObjectId $sp.ObjectId -All $true | Where-Object { $_.PrincipalType -eq "ServicePrincipal" } #Remove all delegated permissions $spApplicationPermissions | ForEach-Object { Remove-AzureADServiceAppRoleAssignment -ObjectId $_.PrincipalId -AppRoleAssignmentId $_.objectId } #Application permissions again $spApplicationPermissions = Get-AzureADServiceAppRoleAssignedTo -ObjectId $sp.ObjectId -All $true | Where-Object { $_.PrincipalType -eq "ServicePrincipal" } #Let's check $spApplicationPermissions These were a few tasks using PowerShell in Azure Active Directory! I hope this article was useful. Best regards, Tom Wechsler P.S. All scripts (#PowerShell, Azure CLI, #Terraform, #ARM) that I use can be found on github! https://github.com/tomwechsler
