Две типичные формы основных имен Kerberos (v5) выглядят так:
username[/instance]@REALM
service/fully-qualified-domain-name@REALM
Я также видел нечто подобное для сервисов, которые могут существовать на нескольких портах:
service/fully-qualified-domain-name:port@REALM
У меня есть собственное приложение, которое сейчас подвергается керберизации, и я хотел бы понять, как следует называть принципалов службы. Служба является распределенной, с несколькими экземплярами, работающими на каждой из нескольких машин в каждом из нескольких субдоменов.
Например, допустим, мое доменное имя zombo.com, а моя Kerberized-служба «tenaciousd» работает на машинах с «www1» по «www5». Кроме того, каждая машина имеет десять экземпляров на хорошо известных портах, скажем, с 25001 по 25010.
Итак, у меня есть пятьдесят экземпляров сервера, все в основном одинаковые, что позволяет мне балансировать нагрузку, постепенно развертывать новые версии и так далее.
Теперь, как мне назвать участников-служб в Kerberos? Должен ли быть один для каждого хоста, на котором запущена служба, как это будет в наиболее распространенной форме?
tenaciousd/www1.zombo.com@ZOMBO.COM
tenaciousd/www2.zombo.com@ZOMBO.COM
tenaciousd/www3.zombo.com@ZOMBO.COM
tenaciousd/www4.zombo.com@ZOMBO.COM
tenaciousd/www5.zombo.com@ZOMBO.COM
Или лучше (и почему) иметь одного участника-службы на каждый экземпляр службы?
tenaciousd/www1.zombo.com:25001@ZOMBO.COM
tenaciousd/www1.zombo.com:25002@ZOMBO.COM
tenaciousd/www1.zombo.com:25003@ZOMBO.COM
...
tenaciousd/www5.zombo.com:25010@ZOMBO.COM
Наконец, как насчет того, чтобы иметь только одного участника службы, что кажется более простым, но менее распространенным?
tenaciousd@ZOMBO.COM
Если это важно, Kerberized служба (и клиенты) используют Cyrus SASL, GNU GSSAPI и MIT Kerberos 5. SASL API принимает параметр «полностью определенное доменное имя» в дополнение к имени службы, но я подозреваю, что это потому, что он поддерживает больше, чем просто Kerberos, и мы, вероятно, могли бы передать что-то, кроме фактических FQDN.
Большая часть найденной мною документации предполагает, что каждая служба работает на одном хосте в области или, по крайней мере, клиенты глубоко заботятся о том, к какому экземпляру службы они подключаются. В моем случае с точки зрения клиента все услуги в значительной степени одинаковы, так что же здесь лучше всего?
Для вещей, которые не являются уникальными (т. Е. Реплицируемых служб, выполняющих одни и те же обязанности), я обычно использую один общий серверный принципал. Это хорошо работает, если внешние объекты видят, например, одно и то же доменное имя, поскольку это поддерживает эту иллюзию.
Это также означает, что если пользователь переключается с экземпляра 1 на экземпляр 49, ему не придется выполнять еще одно квитирование Kerberos, поскольку у него уже есть действующий рабочий билет. Они будут использовать этот билет для аутентификации в любом из экземпляров без необходимости получать новый для каждого экземпляра.
Таким образом, я бы использовал:
tenaciousd/www.example.com@EXAMPLE.COM
в качестве основного имени для этой службы, при условии, что www.example.com - это то, как клиенты обращаются к этой службе.