Section 11 – Implement Access Management for Apps – Plan, implement, and monitor the integration of Enterprise Apps for SSO – Monitoring, AAD App proxy and SSO

And then to the next section in my SC-300 study guide. Today is the turn for:

• monitor and audit access / Sign-ins to Azure Active Directory integrated enterprise applications
• integrate on-premises apps by using Azure AD application proxy

Monitor and audit access

Sign-in logs

Access sign-in logs from https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/SignIns

Who can access it?

To access the sign-ins log, you need to be:

• A global administrator
• A user in one of the following roles:
  • Security administrator
  • Security reader
  • Global reader
  • Reports reader

Views

From Sign-in logs You can find interactive and non-interactive sign-ins but also Service principal and Managed identity sign-ins.

You can filter these logs with multiple attributes

And see more information on the login.

Especially I like the Conditional Access reporting pane. It makes life so much easier.

In the report only You can see the policies that are in Report only mode.

If You have any error codes for the logins, You can debug them here https://login.microsoftonline.com/error

Retain logs

Activity reports

Report	Azure AD Free	Azure AD Premium P1	Azure AD Premium P2
Sign-ins	Seven days	30 days	30 days
Azure AD MFA usage	30 days	30 days	30 days

Download sign-in logs

With Portal

Click the Download option to create a CSV or JSON file of the most recent 250,000 records. Start with download the sign-ins data if you want to work with it outside the Azure portal.

Or with PowerShell

Audit logs

Access audit logs from https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Audit

Who can access it?

To access the audit log, you need to be:

• A global administrator
• A user in one of the following roles:
  • Security Administrator
  • Security Reader
  • Report Reader
  • Global Reader

Enable Audit logs

Audit log search is turned on by default for Microsoft 365 and Office 365 enterprise organizations. To verify that audit log search is turned on, you can run the following command in Exchange Online PowerShell:

The value of True for the UnifiedAuditLogIngestionEnabled property indicates that audit log search is turned on. For more information, see Turn audit log search on or off.

Detailed properties in the Audit log

Retain logs

Activity reports

Report	Azure AD Free	Azure AD Premium P1	Azure AD Premium P2
Audit logs	Seven days	30 days	30 days
Azure AD MFA usage	30 days	30 days	30 days

For users assigned an Office 365 E5 or Microsoft 365 E5 license (or users with a Microsoft 365 E5 Compliance or Microsoft 365 E5 eDiscovery and Audit add-on license), audit records for Azure Active Directory, Exchange, and SharePoint activity are retained for one year by default. Organizations can also create audit log retention policies to retain audit records for activities in other services for up to one year.

For users assigned any other (non-E5) Office 365 or Microsoft 365 license, audit records are retained for 90 days.

Download audit logs

With Portal

Click the Download option to create a CSV or JSON file of the most recent 250,000 records. Start with download the sign-ins data if you want to work with it outside the Azure portal.

Or with PowerShell

Quick tip! Microsoft has released Microsoft 365 Lighthouse that can help partners to take care of their customers tenants. Check it out here.

Longer log retention?

Try out Log analytics so retain logs longer than 90days. By default it isn’t enabled.

To enable open Diagnostics settings and add a diagnostics setting

From here You can add both logs to Log analytics or archive them to and Storage account.

When You choose either one, you don’t have any limit on the retention.

Integrate on-premises apps by using Azure AD application proxy

What is Azure AD Application Proxy?

AAD Application Proxy is like RDS Web Access or Citrix Storefront, i will support the following.

• Web applications that use Integrated Windows Authentication for authentication
• Web applications that use form-based or header-based access
• Web APIs that you want to expose to rich applications on different devices
• Applications hosted behind a Remote Desktop Gateway
• Rich client apps that are integrated with the Microsoft Authentication Library (MSAL)

When you introduce the proxy for the first time, you need to install an connector to on-premise. It supports Windows Server 2012 R2 or later and should be able to communicate with the software that you are publishing.

The agent has automatic updates enabled by default so you don’t have to worry about new versions.

Quick tip! Did you know that Modern Exchange Hybrid uses the same feature? You don’t have to expose EWS to internet, you can just use the agent and Microsoft Proxy Services will carry the traffic to the cloud

Authentication

SAML-based authentication

AAD Application Proxy has several options for authentication workflows. You can use SP-initiated or IdP-initiated authentication.

And to explain a bit, with IdP workflow the user logins from MyApps portal to access the application and with SP they will contact the app directly but the app will send auth request to Azure AD.

So as you can see it’s really useful for giving Azure AD secured access to your on-premise apps no matter where you want to connect from.

And you can these the SSO options with Azure AD Proxy.

Header-Based

1. The Admin customizes the attribute mappings required by the application in the Azure AD portal.
2. When a user accesses the app, Application Proxy ensures the user is authenticated by Azure AD
3. The Application Proxy cloud service is aware of the attributes required. So the service fetches the corresponding claims from the ID token received during authentication. The service then translates the values into the required HTTP headers as part of the request to the Connector.
4. The request is then passed along to the Connector, which is then passed to the backend application.
5. The application receives the headers and can use these headers as needed.

Kerberos-based

1. The user enters the URL to access the on premises application through Application Proxy.
2. Application Proxy redirects the request to Azure AD authentication services to preauthenticate. At this point, Azure AD applies any applicable authentication and authorization policies, such as multifactor authentication. If the user is validated, Azure AD creates a token and sends it to the user.
3. The user passes the token to Application Proxy.
4. Application Proxy validates the token and retrieves the User Principal Name (UPN) from it, and then the Connector pulls the UPN, and the Service Principal Name (SPN) through a dually authenticated secure channel.
5. The Connector performs Kerberos Constrained Delegation (KCD) negotiation with the on premises AD, impersonating the user to get a Kerberos token to the application.
6. Active Directory sends the Kerberos token for the application to the Connector.
7. The Connector sends the original request to the application server, using the Kerberos token it received from AD.
8. The application sends the response to the Connector, which is then returned to the Application Proxy service and finally to the user.

Password-based

Azure Active Directory Application Proxy helps to increase productivity by publishing local applications so that remote staff can also access them safely. On the Azure portal, you can also set up a single entry (SSO) for these applications. Your users only need to be authenticated with Azure AD, and they can access your corporate application without re-entering the system.

Application Proxy supports several single entry modes. The password entry is intended for applications using a combination of username and password to verify authenticity. When you adjust the password-based entry for your application, your users should enter the local application once. After that, Azure Active Directory saves input data and automatically provides its application when your users use it remotely.

How to setup?

Open Application proxy under Enterprise applications.

What is Connector group?

For more scenarios and applications, customers use Azure AD’s Application Proxy. You can attach certain connectors to specific apps by creating Application Proxy connector groups. This feature gives you more control over your Application Proxy deployment and allows you to optimize it.

A connector group is assigned to each Application Proxy connector. For high availability and load balancing, all connectors in the same connector group work as a single unit. A connector group is made up of all connectors. If you don’t make any groups, all of your connectors will be placed in the default group. In the Azure portal, your administrator can establish new groups and assign connectors to them.

All applications are assigned to connector groups. If you do not create a group, all applications will be assigned to the default group. However, if you organize the connectors into groups, you can configure each application to work with a particular connector group. In this case, only the connectors in that group will serve the application on demand. This feature is useful when your application is hosted in different locations. Applications can always be served by physically close connectors because you can create connector groups based on location.

Installing agent

Once installed, give credentials.

And see the magic happen.

Excellent! Before continuing I will explain what happens when You create a new application.

Yes, You guessed right, it will create a new App registration with given info. But there is restrictions here if You don’t want to brake anything.

The following configuration items are being used by app proxy and should not be altered or deleted:

• Enable/Disable “Allow public clients flows”.
• CWAP_AuthSecret (Client secrets).
• API Permissions. Modifying any of the above configuration items on the App registration page will break pre-authentication for Azure AD Application Proxy.

Adding an App

First You give a name and Internal URL. Note! For wildcard applications the URL must be in the format http(s)://*.domain

You will also see External URL and the different options under it.

I will also explain the different suffixes for the External URL in my example.

Onmicrosoft.com is apparent as it’s the default tenant name.

mail.onmicrosoft.com is the for Exchange, yes it has a sub-domain for Your default tenant.

msaproxy.net is for communication between the connector and the Application Proxy cloud service

The others three custom domain are added as Custom domain inside my tenant, like so.

You can use own verified domain and add the sub-domains without verifying them. Now that’s superb! You just have to add CNAME to Your Public DNS.

Pre-authentication

Defines how Application Proxy pre-authenticates users before providing access to the application on your private network.

With pre-authentication enabled, Azure AD will challenge users first for authentication and if single sign-on is configured then the back-end application will also verify the user before access to the application is granted. Changing the pre-authentication mode from Passthrough to Azure AD also configures the external URL with HTTPS, so any application initially configured for HTTP will now be secured with HTTPS

Additional Settings

• Set Backend Application Timeout: This setting is useful in scenarios where the application might require more than 75 seconds to process a client transaction. For example when a client sends a query to a web application that acts as a front end to a database. The front end sends this query to its back-end database server and waits for a response, but by the time it receives a response, the client side of the conversation times out. Setting the timeout to Long provides 180 seconds for longer transactions to complete.
• Use Appropriate Cookie Types
  • HTTP-Only Cookie: Provides additional security by having Application Proxy include the HTTPOnly flag in set-cookie HTTP response headers. This setting helps to mitigate exploits such as cross-site scripting (XSS). Leave this set to No for clients/user agents that do require access to the session cookie. For example, RDP/MTSC client connecting to a Remote Desktop Gateway published via App Proxy.
  • Secure Cookie: When a cookie is set with the Secure attribute, the user agent (Client-side app) will only include the cookie in HTTP requests if the request is transmitted over a TLS secured channel. This helps mitigate the risk of a cookie being compromised over clear text channels, so should be enabled.
  • Persistent Cookie: Allows the Application Proxy session cookie to persist between browser closures by remaining valid until it either expires or is deleted. Used for scenarios where a rich application such as office accesses a document within a published web application, without the user being re-prompted for authentication. Enable with caution however, as persistent cookies can ultimately leave a service at risk of unauthorized access, if not used in conjunction with other compensating controls. This setting should only be used for older applications that can’t share cookies between processes. It’s better to update your application to handle sharing cookies between processes instead of using this setting.
• Translate URLs in Headers: You enable this for scenarios where internal DNS cannot be configured to match the organization’s public namespace(a.k.a Split DNS). Unless your application requires the original host header in the client request, leave this value set to Yes. The alternative is to have the connector use the FQDN in the internal URL for routing of the actual traffic, and the FQDN in the external URL, as the host-header. In most cases this alternative should allow the application to function as normal, when accessed remotely, but your users lose the benefits of having a matching inside & outside URL.
• Translate URLs in Application Body: Turn on Application Body link translation for an app when you want the links from that app to be translated in responses back to the client. If enabled, this function provides a best effort attempt at translating all internal links that App Proxy finds in HTML and CSS responses being returned to clients. It is useful when publishing apps that contain either hard-coded absolute or NetBIOS shortname links in the content, or apps with content that links to other on-premises applications.

App registration page

Now we can see the app inside App registrations and I want to point out something here.

Open the Enterprise applications and open Your Azure AD pre-authenticated app.

Remember that we chose Azure AD to Pre-authentication? When we use that option there is more options here and they seem really familiar.

If I go and change the pre-auth to passthrough.

There is less options.

Assigning to users or groups

You can use the External URL to access the app but it’s not really convenient choice, instead You probably want to publish it to users so they can access the apps example from myapps.microsoft.com portal.

You can also choose a role for Your user or group. Then You have to declare it in Your manifest.

Things to remember

Sign-in and audit logs

To access the audit log, you need to be:

• A global administrator
• A user in one of the following roles:
  • Security Administrator
  • Security Reader
  • Report Reader
  • Global Reader

Retention times

Report	Azure AD Free	Azure AD Premium P1	Azure AD Premium P2
Sign-ins	Seven days	30 days	30 days
Audit logs	Seven days	30 days	30 days
Azure AD MFA usage	30 days	30 days	30 days

Report	Azure AD Free	Azure AD Premium P1	Azure AD Premium P2
Risky users	No limit	No limit	No limit
Risky sign-ins	7 days	30 days	90 days

When does Azure AD start collecting data?

Azure AD Edition	Collection Start
Azure AD Premium P1 Azure AD Premium P2	When you sign up for a subscription
Azure AD Free	The first time you open the Azure Active Directory blade or use the reporting APIs

And for longer storing time You can use Log analytics or Storage Accounts.

Application proxy

To use Azure AD Application Proxy, you must have an Azure AD Premium P1 or P2 license.

Supported scenarios:

• Web applications that use Integrated Windows Authentication for authentication
• Web applications that use form-based or header-based access
• Web APIs that you want to expose to rich applications on different devices
• Applications hosted behind a Remote Desktop Gateway
• Rich client apps that are integrated with the Microsoft Authentication Library (MSAL)

A connector group is assigned to each Application Proxy connector. For high availability and load balancing, all connectors in the same connector group work as a single unit

Using custom domains is supported, just have to add CNAME to public DNS.

Wildcards are also supported but they have to be HTTPS enabled.

Link to main post