LMS Active Directory Integration: Azure AD & LDAP Guide

Integrating Active Directory (AD) or Lightweight Directory Access Protocol (LDAP) with Paradiso LMS creates a unified enterprise identity bridge. This architecture synchronizes corporate user identity data directly across enterprise infrastructure, eliminating manual account administration, enforcing central access controls, and delivering single sign-on (SSO) capabilities.

This guide is written for IT administrators, systems engineers and LMS administrators. It covers server prerequisites, the Azure AD setup in order, user sync and field mapping, cron tuning, and the errors you are most likely to meet. A pre-go-live checklist and an FAQ close the guide.

How LMS Active Directory Integration Works

Architecturally, enterprise identity integration in Paradiso LMS spans two primary infrastructure models:

• On-Premises Active Directory Domain Services (AD DS): Leverages direct LDAP/LDAPS queries to query directory nodes, authenticate users against central domain controllers, and map directory attributes to LMS profile fields.
• Cloud-Based Azure Active Directory (Azure AD / Microsoft Entra ID): Utilizes OpenID Connect (OIDC) modern authentication protocols paired with the Microsoft Graph REST API to execute federated Single Sign-On, OAuth token exchanges, and background user synchronization.

LDAP or Azure AD: which route fits your environment

The choice usually follows where your identities live. If your users sit in an on-premises domain, LDAPS is the direct route. If they sit in Entra ID, use OIDC and Graph.

LDAP means a network path from the LMS to your domain controllers. If the LMS is hosted outside your network, that path becomes a firewall rule, a VPN or a proxy decision for your security team. The Entra ID route uses Microsoft’s cloud endpoints, so it does not ask you to open anything inbound to domain controllers. For a deeper look at the LDAP side, see our guide to how the LMS LDAP protocol works. If you are comparing SSO options across other identity providers, our guide to LMS single sign-on covers them.

Protocol Authentication Lifecycle

The authentication lifecycle follows a structured four-step verification sequence:

1. User Login Request: The learner submits corporate Active Directory credentials at the LMS login interface.
2. Authentication Request: The LMS securely transmits the authentication payload to the central AD/LDAP or Azure AD server via encrypted transport channels (TLS/LDAPS or HTTPS OIDC endpoints).
3. Server Validation: The directory server verifies the submitted credentials against corporate security records, validating password validity, account state, and group policy restrictions.
4. Access Granted / SSO Session: The directory server returns an authentication validation response and token assertion, establishing an active SSO session and granting the user immediate access to their designated LMS portals, assigned cohorts, and learning paths.

Key Business & Operational Benefits

Centralized User & Data Management

Establishing Active Directory as the Single Source of Truth ensures user profile data remains centralized. This prevents duplicate data entry and eliminates manual record-keeping across HR, IT, and training systems. If your HR system rather than the directory is the system of record, our guide to connecting an LMS to HR systems covers that setup.

Automated User Lifecycle & Sync

New employee records created in Active Directory trigger automated user account provisioning in the LMS. Role updates, department transfers, and account deactivations synchronize automatically to maintain system security and data accuracy across the enterprise lifecycle.

Dynamic Grouping, Cohorts, and Role Assignment

Active Directory user attributes (such as department, job title, and physical location) dynamically categorize learners into LMS groups and cohorts. Attribute mappings automatically dictate LMS security permissions (e.g., student, instructor, administrator, or super admin) and enroll users into tailored learning pathways without administrative overhead.

Single Sign-On (SSO) & Learner Experience

By unifying credentials across corporate systems (Outlook, intranet portals, workstations), SSO eliminates password fatigue. Simplifying access removes entry barriers, lowers IT support ticket volume for password resets, and improves course engagement and completion rates.

Enhanced Security & Reliable Reporting

• Centralized Security Governance: Integrates LMS access directly into the organization’s enterprise security framework, enforcing corporate password policies, multi-factor authentication (MFA), conditional access rules, and instant account suspension protocols.
• Precise Operational Analytics: Because user identity data originates directly from a verified central server, LMS audit logs, compliance records, and performance reports reflect precise, up-to-date organizational structures.

Our overview of LMS security features shows where directory-based access control sits among the other controls an enterprise LMS needs.

Server Prerequisites & Infrastructure Configuration

Before initializing the Active Directory integration within Paradiso LMS, host server requirements and underlying PHP configuration parameters must be met.

Server Module & Configuration Checklist

• PHP cURL Extension: Required to process outbound HTTP/HTTPS REST API requests between the LMS host and directory services or Microsoft Graph endpoints.
• Database Connection Persistence ($CFG->dbpersist): Must be explicitly disabled (false) within the application configuration. Architectural Reason: Disabling persistent database connections prevents socket and connection pool exhaustion during heavy concurrent login spikes or large batch synchronization jobs by ensuring idle database connections are terminated immediately following request execution.
• Fully Qualified Domain Name (FQDN): The LMS root URL must be configured as an FQDN accessible to network clients to properly validate authentication callbacks and identity provider metadata.

PHP Configuration Syntax

Enabling the cURL module in php.ini. For Windows environments:

extension=php_curl.dll

For Linux environments:

extension=php_curl.so

Disabling database persistence in config.php:

$CFG->dbpersist = false;

Core Domain Requirements

The LMS configuration variable $CFG->wwwroot must be defined using a Fully Qualified Domain Name (FQDN) pointing to the LMS instance (e.g., https://lms.company.com).

Architectural Requirement: Even in intranet-only network deployment scenarios, an FQDN is mandatory. Cloud identity providers such as Azure AD require exact, compliant HTTP/HTTPS URI structures for redirection endpoints and strictly reject IP addresses or unresolvable internal hostnames during OAuth token callbacks.

Before you start an LDAP connection

The items above apply to the Azure AD route. If you are connecting on-premises Active Directory over LDAP, gather these before you open the LMS settings.

• Domain controller address: The FQDN of the domain controller the LMS will query.
• Base DN: The root of the directory search, for example ou=MainOU,dc=domain,dc=com. Point it at the organizational units you actually want in the LMS, not at the whole domain.
• A dedicated service account: Read access only, limited to the OUs in scope. Do not reuse a personal or domain admin account.
• LDAPS on port 636: Use encrypted transport. Plain LDAP on port 389 sends data unencrypted.
• A network route: If the LMS sits behind a strict corporate firewall or a restricted cloud subnet, agree on the proxy or VPN path first.

Step-by-Step Azure AD & Paradiso LMS Integration Setup

This section provides the technical setup procedure for integrating Azure Active Directory (Azure AD / Microsoft Entra ID) using OpenID Connect (OIDC) and the Microsoft Graph API. Work through the steps in order. The redirect URI in Step 2 needs the most care, because a small mismatch there surfaces later as an OAuth error at callback.

Step 1: Enabling OpenID Connect Plugin in Paradiso LMS

• Navigate to: Site Administration > Plugins > Authentication > Manage authentication.
• Locate the OpenID Connect authentication plugin and click the eye icon to enable it.
• Access plugin settings at: Site Administration > Plugins > Authentication > OpenID Connect.
• Verify and configure the mandatory Endpoint URLs:
  • Authorization Endpoint: https://login.microsoftonline.com/common/oauth2/authorize
  • Token Endpoint: https://login.microsoftonline.com/common/oauth2/token

Architectural Note: The /common/ tenant endpoint enables multi-tenant handling across multiple Microsoft enterprise tenants. Single-tenant corporate deployments can replace /common/ with their specific Azure Directory (Tenant) ID (e.g., https://login.microsoftonline.com/{tenant-id}/oauth2/authorize).

Step 2: Azure AD Application Registration

1. Log in to the Azure Portal and navigate to: App Registrations > New Registration.
2. Set the Application Type to Web app/API.
3. Define the Redirect URI using the precise host format: https://your-lmsdomain/auth/oidc/

WARNING: The trailing slash (/) at the end of the Redirect URI is mandatory. Omission of this slash will cause URI validation mismatches and trigger OAuth authentication errors during callback handling.

Microsoft’s own walkthrough of registering an app in Microsoft Entra ID is a useful companion if your portal screens differ from the labels above.

Step 3: Configuring Microsoft Graph API Permissions

Navigate to API Access / Required Permissions > Add > Select an API > Microsoft Graph. Configure the following required application and delegated permissions:

Expect your security team to review these scopes, and expect the two “Read and write all users’ full profiles” entries to draw the questions. Take the functional purpose column to that review. Microsoft’s Graph permissions reference lists what each permission allows and whether it needs admin consent.

Step 4: Admin Consent & Integration Plugin Setup

• Navigate to: Site Administration > Plugins > Local plugins > Microsoft Office 365 Integration.
• Select the Setup tab.
• Under Step 1: Register LMS and Azure AD, enter the credentials generated in Azure:
  • Paste the Application (Client) ID into the corresponding field.
  • Paste the Key (Client Secret) into the appropriate field.
  • Click Save changes.
• Under Step 2: Choose connection method, select Application access and save changes.
• Under Step 3: Admin consent & additional information, locate the Admin consent option and click Provide admin consent.
• Sign in using an Azure Global Administrator account when prompted to review and grant directory-wide approvals for the requested Microsoft Graph permissions.

Once consent is granted, run the Health Check tool described in the maintenance section below, then sign in with one pilot account before you let a full sync loose. Also note the expiry date of the client secret now. An expired secret is one of the listed causes of the “Error in API call” message.

Advanced User Synchronization, Field Mapping & Account Migration

User Creation Restrictions & Filtering

To prevent provisioning unnecessary user accounts, user creation can be restricted to specific organizational subsets during automated sync (e.g., setting Department = IT). Logins can also be constrained using Regular Expressions (Regex). The following expression restricts login access exclusively to users with authorized corporate domain email addresses:

^[a-zA-Z0-9._%+-]+@company\.com$

Filters are also how you keep service accounts, shared mailboxes and test users out of the LMS. Decide what to exclude before the first sync, because removing unwanted accounts afterwards takes longer than filtering them out at the start.

Attribute Field Mapping Controls

Target Azure AD directory attributes (such as Department, Job Title, and Email) map directly to core LMS user profile fields. Synchronization behavior for mapped attributes is governed by three distinct timing rules:

• On user creation: Maps attribute values only when the account is initially provisioned.
• On every login: Overwrites profile fields with directory data during every interactive user login.
• Both: Updates profile fields during initial creation and continuously on every subsequent login.

Mapping only works as well as the directory data behind it. If Department is blank for part of your workforce, a rule that enrolls people by department will quietly skip them. Audit Department, Job Title and Email in the directory before you map them, and fix inconsistent spellings such as “HR” and “Human Resources” at the source.

Account Migration Workflow (Manual to OIDC)

To convert existing local or manual LMS user accounts to OpenID Connect authentication without losing course completion records, grades, or enrollment histories, follow this sequence:

• Confirm the Microsoft Block is enabled and visible on the user’s LMS dashboard page.
• Log in as the user account intended for conversion and locate the Microsoft Block.
• Click the Connect to Office 365 link inside the Microsoft Block.
• On the Office 365 / LMS Control Panel page:
  • Click the Office 365 Login link under Office 365 Features.
  • Click the Start using Office 365 to log in to LMS link.
  • Enter the user’s corporate Azure AD / Office 365 credentials when redirected to authenticate and complete account binding.

Identity management and account connection capabilities are governed via granular system permissions (Site Administration > Users > Permissions > Define roles):

• auth/oidc:manageconnection: Allows a user to set up or break their own connection to an Office 365 user account.
• auth/oidc:manageconnectionconnect: Allows a user to establish a link between their LMS account and an Office 365 account.
• auth/oidc:manageconnectiondisconnect: Allows a user to break their connection to an Office 365 account and revert to manual credentials.
• local/o365:manageconnectionlink: Allows an administrator or user to link an LMS account to an Office 365 account without changing the underlying LMS login method.
• local/o365:manageconnectionunlink: Allows unlinking an LMS account from an Office 365 account without changing the user’s login method.

Name changes, leavers and record retention

Two directory events cause most of the long-term cleanup work.

Name and email changes. When someone changes their legal name, their email address and User Principal Name (UPN) often change with it. If the LMS matches users on one of those values, the returning identity can look like a new person, and you end up with a duplicate account and a split training history. Decide up front which attribute your matching relies on. In directory terms, objectGUID (on-premises AD) and the object ID (Entra ID) never change, while email and UPN do. If a duplicate does appear, reconcile it with the Connections and User Matching tools described in the next section.

Leavers. Make deactivation, not deletion, your standard offboarding step. Deleting a user removes the completion history that auditors and regulators may ask to see later. Disabling the account revokes access and keeps the record. Build this into your leaver process so the directory change and the LMS outcome stay consistent.

Looking to connect more than just user accounts? Learn more about our complete LMS Microsoft Integration Solutions to unify LMS access with Microsoft Teams, SharePoint, and Outlook.

Run the first sync with a pilot group and quiet notifications

Many platforms send welcome or profile-update emails when accounts are created or changed. Imported in bulk, that can mean thousands of messages to staff who never asked for them. Before the first bulk sync, check your LMS notification settings and mute any user creation or update notifications. Run the sync against a small pilot group first and check attribute values, roles and enrollments. Switch notifications back on once the mapping is confirmed.

Cron Optimization, Maintenance Tools & Troubleshooting Matrix

Cron Performance & Photo Sync Trade-offs

Background user synchronization executes via the native LMS cron service. By default, background synchronization runs once per day at 1:00 AM local site time, processing user records in batches of 1,000 users per batch. Updating user profile photos requires balancing network load and execution performance:

• Sync via Cron Job: Profile photos are retrieved in bulk during scheduled cron execution. Architectural Impact: Each photo sync requires an individual Microsoft Graph API HTTP GET request binary stream download followed by localized image processing (GD/ImageMagick), which significantly increases background cron runtime and server CPU utilization.
• Sync on Login: User photos update on-demand when an individual user logs into the LMS. This offloads processing from the background cron service and distributes resource consumption across interactive sessions, introducing only minor latency during initial login screen loading.

LMS Maintenance & Diagnostic Tools

Administrative diagnostic and maintenance utilities are accessible via: Site Administration > Plugins > Local plugins > Microsoft Office 365 Integration > Tools.

• Tenants: Configures and manages additional Office 365 tenants for complex multi-tenant enterprise deployment models.
• Health Check: An automated diagnostic script that tests Azure configuration validity, endpoint connectivity, token validity, and API response status.
• Connections: Displays active identity linkages, enabling administrators to inspect, manually connect, or disconnect LMS user accounts across systems.
• User Matching Tool: Reconciles local LMS accounts with Office 365 users in bulk via CSV upload processed during cron execution. The CSV file must conform strictly to the following schema:

  username, Office 365 username, match flag
  jdoe, jdoe@company.com, 1

• Resync users in groups for courses: Forces a manual resynchronization of LMS course enrollments to Office 365 group memberships if course group rosters fall out of alignment.
• Recreate deleted Office 365 groups: Automatically re-provisions missing Office 365 groups if they were manually removed from Azure AD or the Microsoft 365 admin center.
• Generate debug data package: Compiles and exports a sanitized environment configuration package for support escalation and advanced diagnostic analysis.

Debug Logging & Error Diagnostic Workflow

1. Navigate to both OpenID Connect settings (Site Administration > Plugins > Authentication > OpenID Connect) and Office 365 Integration settings (Site Administration > Plugins > Local plugins > Microsoft Office 365 Integration > Options tab > Advanced settings).
2. Select the Record debug messages checkbox on both pages to begin capturing detailed error traces.
3. Review recorded log outputs by navigating to Site Administration > Reports > Logs.
4. Set the report drop-down filters to Site errors and All activities to isolate authentication and synchronization events.

Troubleshooting Matrix

Pre-Go-Live Checklist for LMS Active Directory Integration

Run through this list before you switch the integration on for the whole organization.

1. Choose the route: LDAP/LDAPS for on-premises Active Directory, or OIDC with Microsoft Graph for Azure AD / Entra ID.
2. Confirm the server basics: The PHP cURL extension is enabled, $CFG->dbpersist is false, and $CFG->wwwroot is a resolvable FQDN.
3. Verify the connection details: For LDAP, confirm the domain controller address, Base DN, service account permissions and LDAPS route. For Azure AD, confirm the redirect URI ends with a trailing slash.
4. Grant permissions and consent: Add the Microsoft Graph permissions and have a Global Administrator provide admin consent.
5. Audit directory data: Clean Department, Job Title and Email before mapping them.
6. Set filters and mapping rules: Decide which accounts to exclude, and choose the timing rule for each mapped attribute.
7. Mute notifications: Switch off user creation and update emails before the first bulk sync.
8. Pilot first: Sync a small test group and check attribute values, roles and enrollments.
9. Turn on diagnostics: Enable Record debug messages and run the Health Check tool.
10. Diarize the client secret expiry: Put the date in a shared calendar so the renewal is not a surprise.

Getting LMS Active Directory Integration Right

A working LMS Active Directory integration is mostly decided before the first login. Get the FQDN, the redirect URI with its trailing slash, the Graph permissions and the admin consent right, clean up your directory attributes, and pilot with a small group. After that, the integration runs on its own: new hires appear, role changes follow, and leavers lose access without a ticket. When something does break, the Health Check tool and debug logging will usually show you where.

Technical Support & Support Escalation

For specialized deployment scenarios, multi-tenant architectural configurations, or custom integration support, contact the Paradiso eLearning technical support team directly at sales@paradisosolutions.com.

Frequently Asked Questions About LMS Active Directory Integration

What is LMS Active Directory integration?

LMS Active Directory integration links your learning management system to your corporate directory. Employees sign in with their existing credentials, and the LMS creates, updates and deactivates accounts from directory data. Group membership and attributes such as department or job title can also place learners into cohorts and assign roles automatically, which removes most manual account administration.

Does Paradiso LMS work with both on-premises Active Directory and Azure AD?

Yes. For on-premises Active Directory Domain Services, Paradiso LMS uses direct LDAP or LDAPS queries against your domain controllers. For Azure Active Directory, now Microsoft Entra ID, it uses OpenID Connect together with the Microsoft Graph API for single sign-on and scheduled background user synchronization. Which one fits depends on where your user identities are managed.

Why does Azure AD need a fully qualified domain name even on an intranet?

Cloud identity providers such as Azure AD require exact, compliant HTTP/HTTPS URI structures for redirection endpoints. They reject IP addresses and unresolvable internal hostnames during OAuth token callbacks. Set $CFG->wwwroot to an FQDN such as https://lms.company.com, even if the LMS is only reachable inside your network, or authentication callbacks will fail.

Why does my Azure AD login fail with a redirect URI error?

A common cause is a mismatch between the Redirect URI registered in Azure AD and the one the LMS sends. The URI must follow the format https://your-lms-domain/auth/oidc/ and the trailing slash is mandatory. Open the Azure App Registration, compare the value character by character, and correct it. Do not rely on a visual check.

How often does user synchronization run?

By default, background synchronization runs once per day at 1:00 AM local site time through the native LMS cron service, and it processes user records in batches of 1,000 users. Profile photos are the main variable. Syncing them in the cron job increases runtime and CPU use, while syncing them at login spreads the load across user sessions.

Can I move existing manual accounts to Azure AD login without losing course history?

Yes. Each user can connect their existing account through the Microsoft Block on their dashboard by choosing Connect to Office 365 and signing in with their corporate credentials. The account is bound to the Azure AD identity, so course completion records, grades and enrollment histories stay attached. Administrators can also bulk-match accounts with the User Matching Tool and a CSV file.

What should happen to an employee’s LMS account when they leave?

Deactivate the account instead of deleting it. Deactivation revokes login access, while the completion and training history stays in the LMS for audits and compliance reporting. Because account deactivations in Active Directory synchronize to the LMS, make disabling the directory account a fixed step in your offboarding process, which keeps the audit trail intact.