Я вообще не специалист по Windows, но я понимаю основную идею, что Active Directory - это LDAP + Kerberos 5 + особый соус Microsoft. Итак, в ситуации, когда у меня есть компьютер с Windows, который я не могу контролировать и который находится в существующем домене Active Directory, возможно ли, чтобы человек на этом компьютере явно получил билет Kerberos для чужой области, а затем получил ресурсы на управляемый мной сервер Linux, который находится в контролируемой мной области Kerberos / LDAP?
В частности, предположим, что у меня есть в моей области пользователь «foo@MYREALM.COM», и этот пользователь входит в случайную машину Windows в «BAR.COM», который является областью Microsoft AD, используя имя пользователя «baz». Теперь они хотят получить файлы с общего ресурса на моей машине quux.myrealm.com через Samba или NFSv4 или получить доступ к веб-странице, требующей аутентификации Kerberos, и им нужно сделать это как foo@MYREALM.COM вместо baz @ BAR. COM, который является идентификатором, который они использовали для входа в Windows.
способ Kerberos для Linux / Unix / MIT - это "kinit foo@MYREALM.COM", а затем использовать его. Есть ли в windows аналог? Есть ли эквивалент, не требующий установки ничего необычного (например, MIT Kerberos для Windows).
Межсферное доверие здесь не вариант, потому что я сомневаюсь, что существующие администраторы AD добавят соответствующие записи TGT даже для односторонней аутентификации, и, кроме того, у меня нет никакого желания доверять этому домену.
Хорошо, вот кое-что, что я узнал.
Во-первых, у многих людей, которые хотят использовать мои ресурсы, есть машины с Windows, которые не являются частью активного домена, а только персональные машины. Итак, что необходимо, это запустить терминал от имени администратора и
"ksetup / setrealm" MYREALM_GOES_HERE"
Без прав администратора ksetup не будет работать.
После перезагрузки клиентский компьютер Windows будет думать, что он должен разговаривать с моим KDC при получении билетов (мой KDC обнаруживается DNS).
ksetup - это более или менее интерфейс командной строки для изменения информации, которая на машине Linux / Unix будет храниться в /etc/krb5.conf, поэтому вы можете указать область по умолчанию с помощью / setrealm, и вы можете сообщить системе о других областях с помощью / addkdc и установить сопоставление между принципалами Kerberos и локальными пользователями Windows с помощью / mapuser и soforth, как подробно описано здесь:
https://technet.microsoft.com/en-us/library/hh240190%28v=ws.11%29.aspx
чего я не видел, так это способа настроить то, что будет в разделе [capaths] файла krb5.conf, то есть сообщить машине, как получить транзитивные доверительные отношения между доменами, которые явно не связаны в иерархии. (т.е. не ABC.EXAMPLE.COM vs EXAMPLE.COM, а вместо этого скажите ABC.EXAMPLE.COM vs FOOBAR.COM)
Я не уверен, что произойдет, если вы попытаетесь установить ksetup на члене AD, я подозреваю, что он будет более заблокирован.
Я не специалист по Unix, но могу сказать вам, что у Microsoft есть для этого несколько технологий (и я подозреваю, что Unix тоже.)
Первый - это службы федерации Active Directory, которые, согласно статье в Википедии, могут
«предоставить пользователям доступ с единой регистрацией к системам и приложениям, расположенным за пределами организации»
В нем, как и в других продуктах, о которых я упомяну, используется новый подход, основанный на утверждениях, в котором вы можете использовать различные службы маркеров безопасности (STS) для преобразования ваших «утверждений» аутентификации в формат, необходимый вашему серверу или службе для аутентификации ( SAML, JWT и т. Д.).
Службы федерации Active Directory должны быть установлены в домене Windows, поэтому это может не сработать. Однако у Microsoft также есть несколько облачных продуктов для «преобразования требований», которые вы можете использовать вместо этого. Один Службы Azure Active Directory, который одновременно является «поставщиком удостоверений» и «службой токенов безопасности». Предыдущая ссылка указывает, что службы Azure Active Directory предоставляют вам
«Единый вход в тысячи облачных приложений и доступ к веб-приложениям, которые вы запускаете локально».
Я действительно не рекомендую решения LDAP, но если вы хотите пойти по этому пути, вам нужно будет использовать замену «Graph API» для доступа к «базе данных» этой службы. Также обратите внимание, что у этой службы есть опция «синхронизации», которая может синхронизировать учетные записи из локальной Active Directory с этой облачной службой.
Наконец, есть служба контроля доступа Azure, которая предлагает «службу токенов безопасности» (без поставщика удостоверений). Я лично считаю, что эта служба лучше подходит для мобильных приложений, которым необходимо авторизоваться от имени пользователя (OAuth2), но есть некоторое совпадение со службами Azure Active Directory, и вы, возможно, захотите проверить это.
PluralSight есть несколько курсов по этим технологиям, и я предлагаю вам ознакомиться с ними, если вы хотите узнать больше об этих технологиях.