У меня есть базовое представление о том, как Kerberos работает в среде Active Directory, и о методах, которые он использует для аутентификации пользователей и рабочих станций в сети, но мой вопрос ... поскольку Kerberos полагается на выпуск маркера безопасности, который конечный пользователь затем использует для доступа сетевые ресурсы, как системы (ноутбуки), не входящие в домен, могут получать доступ к тем же сетевым ресурсам, используя только имя пользователя и пароль пользователя активного каталога?
Я предполагаю, что было бы больше смысла, если бы Kerberos просто с использованием учетных данных пользователя генерировал токен безопасности и отправлял его системе, но похоже, что там должна быть больше безопасности, чтобы предотвратить доступ недоменной системы к сетевым ресурсам.
Если бы кто-нибудь мог меня просветить, я был бы признателен!
как системы (ноутбуки), не входящие в домен, могут получить доступ к одним и тем же сетевым ресурсам, используя только имя пользователя и пароль пользователя активного каталога?
Это зависит от того, какие «сетевые ресурсы» задействованы. На подключенном к домену компьютере под управлением Windows, в который вы вошли, задействованы как минимум два клиентских удостоверения Kerberos:
Также существует host / workstation @ DOMAIN, но обычно это идентификация службы, работающей на хосте, доступ к которой осуществляется из другого места. Если привилегированный процесс на хосте хочет что-то сделать - скажем, добавить свое имя в DNS с помощью динамического DNS с аутентификацией Kerberos - он будет использовать для этого свою личность, рабочую станцию $ @ DOMAIN. Однако, если вы во время сеанса входа в систему сами обращаетесь к какому-либо ресурсу - скажем, к общему сетевому ресурсу CIFS или аутентифицированному URL-адресу HTTP, - тогда удостоверение клиента ваш основное имя, user @ DOMAIN (учетные данные для которого будут получены автоматически с использованием пароля, который вы ввели для входа в систему). Судя по вашему вопросу, вам кажется, что здесь задействована некоторая комбинация; это не так, они отдельные.
Вот почему нет проблем с использованием Kerberos для доступа к ресурсам Windows с других платформ. Вы также можете ввести «kinit user» в поле Linux, ввести свой пароль, чтобы получить учетные данные Kerberos (TGT) от контроллера домена, а затем использовать Firefox для доступа к веб-странице с проверкой подлинности Kerberos в IIS. Протоколы для всего этого стандартные, и вам не нужно ничего, кроме ваших учетных данных.
В предыдущем ответе утверждалось, что в этом случае требуется NTLM; это неверно (хотя, конечно, это может быть использовано). Однако, когда вы получаете доступ к какому-либо ресурсу с компьютера, не являющегося доменом, и вам предлагается ввести ваше имя пользователя и пароль, вы не обязательно знаете, какой метод аутентификации фактически используется. Он может использовать Kerberos. Он также может просто вернуться к механизму на основе пароля, при котором он отправляет ваше имя пользователя и пароль на сервер для проверки, а затем кеширует ваш пароль, чтобы вам не приходилось повторно вводить его. Многие протоколы позволяют использовать оба способа через схемы абстракции, такие как SASL. Вам нужно будет посмотреть на провод, чтобы увидеть, что происходит.
Старый вопрос, но ответы не особо точные.
Windows не особо заботится о том, присоединен ли ваш компьютер к домену или нет. Присоединение к домену на этом этапе аутентификации на самом деле является лишь подсказкой, чтобы сообщить клиенту, с каким доменом ему, возможно, следует попытаться связаться, если недостаточно информации.
Принцип работы Kerberos auth заключается в том, что он смотрит на кредиты, предоставленные ему во время аутентификации. Если предоставленное имя пользователя содержит достаточно информации для разрешения контроллера домена, он немедленно попытается выполнить Kerberos. Он вернется к NTLM только в том случае, если пользователь предоставит недостаточно информации для того, чтобы клиент смог найти контроллер домена. В основном это работает так:
Типы пользователей \\foo\share
Пользователю предлагается ввести кредиты, ввести user@bar.domain.com и пароль.
Windows видит bar.domain.com и делает что-то, называемое местоположением DC, которое, помимо прочего, пытается разрешить SRV _kerberos._tcp.bar.domain.com из DNS, который либо указывает на контроллер домена, либо нет.
Если возвращается DC, Windows пытается получить TGT от DC, используя кредиты, введенные в (2).
Если это не удается, он может выполнить одно из следующих действий в зависимости от возвращаемых ошибок:
а) вернитесь к (3) и выполните круговой алгоритм
б) вернуться к NTLM
в) полностью провалить попытку
Теперь у него есть TGT для пользователя, и он помещает его в кеш билетов (см. klist.exe).
С помощью TGT и DC, с которыми он может общаться, он запрашивает билет службы для SPN. cifs/foo.
Если контроллер домена обнаружил учетную запись службы с этим SPN, он возвращает билет службы, в противном случае он возвращает ошибку, и Windows возвращается к NTLM.
Билет службы кэшируется.
Клиент отправляет сервисный билет на \\foo\share и SMB делает это.
Это более или менее похоже на то, как это работает на компьютерах, присоединенных к рабочей группе или домену. Единственная разница в том, что шаги 2 и 3 отличаются. На компьютере, присоединенном к домену, кредиты уже известны, а домен уже известен, поэтому он использует собственные кредиты SSO. Определение местоположения контроллера домена все еще выполняется, но не нужно рассуждать о домене пользователя, потому что он уже знает его.
Таким образом, уловка здесь заключается в вводе кредитов на шаге (2), чтобы у Windows было достаточно информации для поиска DC. Это означает использование полного доменного имени, а не добавленных вами настраиваемых дружественных UPN. Это также означает устаревший метод NetBIOS bar\user наверное не сработает. Может быть, если у вас достаточно устаревшей инфраструктуры для ее поддержки (помните NetBEUI?).
В этом случае используется NTLM ...
http://msdn.microsoft.com/en-us/library/windows/desktop/aa378749(v=vs.85).aspx
Ниже приведены инструкции по аутентификации на сервере Samba с использованием Kerberos из клиента Windows 7/10 (возможно, других). Я не тестировал другие версии клиента и сервера:
В клиенте Windows выполните команду «Запуск от имени администратора» cmd.exe. Затем введите эту команду, чтобы предоставить Windows сведения о контроллере домена Kerberos (KDC) для Kerberos REALM.COM.
Если KDC находится в DNS:
ksetup /addkdc REALM.COM
В противном случае:
ksetup /addkdc REALM.COM kdc01.realm.com
(Введите больше KDC для области REALM.COM, если они существуют. Кроме того, можно добавить другие области в любом стиле.)
Затем используйте Explorer для доступа к интересующей сетевой папке. (Например. \\samba.realm.com\share в адресной строке.) Запрос пароля откроется, если общий ресурс защищен.
Вам нужно будет указать область в имени пользователя. Это можно сделать либо как user@REALM.COM или REALM.COM\user.
Затем введите пароль.
Я знаю по крайней мере одну систему, которая может использовать Kerberos, работающую с рабочих станций вне домена. Это приложение называется «Портал SAP NETWEAVER». Когда я вхожу в веб-приложение, которое находится между рабочей станцией и контроллерами домена, я выполнил анализ сети на рабочей станции и при обмене данными. Перед этим выполняется запрос DNS для записей srv _krb домена, которые я передал в поле имени пользователя (это должен быть формат домена FQDN, например mydomain.local \ myusername). После этого появляются некоторые кадры кербероса.