Azure P2S-klientautentisering: Entra, sertifikat eller RADIUS

Installasjonsprogrammet køyrer, profilen blir importert, og tilkoplinga feilar i innloggingstrinnet. Dei fleste av desse sakene er ikkje ein feil i klienten: ein OpenVPN-kompatibel applikasjon kan bera tunnelen og likevel ikkje vita korleis ei Microsoft Entra-innlogging blir utført. Rekkjefølgja som unngår løkka, er metode, deretter klient, deretter profil. Vel autentiseringsmetoden gatewayen er konfigurert for, vel ein klient Microsoft dokumenterer for den metoden, og generer først då profilen klienten ventar. Alt nedanfor følgjer den rekkjefølgja.

Start med metoden, ikkje med installasjonsprogrammet

Gatewayen er konfigurert med éin eller fleire tunneltypar og autentiseringsmetodar. Det paret, og ikkje filtypen på skrivebordet, avgjer kva klientar som blir støtta.

Skriv ned paret før du lastar ned noko, for støttematrisa er smal, og ein feil start kostar ein ettermiddag.

Her er tilordninga eg har i distribusjonsnotata:

Les tabellen som ei avgrensing, ikkje som ei meny. Kvar rad er ein dokumentert kombinasjon, og å blande ein klient frå éi rad med metoden frå ei anna er nøyaktig feilen artikkelen finst for å hindre.

Entra ID tyder OpenVPN pluss Azure VPN Client

For Entra-autentisering på punkt-til-site brukar den støtta ordninga OpenVPN-tunneltypen og Azure VPN Client. Ein generisk dialog for brukarnamn og passord erstattar ikkje den integrasjonen, og den innebygde IKEv2-en i Windows er ikkje ein utskiftbar måte å utføre same innlogginga på. Viss ein tredjepartsklient tilbyr eit Entra- eller Azure AD-alternativ, må du kontrollere det mot gjeldande dokumentasjon frå Microsoft og ikkje mot etiketten. Etiketten er marknadsføring, medan den dokumenterte kombinasjonen er kontrakten.

På macOS er Azure VPN Client òg den dokumenterte vegen for denne metoden.

Sertifikat krev ein klientlegitimasjon, ikkje berre ei rot

Sertifikatautentisering er ein eigen støtta modell, og han fungerer med OpenVPN-klientar Microsoft dokumenterer og med Azure VPN Client på støtta plattformer. På Windows er Azure VPN Client ikkje berre for Entra: han har òg ein dokumentert sertifikatarbeidsflyt. Det han treng, er det tiltenkte klientcertifikatet med ein brukbar privat nøkkel, som gatewayen har tillit til. Den klarerte rota til gatewayen er ikkje ein klientlegitimasjon, og signeringsnøkkelen til utgivaren høyrer aldri heime i ein klientpakke.

Kontroller kjeda før du feilsøkjer profilen. Eit sertifikat utstedt av ei rot gatewayen ikkje har tillit til, gir ein feil som ser ut som ein dårleg profil og eigentleg er eit tillitsproblem.

Hald den private nøkkelen ikkje-eksporterbar der plattforma tillèt det, og test med sertifikatet som faktisk er installert for gjeldande brukar.

RADIUS er eit backend-val med sine eigne kombinasjonar

RADIUS flyttar avgjerda om legitimasjon til ein server du sjølv driv, og det er dokumentert med bestemte tunneltypar og klientar. Det er ikkje automatisk det rette svaret fordi miljøet har fleire operativsystem. Fastslå kva den faktiske klienten kan presentere før du endrar autentiseringspolicyen til gatewayen, fordi å bytte gatewayen til RADIUS ikkje tilpassar alle eksisterande profilar. Klienten må framleis kunne be om eller levere den legitomasjonen.

Viss eit blanda miljø er årsaka, løys det per plattform i staden for å svekke gatewaypolicyen for alle.

Linux etter utfasinga av førehandsvisinga i 2026

Retningslinjene frå Microsoft om utfasing av Linux oppgir 31. august 2026 som utfasingsdato for førehandsvisinga av Azure VPN Client for Linux, så frå november 2026 er den førehandsvisinga bak deg. Eksisterande installasjonar kan halde fram med å verke, men dei får ikkje lenger støtte, oppdateringar eller tryggingsrettingar. Ikkje del ut eit gamalt Linux-installasjonsprogram som ein støtta ny distribusjon. Dette er utfasing av ein klient, ikkje av Azure VPN Gateway eller Windows- og macOS-klientane.

Dei dokumenterte Linux-alternativa er ein OpenVPN-klient med sertifikatautentisering, eller strongSwan med IKEv2 og sertifikat- eller RADIUS-autentisering. Begge er andre konfigurasjonar som krev organisatorisk godkjenning, ikkje ei konvertering du får ved å gje den gamle Entra-profilen nytt namn.

Viss Entra-innlogging er obligatorisk av policygrunnar, må eigaren velje ei støtta plattform eller eit godkjent alternativt design. Det er ei avgjerd, ikkje ein omveg.

Generer profilen og køyr fire kontrollar

Generer klientkonfigurasjonen frå den tiltenkte gatewayen når kombinasjonen er avklart, og importer representasjonen som er dokumentert for den klienten og metoden. Den generiske OpenVPN-mappa og Azure VPN Client XML-profilen kan ikkje bytast om. Viss gatewayen med vilje aktiverer fleire autentiseringstypar, vel den samsvarande profilen og legitimasjonsvegen i staden for å vente at éi tilkopling tilfredsstiller alle. Køyr deretter kontrollane i denne rekkjefølgja:

• Den støtta klienten importerer den genererte profilen utan å redigere han.
• Den tiltenkte identiteten autentiserer seg med metoden profilen ventar.
• Den påkravde rute- og oppløysarpolicyen viser seg på klienten.
• Applikasjonen som er tillaten, når den private ressursen sin.

Ein vellukka import beviser korkje autentiseringskompatibilitet eller autorisasjon for den private ressursen, derfor blir dei fire kontrollane haldne fråskilde.