Локальні помічники NTLM-проксі: доступ клієнта та вхід на вищому рівні

Ваш застосунок підключається до проксі на власному комп'ютері. Потім цей помічник автентифікується на корпоративному проксі. Застосунок не обов'язково сам виконує обмін автентифікації компанії.

application → local helper → company proxy → destination

Помічник на кшталт CNTLM має налаштування облікового запису та проксі вищого рівня. Його локальний слухач має окрему межу доступності та доступу. Пароль, введений у браузері для іншої кінцевої точки, не налаштовує ні того, ні іншого автоматично.

Визначте, яка ланка не спрацювала

Спочатку переконайтеся, що застосунок вибрав реальний слухач і протокол помічника. Помилка до досягнення цього слухача не є збоєм NTLM. Потім перевірте, чи помічник дістався налаштованого батька і чи батько прийняв його ідентичність.

Код 407, повернутий цим шляхом, потребує атрибуції. Зіставте локальну транзакцію з редагованою діагностикою помічника, а не припускайте, що видимий статус указує на обліковий запис, який має надсилати застосунок.

Старі приклади іноді додають заголовок keep-alive і повідомляють про успіх. Постійність з'єднання може мати значення в автентифікації, орієнтованій на з'єднання, але це спостереження не доводить, що кожному невдалому налаштуванню помічника потрібен той самий заголовок. Вибір кінцевої точки, підтримуваний метод, обліковий запис і час життя з'єднання залишаються окремими вхідними даними.

Слухач — це справжня служба

Loopback тримає слухач поза навколишньою мережею; він не розрізняє всі процеси чи користувачів на цьому комп'ютері. Шлюз або ширша прив'язка змінює набір викликів, які потенційно можуть використовувати ідентичність помічника вищого рівня. Робіть цю зміну свідомо.

Використовуйте схвалену схему з помічником, коли застосунок не може виконати потрібний метод. Корисний результат — відомий шлях із відомим власником облікового запису, а не непояснена додаткова служба, яка випадково змушує працювати одне завантаження.