Naalala ng Viscosity ang password: ano ang ginawa ng checkbox na iyon

Ang checkbox na iyon sa prompt ng pag-login ay mukhang kagustuhan ng kliyente, ngunit sa isang pinamamahalaang makina ito ay madalas na desisyon sa patakaran. Ang kontrol ng pag-alala ng Viscosity ay nag-iimbak ng kredensyal sa Keychain ng macOS kapag pinapayagan ng deployment ang pag-iimbak. Ang alamat ay ang checkbox ay laging sa iyo na itakda. Sa pagsasagawa, tatlong magkakaibang bagay ang maaaring humarang dito, at isa lamang sa mga ito ang tungkol sa password.

Ano ang aktwal na iniimbak ng checkbox

Ang pagpili sa opsyon ng pag-alala ay humihiling sa kliyente na itago ang halaga para sa isang koneksyon at account na iyon. Ang item ay napupunta sa Keychain, at ang mga susunod na pag-login ay muling gumagamit nito sa pamamagitan ng sinusuportahang prompt sa halip na sa pamamagitan ng nakatagong kagustuhan. Walang nakasulat sa mismong file ng koneksyon. Ang paghihiwalay na iyon ay ang dahilan kung bakit ang pag-alis ng item sa ibang pagkakataon ay gumagawa ng prompt sa halip na sirang profile.

Ang naka-imbak na halaga ay input sa pagpapatunay na gagawin naman ng server. Hindi nito binabago ang hinihingi ng gateway, hindi nito nilalampasan ang pangalawang salik, at hindi nito ginagawang magagamit muli na lihim ang isang beses na code. Ang pinaikli nito ay ang pagta-type, hindi ang patakarang inilalapat ng deployment sa account na iyon.

Bakit maaaring wala ang kontrol

Maaaring huwag paganahin ng administrador ang pag-iimbak ng kredensyal para sa pinamamahalaang pag-install, at idinodokumento ng SparkLabs ang kontrol ng pag-alala kasama ang pag-uugali nito sa Keychain sa gabay sa pag-iimbak ng kredensyal. Kapag wala ang checkbox, hindi ito sira, at ang paghahanap ng utos ng kagustuhan na lumalampas dito ay maling tugon.

Tanungin ang may-ari kung aling sinusuportahang daloy ng trabaho ang naaangkop sa halip. Ang deployment na nagbabawal sa pag-iimbak ay karaniwang may dahilan, at ang dahilan ay madalas na ang account ay ibinabahagi, ang device ay hindi pinagkakatiwalaan, o ang kredensyal ay dapat mag-expire ayon sa iskedyul. Ang paglampas sa setting ay ginagawang insidente ang sinadyang kontrol, at ang insidente ay karaniwang dumarating na may audit ng ibang tao na nakalakip.

Sa isang hindi pinamamahalaang pag-install, ang nawawalang kontrol ay tanong sa suporta na may nakalakip na numero ng bersyon. Ipadala ang naka-install na build ng kliyente at kung ano ang aktwal na ipinapakita ng prompt, sa halip na hulaan ang mga nakatagong default.

Tatlong prompt na hindi isang prompt

Ang isang beses na code ay hindi password, ang password ay hindi awtorisasyon ng Keychain, at ang pagtanggi ng server ay wala sa tatlo. Ang paghahalo sa kanila ay gumagawa ng mga pagkabigo na mababasa na parang maling kredensyal habang ang tunay na problema ay isang field, dialog, o ruta.

Ang dialog ng Keychain ay lokal ayon sa disenyo. Tinatanong nito kung maaaring basahin ng application na ito ang item na ito sa makinang ito, at ang pag-apruba dito ay walang sinasabi sa server ng VPN.

Kaya naman ang pagtanggi sa dialog ay gumagawa ng pagkabigo sa panig ng kliyente na hindi kailanman nakikita ng server, samantalang ang maling password ay gumagawa ng pagtanggi sa panig ng server na maaari lamang iulat ng kliyente. Basahin ang dialog bago ito sagutin, at tiyakin na ang application na humihiling ay ang kliyenteng inaasahan mo at hindi isang installer o helper na proseso. Ang pagkakaiba ay pinakamahalaga sa mga ibinabahaging makina, kung saan ang item ay maaaring maabot ng higit sa isang account.

Ang pangalawang salik ay nasa labas ng lahat ng ito. Ang pag-iimbak ng password ay hindi nag-iimbak ng code, at ang deployment na nangangailangan ng code ay nangangailangan pa rin nito sa bawat koneksyon. Panatilihing nakikita ang hakbang na iyon sa panahon ng pagsubok, dahil ang daloy na tahimik na lumalampas dito ay hindi ang daloy na na-configure mo.

Pagbawi ng isang kredensyal nang hindi nire-reset ang iba

Kung mabigo ang pagpapatunay pagkatapos ng pagbabago ng password, gamitin ang dokumentadong landas ng kliyente para sa muling prompt at pag-update para sa isang koneksyon na iyon sa halip na i-edit ang Keychain nang manu-mano. Basahin ang mensahe bago palitan ang anuman, dahil ang timeout, pagtanggi ng sertipiko, o nawawalang ruta ay hindi naaayos sa pamamagitan ng pag-overwrite ng naka-imbak na password. Ang paulit-ulit na paggawa nito ay pangunahing nagtuturo sa iyo na huwag pansinin ang error na ipinapakita ng kliyente. I-update ang apektadong kredensyal, pagkatapos ay kumonekta muli at obserbahan kung aling prompt ang lalabas.

Ang buong reset ng Keychain na iminumungkahi ng mga forum ng suporta ay isang pagbabagong mas malaki kaysa sa problema. Ang naka-imbak na password ng isang koneksyon ay walang kinalaman sa sertipiko ng isa pang koneksyon, at ang pagbura ng lahat ay ginagawang isang buong hapon ng muling pagpapatala ang isang lumang item.

Tapusin sa pamamagitan ng pag-disconnect at muling pagkonekta gamit ang mga normal na kontrol, na nagpapatunay na ginagamit ang nilalayong account at ang pag-alis ng naka-imbak na item ay gumagawa ng prompt sa halip na pagkabigo. Ang mahuhulaang muling paggamit na may isang malinaw na paraan upang i-update o alisin ang kredensyal ay ang resultang sulit subukan.