Совместное использование папок и клиентов AD без изменений
У меня следующая проблема. В моей компании я установил DNS-сервер + AD в WS2008 R2. У меня проблема в том, что при совместном использовании папки для группы, когда я добавляю или удаляю пользователей из группы, клиенты не вносят изменения, пока вы не закроете сеанс и не начнете снова. Например, вы не закрываете сеанс, пока пользователь не сможет получить доступ к общей папке, но не внутри группы. Я также вижу что-то странное, что если я получаю доступ к IP, изменения отражаются, но если я согласен с DNS, изменения не отражаются, и DNS разрешается правильно. Кто-нибудь может мне помочь? Спасибо вам большое!
2 ответа
Когда пользователь входит в систему, он получает билет Kerberos. Этот тикет содержит список всех групп, к которым принадлежит пользователь в то время. Если вы добавите их в группу после того, как они вошли в систему, они должны выйти из системы или войти в систему, чтобы получить новый билет с новым списком групп.
Когда вы обращаетесь к общему ресурсу по DNS-имени, это соединение аутентифицируется с помощью Kerberos. Когда вы получаете доступ к общему ресурсу по IP, NTLM используется для проверки подлинности соединения (не Kerberos). NTLM не использует тикеты, и членство оценивается более динамично. Тем не менее, Kerberos является отраслевым стандартом метода аутентификации, который используется более широко и предлагает другие преимущества, которые не предлагает NTLM.
Это ожидаемое поведение. Windows проверяет членство в вашей группе только при создании билета на выдачу билетов Kerberos. Здесь есть хорошее объяснение, но цитата:
Когда Алиса успешно прошла аутентификацию на своем DC (это DC домена, в котором определена учетная запись пользователя Алисы), KDC DC создает билет предоставления билетов Kerberos (TGT). Чтобы позволить KDC заполнить поле PAC TGT данными авторизации Алисы, DC выполняет следующие шаги:
- На шаге 1 DC запрашивает локальный раздел домена AD, чтобы выяснить членство Алисы в глобальной группе. К ним относятся не только членство в глобальной группе Алисы, которое было назначено непосредственно для ее учетной записи пользователя, но также и членство в глобальной группе, назначенное одной из глобальных групп, к которой принадлежит Алиса.
- На шаге 2 DC запрашивает локальный раздел домена AD, чтобы выяснить членство в универсальной группе Алисы. Опять же, они включают в себя не только членство в универсальной группе Алисы, которое было назначено непосредственно ее учетной записи пользователя, но также и членство в универсальной группе, назначенное одной из универсальных или глобальных групп, к которым принадлежит Алиса.
- На шаге 3 контроллер домена запрашивает раздел локального домена AD, чтобы выяснить членство в локальной группе домена Алисы. Еще раз, они включают в себя не только членство в локальной группе Алисы, которое было назначено непосредственно ее учетной записи пользователя, но также и членство в локальной группе домена, которое было назначено одной из локальных, универсальных или глобальных групп домена, к которым принадлежит Алиса.
Затем KDC сохраняет данные авторизации, собранные за эти три шага, в TGT Алисы и перенаправляет TGT на рабочую станцию Алисы. Рабочая станция Алисы автоматически кэширует TGT в локальном кеше билетов Алисы Kerberos.
Чтобы разрешить Алисе доступ к ресурсу, расположенному на рядовом сервере, и разрешить Алисе прозрачную аутентификацию на этом рядовом сервере, логика Kerberos на рабочей станции Алисы будет затем использовать кэшированный TGT Алисы, чтобы запросить у KDC билет службы для ресурса.
Если запрос на сервисный билет действителен, KDC сгенерирует сервисный билет. Чтобы заполнить PAC нового сервисного билета, KDC копирует данные авторизации, которые он находит в PAC TGT Алисы. Затем KDC отправляет служебный билет Алисе. Опять же, рабочая станция Алисы автоматически кэширует билет службы в локальном кэше билетов Алисы Kerberos.
(Kerberos сохраняет членство в вашей группе в поле "Сертификат привилегированного доступа (PAC)".
Надеюсь, это поможет.