Судя по всему, ЯНХНП, как это всё работает.

Если кто-то с этим работал, объясните, пожалуйста.

Мы переходим на KerberosV5.

Начну с DCOM-а.
У нас сейчас проверка доступа делается через интерфейс IClientSecurity, через SetBlanked, у которого одним из параметров идёт указание типа протокола аутентификации. В случае c Керберосом надо указать валидно имя принципала (SPN, server principal name). И вот с SPN начинаются непонятки.
1. Его должен зарегистрировать сам сервис? Или нет? Если у меня несколько серверов с DCOM-сервисом в лесу, то это считается распределённой системой или просто это набор одиночных хостов? Или можно и так и так?

2. setspn работает через API? Есть (большая) разница между setspn и DsServerRegisterSpn? Сейчас я через setspn на своей машине не могу зарегистрировать SPN, потому что у меня не хватает прав на это, ок. Но я могу через RpcServerInqDefaultPrincName получить SPN и RpcServerRegisterAuthInfo у меня работает вроде бы, ошибок нет. Что это значит? Что этот SPN существует в KDC или нет?

3. про тикеты вообще не понятно. С DCOM: я поднимаю сервис, кроме регистрации в KDC что-то ещё требуется от самого сервиса? Можно/нужно ли регистрироваться как-то при запуске самого сервиса или это достаточно сделать 1 раз через setspn? Сейчас я запускаю на сервере DCOM от имени своей учётки, без каких-либо регистраций. С клиента в качестве принципала использую имя учётки - и всё работает! Как так? Но если я использую для поднятия DCOM локальную учётку или локальный сервис - я не могу подобрать SPN, какой должен быть SPN? А для локального сервиса? Хотя с локальным сервисом, видимо, надо как-то регистрироваться в KDC и... что потом надо сделать в DCOM?
C RPC всё вроде бы работает. Если я поднимаю RPC-сервер из-под доменной/локальной учётки, указывая из в качестве принципала - всё работает. Если не звать RpcServerRegisterAuthInfo - не работает. Вроде бы как всё нормально. Но где тут и как используются тикеты. В klist я тикет на свой РПЦ сервер, стало быть, всё ок?

Но наша главная цель DCOM, с ним всё непонятно.

1. Если это дефолтный SPN, то его не надо регистрировать. Регистрировать может только доменный админ(юнит с нужными правами). Если несколько серверов в лесу - каждому нужен свой уникальный SPN. Это нужно для KDC, когда он будет проверять, туда ли прицепляется клиент.

2. Скорее всего да, через API. Регистрация (в домене) это одно, а привязка SPN к сервису - это другое. Можно не регистрировать SPN, а взять дефолтный и привязать, а потом клиенту по нему же ходить. Данный финт проходит только если клиент знает юзера, от имени которого запущен сервис, т.е. сможет построить SPN по имени юзера и по имени хоста. Существует ли этот SPN в KDC, я не знаю, да это и не важно :)

3. Про тикеты - это просто теория, как оно внутри работает, для самой работы это не нужно. При поднятии DCOM регистрация не требуется. Регистрация, обычно требуется 1 раз, доменным админом(у кого есть права). После этого делается RpcServerRegisterAuthInfo на стороне сервиса. При регистрации используются: уникальное имя сервиса, имя хоста и имя доменной учётки. После этого, сервис поднимается от имени этой учётки. Клиент использует SPN вида <имя_сервиса>/<имя_хоста>. Использование имени учётки в SPN возможно, но не сильно удобно со стороны клиента.

4. Ошибка RPC_S_SEC_PKG_ERROR (1825) как правило, говорит о том, что или SPN не правильно указан, или не от того юзера запущен сервис.

5. Для РПЦ, порядок действий
сервер:
RpcServerUseProtseqEp - список протоколов
RpcServerInqBindings - получение вектора хендлов
RpcEpRegister - регистрация РПЦ сервера
RpcServerRegisterAuthInfo - привязка SPN
RpcServerListen - переход в ожидание запросов
клиент:
RpcBindingFormStringBinding - привязка интерфейса к серверу
RpcMgmtInqServerPrincName - извлечение SPN из интерфейса, т.е. можно самому и не указывать
RpcBindingSetAuthInfoEx - привязка SPN и прочая секьюрная кухня.
дальше вызываем функции сервера через интерфейс.

Внимание: некоторые функции требуют ручной чистки возвращаемых параметров.

Спасибо! Почитать успел самое начало, к тому моменту это я уже знал, но в книге это подробнее и последовательнее написано, так что благодаря ей, всё совсем встало на свои места. Ну и, например, про RpcMgmtInqServerPrincName никто кроме автора ни разу не упоминул :)

Пока с этим всем разбирался, стал большим поклонником РПЦ