ການຢືນຢັນຕົວຕົນຂອງພຣັອກຊີ NTLM ມີ handshake, ບໍ່ແມ່ນພຽງແຕ່ແນບຊື່ຜູ້ໃຊ້ເທື່ອດຽວ. ກ່ອນປ່ຽນລະຫັດຜ່ານບັນຊີ ໃຫ້ຢືນຢັນວ່າ ພຣັອກຊີສະເໜີ NTLM ແທ້ ແລະໄຟລ໌ປະຕິບັດການ curl ຮອງຮັບມັນ.

curl --version

ກວດລາຍການຄຸນສົມບັດຂອງໄຟລ໌ທີ່ປະຕິບັດຄຳຮ້ອງຂໍຂອງທ່ານ. ການຕິດຕັ້ງ curl ອື່ນ, ອິມເມຈຄອນເທນເນີ ຫຼື build ຂອງລະບົບປະຕິບັດການ ອາດຮອງຮັບການຢືນຢັນຕົວຕົນຕ່າງກັນ.

ເລືອກວິທີສຳລັບພຣັອກຊີໂດຍສະເພາະ

curl --proxy http://proxy.example:3128 --proxy-ntlm --proxy-user 'EXAMPLE\alice' --noproxy '' --connect-timeout 5 --max-time 20 https://example.com/

endpoint, domain ແລະຊື່ຜູ້ໃຊ້ແມ່ນຕົວຢ່າງ. ໃຊ້ຮູບແບບທີ່ຜູ້ດູແລລະບຸ. ຖ້າ argument ບໍ່ມີລະຫັດຜ່ານ curl ສາມາດຖາມມັນແທນການປ່ອຍຄວາມລັບໄວ້ໃນຄຳສັ່ງທີ່ສະແດງ.

challenge ຢືນຢັນຕົວຕົນຄັ້ງທຳອິດອາດເປັນສ່ວນໜຶ່ງຂອງການເຈລະຈາ. ແຍກມັນອອກຈາກການປະຕິເສດຫຼັງ handshake ສຳເລັດ. ຢ່າໃຊ້ຕົວເລືອກ NTLM ຂອງເຊີບເວີຕົ້ນທາງເພື່ອຕອບ challenge ຂອງພຣັອກຊີ.

ນຳພຶດຕິກຳການເຊື່ອມຕໍ່ເຂົ້າໃນການວິນິດໄສ

ສະຖານະຂອງ NTLM ຜູກກັບການເຊື່ອມຕໍ່. handshake ຕ້ອງດຳເນີນຕາມເສັ້ນທາງການເຊື່ອມຕໍ່ທີ່ຄາດໄວ້; ການປ່ຽນການເຊື່ອມຕໍ່ຊ້ຳໆລະຫວ່າງຂັ້ນຕອນອາດກີດຂວາງການສຳເລັດ.

ໃນແອັບທີ່ໃຊ້ libcurl ໃຫ້ໄລບຣາຣີຈັດການການຢືນຢັນຕົວຕົນ ແລະການໃຊ້ການເຊື່ອມຕໍ່ຄືນ. ຢ່າສ້າງ pool ທົ່ວໄປທີ່ຖືວ່າການເຊື່ອມຕໍ່ທີ່ຢືນຢັນສຳລັບຕົວຕົນຕ່າງກັນສາມາດສັບປ່ຽນກັນໄດ້. ສຳລັບບໍລິການຫຼາຍຈຸດຜ່ານ ຫຼືຕົວກາງ ໃຫ້ກວດວ່າມັນຮັກສາການຈັດວາງການເຊື່ອມຕໍ່ທີ່ຈຳເປັນຫຼືບໍ່.

ຖ້າການຮອງຮັບ ແລະການເລືອກວິທີຖືກຕ້ອງ ໃຫ້ສືບສວນຮູບແບບບັນຊີ, ນະໂຍບາຍ domain ແລະບັນທຶກຢືນຢັນຕົວຕົນຂອງເຊີບເວີທີ່ໄດ້ລຶບຂໍ້ມູນລະອຽດອ່ອນ. ການໝົດເວລາກ່ອນ challenge ໃດໆຍັງເປັນບັນຫາການເຂົ້າເຖິງ, ບໍ່ແມ່ນຫຼັກຖານວ່າລະຫັດຜ່ານ NTLM ຜິດ.

trace ລະອຽດອາດມີ token ຢືນຢັນຕົວຕົນ ແລະຊື່ພາຍໃນ. ໃຊ້ມັນພາຍໃນເຄື່ອງ ແລະລຶບຂໍ້ມູນລະອຽດອ່ອນກ່ອນແບ່ງປັນ; ລາຍງານຂໍ້ຜິດພາດສາທາລະນະບໍ່ຕ້ອງການການແລກປ່ຽນ token ດິບ.

ບົດຄວາມທີ່ກ່ຽວຂ້ອງ