Waarom ’n Protected Users-skootrekenaar die VPN voor aanmelding nodig het

’n Skootrekenaar, ’n werkende rekening en ’n hotelnetwerk lei tot ’n aanmeldlus wat geen herhaling breek nie. Die rekening is in Protected Users, wat verhoed dat Windows die verifieerder stoor wat dit nodig het om die gebruiker vanlyn te verifieer. Enige plan soos “eers aanmeld, dan die tonnel verbind” het die volgorde omgekeerd, en die beskerming doen presies wat dit belowe. Wat volg, veronderstel ’n tradisionele Active Directory-rekening op ’n ondersteunde Windows-gasheer.

Wat die beskerming werklik wegneem

Windows stoor gewoonlik ’n verifieerder sodat ’n domeinrekening kan aanmeld terwyl ’n domeinbeheerder onbereikbaar is. Protected Users blokkeer dit vir die rekening, wat vanlyn domeinaanmelding as ’n moontlikheid verwyder eerder as om dit onbetroubaar te maak.

Dit is nie die gewone verouderde-kas-probleem nie, en die gewone middele is nie van toepassing nie. Herhaaldelik aanlyn aanmeld, die wagwoord weer verander of die kas-aanmeldingstelling verhoog sal nie die vermoë herstel nie, want nie een van daardie handelinge skep die verifieerder wat die beleid weier om te stoor nie. Die rekening werk soos ontwerp, en die ontwerp veronderstel dat die netwerk teenwoordig is wanneer Windows vra. Om die simptoom as ’n kasfout te behandel, is hoe spanne ’n profiel herbou wat nooit stukkend was nie.

Waarom die tonnel moet bestaan voordat die lessenaar verskyn

Die toestel moet domeinverifikasie bereik op die oomblik wanneer Windows daarom vra, wat voor enige gebruikersessie is. ’n VPN-kliënt wat eers begin nadat die lessenaar verskyn, laat ’n nuwe aanmelding wag vir ’n pad wat nooit kom nie. Die afhanklikheid hoort by die masjien, nie by ’n gebruiker wat nog nie aangemeld het nie.

Gebruik ’n ondersteunde vooraf-aanmeld-reëling wat met die eindpunt- en identiteitseienaars ooreengekom is. ’n Always On VPN-toesteltonnel wat met ’n rekenaarsertifikaat verifieer word, kwalifiseer wanneer die bestuurde toestel aan daardie ontplooiing se voorvereistes voldoen. ’n Verskaffer se ondersteunde integrasie op die aanmeldskerm is nog een. ’n Gewone gebruikerprofiel met ’n outomatiese sneller is nie een van die twee nie, hoe soortgelyk dit ook in die kliëntkoppelvlak lyk.

Wat daardie pad nodig het, is naamresolusie vir die domein, ’n bereikbare domeinbeheerder en watter verifikasieprotokolle die rekening ook al mag gebruik, en nie een daarvan word deur ’n verbinding-aanwyser verskaf nie. Die roetes en filters moet die identiteitsdienste dra en niks anders wat nie nodig is nie, want daardie voorvoegsellys is die oppervlak wat ’n gesteelde skootrekenaar kry voordat enigiemand aanmeld. Split-tonnel-besluite wat vir die gebruikerstonnel geneem is, dra nie oor na die toesteltonnel nie, so hersien die twee afsonderlik.

Bereikbaarheid is nie verifikasieversoenbaarheid nie

’n Tonnel kan pakkette perfek dra terwyl domeinverifikasie misluk, want die meganisme wat probeer word, is een wat die rekening nie mag gebruik nie. In ’n domein wat die groep se beperkings afdwing, is NTLM vir lede onbeskikbaar en Kerberos benodig ’n AES-versoenbare rekening en opstelling. ’n Pakketpad kan nie een van die twee herstel nie. Daarom is ’n skoon ping na ’n domeinbeheerder nie bewyse dat aanmelding sal werk nie.

Twee geloofsbriewestelsels kan ook in die spel wees. Die VPN kan teen ’n identiteitsverskaffer verifieer terwyl Windows afsonderlik ’n domeinaanmelding nodig het, en aanvaarding deur die eerste sê niks oor die tweede nie. “Die VPN het verbind” en “die gebruiker is aangemeld” is afsonderlike waarnemings, en om een reg te maak impliseer nie die ander nie.

Lees die verifikasiestawing

Versamel gebeurtenisse van die kliënt en van ’n domeinbeheerder vir dieselfde poging, nie net van een kant nie. Die Protected Users-logs sit onder Applications and Services Logs\Microsoft\Windows\Authentication, en ’n administrateur moet dalk ’n log aanskakel voordat dit iets opneem. Korreleer die tydstempels met die tonnel se eie verbindingslog, want ’n volgordefout lyk soos ’n geloofsbrief-fout van weerskante.

Die eerste opdrag hieronder lys elke verifikasielog wat die toestel blootstel, sodat jy die een lees wat bestaan eerder as die een wat ’n blogpos genoem het. Die tweede lees onlangse inskrywings sodra jy die naam ken. Kyk na die verifikasiepakket, die rekening en die fouttoestand, want ’n ontbrekende netwerkpad en ’n verwerpte meganisme laat verskillende bewyse na en net een daarvan is ’n VPN-probleem. As die tonnel ná die poging opgekom het, was die volgorde verkeerd, maak nie saak wat daardie inskrywings sê nie.

Get-WinEvent -ListLog *Authentication*
Get-WinEvent -LogName Microsoft-Windows-Authentication/Operational -MaxEvents 20

Bewys die grens vanaf ’n koue selflaai

Voer die toets uit van ’n afgemelde of pas selflaaide toestand met ’n beperkte rekening, en hou ’n goedgekeurde herstelpad oop voordat jy enigiets vir bevoorregte gebruikers verander. ’n Toets op ’n lessenaar wat reeds loop, oefen niks van die kodepad wat saak maak nie, wat die meeste verslae verduidelik van ’n regstelling wat tot die volgende herlaai gehou het. Werk dan deur die vier stappe in hierdie volgorde.

1. Bevestig dat die toestel ’n domeinbeheerder kan vind voordat iemand aanmeld, met nltest /dsgetdc:corp.example.com.
2. Probeer die domeinaanmelding, en vra dan of ’n kaartjie hoegenaamd bekom is, met klist.
3. Lees die verifikasielog wat die toestel opneem, met die twee opdragte hierbo, en let op die pakket en die fouttoestand.
4. Bevestig dat die goedgekeurde herstelgeloofsbrief nog vanaf die aanmeldskerm werk, want dit is die enigste pad terug as die grenstoets misluk.

Om ’n lêerdeling met verskafde geloofsbriewe oop te maak, skep ook nie ’n vanlyn interaktiewe aanmelding nie, so dit is nie ’n plaasvervanger vir enige stap hierbo nie. As die organisasie werklik ontkoppelde aanmelding nodig het, is die antwoord ’n versoenbare rekening- en eindpuntontwerp wat doelbewus gekies is. Om die rekening uit die groep te haal, of om een onbeperkte noodaanmelding op elke skootrekenaar te hou, is ’n identiteitsbeleidbesluit wat ’n VPN-verandering nie vir jou kan maak nie.

Die dokumentasie oor Protected Users beskryf beide die verifieerdergedrag en die domeinbeperkings waarvan hierdie ontwerp afhanklik is. Beplan die herstelproses voordat iemand reis, want die koue-selflaaitoets is die enigste plek waar dit geoefen word.