Использование ресурсов в чужой области Kerberos из Windows без междоменного доверия?
Я совсем не 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.
Linux / Unix / MIT Kerberos: " kinit foo@MYREALM.COM", а затем сделайте это. Есть ли эквивалент в Windows? Есть ли эквивалент, который не требует установки чего-либо необычного (например, MIT Kerberos для Windows).
Межсферное доверие здесь не вариант, потому что я сомневаюсь, что существующие администраторы AD добавят соответствующие записи TGT даже для односторонней аутентификации, и, кроме того, у меня нет никакого желания доверять этому домену.
Хорошо, вот кое-что, что я выяснил.
Во-первых, у многих людей, которые хотят использовать мои ресурсы, есть машины windows, которые не являются частью Active Domain, только персональные машины. Поэтому для этого нужно запустить терминал от имени администратора и
"ksetup /setrealm MYREALM_GOES_HERE"
Без прав администратора ksetup не будет работать.
После перезагрузки машина windows клиента подумает, что ей следует поговорить с моим KDC при получении тикетов (мой KDC имеет обнаруживаемый DNS).
ksetup более или менее представляет собой интерфейс командной строки для изменения информации, которая будет храниться на машине Linux/Unix в файле /etc/krb5.conf, поэтому вы можете указать область по умолчанию с помощью /setrealm, а также рассказать системе о других областях с помощью /addkdc и задать отображение между kerberos принципалами и локальными пользователями окон с помощью /mapuser и soforth, как подробно описано здесь:
https://technet.microsoft.com/en-us/library/hh240190%28v=ws.11. %29.aspx
чего я не видел, так это способ настроить то, что было бы в разделе [capaths] файла krb5.conf, то есть сказать машине, как получить переходное доверие между доменами, которые очевидно не связаны в иерархии (т.е. не ABC.EXAMPLE.COM против EXAMPLE.COM, а вместо этого скажем ABC.EXAMPLE.COM против FOOBAR.COM)
Я не уверен, что произойдет, если вы попробуете ksetup на члене AD, я подозреваю, что это будет более заблокировано.
Я не из Unix, но могу сказать, что у Microsoft есть несколько технологий для этого (и я подозреваю, что у Unix тоже. )
Первая - это Active Directory Federation Services, которая, согласно статье в Википедии, может
"предоставлять пользователям единый доступ к системам и приложениям, расположенным за пределами организации"
Это, как и другие продукты, о которых я упомяну, использует новый "Претензионный подход", в котором вы можете заставить различные службы Security Token Services (STS) преобразовывать ваши аутентификационные "претензии" в формат, необходимый вашему серверу или службе для аутентификации (SAML, JWT и т.д.). )
Службы федерации Active Directory должны быть установлены в домене Windows, поэтому это может не сработать для вас. Однако у Microsoft также есть пара облачных продуктов "преобразования утверждений", которые вы можете использовать вместо них. Одним из них является Azure Active Directory Services, который одновременно является "Поставщиком идентификационных данных", а также "Службой жетонов безопасности". Предыдущая ссылка гласит, что Azure Active Directory Services предоставляет вам
"единую регистрацию тысяч облачных приложений и доступ к веб-приложениям, которые вы запускаете на месте".
Я действительно не рекомендую LDAP решения, но если вы хотите использовать именно такой путь, вам нужно будет использовать замену "Graph API" для доступа к "базе данных" этой службы. Также обратите внимание, что эта служба имеет опцию "синхронизации", которая может синхронизировать учетные записи из местной Active Directory с этой облачной службой.
Наконец, есть служба контроля доступа Azure's Access Control Service, которая предлагает "Security Token Service" (без идентификатора поставщика). Лично я считаю, что эта служба лучше подходит для мобильных приложений, которым нужно авторизоваться от имени пользователя (OAuth2), но есть некоторое дублирование со службой Azure Active Directory Services, и вы, возможно, захотите это проверить.
PluralSight имеет ряд курсов по этим технологиям, и я предлагаю вам ознакомиться с ними, если вы хотите узнать больше об этих технологиях.
.