Microsoft Graph: Restrict Access Using Conditional Access Policy

In this post we will be going through setting up a conditional access policy to allow connection’s to a Microsoft App Registration that will be used for calling Microsoft GraphAPI from only certain countries / public IP’s.

Microsoft has a preview feature in Conditional Access for workload identities. A workload identity is an identity which allows an application or service principal access to resources.

When an App Registration is created, it will create a service principal. This service principal is what we will use in the conditional access policy.

First we need to create the named location to define where we want to allow the access from.

To create a named location go to endpoint management admin page.

https://endpoint.microsoft.com/

Go to Endpoint security > Conditional access.

Once in Conditional access, go to Named location and add the required countries locations and or IP ranges.

To add as single IP use /32 bit subnet mask.

Once we have the named locations we can create the Conditional access policy.

Go to the policies tab and click on new policy.

Give the policy a name and set the assignment to workload identities.

Next select the service principal for the Graph App registration.

Next on Cloud apps or actions select, All cloud apps

Next we need to specify which location will be included, which we set to any location as we will use the exclude to allow access from the named location we will connect from.

Next select the location that will be excluded from the policy in my case it will be the public IP we added earlier to the named location.

Next we set the access, I will be blocking access as I only want to allow access from the one public IP we specified in the excluded location.

With any conditional access policy I would recommend setting the policy to Report-only to confirm that only the access that we excepted to be blocked is.

To check if the policy is applying correctly against the service principal we can check the sign-in logs.

First connect using Graph query and then go to sign-in logs.

Select service principal sign-ins.

Click on the request ID and look at the Report-only tab to see if the access would have been blocked or allowed.

Once we confirm that the policy is applying the correct access, the conditional access can be set to on.

Now once we try to connect from an IP or location not on the excluded list, it will be blocked from accessing.

When we connect from an allowed location, we will get back the access token and be allowed to connect.

When creating App registration we should look at access controls for these as this can be over looked and lead to a security risk, most application do not need access from any location and should be limited to only the require location or IP address to give greater access control.

Allow External Access to vCenter Using Azure Application Proxy

With some of the recent critical vulnerability’s for both VMware and Log4j vulnerability this is has shown again that having vCenter open on the internet is not a good idea as it leave a big target for hackers to try exploit.

There are several ways to avoid having vCenter directly available on the internet, in this post we will be going through publishing using the Microsoft Azure Application Proxy. This will be using Azure AD as an authentication source and we can add addtional security like MFA.

First before we can use the Azure Application Proxy we need to make sure we have an Azure subscription and the appropriate license types. The application proxy is available for users that have either a Azure AD P1 or P2 license.

Once all the pre requisite are meet we can install the Azure Application Proxy, we will be using a Windows Server 2019 VM.

For Windows Server 2019 we need to disable http2 protocol, to disable run the below command from PowerShell.

Set-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp\' -Name EnableDefaultHTTP2 -Value 0

To download the installer, logon to the Azure portal > Azure Active Directory > Application proxy.

Once downloaded run the installer on the server that will be used for the app proxy. To register the connector the minimum rights is to be part of the application administrator role in Azure.

During the install we will be prompted to enter details for an account that has the correct permissions.

The install can take a minute or two to finish.

Once the install has completed the Azure Application proxy connector should show in Azure.

Now that we have the proxy connected to Azure, we will need to register the enterprise application.

Go to Azure AD > Enterprise applications > create your own application

Give the application a name and click create.

Give the app a name
Add in the internal URL for vCenter
Set external URL this can either be an msappproxy.net address or custom domain named
Set the pre authentication to either Azure AD or passthrough (to use MFA or conditional access policy set to Azure AD)
Set the connector group

I left the addtional settings as the defaults. If the internal and external URL are different (its recommend from Microsoft to use the same DNS address), then to allow the redirect set the translate URLs in > Application Body to yes so allow link translation from the external to internal URL.

Click create, the app can take a few minutes provision.

We can restrict access to the app by using security groups or induvial users access.

Once we have setup the access group we can now connect to the external URL.

If the internal application is using an self singed cert or un trusted certificate authority, then the cert will need to be add to the trusted root cert store on the application proxy server.

This is the TLS error:

There should also be event log 13001 log under Applications and Services Logs/Microsoft- AAD Application Proxy Connector/Admin.

Download the root CA cert from vCenter and install to the trusted root on the server that has the Azure Application Proxy connector installed.

The second option is to use a custom SSL cert for vCenter, I have done a previous post on how to install a custom cert.

Set Custom SSL Certificate on VMware vCenter 6.7 Appliance using Windows CA

After this has been completed the page should now load without issue using the external Azure msapproxy address.

If the application proxy is set to use pre authentication then users will be redirected to the sign in page for Azure and be subject to any conditional access policies.

When connecting from an account that has not been give access rights they will not be able to connect.

The VMware remote console does not work using the Azure Application proxy as it requires both port 443 and 902, the application proxy can’t connect on 902 so the connection fails.

Azure Application Proxy SSO Integrated Windows Authentication

Today I was setting up Integrated Windows Authentication single sign on for an Azure Application proxy that connects to an internal Apache web application.

We had already configured the application for SSO internally.

Below is the link to the Kerberos SSO for Azure App Proxy

Kerberos-based single sign-on (SSO) in Azure Active Directory with Application Proxy | Microsoft Docs

Prerequisites

Before you get started with single sign-on for IWA applications, make sure your environment is ready with the following settings and configurations:

Your apps, like SharePoint Web apps, are set to use Integrated Windows Authentication. For more information, see Enable Support for Kerberos Authentication.
All your apps have Service Principal Names.
The server running the Connector and the server running the app are domain joined and part of the same domain or trusting domains.
The server running the Connector has access to read the TokenGroupsGlobalAndUniversal attribute for users.

First step was to confirm that there was an SPN configured for the Application. Since this is a web application we will use http for the serviceclass.

setspn -Q http/webapp.domain.local

If the SPN isn’t configured use setspn to register.

setspn -A http/webapp.domain.local computername

The next step is to configure the delegation on the Azure application proxy connector server.

Go to the server object in AD, open the properties and go to delegation.

Click add and select the computer or user account that has the SPN that will be used and select the service.

The last step that I had to do was add the server to Windows Authorization Access Group so that the connector could have read access to TokenGroupsGlobalAndUniversal users attribute in AD.

When I didn’t have the server in this group I was getting SPN issues.

Next we need to configure SSO in Azure Enterprise app. Logon to Azure

Azure Active Directory > Enterprise applications > App

Select Single sign-on and Windows Integrated Authentication

Put in the internal SPN that was configured earlier and set the delegated login, Our app uses samaccount name so I used On-premises SAM account name.

Once the above is completed close all open session to Office 365 / Azure AD and re-signed in to the external URL for the application proxy and the application should now signed in using SSO without have put in credentials a second time.

Connecting to Microsoft GraphAPI Using PowerShell

Recently I have been looking to use Microsoft Graph to query specific information for Microsoft 365 services.

Microsoft Graph is an development tool that connects to multiple Microsoft 365 services to allow querying data and automate tasks.

There are a few steps required to start using Graph which involves creating a app registration on Azure to issue authentication tokens and API permission to view data.

Use the Microsoft Graph API – Microsoft Graph | Microsoft Docs

I also used a blog post by AlexAsplund on adamtheautomator as this was very good at explaining the process and goes more in depth.

Using the Microsoft Graph API with PowerShell (adamtheautomator.com)

In this post we will be going through configuring the app registration and query some data from Azure AD.

First step is to logon to the Azure portal > Azure AD > App registration and click on New registration.

Give the app a name and specify the support account type in this case we only want account from our tenant.

Once completed, we should now see the app has been created.

Next step we need to configure the API permissions, depending on the type of access required we will use either delegated or application permission as some data can only be access by either permission types.

below is a extract from the Microsft Docs on permission types

Microsoft identity platform developer glossary | Microsoft Docs

permissions

A client application gains access to a resource server by declaring permission requests. Two types are available:

“Delegated” permissions, which specify scope-based access using delegated authorization from the signed-in resource owner, are presented to the resource at run-time as “scp” claims in the client’s access token.
“Application” permissions, which specify role-based access using the client application’s credentials/identity, are presented to the resource at run-time as “roles” claims in the client’s access token.

To assign permission go to the app registration we created earlier and go to API permissions > Add a permission and select Microsoft Graph.

To check which permissions are required I used the below Microsoft Docs .

Microsoft Graph permissions reference – Microsoft Graph | Microsoft Docs

Select the permission type and the required permission in this case I want to be able to read groups, users and directory so.

Once the required permissions are added if they required admin permission those will need to be granted using the grant admin consent option below.

There are many different way’s to connect to Microsoft Graph but in this post we will be using client secret.

We will need the application ID

We will create a client secret

Give the client secret a name and set the expire in this case we will use 1 year.

There should now be client secret and the value is used to authenticate. (Take note of the value and save in secure location like a password vault or Azure Key vault as once you leave the app blade the value will be hidden and if you lose, it will have to be recreated.)

Once we have the above configured we can connect to GraphApi to generate a token. We will used Invoke-RestMethod.

The secret can be hardcoded but I decided to use read-host so that I could add the secret manually, as it’s not recommend to have any password/secret hardcoded in script.

Below is the command I used to get the token.

$ApplicationID = ""
$TenatDomainName = ""
$AccessSecret = Read-Host "Enter Secret"


$Body = @{    
Grant_Type    = "client_credentials"
Scope         = "https://graph.microsoft.com/.default"
client_Id     = $ApplicationID
Client_Secret = $AccessSecret
} 

$ConnectGraph = Invoke-RestMethod -Uri "https://login.microsoftonline.com/$TenatDomainName/oauth2/v2.0/token" `
-Method POST -Body $Body

$token = $ConnectGraph.access_token

To verify we have a token run the variable $ConnectGraph to view.

Now that we have a token we can run a queries against GraphAPI.

Below we will be running a query for Azure AD groups and selecting display name.

$GrapGroupUrl = 'https://graph.microsoft.com/v1.0/Groups/'
(Invoke-RestMethod -Headers @{Authorization = "Bearer $($token)"} -Uri $GrapGroupUrl -Method Get).value.displayName

To view some examples we can use Graph Explorer.

Graph Explorer – Microsoft Graph

In a future post we will be going through more query’s and automating tasks using GraphAPI.

Create Azure conditional access policy with named location

In this post we will be going through creating an Azure conditional access policy to restrict logging on to Azure / Office 365 from specific locations.

Conditional access policies are used to set requirements for accessing Azure or Office 365 resource, when using Named locations we can then set based on IP range, Trusted locations or Countries and regions.

Below diagram is from Microsoft on how conditionals access works.

What is Conditional Access in Azure Active Directory? | Microsoft Docs

Conceptual Conditional Access process flow

First step is to logon to Azure and go to Azure AD conditional access

Create a named location that will be used to restrict access.

Once in named location we can either create a location based on IP range or countries / regions. In this case we will be using a country.

Next we will create the conditional policy

Give the policy a name, we will be using a group to apply the policy but this could be change to all users or by directory role. (We can use select users or groups to apply the policy to a specific group as if applied to all users there could be a risk of locking yourself out of Azure portal)

Next we can apply the policy to specific apps or all apps. (If applying to all apps there will be a warning to not lock yourself out)

Next we set the conditions in this case we will be using location, I will be applying the policy to any location.

We can then set the named location as excluded in the policy so that it wont be applied if the access is coming from a country that is on the allowed named location.

This image has an empty alt attribute; its file name is image-26.png

Next we can set the access control settings, in this case we will block access but this could be changed to require MFA or other settings below.

Last step is to set session options to use conditional access app control, force sign-in frequency, Persistent browser session. We wont be setting any of the session settings as this policy is to block access.

There are three options report-only, on or off. To test the policy and check what will be blocked without running the risk of blocking real users set to report-only (This would be recommend for testing policy before rolling out to all users.)

Click create and the policy should now show and the state should be report-only.

To test if the policy is going to be applied we can check a users sign-ins, click on a signing log and go to Report-only, click on the three dots and show details.

This will show what part of the policy has been satisfied and not satisfied. Since the location has not been satisfied (as we are connecting from a excluded location) and the policy is not applied.

This image has an empty alt attribute; its file name is image-31.png

When the users tries to access from a country that is not in the allowed location, the result will be a failure and the users would be blocked from accessing.

Once testing has been completed and there are no unexpected blocks we can then go back to the conditional access policy and change the state to on, to apply the policy to users.

Now when a restricted user try’s to access an Azure / Office 365 resource from country not in the named location they will receive a message like the below.

Configure MFA For Azure Application Proxy

On the last post we setup Azure Application Proxy to allow internal application’s to be made available externally using AAD integration.

To add additional security to the setup we can enable MFA for the group or users that will be allowed access.

To enable MFA we need to create a conditional access policy and enable on the application proxy.

First step Login to Azure

Go to Azure Active Directory (AAD) AZ1

Go to Enterprise applications

AZ3

Select the Application proxy that will require MFA to be enabled

Once in the Application proxy go to Conditional Access and select New policy MFA1

Give the policy a meaningful name as it will appear in the overall Conditional Access policy’s aswell as on the Application. This will make it easier to manage if there are multiple policy’s.

Then select Users and groups and select the required users or group MFA2

Next select the cloud apps that will require MFA in this case it is the Exchange ECP application that was configured previously MFA3

We will not setup conditions but if this is required it can be set to only allow access from certain devices types, location & sign-in risk level.

Next go to Access controls and then Grant tab. Select Grant access, tick Require multi-factor authentication and Requires one of the selected controls MFA4

Last step is to Enable the policy

MFA7

Click create at the bottom of the policy

The policy should now show and have tick under Enabled MFA5

Now when we try to access the ECP Application proxy URL,

we should be prompted for MFA MFA8

and asked to register and verify a device to be use for MFA MFA9

It is a good idea to enable MFA for application as it gives an additional layer of security.

Configure Azure Application Proxy To Access Internal Application

To access internal applications we can use Azure Application proxy to integrate with Azure AD and allow remote access to internal resources.

To use Azure Application Proxy requires Azure AD basic, Premium P1 or Premium P2 subscription.

An Account with Global administrator rights

The Azure application proxy connector requires Windows Server 2012 R2 or later

Below are pre-req ports and URL’s

See link below to Microsoft documentation

https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy

Port number	How it’s used
80	Downloading certificate revocation lists (CRLs) while validating the SSL certificate
443	All outbound communication with the Application Proxy service

URL	How it’s used
.msappproxy.net .servicebus.windows.net	Communication between the connector and the Application Proxy cloud service
mscrl.microsoft.com:80 crl.microsoft.com:80 ocsp.msocsp.com:80 http://www.microsoft.com:80	Azure uses these URLs to verify certificates
login.windows.net login.microsoftonline.com	The connector uses these URLs during the registration process.

The following diagram shows how Azure AD and Application Proxy work together to provide single sign-on to on-premises applications. azureappproxxy

To start we need to download and configure the proxy connector

Go to Azure Active Directory (AAD) AZ1

Once in AAD go to Application proxy

AZ2

Click Download connector service APinstall0

Once downloaded run the MSI on the server that will be used as the application proxy connector (I used a server in a DMZ zone). It will prompt for an Azure account with Global admins rights.

Once configured the server should now show in the application proxy tab APinstall4

Once connected and active next step is to configure application

Go to AAD and Enterprise applications

AZ3

Once in Enterprise applications click on New application APinstall7

Click on On-premises application APinstall8

Below is a description for each field and option available in the application proxy

Name:
The name of the application that will appear on the access panel and in the Azure portal.

Internal URL:
The URL for accessing the application from inside your private network. You can provide a specific path on the backend server to publish, while the rest of the server is unpublished. In this way, you can publish different sites on the same server as different apps, and give each one its own name and access rules.
If you publish a path, make sure that it includes all the necessary images, scripts, and style sheets for your application. For example, if your app is at https://yourapp/app and uses images located at https://yourapp/media, then you should publish https://yourapp/ as the path. This internal URL doesn’t have to be the landing page your users see. For more information, see Set a custom home page for published apps.

External URL:

The address for users to access the app from outside your network. If you don’t want to use the default Application Proxy domain, read about custom domains in Azure AD Application Proxy.

Pre Authentication:
How Application Proxy verifies users before giving them access to your application.

Azure Active Directory – Application Proxy redirects users to sign in with Azure AD, which authenticates their permissions for the directory and application. Microsoft recommend keeping this option as the default, so that you can take advantage of Azure AD security features like conditional access and Multi-Factor Authentication. Azure Active Directory is required for monitoring the application with Microsoft Cloud Application Security.

Passthrough – Users don’t have to authenticate against Azure Active Directory to access the application. You can still set up authentication requirements on the backend.

Connector Group:
Connectors process the remote access to your application, and connector groups help you organize connectors and apps by region, network, or purpose. If you don’t have any connector groups created yet, your app is assigned to Default.
If your application uses WebSockets to connect, all connectors in the group must be version 1.5.612.0 or later.

Fill out the details required. I am using passthrough for pre authentication for the web site but this can be changed to AAD which then requires authentication before the site can be accessed.

(I created a basic IIS page on an internal web server to test with) APinstall9

Next step copy the external URL and try to access the site. There should be no prompt and the site should load

(Yay my lovely test site is available 🙂 ) APinstall13

I decided to also allow access to my internal Exchange server and to also test the AAD pre-authentication.

First create a second application proxy and set the Pre Authentication to Azure Active Directory APinstall14

I wanted to use a custom domain name for the second application proxy so I changed the external URL to the custom domain name in Azure.

Once a custom domain is selected we can add a certificate to match the URL.

There will be a warning that a CNAME entry will be required to point from the custom URL to the msappproxy.net address APinstall18

(This will require a CNAME record to be created on public DNS server that will map the application proxy to msappproxy.net) CNAME

Once configured we need to add a user or group to allow access.

Go to the application proxy, select the required application proxy and click on Users and groups, Add user and select either the user or group that will be allowed access APinstall16 APinstall15

Copy the link for the application proxy.

Unless a valid cert was also uploaded you will receive a cert error click continue to site.

It should now prompt for AAD authentication. Use an account that has access right to the proxy APinstall11

Once logged in the ECP page should now show. APinstall10