Успішний вхід у браузері для людини за робочим столом не підтверджує ідентичність служби LocalSystem. LocalSystem пов'язаний з комп'ютером, а не з користувачем, який увійшов.

Коли застосунок використовує контекст безпеки Windows для автентифікації на проксі, з'ясуйте, який обліковий запис проксі фактично отримує. На машині, приєднаній до домену, це може бути запис комп'ютера, а не запис працівника.

Windows має окрему політику Network security: Allow Local System to use computer identity for NTLM. Вона керує службами LocalSystem, які використовують Negotiate, коли переходять на NTLM. Підтримувана політика та її типове значення відрізняються в різних історичних версіях Windows.

Клієнт HTTP також має використовувати підтримуваний шлях автентифікації на проксі та запитувати передбачені облікові дані. Сама політика не додає підтримку автентифікації довільному клієнту.

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

Схожі статті