Miért kér a Mac VPN minden alkalommal Keychain-hozzáférést
Állapítsa meg, melyik összetevő váltja ki a Mac VPN minden kérését, állítsa le a dupla kapcsolódási kísérleteket, és javítsa a Keychain-hozzáférést a teljes kulcskarikuly újraállítása nélkül.
A Connect egyszeri kattintása egy bejelentkezési ablakot eredményezne. Macen gyakran három jön, és ritkán ugyanaz a tulajdonosuk: a kulcskarikuly a helyi hitelesítőadat-kérések tulajdonosa, a VPN-átjáró a hitelesítésé, a kliens pedig a saját értesítéseié. Ahelyett, hogy olyan kapcsolót keresne, amely mindent elnémít, kezelje minden ablakot külön hibaként, saját javítással. Az alábbi útmutató egyetlen szándékos kapcsolódási kísérleten vezet végig, és egy megismételhető ellenőrzéssel zárul.
Nevezze meg minden párbeszédablak tulajdonosát, mielőtt beállítást változtat
Az első lépés a nyilvántartás, nem a konfiguráció. Végezzen egy kapcsolódási kísérletet, és minden megjelenő ablakhoz írjon le négy mezőt: a párbeszédablakban látható alkalmazásnevet, a pontos szöveget minden titok nélkül, azt a fázist, amelyben megjelent, és azt, hogy mi történt, amikor megszakította. Három ilyen sor szinte minden általam látott jelentést lefed.
A tulajdonjog határozza meg a helyes javítást, és a rossz javítás az, ami általában egy kérésből hármat csinál:
| Window | Who owns it | Correct fix | What not to do |
|---|---|---|---|
| “wants to use your confidential information stored in…” | The item's access control list in your login keychain | Approve the specific client helper, once, after checking the name | Resetting the login keychain, or granting Always Allow to every application |
| “Sign in to <organization>” or an MFA push | The gateway's identity provider | Use the client's supported session renewal, or re-authenticate | Scripting a fixed password or code into the client |
| “Connection failed”, “Update required”, a policy banner | The client or your organization | Read the first error and fix its cause | Hiding notices by editing a preference file the client rewrites |
Az ugyanazon kísérleten belül visszatérő kérés más jel, mint a következő kísérletnél visszatérő. Az első általában azt jelenti, hogy a kapcsolat Ön alatt újraindult; a második általában azt, hogy egy tárolt hitelesítő adatot kérnek újra. Jegyezze fel, melyik van Önnél, mielőtt a kulcskarikulyhoz nyúl, mert a kettőnek szinte semmi közös vonása nincs.
Tudja meg, hány dolog indítja az alagutat
Négy mechanizmus indíthatja ugyanazt a VPN-t Macen: egy menüsor-művelet, egy bejelentkezési elem, egy On Demand szabály, valamint egy szkript vagy ügynök. Amikor kettő tüzel, a második indítás akkor érkezhet, amikor az első még hitelesítésre vár, ami duplikált ablakot és semmi előrelépést eredményez. Először listázza, mi van beállítva: scutil --nc list kiírja a Rendszerbeállítások által ismert VPN-szolgáltatásokat, jelenlegi állapotukkal. Azok a kliensek, amelyek saját hálózati kiterjesztést szállítanak, az alkalmazáson belül tartják a profilokat, és lehet, hogy nem jelennek meg ott, ezért ellenőrizze a kliens saját kapcsolatlistáját is.
Ezután keressen versengő indítókat. scutil --nc show "Work VPN" kiírja egy beépített szolgáltatás konfigurációs szótárát, beleértve az On Demand szabályokat; egy szabály, amely bármely interfészváltozásnál újracsatlakozik, újraindítja az alagutat — és újranyitja a hitelesítési kérést — minden alkalommal, amikor a Wi-Fi vándorol vagy egy kijelző felébreszti a hálózati vermet. Ellenőrizze a bejelentkezési elemeket a Rendszerbeállítások > Általános > Bejelentkezési elemek alatt, és listázza a felhasználónkénti ügynököket ezzel: ls ~/Library/LaunchAgents. Hagyja békén, ami egy MDM által kezelt biztonsági verem tulajdona; eltávolítása általában visszakerül a következő ellenőrzéskor.
Hogy lássa, mi fut valójában egy kísérlet során: ps -Ao pid,comm | grep -iE 'vpn|tunnel|extension'. Két kliens-segéd ott, ahol egyet vár, sokkal gyakrabban magyarázza meg a „miért kaptam két kérést” kérdést, mint bármely hitelesítőadat-probléma.
Javítsa a kulcskarikuly-hozzáférést a kulcskarikuly újraállítása nélkül
A kérés a tárolt elem hozzáférés-vezérlési listájából jön, nem a VPN-protokollból. Minden elem rögzíti, mely alkalmazások olvashatják kérdezés nélkül. Egy kliensfrissítés után a kérdező segéd más nevet vagy aláírást viselhet, miközben az elem még a régit listázza, ezért a macOS minden kapcsolatnál újra kérdez. Az új segéd jóváhagyása ehhez az egy elemhez a teljes javítás; minden alkalmazás jóváhagyása nem az.
Megerősítheti, hogy az ACL a ok, anélkül hogy hozzányúlna a VPN-hez: security find-generic-password -s "service-name" -g ugyanazt az elemet olvassa ki egy terminálból. Ha az a parancs is kiváltja a kérést, a párbeszédablak a kulcskarikulyhoz tartozik, és az alagút csak a kiváltó. Az Apple útmutatása a három gombról — Engedélyezés egyszer, Engedélyezés mindig, Elutasítás — egy olvasást megér, mert az Elutasítás az, ami a kérést azonnal visszahozza, nem a következő kísérletnél.
Ha rossz segédet hagyott jóvá, nyissa meg az elemet a Keychain Accessben, váltson az Access Controlra, és távolítsa el azt a bejegyzést; ez a visszaállítás. A bejelentkezési kulcskarikuly törlése, vagy egy azt újraépítő javítóeszköz futtatása szintén eldobja a nem kapcsolódó jelszavakat, és sokkal nagyobb változás, mint a probléma.
Tartsa a bejelentkezési és házirend-lépéseket az őket birtokló folyamatokban
A böngészős bejelentkezés vagy az MFA-kihívás az átjáróé. Ha a szervezete munkamenet-megőrzést vagy tanúsítványalapú hitelesítést kínál, használja, mert ez a támogatott módja a ritkább hitelesítésnek. Egy rögzített kód beírása a kliensbe, vagy jelszó tárolása egy szkriptben, hogy a kérés soha ne jelenjen meg, interaktív tényezőt cserél statikus titokra, és a következő házirendváltáskor meghiúsul.
A szervezeti értesítések az egyetlen kategória, amelyet nem szabad elnyomni. Általában testtartás-ellenőrzést vagy elfogadható használatról szóló nyilatkozatot kényszerítenek ki, és elrejtésük akkor is kiveheti az eszközt a megfelelőségből, amikor az alagút működik. A hibapárbeszédek a másik kategória: őrizze meg az első hiba szövegét, mert a második párbeszéd gyakran csak ugyanaz a hiba, amelyet újabb kísérlet után jelentenek.
Ellenőrizze egy kísérlettel, majd újraindítás után
Miután a duplikált indítók eltávolításra kerültek és a kulcskarikuly-bejegyzés javult, végezzen egyetlen kísérletet: lépjen ki minden klienspéldányból, beleértve a menüsor-segédet, csatlakozzon egyszer, és számolja meg az ablakokat. A kulcskarikuly jóváhagyását szeretné, ha az elem újraépült, és egy hitelesítési lépést. Semmi többet. scutil --nc status "Work VPN" Connected állapotot kellene jelentenie egy beépített szolgáltatásnál.
Ezután indítsa újra egyszer, és ismételje meg. Az csak újraindítás után visszatérő kérés bejelentkezési elemre vagy On Demand szabályra utal, nem hitelesítő adatokra; a munkameneten belül visszatérő az ACL-re vagy egy második indítóra. Ha a két kör után is ismétlődik, a hasznos dolog, amit a rendszergazdájának adhat, az első kísérlet háromsoros táblázata — tulajdonos, pontos szöveg, fázis —, nem a párbeszédablak képernyőképe.
A kevesebb kérés a cél, nem a néma. Az a kapcsolat, amely elrejti az engedélyezési lépéseit, olyan kapcsolat, amelyet már nem tud auditálni, és a következő tanúsítvány-rotáció úgy találja Önt, hogy fogalma sincs, melyik összetevő hibázik.