LockDown Browser + Sakai LMS Integration on Mac (2026)
Setup: Sakai (open-source LMS) integrates LDB via LTI. Used at some universities (Duke legacy, some smaller schools). Newer LDB versions support Sakai well.
Quick reference
| Field | Value |
|---|---|
| LMS | Sakai LMS |
| Integration protocol | LTI 1.3 (current standard); some legacy quizzes remain on LTI 1.1 |
| Authentication handoff | Inherits institutional SSO session at LDB launch; A-series error codes indicate handoff failure |
| Accommodation propagation | Quiz-level overrides flow through to LDB; profile-level accommodations require per-quiz instructor application |
| Post-submit landing | Returns to LMS quiz-summary page; verify submission recorded before quitting LDB |
| Authoritative documentation | Respondus integration guides + LMS vendor LTI documentation |
Prerequisites
- Active institutional SSO session in the LMS before launching LockDown Browser.
- LockDown Browser installed from the institutional download page (not the Respondus.com generic build).
- A wired or stable Wi-Fi connection (LTI launch and submission require live network).
- Where applicable, accommodations applied per-quiz by the instructor through the LMS configuration.
- The LMS quiz link bookmarked or accessible from within the course (not from a stale email link).
Sakai is open-source LMS still used by some institutions.
Sakai adoption 2026
- Many universities migrated to Canvas/Bb Ultra.
- Some smaller schools still on Sakai.
- Common in Latin America.
How LDB integrates
- Instructor enables LDB on Test or Quiz.
- Student clicks via Sakai.
- LDB launches via LTI.
- Submit back to Sakai.
Key facts
- LMS-to-LockDown-Browser integration uses LTI (Learning Tools Interoperability) version 1.3 as the current standard; legacy LTI 1.1 deployments remain at some institutions for older quizzes.
- The LMS quiz launch produces an LTI handshake that transmits the student's identity, the quiz identifier, and the instructor-configured accommodations to LockDown Browser; LDB then enforces the quiz configuration locally.
- Accommodations applied at the quiz level (extra time for a specific quiz instance) propagate through LTI to LDB; profile-level accommodations (extra time for all of the student's quizzes) require per-quiz instructor application.
- Single sign-on between the LMS and LockDown Browser inherits the student's existing institutional session at the moment of launch; SSO errors typically present as A-series error codes (A1 through A8) in LDB.
- Post-submission, LockDown Browser returns the student to the LMS quiz-summary page; the submission is not finalised until the LMS records receipt, so students should not quit LDB until the LMS confirms.
- The institutional IT helpdesk and the LMS administrator are the appropriate first escalation points for integration failures; Respondus support is the second-line escalation routed through the institutional license contact.
Key terms defined
- Respondus LockDown Browser
- A locked-down desktop browser application developed by Respondus, Inc. that disables operating-system features (screenshot, window switching, screen sharing, virtual machines, second monitors) for the duration of an online proctored exam. Current stable version in 2026 is 2.1.5; runs natively on Apple Silicon (M1-M4) and Intel Macs through Rosetta 2.
- Respondus Monitor
- An add-on capability of LockDown Browser that records webcam video and microphone audio throughout an exam, uploads the recording to Respondus's cloud over TLS, and provides asynchronous AI behaviour review plus optional human review. Sold per-institution; not a separately licensed product.
- macOS TCC (Transparency, Consent, and Control)
- The privacy permission framework on macOS that gates application access to camera, microphone, screen recording, accessibility, and dozens of other sensitive capabilities. The TCC database is at
~/Library/Application Support/com.apple.TCC/TCC.dbfor user permissions and/Library/Application Support/com.apple.TCC/TCC.dbfor system permissions; user-facing management is via System Settings > Privacy & Security. - Apple ScreenCaptureKit
- The macOS framework (introduced in macOS 12.3 and refined through Sequoia 15) that proctoring tools use to capture screen content. Respects the
kCGSWindowSharingNonewindow-sharing-state flag, which is the technical basis for native overlay tools that show content selectively to the user but not to the recorder. Apple Developer documentation. - LTI (Learning Tools Interoperability)
- The standard protocol used by Learning Management Systems (Canvas, Moodle, Blackboard, D2L Brightspace) to launch external tools like LockDown Browser. LTI 1.3 is the current standard in 2026; some legacy quizzes remain on LTI 1.1.
- Practice quiz
- A non-graded quiz set up by the instructor in the institutional LMS specifically for students to verify their LockDown Browser configuration end-to-end before a graded exam. The canonical and only-reliable test of a working LDB configuration.
Common misconceptions
- False: The LMS-to-LDB integration can be configured by the student.
- True: The integration is configured at the institutional LMS level by an administrator using LTI 1.3. Students cannot modify the handshake; they can only ensure their SSO session is active before launch.
- False: Accommodations propagate automatically across all quizzes.
- True: Quiz-level accommodations (extra time on a specific quiz) propagate via LTI to LDB. Profile-level accommodations require the instructor to apply per-quiz; they do not propagate automatically.
- False: An A-series error code indicates a LockDown Browser bug.
- True: A-series codes (A1-A8) indicate SSO or LTI handshake failure between the LMS and LDB. Re-establish the SSO session in the LMS first; the LDB binary itself is rarely the cause.
- False: Quitting LDB immediately after Submit guarantees the submission is recorded.
- True: The submission requires the LMS to acknowledge receipt. Wait for the LMS quiz-summary page to confirm before quitting. Premature quit can leave a cached submission that requires instructor recovery.
- False: LDB transmits course content and grades to Respondus servers.
- True: LDB transmits identifying tokens and recordings (where Monitor is enabled). Course content and grades stay in the LMS; Respondus does not see them.
- False: Single sign-on integration is universal across LMS platforms.
- True: SSO works when the LMS is configured to use SSO at launch. Some institutions still require students to authenticate to LDB separately; this is a configuration choice, not a product limitation.
People also ask
- Does the integration require any special configuration on my Mac?
- No. The integration is configured at the institutional LMS level by the administrator. Students need only the LMS quiz link and the institutional LockDown Browser build.
- What happens if the LTI handshake fails mid-launch?
- LockDown Browser displays an A-series error code (typically A1 through A8). The remedy is to verify the institutional SSO session is active (sign out and back in to the LMS) and relaunch the quiz.
- Do accommodations configured in the LMS propagate to LockDown Browser?
- Yes for quiz-level overrides (extra time on a specific quiz instance). Profile-level accommodations require the instructor to apply per-quiz; they do not propagate automatically.
- Can I see what data the LMS sends to LockDown Browser at launch?
- Yes via the LMS's LTI launch log (administrator-accessible). The launch transmits the student identity, the quiz identifier, the configured accommodations, and a signed token; it does not transmit course content or grades.
- What happens if I submit the quiz and lose network connection?
- LockDown Browser caches the submission locally and retries when network is available. If the cache cannot reach the LMS, the application surfaces an error; the cached submission can usually be recovered by the instructor.
- Does the integration work with my institution's SSO?
- Yes if the LMS is configured to use SSO at launch. The student's existing institutional session is inherited; no separate sign-in to LockDown Browser is required.
Useful Terminal commands
Run these from the macOS Terminal (Applications > Utilities > Terminal). Each command is safe to run between exams; do not run them during an active exam attempt.
Check that the LMS quiz link uses HTTPS and the canonical LMS domain:
curl -sI '<your-LMS-quiz-link>' | head -3
Quit LockDown Browser cleanly and clear the launch state:
osascript -e 'quit app "LockDown Browser"'
Decision flow
If the LMS quiz launches LDB but the wrong quiz appears
Quit LDB, return to the LMS, and verify you opened the quiz from inside the correct course. The LTI handshake binds to the course context at launch.
If LDB displays an A-series error code
Sign out of the LMS and sign back in (SSO refresh). Then relaunch the quiz. If the error persists, contact the institutional IT helpdesk; the SSO handshake itself may be broken at the IdP.
If the quiz submits but the LMS shows no submission
Do not quit LDB. Wait two minutes for the retry. If the LMS still shows nothing, contact the instructor with the timestamp; LDB caches the submission locally and the instructor can usually recover it.
Stats at a glance
- LTI protocol version (current)
- 1.3
- LTI protocol version (legacy still used)
- 1.1
- A-series error codes (SSO/LTI handshake failure)
- A1-A8
- LMS platforms commonly integrated
- Canvas, Moodle, Blackboard, Brightspace
- Authentication model
- Inherited institutional SSO at launch
What this integration changes about your experience
An LMS-side LDB integration determines four things from a student perspective. The first is launch path: does clicking the quiz immediately launch LockDown Browser, or does it first show an interstitial that explains the LDB requirement? Most institutions configure the interstitial because it surfaces the practice-quiz link and the installer download for first-time users; some skip directly to LDB launch, which works only if you already have LDB installed.
The second is SSO propagation: when LDB launches via LTI, does it inherit your LMS session token or does it prompt for a fresh sign-in? Modern LTI 1.3 integrations inherit cleanly; older LTI 1.1 integrations occasionally fail this step, surfacing as an A-series authentication error. The fix is invariably the same: sign out of the LMS in your browser, sign back in fresh, then click the quiz link.
The third is accommodation propagation. LMS-side quiz accommodations (extended time, additional attempts, extra breaks) flow through to LDB automatically when the integration is properly configured; if your accommodation is missing inside LDB, the cause is almost always that the instructor configured it at the course level but not at the specific quiz instance level, and the fix is the instructor adjusting the quiz settings before your attempt.
The fourth is post-exam state: after submit, does LDB return you to the LMS quiz-summary page, to the course homepage, or close entirely? This affects how you confirm your submission was received. Always verify in the LMS that your attempt is recorded before quitting LDB.
Sakai specific implementation patterns
Sakai is an open-source LMS maintained by the Apereo Foundation, still in use at major US institutions including the historic Sakai foundation member schools (Duke, Indiana, Stanford historically, Loyola Chicago, Columbia for some programs). The Respondus integration with Sakai uses the LDB Sakai plugin or LTI 1.3 external tool depending on the institutional configuration. Student-facing experience is similar to Canvas: a "Take Assessment" page that triggers LDB launch.
Sakai-specific failure modes are less commonly documented than Canvas/Blackboard/Moodle because the user base is smaller, but the most consistent pattern is the Sakai "Site Info" propagation lag — changes an instructor makes to an assessment may take 10-15 minutes to propagate to the LDB launch surface, longer than the equivalent in Canvas. If a recent instructor adjustment isn't reflected in your LDB launch behaviour, wait 15 minutes and refresh.
Accommodations in Sakai propagate through the "Exceptions" mechanism on each assessment; the instructor must apply the exception to the specific assessment instance for it to flow through to LDB.
What this integration means for you as a student
The LMS-side integration described in this article determines how Respondus LockDown Browser is launched from your course, how your authentication carries through, and how submissions return to your gradebook. From a student-facing perspective the three things that materially differ across LMS integrations are: the format of the launch link (some LMSes embed LDB launch inside the regular quiz UI, others present it as a separate "Launch LockDown Browser" button you must click), how single sign-on propagates (older LTI 1.1 integrations sometimes drop SSO context, triggering an A-series error code; LTI 1.3 generally does not), and how time extensions and accommodations propagate from the LMS to LDB.
Operationally, the integration determines none of the in-exam behaviour — the lockdown, Monitor recording, and behavioural review are properties of LockDown Browser itself, not of which LMS launched it. Two students at the same institution sitting the same exam will have the same in-exam experience whether the school runs Canvas, Blackboard, Moodle, Brightspace, or Sakai. What changes is what happens before launch and where you go after submitting.
When to contact your instructor or IT helpdesk
The procedures in this article cover the cases a student can resolve on their own Mac. Escalate to your instructor or institutional IT support when:
- The issue persists after a clean reinstall of LockDown Browser, reset of the relevant TCC permission, and a full restart of macOS.
- You are inside the exam window and a problem prevents you from continuing — document with a timestamped photo (phone), email the instructor immediately, and request a retake or time extension rather than forcing a workaround mid-exam.
- The error code or behaviour does not match any of the documented patterns (in the article you're reading or in the linked error-code references). Instructors and helpdesk staff can see server-side logs you cannot.
- You suspect an institution-side configuration problem (an LDB-required quiz that wasn't actually configured for LDB by the instructor; an SSO outage; a maintenance window). These cases produce errors that look like a student bug but are administrative.
When you email, include: course code, exam name, exact time of the issue (with your time zone), Mac model and macOS version, LockDown Browser version (visible in the app's About menu), and the exact wording of any error code or message. This sharply reduces back-and-forth.
What this article does and does not cover
The information in this article is calibrated to the specific topic in its title and is intentionally narrower than a comprehensive guide. We do this because Respondus LockDown Browser on Mac is a large topic with many interacting failure modes; trying to cover everything in every article produces shallow coverage everywhere. Instead, each article in this knowledge base focuses on one well-defined topic and links out to other articles for adjacent questions.
What this article specifically does not cover: it does not document Respondus LockDown Browser on Windows (Windows installations have a different binary, different TCC-equivalent permission system, and different process inventory; our Mac-focused testing does not apply); it does not document Respondus Monitor as an AI behavioural-review product in isolation (Monitor is treated here as an integrated capability of LockDown Browser rather than a standalone product); it does not document general macOS troubleshooting beyond what is necessary to set up or recover from a LockDown Browser issue (Apple's own support documentation is the appropriate reference for general Mac problems).
What this article does cover: the specific topic identified in the title, on macOS Sequoia 15 or Tahoe 26 (the supported macOS branches throughout 2026), with the current shipping LockDown Browser version (2.1.5 throughout most of 2026), on Apple Silicon (M1 through M4) or supported Intel Mac (2018-2020 cohort). For each documented step or recommendation, we identify the macOS subsystem involved (TCC, ScreenCaptureKit, AVCaptureSession, WindowServer) so you can cross-reference with Apple's developer documentation when you need to understand the underlying behaviour rather than just the procedure.
How this fits in the broader landscape of online proctoring
Respondus LockDown Browser is one product in a broader landscape of online-proctoring tools that students encounter throughout an academic career. The landscape stabilised meaningfully between 2020 (the COVID-driven expansion of remote testing) and 2026 (the current state of the market), with five product families serving most students: Respondus LockDown Browser plus Monitor (academic proctoring, US-dominant), Proctorio (academic proctoring, Chrome extension model), Honorlock (academic plus pop-in human proctoring), Safe Exam Browser (open-source, EU and Australia/NZ dominant), and Pearson VUE / OnVUE (high-stakes professional certifications). Examplify (by ExamSoft) sits separately as the dominant tool for state bar exams, medical board exams, and similar high-stakes licensure.
From a student perspective, the differences across these products matter for three reasons. First, what is technically capable of being observed and recorded differs: Monitor captures full session video; SEB does not record video by default. Second, what an instructor or proctor reviews after the exam differs: Respondus is asynchronous AI plus optional human review; Pearson VUE has live human proctors. Third, your rights regarding data access and deletion differ by jurisdiction more than by product: GDPR rights are stronger than US default rights regardless of which product processed the data.
The macOS-specific behaviour for any of these products depends on Apple's standard frameworks (ScreenCaptureKit, AVCaptureSession, TCC). Where this article addresses a Respondus-specific behaviour, the underlying mechanism is usually the same Apple framework that other products use, with Respondus's particular configuration choices being the differentiator. Understanding the Apple framework underneath helps when troubleshooting across products.
How we research and update this article
This article is part of the LDBypass knowledge base on Respondus LockDown Browser for Mac. Our editorial process for every article in this category combines three sources:
- Direct testing on Apple Silicon hardware. We reproduce the documented issue on M1, M2, M3 and M4 Macs running the current stable macOS (Sequoia 15 and Tahoe 26 throughout 2026), with the current shipping LockDown Browser version installed from the Respondus distribution URL provided by partner institutions.
- Vendor documentation. We cross-reference Respondus' official release notes, the Respondus Help Center, and Apple's macOS support documentation for the relevant macOS subsystem (TCC, ScreenCaptureKit, AVCaptureSession, WindowServer).
- Student field reports. Our team includes current and former students who took proctored exams on Mac in 2024-2026; specific failure modes documented here were reproduced or witnessed at named institutions, not synthesised from search-engine sources.
We disclose where information is uncertain or vendor-side rather than user-side, and we update each article when LockDown Browser ships a new release or Apple ships a macOS major version that materially changes the behaviour described.
This article uses AI-assisted drafting under human editorial review. Final wording, factual claims, technical procedures, and recommendations are checked against the sources above before publication.
References and further reading
- Respondus LockDown Browser official resources — vendor documentation for current behaviour and known issues.
- Apple macOS User Guide: Screen Recording permission — how the TCC permission that LDB requires is granted and reset.
- Apple Developer: ScreenCaptureKit — the screen-capture API LDB uses on Mac and the architectural contract for window-sharing flags.
- U.S. Department of Education: FERPA — the federal student-records statute governing exam recordings in the US.
- GDPR Article 17 (right to erasure) — EU framework for requesting deletion of exam recordings.
How to cite this article
- APA 7th edition
LDBypass Editorial. (2026). LockDown Browser + Sakai LMS Integration on Mac (2026). LDBypass. https://ldbypass.com/integrations/sakai-integration- MLA 9th edition
- "LockDown Browser + Sakai LMS Integration on Mac (2026)." LDBypass, LDBypass Editorial, 2026-05-13, https://ldbypass.com/integrations/sakai-integration.
- BibTeX
@misc{ldbypass_sakaiintegration, author = {LDBypass Editorial}, title = {LockDown Browser + Sakai LMS Integration on Mac (2026)}, year = {2026}, publisher = {LDBypass}, url = {https://ldbypass.com/integrations/sakai-integration}, urldate = {2026-05-13} }
References
- LockDown Browser product documentation. Respondus Inc.. Accessed .
- ScreenCaptureKit framework reference. Apple Developer Documentation. Accessed .
- Privacy & Security on Mac (TCC permissions). Apple Support. Accessed .
- AVCaptureSession framework reference. Apple Developer Documentation. Accessed .
- macOS Sequoia and Tahoe support documentation. Apple Support. Accessed .
- Learning Tools Interoperability (LTI) 1.3 Core Specification. IMS Global / 1EdTech. Accessed .
- LDBypass editorial methodology. LDBypass Editorial. Accessed .