Showing posts with label Azure. Show all posts
Showing posts with label Azure. Show all posts

Saturday, January 6, 2024

Securing API Access to SharePoint Online: A Guide to Azure Application Registration and SharePoint App Creation

Gaining API access to a SharePoint environment is essential for developers looking to build applications that interact with SharePoint data. This can be achieved in two primary ways: through Azure Application registration or by creating an application directly in SharePoint. Each method has its own set of steps and considerations. In this blog, we will explore both methods and guide you through the process of setting up and securing API access to your SharePoint environment.

Method 1: Azure Application Registration

Azure Active Directory (Azure AD) offers a secure way for applications to access SharePoint through Azure Application registration. Here's how you can set it up:

  1. Navigate to Azure Portal: Start by going to the Azure portal and creating a new application registration. This will represent your application in the directory and will be the basis for its authentication and authorization processes.

  2. Configure Application Settings: Assign a name to your application and configure settings such as supported account types and redirect URIs. These settings will determine how your application interacts with users and other services.

  3. Set API Permissions: The most crucial step is setting the API permissions for your application. Navigate to the "API permissions" section and add permissions for SharePoint. For read-only access, you will typically add permissions such as Sites.Read.All or Files.Read.All. Ensure you understand the scope and implications of each permission you grant.

Method 2: Creating an Application in SharePoint

For those who prefer to work directly within the SharePoint environment, creating an application in SharePoint is a viable alternative. Here's how to do it:

  1. Access SharePoint Admin Center: Log into your SharePoint admin center and navigate to the 'appregnew.aspx' page (https://<main-site name> ). This is where you'll register your new application. This is needed only if the Azure AD APPlication is not created.

  1. Generate Client ID & Secret: Click on the "Generate" button to create a new client ID and secret. These credentials will be used to authenticate your application with SharePoint.

Once the Application is created through Method 1 or Method 2 next step is to provide right access to the same. 

Next step is granting permissions to the newly created principal. Since we're granting tenant scoped permissions this granting can only be done via the appinv.aspx page on the tenant administration site. You can reach this site via

Once the page is loaded add your client id and look up the created principal:

Set Permissions: Define the permissions your application will need by providing the permission XML. For full control permissions, you might use something like:

<AppPermissionRequests AllowAppOnlyPolicy="true"> <AppPermissionRequest Scope="http://sharepoint/content/tenant" Right="FullControl" /> </AppPermissionRequests>

When you click on Create you'll be presented with a permission consent dialog. Press Trust It to grant the permissions:

Best Practices and Considerations

  • Security: Regardless of the method you choose, security should be your top priority. Treat your client ID and secret as you would any sensitive credentials. Ensure that only authorized personnel have access to this information and that it's stored securely.

  • Permission Scope: Always adhere to the principle of least privilege. Grant only the permissions necessary for your application to function. Excessive permissions can pose a security risk.

  • Maintenance: Regularly review and update your application's settings and permissions to accommodate changes in your environment or application requirements.

  • Documentation: Both Microsoft's Azure documentation and SharePoint documentation are excellent resources. Refer to these regularly to stay updated on best practices and new features.

By following these steps and considerations, you can successfully set up API access to your SharePoint environment, whether through Azure Application registration or directly within SharePoint. Each method has its own benefits and the best choice depends on your specific needs and environment. Always prioritize security and stay informed on best practices to ensure a successful and safe integration.

Tuesday, April 11, 2023

Using Azure Lighthouse for Monitoring Other Tenant.

Azure Lighthouse is a service provided by Microsoft Azure that allows service providers to manage multiple customers’ Azure services from a single control plane. It provides a centralized portal to manage multiple Azure tenants, customers or subscriptions, giving the service provider a single view of all Azure resources across different customer environments. Azure Lighthouse provides several features including delegated resource management, multi-tenant management, and cross-tenant management, which help service providers to manage resources across their entire customer base in a secure and efficient manner. It simplifies and streamlines the management of Azure services, provides greater visibility into customers’ environments, and enables service providers to deliver better services to their customers.

In Short, we give access to a subscription or resource to a User/Group in another tenant with specific Roles. 

Sample ARM Template for adding a Customer account to Service Providers Lighthouse. 

"managedByTenantId": "a86bc255-XXXX-CCCC-VVVV-51fba84872aa"

Above is the Tenant ID of the Managed Services Provider. 


Above is the Name of the Offering.


Above is the Description of the Offering.

"principalId": "9d45cb5e-4682-4a4d-b54a-a89e3fa7bc84",

Above is the Object ID of the User or the Group we are selecting for this Offering.

"roleDefinitionId": "acdd72a7-3385-48ef-bd42-f606fba81ae7",

Above is the ID of the Role we are selecting.

"principalIdDisplayName": "Azure Reader Access"

Above is the Name of the Role we are selecting.

Sample ARM

"$schema": "",
"contentVersion": "",
"parameters": {
"mspOfferName": {
"type": "string",
"metadata": {
"description": "Specify a unique name for your offer"
"mspOfferDescription": {
"type": "string",
"metadata": {
"description": "Name of the Managed Service Provider offering"
"variables": {
"mspRegistrationName": "[guid(parameters('mspOfferName'))]",
"mspAssignmentName": "[guid(parameters('mspOfferName'))]",
"managedByTenantId": "a86bc255-XXXX-CCCC-VVVV-51fba84872aa",
"authorizations": [
"principalId": "9d45cb5e-AAAA-BBBB-CCCCC-DDDDDDDD",
"roleDefinitionId": "acdd72a7-3385-48ef-bd42-f606fba81ae7",
"principalIdDisplayName": "Azure Reader Access"
"principalId": "9d45cb5e-AAAA-BBBB-CCCCC-DDDDDDDD",
"roleDefinitionId": "cfd33db0-3dd1-45e3-aa9d-cdbdf3b6f24e",
"principalIdDisplayName": "Support Request Contributor"
"resources": [
"type": "Microsoft.ManagedServices/registrationDefinitions",
"apiVersion": "2020-02-01-preview",
"name": "[variables('mspRegistrationName')]",
"properties": {
"registrationDefinitionName": "[parameters('mspOfferName')]",
"description": "[parameters('mspOfferDescription')]",
"managedByTenantId": "[variables('managedByTenantId')]",
"authorizations": "[variables('authorizations')]"
"type": "Microsoft.ManagedServices/registrationAssignments",
"apiVersion": "2020-02-01-preview",
"name": "[variables('mspAssignmentName')]",
"dependsOn": [
"[resourceId('Microsoft.ManagedServices/registrationDefinitions/', variables('mspRegistrationName'))]"
"properties": {
"registrationDefinitionId": "[resourceId('Microsoft.ManagedServices/registrationDefinitions/', variables('mspRegistrationName'))]"
"outputs": {
"mspOfferName": {
"type": "string",
"value": "[concat('Managed by', ' ', parameters('mspOfferName'))]"
"authorizations": {
"type": "array",
"value": "[variables('authorizations')]"

Tuesday, April 14, 2020

Configure AWS Login With Azure AD Enterprise App

The idea is to enable users to sign in to AWS using their Azure AD credentials. This can be achieved by configuring single sign-on (SSO) between Azure AD and AWS. The process involves creating an enterprise application in Azure AD and configuring the AWS application to use Azure AD as the identity provider. Once this is set up, users can log in to AWS using their Azure AD credentials and access the AWS resources that they have been authorized to use. The tutorial provided by Microsoft explains the steps involved in setting up this SSO configuration between Azure AD and AWS.

  1. Azure >> Enterprise APP >> <<Configure Azure AD SSO
    1. Deploy Amazon Web Services Developer App
    2. Single Sign On >>.SAML
      1. Popup to save
        1. Identifier:
        2. Reply URL:
      2. Save
    3. SAML Signing Certificate
      1. Download "Federation Metadata XML"
    4. Add the AD user's to Application's User' and Group
  2. AWS >> IAM >> Identity provider
    1. Create
      1. SAML
      2. AZADAWS
      3. Upload the Metadata XML
    2. Verify Create
  3. AWS>> IAM >> ROLE << This Role will Come in Azure Application
    1. SAML 2.0 Federations
      1. Choose :  Earlier Created Identity provider
      2. Allow programmatic and AWS Management Console access
      3. Choose required permissions
      4. Create the role with Appropriate name
  4. AWS >> IAM >> POLICIES <<  This policy will allow to fetch the roles from AWS accounts.
    1. Choose JSON
      1. { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iam:ListRoles" ], "Resource": "*" } ] }
    2. Name : AzureAD_SSOUserRole_Policy.
    3. Create the Policy
  5. AWS >> IAM >> USER
    1. Name : AzureADRoleManager
    2. Choose Programmatic access
    3. Permission : Attach existing polices
      1. Choose : AzureAD_SSOUserRole_Policy
    4. Create User
    5. Copy Access and Secret key
  6. Azure Enterprise App >> Choose Amazon Web Services App which was deployed
    1. Provisoing
      1. Make it automatic
      2. Give Aws Access and Secret key
      3. Test and Save
      4. Make the "Provisioning Status" to ON
      5. Wait for a sync to complete
      6. Once Sync is Completed got the user's and Groups
        1. Choose the user, select Click EDIT
        2. Choose the AWS Role

Wednesday, January 29, 2020

Azure AD integration to GCP Cloud for SSO

Idea is to enable SSO to GCP cloud with Azure AD configuration

Make sure cloud identity is subscripted in GCP account and we have a super admin user in that account.
Also the same domain is verified in both Azure and GCP.
Note: If Same domain is verified in any other Gsuit or GCP account, that should be used.

Base Document Followed

In GCP: Create 1 Super admin in Google env (Super admin is only available in which is available only if Gsuite or if Cloud Identity is register.)
In Azure:  Create 1 Application for the User Provisioning.
Make sure the user has been created in GCP user portal.

In Azure Create Second App
We will face login error after configuring as per the GCP document.  Errors have been listed below. To solve we need add the Identifier and Reply URL.

Errors faced

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. Please contact your admin to fix the configuration or consent on behalf of the tenant. Client app ID: 01303a13-8322-4e06-bee5-80d612907131.
Solution :  In SAML Config : add Identifier (Entity ID) :<Domain Name>

AADSTS900561: The endpoint only accepts POST requests. Received a GET request.
Solution :  In SAML Config : add Reply URL :*

Friday, February 16, 2018

Azure VPN Gateway with Cisco ASA using Routing

The Azure VPN Gateway and Cisco ASA can encounter routing-type issues when configured together. To resolve this, the UsePolicyBasedTrafficSelectors must be enabled in the Azure Connection. The provided code is a PowerShell script that retrieves the specified Azure virtual network gateway connection and creates a new IPsec policy with specific parameters. The script then sets the IPsec policies for the connection to the new policy and enables UsePolicyBasedTrafficSelectors to solve the routing issue.

$RG1 = "****************"

This line declares a variable $RG1 and sets its value to a string of asterisks. This is likely just a placeholder for the actual resource group name.

$Connection16 = "****************"

Similar to the first line, this line declares a variable $Connection16 and sets its value to a string of asterisks. This is likely just a placeholder for the actual connection name.

$connection6 = Get-AzureRmVirtualNetworkGatewayConnection -Name $Connection16 -ResourceGroupName $RG1

This line retrieves the virtual network gateway connection object for a connection with the specified name ($Connection16) in the specified resource group ($RG1). The connection object is assigned to the variable $connection6.

$newpolicy6 = New-AzureRmIpsecPolicy -IkeEncryption AES256 -IkeIntegrity SHA384 -DhGroup DHGroup24 -IpsecEncryption AES256 -IpsecIntegrity SHA1 -PfsGroup PFS24 -SALifeTimeSeconds 28800 -SADataSizeKilobytes 4608000

This line creates a new IPsec policy object ($newpolicy6) with the specified settings for IKE encryption, integrity, DH group, IPsec encryption, integrity, Perfect Forward Secrecy (PFS) group, Security Association (SA) lifetime, and SA data size.

Set-AzureRmVirtualNetworkGatewayConnection -VirtualNetworkGatewayConnection $connection6 -IpsecPolicies $newpolicy6

This line updates the virtual network gateway connection object ($connection6) with the new IPsec policy ($newpolicy6) created in the previous step.

Set-AzureRmVirtualNetworkGatewayConnection -VirtualNetworkGatewayConnection $connection6 -IpsecPolicies $newpolicy6 -UsePolicyBasedTrafficSelectors $True

This line updates the virtual network gateway connection object ($connection6) again, this time enabling policy-based traffic selectors by setting the -UsePolicyBasedTrafficSelectors parameter to $True. This is necessary to resolve routing issues that can occur when configuring the Azure VPN Gateway with a Cisco ASA.

PS Azure:\> $connection6.UsePolicyBasedTrafficSelectors



PS Azure:\> $connection6.IpsecPolicies

Tuesday, November 28, 2017

Increases swap in azure linux machine

In Azure to create a swap file in the directory that's defined by the ResourceDisk.MountPoint parameter, you can update the /etc/waagent.conf file by setting the following three parameters:


Note The xx placeholder represents the desired number of megabytes (MB) for the swap file.
Restart the WALinuxAgent service by running one of the following commands, depending on the system in question:

Ubuntu: service walinuxagent restart
Red Hat/Centos: service waagent restart

Run one of the following commands to show the new swap apace that's being used after the restart:

dmesg | grep swap
swapon -s
cat /proc/swaps
file /mnt/resource/swapfile
free| grep -i swap

If the swap file isn't created, you can restart the virtual machine by using one of the following commands:

shutdown -r now
init 6