У меня есть пара вопросов по Kerberos в Windows.
Я хочу узнать, какова цель сопоставления пользователя со службой с помощью ktpass.
Например, я работаю в Windows и запускаю ktpass следующим образом:
ktpass -out <keytab location> -princ <host/domain.com> -mapUser userA@domain.com -mapOp add .........
Когда мы сопоставляем пользователя с -princ означает ли это, что только "userA" может аутентифицировать службу? Как мы используем -add и -set вариант? В чем разница?
Моя проблема в следующем:
У меня есть:
Но:
Поэтому я думаю об использовании вместо этого SPN и сопоставлении с userA, а userA может использовать только службу. Но я не уверен, служит ли это сопоставление также разрешающей цели.
Для Krb5LoginModule Sun java есть опция useTicketCache.
Если я установлю значение true, означает ли это, что если какой-то пользователь войдет в систему, Krb5loginmodule будет использовать его / ее учетные данные Kerberoes, которые хранятся в памяти их компьютера?
Я спрашиваю об этом, потому что в другой реализации Krb5loginmodule
Например: IBM, нет useTicketCache, но есть useCcache, но useCcache должен указать местоположение билета; Я не хочу указывать это место.
Как это можно сделать в версии krb5loginmodule от IBm?
Я могу это сделать:
Обычно файл keytab используется для субъекта-службы, но могу ли я использовать эту keytab для хранения учетных данных пользователя.
Например: ktab -k mykeytab.keytab -a userA@REALM.COM ? не делая setspn или ktpass?
В AD субъекты-службы Kerberos связаны с объектами пользователей или компьютеров AD как атрибуты LDAP servicePrincipalName, поэтому необходимо указать учетную запись, в которую следует добавить участника. Это не определяет, какие пользователи могут аутентифицироваться к сервис (как вы догадались), а скорее, под какой учетной записью AD должна запускаться сама служба (если она работает в Windows). Это связано с тем, что службе нужны ключи для этого принципала для проверки билетов Kerberos, которые будут отправлены пользователями, и у нее будет доступ к ключам, если она работает под учетной записью, к которой привязан принципал. В Windows это происходит автоматически; в Unix это обычно выполняется администратором вручную, создавая файл keytab, содержащий ключи, и настраивая службу для его использования.
Для Krb5LoginModule Sun java есть опция useTicketCache. Если я установлю значение true, означает ли это, что если какой-то пользователь войдет в систему, Krb5loginmodule будет использовать его / ее учетные данные Kerberoes, которые хранятся в памяти их компьютера?
Это идея, хотя она работает плохо из-за того, что Java решила встроить полную реализацию Kerberos в JDK, а не использовать ту, которая предоставляется хостом (есть вариант для последнего, но только в Unix, и большинство людей не знают о или использовать). В Unix пакет Java Kerberos может читать ccache в стиле MIT, но не записывать в него. В Windows он может читать SSPI ccache (учетные данные пользователя), но вам необходимо установить раздел реестра:
HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Control \ Lsa \ Kerberos \ Parameters \ allowtgtsessionkey = DWORD 1
... чтобы Java могла получить сеансовый ключ для TGT, чтобы использовать его. Это ограничено по умолчанию и обычно не требуется, поскольку программа Windows обычно запрашивает SSPI для выполнения операций, для которых требуется ключ сеанса, а не выполняет их самостоятельно.
Обычно файл keytab используется для субъекта-службы, но могу ли я использовать эту keytab для хранения учетных данных пользователя.
В keytab хранится набор пар (принципал, ключ); не имеет значения, является ли принципал пользователем или службой. Вы можете сохранить ключи, соответствующие вашему паролю, в keytab (например, с помощью программы MIT "ktutil"), а затем аутентифицироваться с помощью keytab вместо того, чтобы вводить свой пароль (например, с помощью "kinit -k -t"). Однако имейте в виду, что по сути это то же самое, что и ввод пароля в файл, со всеми вытекающими из этого соображениями безопасности.