Mac VPN-certifikat: hvilken konto ser gatewayen?

Profilen viser dit navn, certifikatets synlige etiket siger noget andet, og gatewayens log registrerer en tredje identifikator. Ingen af dem lyver, og det er netop problemet: tre forskellige felter læses, som om de svarede på ét spørgsmål. Forbindelsen fremlægger en legitimationsoplysning, en IKEv2-identifikator og en konto, og gatewayen afgør, hvilken af dem der autoriserer hvad.

Tre identiteter i én forbindelse

Det synlige profilnavn er en etiket for mennesker. Det vælger en forbindelse og intet andet. Certifikatet er en legitimationsoplysning, og hvorvidt det kan bevise noget, afhænger af, om klienten har den matchende private nøgle. Kontofeltet er en påstand om en principal, og serveren står frit for at mappe det til en anden lokal identitet.

Når godkendelsen fejler, så spørg hvilken af de tre fejlen henviser til. En afvist legitimationsoplysning, en ukendt identifikator og en deaktiveret konto giver forskellige meddelelser, og behandler man dem som ét «certifikatproblem», sendes man til den forkerte konsol.

Læs de oprindelige felter efter deres opgave

I en administreret oprindelig IKEv2-konfiguration adskiller Apples nyttelastreference værdierne, og godkendelsesmetoden afgør, hvilken kombination der kræves:

Et certifikat og et EAP-login kan have forskellige roller i samme forbindelse. Tving ikke hvert felt til at indeholde den samme tekst, blot fordi ét af dem gør det, og antag ikke, at ændring af det ene tilsidesætter de andre. En VPN-app fra tredjepart kan udstille en helt anden model; brug dens dokumenterede identitetsvalg i stedet for at overføre oprindelige feltnavne til den.

Et servercertifikat er ikke en klientidentitet

Certifikatet, der validerer gatewayen, er et tillidsanker. Det beviser, at du nåede den server, du forventede. En klientidentitet er et andet objekt: den omfatter adgang til den private nøgle, som beviser, at den forbindende part er den, den udgiver sig for at være. Omdøbning af en synlig konto kan ikke gøre det ene til det andet.

Det er her, en velment rettelse går galt. Import af gatewayens CA-certifikat til klientlageret gør intet for klientgodkendelsen, og mærkning af den post med brugerens navn gør den ikke til en brugeridentitet. De to objekter lever i forskellige dele af profilen og besvarer forskellige spørgsmål.

Følg principalen til gatewayens mapping

Bekræft, hvad legitimationsoplysningen blev udstedt til: denne bruger, denne enhed eller en delt rolle. Mac-loginkontoen er ikke automatisk den principal, og et certifikat kopieret fra en anden maskine beholder identiteten af den maskine, det blev udstedt til.

Sammenlign derefter selve legitimationsoplysningen, ikke etiketten. Udsteder, serienummer og fingeraftryk lader dig og administratoren bekræfte, at I taler om det samme objekt. Viste navne kan redigeres og duplikeres ofte, hvilket gør dem til den dårligste tænkelige identifikator under en hændelse.

Det sidste skridt er på gatewayen. Bed dens ejer om at korrelere én forbindelse med de fremlagte identifikatorer og den kontomappingsregel, der forbrugte dem. En etiket på klientsiden kan ikke fastslå, hvad serveren besluttede, og en regel, der mapper et certifikat til en deaktiveret konto, vil fejle, mens alle felter på klientsiden ser korrekte ud.

Reparer det lag, der ejer uoverensstemmelsen

Hvis profilen peger på den forkerte legitimationsoplysning, så ret dens reference eller dens valg. Hvis legitimationsoplysningen tilhører en anden principal, så gå gennem udstederens genregistrering i stedet for at redigere etiketter. Hvis gatewayen binder en gyldig legitimationsoplysning til den forkerte konto, må dens policyejer rette mappingen. Det er tre forskellige ændringer med tre forskellige godkendere.

Fornyelse fortjener samme omhu. Udskiftning af certifikatet, omdøbning af dets synlige etiket og flytning af en person mellem kontosystemer påvirker ikke nødvendigvis mappingen på samme måde. Notér, hvilken af de tre du ændrede, for den næste fejl vil se identisk ud fra klienten og anderledes ud i gatewayens log.

Del kun de minimale offentlige identifikatorer, som supporten har brug for. En privat nøgle eller en komplet identitetspakke er aldrig en del af den udveksling, uanset hvor bekvemt det ville gøre diagnosticeringen.