none
Не работает delegation пользователя который зашел через локальный кэш и потом подключится к сети через VPN RRS feed

  • Вопрос

  • Привет всем.

    Дано:

    Корпоративная сеть с AD. (для примера домен test)

    Сервер 1: Windows 2012 R2 Standard 64bit, на нем работает RESTful система предоставляющая WEB API, она запущенна под сервисной учеткой SVC-WEB-API (API на базу в Сервер 2 )на котором включена делегация через trust this user for delegation to any service (kerberos only).

    Сервер 2: Windows 2012 R2 Standard 64bit, на котором есть база, и на базу даны доступы через группы AD.

    Если компьютер пользователя в корпоративной сети, и пользователь залогинился и открыл IE или Firefox и обратился по WEB ссылкам(примерно https://Сервер1.test.corp/webapi/tables/sjkdfhkjsdhsdf/data) на Сервер 1 то все работает.

    Т.е в корпоративной сети все работает.

    Проблема:

    Компьютер вне корпоративной сети , пользователь заходит на рабочий ноутбук через учетку AD сохраненную в кэше, и подключается к корпоративной сети через VPN (Cisco AnyConnect Secure Mobility Client) и у него:

                    Работает все сервисы на которых есть Windows авторизация, кроме WEB API на Сервер 1 (делегирования не работает.)

    Что выяснил:

                    Если запустить браузер под другим пользователем при подключённом VPN, то все работает.

    При подключении через VPN В Журнале событий сервера 1 видно что есть события подключение пользователя, а в журнале событии сервера 2 уже видно что подключение анонимное.

    Не работает делегирование пользователя который зашел через локальный кэш и потом подлечился к сети через VPN

    Как сделать чтобы при подключении VPN пользователь как бы за нова прошел Аутентификацию ?


    • Изменено YERZHANOV Zhassulan 25 ноября 2018 г. 5:12 ошибка в загаловке
    24 ноября 2018 г. 5:03

Ответы

  • Проверьте  не включено ли у вас делегирование ограниченное делегирование с Сервер1 на Сервер2 только для протокола Kerberos. Если так - включите для всех протоколов.

    Потому как пользователь, вошедший на компьютер по сохраненным учетным данным, скорее всего, аутентифицируется на Сервер1 по NTLM (кстати, этот факт можно проверить по журналу событий Безопасность Сервер1), т.к. TGT для аутентификации по Kerberos он в момент входа получить не мог.


    Слава России!

    24 ноября 2018 г. 7:18
  • Да, RODC выдает не такой TGT, как нормальный DC. Например, закрытая информация в нем зашифрована ключом, специфичным для RODC, а не общедоменным (который связан с учетной записью krbtgt). А потому он годится только для запроса доступа к ресурсам, пароли которых реплицируются на RODC. Для запроса к другим ресурсам в домене требуется более сложная процедура, нежели обычный запрос билета службы.

    Как именно это влияет в вашем случае, я сказать затрудняюсь. Это зависит от деталей настройки: реплицируются ли пароли учетной записи веб-службы  и Сервер2 (или учетной записи службы, если служба, к которой требуется делегирование, работает под своей учетной записью)  на RODC, как настроено межсетевое экранирование и т.п.

    Поэтому я бы на вашем месте начал с выяснения оставшегося вопроса из тех двух, которые я задал в предыдущем ответе - по какому протоколу аутентифицируются на Сервер1 пользователи, подключившиеся с сохраненными учетными данными - Kerberos или какому-то другому (NTLM, к примеру). Это можно посмотреть в журнале безопасности Сервер1 (я полагаю, что там вы являетесь администратором).

    Если для аутентификации не используется Kerberos, то, с учетом того, что делегирование для учетной записи веб-службы настроено в варианте "только для Kerberos", то можно достоверно утверждать, что в такой делегирование осуществляться не будет. И ставить вопрос перед администраторами AD: что с этим делать?

    Возможно, достаточно будет реплицировать пароли веб-службы и Сервера2/службы на нем на RODC. И почти наверняка решит проблему включение делегирования в варианте для всех протоколов.


    Слава России!

    25 ноября 2018 г. 9:57

Все ответы

  • Здравствуйте. Из выше описанного, я понял, что вам нужна аутентификация по AD когда клиент стучится через VPN, так?

    Если так, то через циско вот не скажу, но допустим Я использую Kerio VPN  и в нем есть интерграция AD, что дает в последующем авторизацию через VPN по kerberos/

    Наверное такая же и штука есть в циско, коллеги думаю подскажут, кто пользуется. 

    24 ноября 2018 г. 5:50
  • Спасибо за ответ.

    Напрямую авторизация kerberos работает. не работает когда  к сервису обращается пользователь, а сервис в свою очередь делает запрос на базу данных не своей учеткой а учеткой пользователя который к нему обратился (delegation).

    Я подозреваю что это специально сделано что авторизованные через локально сохраненный кэш учетки не делегировались. Если VPN подключен и запустить браузер под другим пользователем(читай авторизоваться не локально а в контроллере домена) то все работает даже через VPN.



    24 ноября 2018 г. 7:00
  • Проверьте  не включено ли у вас делегирование ограниченное делегирование с Сервер1 на Сервер2 только для протокола Kerberos. Если так - включите для всех протоколов.

    Потому как пользователь, вошедший на компьютер по сохраненным учетным данным, скорее всего, аутентифицируется на Сервер1 по NTLM (кстати, этот факт можно проверить по журналу событий Безопасность Сервер1), т.к. TGT для аутентификации по Kerberos он в момент входа получить не мог.


    Слава России!

    24 ноября 2018 г. 7:18
  • Проверьте  не включено ли у вас делегирование ограниченное делегирование с Сервер1 на Сервер2 только для протокола Kerberos. Если так - включите для всех протоколов.

    Потому как пользователь, вошедший на компьютер по сохраненным учетным данным, скорее всего, аутентифицируется на Сервер1 по NTLM (кстати, этот факт можно проверить по журналу событий Безопасность Сервер1), т.к. TGT для аутентификации по Kerberos он в момент входа получить не мог.


    Слава России!

    Спасибо вам за ответ!

    У нас нет админских прав на AD и я ограничен в тестах, плюс еще я не очень хорошо знаком с AD. Но по вашему ответу я нашел как очищать TGT (klist purge) но это не помогло.

    Но я нашел другое:

    Если я рабою под AD админской ADM-L1 учеткой через VPN все работает. Значит само делегация работает , оно не работает для обычных пользователей.

    Потом я сравнил обе учетки, и нашел что моя простая учетка и учетка ADM-L1 отличается только тем что на простой учетке прописаны Read Only Domain Controller (RODC) которые находятся в нашей региональной подсетке.

    После я посмотрел учетки простых пользователей которые находятся в основной сетке(Франция) и обнаружил что у них RODC не прописан.

    После я попросил одного пользователя из основной сети подключится через VPN и попробовать открыть ссылки которые я дал. И у него все получилось.

    У меня предположение что при подключении через  VPN пользователи у которых прописан RODC авторизуются в нем и им не выдается разрешение на делегирование (я так понял TGT бывают нескольких видов, один из них с возможностью делегирование и RODC его не может выдать)

    Правильно я рассуждаю или пошел по ложному пути?


    25 ноября 2018 г. 3:14
  • Да, RODC выдает не такой TGT, как нормальный DC. Например, закрытая информация в нем зашифрована ключом, специфичным для RODC, а не общедоменным (который связан с учетной записью krbtgt). А потому он годится только для запроса доступа к ресурсам, пароли которых реплицируются на RODC. Для запроса к другим ресурсам в домене требуется более сложная процедура, нежели обычный запрос билета службы.

    Как именно это влияет в вашем случае, я сказать затрудняюсь. Это зависит от деталей настройки: реплицируются ли пароли учетной записи веб-службы  и Сервер2 (или учетной записи службы, если служба, к которой требуется делегирование, работает под своей учетной записью)  на RODC, как настроено межсетевое экранирование и т.п.

    Поэтому я бы на вашем месте начал с выяснения оставшегося вопроса из тех двух, которые я задал в предыдущем ответе - по какому протоколу аутентифицируются на Сервер1 пользователи, подключившиеся с сохраненными учетными данными - Kerberos или какому-то другому (NTLM, к примеру). Это можно посмотреть в журнале безопасности Сервер1 (я полагаю, что там вы являетесь администратором).

    Если для аутентификации не используется Kerberos, то, с учетом того, что делегирование для учетной записи веб-службы настроено в варианте "только для Kerberos", то можно достоверно утверждать, что в такой делегирование осуществляться не будет. И ставить вопрос перед администраторами AD: что с этим делать?

    Возможно, достаточно будет реплицировать пароли веб-службы и Сервера2/службы на нем на RODC. И почти наверняка решит проблему включение делегирования в варианте для всех протоколов.


    Слава России!

    25 ноября 2018 г. 9:57