ເປັນຫຍັງຄຳຂໍພຣັອກຊີໜຶ່ງຈຶ່ງຂໍລະຫັດຜ່ານ ໃນຂະນະທີ່ Kerberos ເຮັດວຽກກັບອື່ນໆ
ຊອກຫາກົດລະບຽບນະໂຍບາຍທີ່ກຳນົດໂດເມນການພິສູດຢືນຢັນພຣັອກຊີທີ່ບໍ່ຄາດຄິດໃຫ້ຄຳຂໍໜຶ່ງ ເຖິງແມ່ນຄຳຂໍອື່ນໆໃຊ້ Kerberos ສຳເລັດ.
ຫຼາຍຄຳຂໍໃຊ້ Kerberos ຢ່າງສຳເລັດຜ່ານພຣັອກຊີຂອງບໍລິສັດ. ຄຳຂໍໜຶ່ງສ້າງການຂໍລະຫັດຜ່ານ. ກ່ອນປ່ຽນ keytab ໃຫ້ກວດເບິ່ງວ່າຄຳຂໍນັ້ນເລືອກນະໂຍບາຍການພິສູດຢືນຢັນໃດ.
ປະຕູສາມາດເລືອກໂດເມນ ແລະ ຮູບແບບທີ່ຮອງຮັບຜ່ານນະໂຍບາຍ. ສອງທຸລະກຳທີ່ມາຮອດພຣັອກຊີດຽວກັນຈາກບຣາວເຊີດຽວກັນບໍ່ຈຳເປັນຕ້ອງໄດ້ຂໍ້ກຳນົດການພິສູດຢືນຢັນຄືກັນ.
ພິຈາລະນາຮອຍສະເໝືອນນີ້:
| ທຸລະກຳ | ນະໂຍບາຍທຳອິດທີ່ກົງກັນ | ການພິສູດຢືນຢັນທີ່ມີ |
|---|---|---|
| ເອກະສານຫຼັກ | ກົດການທ່ອງເວັບທີ່ຈັດການ | Negotiate |
| ສະຄຣິບຈາກໂຮສອື່ນ | ຂໍ້ຍົກເວັ້ນປາຍທາງກ່ອນ | Basic ຫຼື NTLM |
ການແລກປ່ຽນທີ່ສຳເລັດທຳອິດສະແດງວ່າເສັ້ນທາງໜຶ່ງທີ່ເລືອກເຮັດວຽກ. ມັນບໍ່ສະແດງວ່າທຸລະກຳທີສອງໄປຮອດເສັ້ນທາງນັ້ນ. ຂໍ້ມູນຢືນຢັນອາດຖືກຕ້ອງ ແຕ່ກົດທີ່ເລືອກກົນໄກພິສູດຢືນຢັນອາດຜິດ.
ກວດເບິ່ງກົດທີ່ເລືອກ ແລະ ລຳດັບຂອງມັນ
ເຊື່ອມໂຍງປາຍທາງ ແລະ ເວລາຂອງຄຳຂໍທີ່ຖືກທ້າທາຍກັບຮອຍນະໂຍບາຍຂອງປະຕູ. ລະບຸໂດເມນ ການເລືອກຮູບແບບ ແລະ ໂໝດການພິສູດຢືນຢັນທີ່ກົດທຳອິດທີ່ໃຊ້ໄດ້ສ້າງຂຶ້ນ. ປຽບທຽບຄ່າເຫຼົ່ານັ້ນກັບຄຳຂໍທີ່ສຳເລັດຈາກລູກຄ້າດຽວກັນ.
ນະໂຍບາຍທີ່ອີງໃສ່ຕົວຕົນທີ່ຜູກກັບ IP ກໍອາດມີພຶດຕິກຳຕ່າງຈາກນະໂຍບາຍທີ່ຕ້ອງການການພິສູດຢືນຢັນເທິງການເຊື່ອມຕໍ່. ຢ່າສົມມຸດວ່າການບໍ່ມີການຈັບມືໃໝ່ໝາຍຄວາມວ່າເລືອກໂດເມນດຽວກັນ.
ຖ້າແຫຼ່ງຂໍ້ມູນຕົກຢູ່ໃນຂໍ້ຍົກເວັ້ນທີ່ບໍ່ໄດ້ຕັ້ງໃຈ ໃຫ້ແກ້ໄຂກົດນັ້ນ ຫຼື ຂອບເຂດຂອງມັນ ແລ້ວທົບທວນຮອຍທີ່ເກີດຂຶ້ນ. ການຂະຫຍາຍວິທີການພິສູດຢືນຢັນທີ່ອະນຸຍາດທົ່ວທຸກແຫ່ງອາດປິດບັງຄວາມບໍ່ສອດຄ່ອງ ແຕ່ປ່ຽນພຶດຕິກຳການເຂົ້າເຖິງຂອງການຈະລາຈອນທີ່ບໍ່ກ່ຽວຂ້ອງ.
ຖ້າໂດເມນທີ່ຕ້ອງການຖືກເລືອກ ແລະ ການແລກປ່ຽນທີ່ຄາດຫວັງລົ້ມເຫຼວ ໃຫ້ສືບຕໍ່ໄປຫາຫຼັກຖານບັນຊີ ແລະ Kerberos. ເມື່ອນັ້ນປີ້ ຊື່ບໍລິການ ຫຼື ການວິເຄາະ backend ຈຶ່ງກ່ຽວຂ້ອງ.