SharePoint en OneDrive: IDCRL is definitief uitgefaseerd – zo herstelt u legacy-koppelingen

Een SharePoint Online- of OneDrive for Business-koppeling die sinds 2026 plotseling niet meer kan aanmelden, kan nog afhankelijk zijn van IDCRL: de legacy Identity Client Run Time Library-authenticatie. Microsoft heeft deze route definitief geblokkeerd. Sinds 1 mei 2026 kan IDCRL voor SharePoint Online en OneDrive for Business niet meer worden ingeschakeld. Dit artikel is daarom geen vooruitblik op een komende wijziging, maar een herstel- en migratiegids voor organisaties die nog legacy-scripts, eigen applicaties of oude CSOM-code tegenkomen.

De impact is gericht. Normale moderne aanmeldingen in Microsoft 365 gebruiken al OpenID Connect en OAuth. Het risico zit vooral bij achtergrondtaken en maatwerk dat nog gebruikersnaam-wachtwoordauthenticatie, een legacy-cookie of een oud endpoint gebruikt. Behandel een storing dus niet als een algemeen SharePoint-probleem en probeer IDCRL niet opnieuw open te zetten: er is na de definitieve blokkade geen tijdelijke terugvaloptie meer.

Wat is IDCRL en wat is de huidige status?

IDCRL staat voor Identity Client Run Time Library. Microsoft gebruikte het in oudere SharePoint Online- en OneDrive-scenario’s om een legacy-aanmeldcookie te verkrijgen. Microsoft heeft die aanpak uitgefaseerd ten gunste van OpenID Connect en OAuth, onder meer omdat moderne tokens en de Microsoft Authentication Library (MSAL) beter aansluiten op actuele beveiligings- en toegangsmodellen.

In de eerste fase van 2026 kon legacy-authenticatie tijdelijk worden heringeschakeld voor een beperkte overgangsperiode. Die periode is voorbij. Vanaf 1 mei 2026 wordt IDCRL door SharePoint Online en OneDrive for Business permanent geblokkeerd en kan de tenantinstelling niet meer als noodoplossing worden teruggezet. Leg daarom geen herstelplan vast dat afhankelijk is van een oude PowerShell-toggle of een uitzondering voor een enkel script.

Welke koppelingen lopen risico?

Onderzoek vooral automatisering die buiten het normale browserpad draait. Microsoft noemt twee herkenbare categorieën. De eerste is code die de klasse SharePointOnlineCredentials gebruikt. De tweede is directe communicatie met legacy-endpoints om een token of cookie uit te wisselen. Een script kan jarenlang probleemloos hebben gedraaid en pas zichtbaar falen wanneer het opnieuw wordt uitgevoerd, een wachtwoord verandert, een server wordt vervangen of een proces na een storing opnieuw start.

CSOM-code of PowerShell-automatisering met SharePointOnlineCredentials, opgeslagen gebruikersnaam en wachtwoord of een oudere cookie-aanpak.
Eigen integraties die https://login.microsoftonline.com/rst2.srf of https://<tenant>.sharepoint.com/_vti_bin/idcrl.svc benaderen.
Onbeheerde achtergrondtaken op servers, scheduled tasks, middleware of oude build- en exportprocessen waarvan de oorspronkelijke eigenaar niet meer bekend is.
Historische documentatie die een serviceaccount met wachtwoord als standaardroute voor SharePoint Online beschrijft.

Begin met feiten, niet met een brede wijziging

Een HTTP 401- of 403-fout bewijst op zichzelf niet dat IDCRL de oorzaak is. Ook een verlopen certificaat, ontbrekende Entra-toestemming, gewijzigde Conditional Access-policy of onjuist token-audience kan dezelfde gebruikerservaring opleveren. Verzamel daarom vóór een code- of beleidswijziging de foutmelding, het uitvoermoment, de betrokken workload, het gebruikte account en de aangeroepen URL. Koppel die gegevens aan de eigenaar van de integratie.

Microsoft beschrijft in Microsoft Purview Audit de activiteit IDCRLSuccessSignIn als ingang om historische IDCRL-aanroepen te vinden. Gebruik die informatie als aanwijzing, voor zover de auditretentie in de tenant nog gegevens bevat. Het ontbreken van historische resultaten is geen garantie dat geen enkele oude toepassing meer bestaat; een taak kan buiten de retentieperiode vallen of slechts incidenteel draaien.

Een gerichte inventarisatie in vijf stappen

Zoek in code en configuratie. Doorzoek repositories, scriptshares, jobservers en configuratiebeheer op SharePointOnlineCredentials, rst2.srf, idcrl.svc, GetAuthenticationCookie en opgeslagen SharePoint-serviceaccounts.
Breng alle uitvoerlocaties in kaart. Neem scheduled tasks, Azure- of on-premises workers, ETL-jobs, archiefprocessen, back-ups, rapportages en externe integraties mee.
Controleer historische telemetrie. Zoek in Purview, binnen de beschikbare retentie, naar IDCRLSuccessSignIn en leg tenant, account, moment en betrokken workload vast.
Wijs een functioneel eigenaar toe. Een technisch account is geen eigenaar. Leg vast welk proces de koppeling ondersteunt, wie de impact kan testen en wie over rechten beslist.
Classificeer de aanmeldroute. Bepaal of de toepassing namens een gebruiker werkt of zelfstandig op de achtergrond draait. Die keuze bepaalt of een delegated of application-only ontwerp passend is.

Vervang legacy-aanmelding door moderne tokens

De structurele route is OAuth of OpenID Connect met Microsoft Entra ID. Registreer de applicatie in Entra, kies de minimale rechten die het proces nodig heeft en laat de applicatie via een passende MSAL-flow een access token verkrijgen. Voor een gebruikersgestuurd proces past doorgaans delegated toegang; voor een onbemande taak hoort het ontwerp juist expliciet voor een application-only scenario te worden beoordeeld. Vermijd een nieuwe oplossing die opnieuw een persoonlijk wachtwoord of een ongecontroleerd serviceaccount in een script vastlegt.

Voor SharePoint Online-CSOM raadt Microsoft de .NET Standard-variant aan. Daar is SharePointOnlineCredentials niet beschikbaar; de toepassing verkrijgt zelf een OAuth-token en plaatst dat als Bearer-token op de SharePoint-aanroep. Deze wijziging is meer dan een syntactische vervanging: controleer token-audience, toegewezen SharePoint-rechten, tenant consent, secret- of certificaatbeheer en het gedrag van foutafhandeling en tokenvernieuwing.

Kies per proces de juiste migratieroute

Interactie namens een gebruiker: ontwerp een delegated flow met een expliciete gebruikerscontext, zodat toegangscontrole en Conditional Access aansluiten op de normale aanmeldroute.
Onbemande verwerking: registreer een applicatie met alleen de noodzakelijke application permissions, een duidelijke eigenaar en gecontroleerd geheim- of certificaatbeheer. Beperk bereik en rechten tot wat de taak werkelijk nodig heeft.
Oude CSOM-code: migreer naar een ondersteunde tokenroute en test alle aanroepen. Neem niet aan dat een package-update alleen voldoende is als de code nog cookies of gebruikersnaam-wachtwoord gebruikt.
Directe legacy-endpoints: vervang de cookie-uitwisseling door een tokenflow; laat de applicatie niet meer afhankelijk zijn van rst2.srf of idcrl.svc.

Test de volledige werking van de integratie

Een geslaagde tokenaanvraag is niet hetzelfde als een geslaagde integratie. Test in een afgescheiden omgeving of pilot alle stappen die het proces uitvoert: aanmelden, lezen, schrijven, uploaden, downloaden, metadata bijwerken, foutafhandeling en geplande herhaling. Test ook een tokenvernieuwing en een herstart van de worker. Zo wordt zichtbaar of een hidden dependency op een oude cookie, een te ruime permissie of een onjuiste audience nog aanwezig is.

Leg voor elke koppeling de oude aanmeldroute en de beoogde moderne route vast.
Laat de functioneel eigenaar een representatieve run controleren, inclusief uitzonderingen en grote bestanden waar relevant.
Controleer audit- en applicatielogs op mislukte autorisatie, onverwachte scopes en herhaalde tokenfouten.
Plan de omzetting per integratie, niet als ongedifferentieerde tenantwijziging.
Verwijder na succesvolle validatie opgeslagen wachtwoorden, ongebruikte credentials en oude documentatie volgens het geldende change- en secretmanagementproces.

Geen tijdelijke bypass meer

De tijdelijke PowerShell-instelling die in de overgangsperiode legacy-authenticatie nog kon toestaan, is na 1 mei 2026 geen oplossing meer. Gebruik ook geen brede uitzonderingen in Conditional Access, een lager beveiligingsniveau of een gedeeld beheerdersaccount om een falende automatisering snel weer werkend te krijgen. Dat maskeert het ontwerpgebrek en kan een nieuw beveiligingsprobleem introduceren.

Als een bedrijfskritische job uitvalt, behandel de situatie als een gerichte integratie-incident: bepaal de eigenaar, beperk de zakelijke impact, kies een moderne authenticatiearchitectuur en laat die gecontroleerd testen. De structurele uitkomst is een expliciet beheerde Entra-app en tokenroute, niet het herstellen van de verdwenen IDCRL-cookieflow.