Kiel revoki unu Azure Point-to-Site-klientan atestilon

Revoki unu Azure Point-to-Site-klienton signifas aldoni ĝian fingrospuron al la revokita listo de la pordego. Tio ne signifas forigi la fidan radikon. La radiko estas la eldonanto de ĉiu klienta atestilo, kiun vi iam ajn donis, do forigi ĝin estas alia operacio kun multe pli granda efiko. La unuo de revoko ĉi tie estas unu sola atestilo.

Paŝo 1: Precizigu la atestilon, kiun vi celas

Komencu de la atestila registro, ne de montrata nomo. Azure montras amikan nomon, kiun vi mem tajpis, kaj tiu etikedo ne devas kongrui kun la subjekto aŭ la aparato, por kiu ĝi estis eldonita.

Ankoraŭ unu kontrolo antaŭ ol revoki: eksciu, kiom da aparatoj prezentas ĝin. Se pluraj tekkomputiloj estis konstruitaj el kopioj de la sama PFX, revoko de la fingrospuro ŝlosas ilin ĉiujn, kaj Azure ne povas distingi la perditan de la rezerva en la tirkesto.

Ĉe la kliento, Get-ChildItem Cert:\CurrentUser\My | Select-Object Subject, Thumbprint, NotAfter listigas tion, kio estas instalita por tiu uzanto, kaj Cert:\LocalMachine\My ankaŭ indas kontroli, ĉar la VPN-kliento povas elekti el ambaŭ konservejoj. Komparu la fingrospuron kun via aliĝa inventaro. Renovigita atestilo havas alian fingrospuron eĉ kiam la subjekto estas identa.

Vi ne bezonas la privatan ŝlosilon de la kliento nek pasvortprotektitan PFX por legi la fingrospuron de publika atestilo. Ĉiu proceduro, kiu postulas unu el ili, estis kopiita el alia tasko.

Paŝo 2: Aldonu ĝin al la revokita listo de la pordego

En la portalo malfermu la virtualan retpordegon, poste la agordon Point-to-site, poste la sekcion de revokitaj atestiloj. Aldonu amikan nomon, kiun vi rekonos post ses monatoj, kaj algluu la fingrospuron kiel unu daŭran ĉenon sen la spacoj.

Kontrolu, kiu pordego estas elektita antaŭ ol konservi, ĉar abono kun pluraj pordegoj estas ĝuste la loko, kie tio misfunkcias. La gvidilo pri atestila agordo de Microsoft diras, ke post kiam la ĝisdatigo finiĝas, la atestilo ne plu povas esti uzata por konekti.

Konfirmu poste la konservitan valoron anstataŭ fidi la sciigon de la portalo: az network vnet-gateway show --name gw-p2s --resource-group rg-vpn --query "vpnClientConfiguration.vpnClientRevokedCertificates" montras, kion la pordego fakte tenas.

Paŝo 3: Kontrolu ambaŭ direktojn

Testu la rifuzon per la revokita atestilo, poste testu, ke alia atestilo sub la sama radiko ankoraŭ aŭtentikiĝas. Tiu dua testo estas la plej ofte preterlasata, kaj ĝi estas tiu, kiu kaptas hazardan forigon de la radiko aŭ politikan ŝanĝon, pri kiu neniu menciis. Uzu aparaton, sur kiu vi povas vidi, kiu atestilo estas prezentata. Kliento kun pluraj atestiloj povas kviete uzi funkciantan kaj igi vian revokon aspekti difektita.

Notu ambaŭ rezultojn en la bileto. Revoko kontrolita nur en la rifuza direkto estas duone kontrolita.

Paŝo 4: Seancoj jam aktivaj

La dokumentita rezulto koncernas novajn konektojn. Ne etendu ĝin al promeso, ke ĉiu ekzistanta tunelo falos en la sekundo, kiam la listo estos konservita. Se tuja forigo gravas, uzu la regilojn, kiujn via deplojita agordo efektive ofertas, kaj kontrolu la konkretan seancon anstataŭ supozi.

Testu tion aparte de aŭtentikigo, ĉar la du malsukcesas en malsamaj lokoj kaj lasas malsamajn spurojn.

Retroigo kaj la mallongigoj evitindaj

Retroigi signifas forigi la fingrospuron el la revokita listo kaj atendi, ke la sama ĝisdatigo finiĝu. Tio estas sekura, kiam vi revokis la malĝustan enskribon, kaj danĝera, kiam la atestilo estas vere kompromitita, do unue decidu, en kiu kazo vi estas. Forigi la fidan radikon ne estas mallongigo por unu perdita tekkomputilo. Forigi lokan VPN-profilon sur unu maŝino ne ŝanĝas, kion akceptas iu ajn pordego.

Se la idento ankaŭ aŭtentikiĝas ĉe dua pordego, ambaŭ bezonas la saman traktadon. La revokita listo apartenas al pordego, ne al la abono.