Moodle user provisioning is not merely a technical task. It represents a fundamental organizational decision about identity management. When an organization integrates Single Sign-On (SSO) with Moodle, it aims to streamline access and manage user lifecycles efficiently.
Without a clear decision about which system owns user identity, these projects add complexity rather than removing it. What follows are the decisions that determine whether the integration works.
I recently migrated my site to Mindfield from another host, and the experience couldn’t have been better. Mindfield kept working until they were certain that my site was operating as well as it was before, and they even helped clean up a few issues to improve my site’s performance – issues my prior host never mentioned. I also found Mindfield’s communication to be excellent. Before the migration, they prepared me for what to expect, and during the migration they kept me well-informed.
Jim Benedek
review Source: Google Reviews
Outline
- Choosing the Authoritative System of Record for Identity
- Distinguishing Authentication from Authorization in SSO
- User Provisioning and Deprovisioning as Governance Policy
- Managing Membership Status and Course Access
- Data Ownership and Reconciliation Across Platforms
- Navigating Complex Moodle User Provisioning with Expert Guidance
- Frequently Asked Questions (FAQs)
Choosing the Authoritative System of Record for Identity
Every Moodle user provisioning strategy rests on one decision: which single system is the authoritative record of who your users are. That choice is organizational before it is technical, and it dictates every configuration and policy that follows.
Why a Single Source of Truth is Essential
A single source of truth means every connected system, Moodle included, reads the same definitive set of user data. When more than one system can create or change that data, names, email addresses and profile fields drift apart, and someone has to reconcile them by hand.
Evaluating Candidate Systems: AMS, CRM, SIS
The authoritative system often depends on your organization’s primary function and existing infrastructure. For example, professional associations typically point to their Association Management System (AMS) as the identity source. This is because it holds definitive membership data.
Private schools, by contrast, usually rely on their Student Information System (SIS). This system manages student rosters and academic records. Continuing education providers and training companies usually hold the learner profile and its engagement history in their Customer Relationship Management (CRM) system. Each system excels at holding specific types of data, making its selection a strategic alignment with business priorities.
Moodle as the System of Record: When it Makes Sense
Moodle can legitimately be the system of record when no upstream system holds the definitive roster, which is usually a smaller organization where Moodle is the only platform managing users. It then controls user creation and profile updates outright.
Organizational Mandate Over Technical Preference
The choice of the authoritative system is a governance decision that belongs to the organization, not solely to the integration vendor or technical team. It requires understanding manual vs automated business processes and data ownership. Moodle’s default behavior, where user profile fields are Unlocked and updated On creation, means that Moodle quietly becomes a system of record for user-editable data the moment an account is created, unless deliberately configured otherwise.
Therefore, administrators must explicitly use the “Lock value” setting. Moodle’s help text clarifies: “Use this option if you are maintaining this data in the external auth system.” This ensures external systems truly remain authoritative for specific fields.
Distinguishing Authentication from Authorization in SSO
Many SSO projects inadvertently collapse the crucial distinction between authentication and authorization, leading to unexpected access issues. Single Sign-On primarily addresses authentication, answering the question, “Is this the person they claim to be?” It verifies identity. Authorization, on the other hand, answers, “What is this person allowed to do or access?” This includes course enrolment, role assignments, and capabilities within Moodle.
The Scope of Single Sign-On
OAuth 2, Shibboleth and the widely used third-party SAML2 plugin all confirm a user’s identity against an external directory and then create or update a Moodle account. Their function stops there. None of them decides what courses that user can open or what permissions they hold, and assuming otherwise is the common pitfall.
The Cost of Collapsing the Distinction
When authentication and authorization are conflated, organizations end up with users who can log into Moodle but cannot reach their courses, or worse, who can reach courses they should never have seen.
Moodle’s Separate Subsystems
Authorization is its own configuration, and it is where Moodle roles and permissions stop working if nobody owns it. The separation is architectural. Core authentication plugins, External database, LDAP and OAuth 2 among them, verify credentials and maintain the account, and nothing more. It is the same split behind a familiar class of Moodle course enrolment issues, where the sign-in works and the enrolment never arrives.
Moodle ships an LDAP authentication plugin and, separately, an LDAP enrolment plugin. Two plugins, two configurations, two policies, and the second one is nobody’s default assumption.
User Provisioning and Deprovisioning as Governance Policy
Automated user provisioning and deprovisioning are often seen as purely technical tasks, a matter of “plumbing” between systems. However, the mechanisms are only half the equation. The policies governing who gets an account, on what trigger, and what happens when that trigger reverses, are crucial governance decisions.
No vendor can make these choices for a client, as they reflect an organization’s unique operational needs and compliance requirements.
Defining Account Lifecycle Triggers
Name the triggers. Does an account appear when a student registers in the SIS, when a member joins the AMS, or when an employee is added to the HR system? And what event reverses it?
Is it a membership lapse, an employee departure, or course completion? These triggers directly inform the configuration of Moodle’s authentication plugins. Moodle’s site setting Prevent account creation when authenticating is off by default, meaning that “When a user authenticates, an account on the site is automatically created if it doesn’t yet exist.” This default provisioning policy means anyone authenticated by the identity provider will receive a Moodle account.
Moodle’s Default Provisioning Behaviors
Moodle says as much itself. The OAuth 2 settings page carries a warning: “This authentication plugin allows users to create accounts on your site. You may want to enable the setting ‘authpreventaccountcreation’ if you use this plugin.” The default favours access over control.
When considering deprovisioning, plugins like External database and LDAP offer a Removed ext user setting. The options are:
- Keep internal: The default, which retains the Moodle account even if the user is removed from the external source.
- Suspend internal: The Moodle account is suspended, preventing login but preserving data. These users are automatically restored if they reappear in the external source.
- Full delete internal: The Moodle account is permanently removed. A fully deleted account does not automatically return if the person rejoins the external system.
Strategic Deprovisioning: Suspensions vs. Deletions
Suspension suits a temporary absence or a lapsed membership: grades, certificates and forum posts survive, and the account comes back on its own when the person reappears in the external source.
Full deletion looks tidier and is not reversible. It takes the certification history and academic record with it, which is exactly what an alumni service or an audit later asks for. The default, Keep internal, keeps the account instead.
Managing Membership Status and Course Access
Nothing in Moodle user provisioning punishes a change in someone’s status more quietly than the gap between how Moodle treats their account and how it treats their course access.
The Contradiction of Moodle Defaults
Moodle’s default for the Removed ext user setting on authentication plugins is Keep internal, which ensures the user’s account persists. However, the default for the External unenrol action setting on enrolment plugins, such as external database enrolment or cohort sync, is Unenrol user from course. This means a user could retain a valid Moodle login (because their account is kept) but lose access to all their courses (because they are unenrolled).
This combination creates a scenario where a lapsed member, for example, can still log in but finds their in-progress courses suddenly inaccessible and their associated data potentially purged.
Handling Lapsed Members and Alumni
Consider a lapsed member halfway through a certification course. If the external system removes their membership, Moodle’s default enrolment action would unenrol them. Moodle’s help text for this setting warns, “Please note that some user data and settings are purged from course during course unenrolment.” This means their progress, grades, and submissions for that course could be lost.
Similarly, a departed staff member might still need access to their certification history for future employment. Preserving it is the same problem as deleting Moodle accounts without losing course history. If their account is fully deleted or unenrolled from relevant courses, retrieving that history becomes difficult. Strategic choices for the External unenrol action setting are crucial:
- Unenrol user from course: The default, which removes course access and may purge data.
- Keep user enrolled: Preserves course access despite changes in external status (not available for cohort sync).
- Disable course enrolment: Keeps the user enrolled but suspends their ability to interact with the course.
- Disable course enrolment and remove roles: Suspends enrolment and removes associated roles. Moodle’s source notes this can make users disappear from gradebooks.
Impact on Gradebook and Course Data
An unenrolled user can vanish from the gradebook, forum discussions and activity reports even though the account itself is untouched.
That breaks reporting, auditing and any complete record of learner achievements. Decide first whether historical course data for inactive users has to survive, because that answer sets both deprovisioning settings.
Data Ownership and Reconciliation Across Platforms
Once Moodle user provisioning is running, the AMS, CRM or SIS and Moodle each hold a version of the same person, and the versions will not stay identical. Someone has to be accountable for deciding which one wins.
The Challenge of Distributed Identity Data
A user’s name, email and organizational role are typically held upstream and synchronized into Moodle. Leave the profile fields Unlocked, as they ship, and the user can edit their copy, so the two versions separate.
A user updates their preferred email address in Moodle. The external system is still the authoritative source and is set to update Moodle only on creation, so the change never travels upstream, and the mail keeps going to the old address.
Reconciling Discrepancies
Reconciliation happens in the authentication plugin’s field mappings. The “Update local (field)” setting offers:
- On creation: Moodle copies the external value once, at account creation. Any subsequent changes in the external system will not update Moodle, and the user can edit the field locally. This effectively makes Moodle the system of record for that field after creation.
- On every login: Moodle updates the field with the external value each time the user logs in. This ensures Moodle’s data always reflects the authoritative external system.
Setting “Lock value (field)” to Locked stops the user editing that field in Moodle, which is what keeps the external system authoritative for it. Left at the defaults, ownership of every user-editable field moves to Moodle without anyone deciding it should.
Accountability for Data Integrity
Whose version wins when they disagree? The designated system of record, the AMS, CRM or SIS, and Moodle configured to reflect it.
That is a decision for organizational leaders, not only for IT. In practice a disagreement looks like a completion certificate issued under an outdated name held in Moodle, months after the member updated it in the AMS. Someone has to own data quality across all of it, by name.
Navigating Complex Moodle User Provisioning with Expert Guidance
A workable Moodle user provisioning strategy is a governance question before it is a configuration one, and the two have to be settled together. Mindfield Consulting’s Moodle specialists work through the system-of-record decision with you, then configure Moodle to hold that line. That covers the account lifecycle, the enrolment behaviour behind it, and the reconciliation rules across every connected platform. The result is an integration that still matches your policy a year after it goes live.
Frequently Asked Questions (FAQs)
This article may contain conceptual illustrations to help support the article content.
