How to Configure SSO with Azure AD for Line-of-Business Apps

SSO via Azure AD (now called Microsoft Entra ID) enables users to sign in once with their Azure AD credentials to access internal and line-of-business (LOB) apps, so users don’t have to remember multiple usernames or go through repeated logins. This improves the user experience, security, and access control across hybrid and cloud environments.

Azure SSO supports a wide range of application types, including modern and legacy systems. Common LOB app scenarios include:

• Internal web apps (IIS-hosted, .NET-based)
• Custom SaaS apps
• On-prem apps exposed via Azure AD Application Proxy
• Legacy apps that require header-based or form-based SSO

This guide walks you through the steps to configure Azure SSO for these applications.

Steps to manage SSO with Azure AD for Line-of-Business (LOB) applications

To avoid problems with setup and make sure everything goes smoothly, make sure the following requirements are in place before you start:

📌 General prerequisites:

• Azure AD tenant with Premium P1 license (required for Application Proxy or Conditional Access)
• A LOB application hosted either on-premises or in Azure
• Domain-joined or Azure AD-joined endpoints
• Admin access to Azure Portal and the application server

Step 1: Register the LOB app in Azure AD

This step creates an identity for your application in Azure AD so it can be managed securely. Once registered, Azure AD recognizes the app and can issue tokens to it.

1. Open the Azure Portal.
2. Navigate to Azure Active Directory > App registrations > New registration.
3. Enter a name for the app.
4. Set Redirect URI (e.g., https://app.domain.com/auth/callback) (Read #1 in ⚠️ Things to look out for.)
5. Click Register.
6. After registration:
   • Copy the Application (client) ID.
   • Under Authentication, choose the platform and enter your redirect URI.
   • Under API permissions, add Microsoft Graph permissions: openid, profile, and email.

💡 What is a LOB in Azure?

A Line-of-Business (LOB) app is a custom or internal app that is made just for the needs of a business. It is often made in-house and not made public.

Step 2: Configure SSO options based on app type

Every app supports a different authentication method (SAML, OAuth2, or OIDC). This step tells Azure AD which one to use so users can sign in without issues.

For modern apps (OIDC or SAML)

1. Navigate to Azure Active Directory > Enterprise Applications > [Your App] > Single sign-on.
2. Choose:
   • SAML for apps that support SAML 2.0
   • OIDC (OpenID Connect) for apps built with modern identity providers
3. Configure the required fields:
   • Identifier (Entity ID)
   • Reply URL (Assertion Consumer Service)
   • Sign-on URL

(Read #2 in ⚠️ Things to look out for.)

4. Assign users or groups under the Users and Groups tab.

For legacy or header-based apps

Use Azure AD Application Proxy with pre-authentication (see Step 3).

💡 What is SSO in Azure?

Single Sign-On (SSO) in Azure is a feature that allows users to access multiple apps with one login. It simplifies authentication and strengthens security by centralizing identity management.

Step 3: Set up Azure AD Application Proxy (for on-prem apps)

If your app is hosted on-premises, Azure AD can’t reach it directly. Application Proxy acts as a secure tunnel between Azure and your internal network. (Read #3 in ⚠️ Things to look out for.)

📌 Prerequisites:

• A Windows Server 2016+ inside the network
• The Application Proxy Connector is installed on that server

Instructions:

1. Download or install the Application Proxy Connector from Azure.
2. Log in with an Azure AD Global Admin account.
3. In Azure Portal, navigate to Azure AD > Enterprise Applications > + Add > On-premises application.
4. Enter:
   • Internal URL – http://internalapp.local
   • External URL – https://app-tenant.msappproxy.net
   • Enable Preauthentication via Azure AD

Validate connection

1. Press Win + R, type cmd, and click Enter to open the Command Prompt.
2. Run: netstat -ano | findstr :443

Step 4: Configure SSO token behavior on client devices

Client devices need to know how to handle SSO tokens (how to request, store, and refresh them) when needed. Use this step to configure SSO token behavior on client devices.

Enable seamless SSO and Pass-through Authentication

1. Set up Azure AD Connect, enable Seamless SSO, and optionally Pass-through Authentication (PTA).
2. Confirm setup in PowerShell: Get-AzureADSSOStatus

Registry validation (client-side SSO token caching)

1. Check token settings in:

HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity

Keys like EnableADAL or Version can impact modern authentication behavior in office-integrated apps.

CMD check (token presence)

1. To inspect or reset Kerberos tickets, run: klist

Use klist purge to clear old Kerberos tickets if issues arise.

Step 5: Enforce policies via GPO

To ensure consistency across your devices, use Group Policy to control Kerberos behavior, token lifetimes, and browser compatibility. (Read #4 in ⚠️ Things to look out for.)

Configure Kerberos policies

1. Press Win + R, type gpedit.msc, and click Enter to launch the Local Group Policy Editor.
2. Navigate to:

Computer Configuration > Administrative Templates > System > Kerberos

📌 Ensure time sync and Kerberos settings align with your authentication policies.

For browser-based apps (SSO via browser)

1. Navigate to:

User Configuration > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page > Local Intranet Zone

2. Add the app’s URL to trusted sites using PowerShell:

Set-ItemProperty -Path “HKCU:\Software\Microsoft\Windows\
CurrentVersion\Internet Settings\ZoneMap\Domains\app.domain.com” -Name https -Value 1

3. Use browser policy templates to enforce SSO in Edge or Chrome.

Step 6: Automate access and token validation with PowerShell

PowerShell is your toolkit for validating tokens, automating access, and checking if your setup works as intended.

📌 Prerequisites:

• PowerShell installed
• Microsoft Graph API access (optional for automation)

Instructions:

1. Press Win + S, search for PowerShell, and select Windows PowerShell from the results.
2. Run this script to request a token manually: (Read #5 in ⚠️ Things to look out for.)

This confirms that app-to-app communication and service account access are working correctly.

⚠️ Things to look out for

Additional considerations

You may consider these recommendations to strengthen, secure, and maintain your SSO configuration with Azure AD for LOB apps:

Enforce MFA and device trust (Conditional Access)

Use Conditional Access to require Multi-Factor Authentication (MFA) and allow access only from trusted or compliant devices. This adds another layer of security and helps prevent unauthorized access, even if credentials or tokens are stolen.

💡 Tip: Read How to Configure Conditional Access Policies in Azure AD.

Control permissions with App roles

Instead of granting everyone the same level of access, use App roles to define what users can do inside the LOB app. Assign roles like Admin, Editor, or Viewer to enforce least privilege access and reduce security risks.

Monitor SSO health

Use Azure AD Sign-in Logs to monitor who accessed which app and when, success and failure rates for sign-ins and MFA, and potential security concerns. This helps with auditing, troubleshooting, and meeting compliance requirements.

Enforce SSO compatibility via Intune

If you use Microsoft Intune to manage devices, deploy Configuration Profiles to apply browser settings, app-specific policies, and device compliance rules. This helps maintain a smooth and consistent SSO experience across all enrolled devices.

Troubleshooting

Here are common issues you may encounter when configuring SSO with Azure AD for LOB apps, along with their root causes and how to resolve them:

NinjaOne services

NinjaOne supports SSO deployments and monitoring across client environments by:

Remote validation

Running PowerShell scripts remotely to check for token cache presence, registry keys, and network access.

Policy deployment

Pushing GPO-equivalent configurations to enforce browser compatibility and Kerberos authentication settings.

SSO alerts

Alerting on device or application state changes related to SSO or token expiration.

SSO tagging

Tagging devices and users based on SSO configuration status to support audits, compliance tracking, and environment health visibility.

Auto remediation

Automating policy remediation on endpoints that fail SSO pre-checks.

These tools empower MSPs to deliver secure, consistent SSO experiences across client fleets while reducing operational overhead.

💡 Tip: Also read Enable SSO.

Configure SSO with Azure AD for LOB apps to streamline access and strengthen security

SSO with Azure AD helps organizations modernize access control while simplifying the user experience for internal and LOB apps. Azure AD supports both modern cloud apps and older on-prem web services, giving you the flexibility to secure whatever your environment needs.

This guide covered everything you need to get started, from registering your app in Azure AD, setting up SAML, OIDC, or proxy-based authentication, to tightening client settings through Group Policy, PowerShell, and registry changes. It also showed how NinjaOne reinforces and monitors SSO environments for MSPs.

Related topics:

• SAML vs. SSO: What’s the Difference?
• Azure AD Connect: What It Is and How to Configure It
• Integrating On-Premises and Cloud with Microsoft Entra Hybrid Join
• Integrating On-Premises and Cloud with Hybrid Azure AD Join
• Active Directory Authentication: A Complete Overview
• SSO and SCIM Integration in NinjaOne
• What is the Cost of SSO Software? SSO Pricing