Visual Studio alleen traag op de VPN? Controleer CRL en OCSP

Visual Studio start thuis normaal, dan maakt dezelfde laptop verbinding met de bedrijfstunnel en elke start blijft een halve minuut op het opstartscherm staan. Haal het beleid weg en de vertraging verdwijnt mee; haal de tunnel weg en hetzelfde gebeurt. Beide waarnemingen kloppen, daarom krijgen de twee componenten steeds de schuld van elkaar. De beslissende vraag is of een intrekkingsopvraag voor een certificaat wacht op een route die alleen de tunnel biedt, of er helemaal geen vindt.

Meet het ophalen, niet de start

Een WDAC-beleid, uitgerold als een ondertekend SiPolicy.p7b, bepaalt welke images op de machine mogen draaien. Code-integriteit valideert de handtekeningsketen van een image vóór uitvoering, en die validatie kan een intrekkingsvraag bevatten. Het antwoord hangt af van het CRL-distributiepunt of de OCSP-responder die het certificaat in zichzelf noemt.

Dat zijn gewone netwerkverzoeken, dus hun kosten hangen af van waar de responder staat. Wanneer die alleen via de tunnel bereikbaar is, of de naam alleen via een DNS-server achter de tunnel wordt opgelost, wacht de validatie tot de tunnel klaar is. Visual Studio laadt bij het opstarten een groot aantal ondertekende assembly's en extensies, en een kleine vertraging per image wordt een zichtbare stilstand. Niets is misvormd en het beleid gedraagt zich precies zoals geconfigureerd, daarom lijkt het verwijderen van het beleid het probleem op te lossen.

Elke ondertekende image kan een netwerkoproep uitlokken

Begin met een ondertekend binair bestand dat al op de schijf staat en vraag het platform het te verifiëren met hetzelfde ophaalgedrag als een start. Voer de opdracht één keer op de tunnel en één keer daarbuiten uit en vergelijk daarna de ophaalregels in plaats van het eindoordeel.

certutil -verify -urlfetch C:\Tools\Contoso.Editor.dll
nslookup ocsp.contoso.example
Test-NetConnection ocsp.contoso.example -Port 80

De uitvoer noemt de keten, de CRL- en OCSP-adressen en of elke ophaalactie slaagde. Een responder die op de tunnel een time-out krijgt en daarbuiten antwoordt, is het bewijs dat u nodig hebt, en het weegt veel zwaarder dan een indruk van traagheid. Als het ophalen langzaam slaagt, noteer dan het adres zodat de volgende stap die host rechtstreeks kan testen.

Los de hostnaam van de responder op en test de bereikbaarheid buiten de toepassing, want een naam die niet oplost, wordt nooit gerepareerd door een clientinstelling. Het operationele logboek van CodeIntegrity levert de andere helft van het bewijs en koppelt een validatiegebeurtenis aan de tijdstempel van de trage start.

Verkort de vertraging zonder de controle te verwijderen

Het beleid uitschakelen of naar de auditmodus zetten laat de vertraging verdwijnen en haalt de controle weg die de organisatie heeft uitgerold, dus beschouw dat als de verkeerde reparatie. De smallere opties zijn een routeringswijziging zodat de responder via de tunnel bereikbaar is, een uitzondering in de gesplitste tunnel voor de responderhosts, een DNS-correctie wanneer de naam naar een onbereikbaar adres oplost, of een ondersteunde cacheproxy voor intrekkingsgegevens. Elk heeft een andere eigenaar: het PKI-team bezit de bereikbaarheid van de responder, het netwerkteam bezit de tunnelsplitsing en het endpointteam bezit het beleid.

Elke intrekkingshost uit de tunnel uitsluiten is niet automatisch veilig, want een interne responder kan met opzet intern zijn. Bevestig de uitzondering met het team dat de PKI beheert voordat u een regel schrijft die certificaatcontroles stil naar het openbare internet stuurt. Een wijziging zonder die bevestiging is het soort dat bij de volgende beleidsvernieuwing wordt teruggedraaid.

Verifieer een koude start na de wijziging

Meet een koude start in beide toestanden en bewaar de cijfers, want een warme start bewijst bijna niets zodra de assembly's in de cache staan. Herhaal de start vanuit een nieuwe sessie zodat het laadpad van de extensies opnieuw wordt doorlopen.

Get-WinEvent -LogName Microsoft-Windows-CodeIntegrity/Operational -MaxEvents 40 |
  Where-Object { $_.TimeCreated -gt (Get-Date).AddMinutes(-10) }
Get-ChildItem C:\Windows\System32\CodeIntegrity\CiPolicies\Active
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard

Een gerepareerde configuratie neemt nog steeds contact op met de responder, of gebruikt een cachepad dat uw PKI-team heeft goedgekeurd, en het logboek toont dat de validatie wordt voltooid in plaats van te verlopen. Bevestig dat een recent ondertekende toepassing nog steeds start, want een beleid dat alles toestaat is geen geslaagde reparatie. Controleer ook de map van het actieve beleid en de handhavingsstatus, zodat bekend is dat het beleid dat u debugt het beleid is dat draait. Houd de certificaatketen, het adres van de responder en de starttijdstempels in hetzelfde ticket, want een vernieuwing verplaatst meestal de responder en laat de uitzonderings- of DNS-regel verouderen.