Alex S, ща копаюсь в той же теме.

Менять NTLM на Negotiate в этих трёх местах бессмысленно и вредно, потому как это запись и получение собственно NTLM токенов. У Вас продолжало работать потому, видимо, что не перекомпилировался исправленный Вами модуль при сборке приложения. Чтоб системный модуль перекомпилировался, нужно его ещё компилятору тем или иным способом подсунуть, а так он обычно готовые .dcu из папки lib использует.

Регистрируется этот IdAuthenticationSSPI для ещё и для Negotiate потому, что когда от сервера приходит заголовок WWW-Authenticate со словом Negotiate, это значит что сервер предполагает клиенту некоторую свободу выбора. Клиент может ответить токеном NTLM, и сервер типа станет по NTLM авторизовать. Но токеном Negotiate отвечать не нужно.

А вот готовой реализации клиента Kerberos под Delphi (и уж тем более под Indy) я пока не нашёл.

Хм.. Однако, наврал.

На текущий момент, когда у меня заработал Kerberos и Negotiate под Indy 10 через SSPI, я понимаю ситуацию так:

Если сервер предлагает авторизацию методом 'Negotiate', то отвечать нужно токенами со словом 'Negotiate'. Правда, получать такие токены нужно после передачи в AcquireCredentialsHandleW в качестве PackageName тоже имени 'Negotiate' Он будет немножко другой текст токенам делать. Аналогично с Kerberos-ом: пакет нужно указать 'Kerberos', и перед токенами писать 'Kerberos'. В общем, что прислали с сервера - то и продолжаем приписывать.

В отличие от NTLM, Kerberos требует, чтоб ему при первом обращении к InitializeSecurityContextW в InitAndBuildType1Message аргументом pszTargetName передать не nil или пустую строку, а SPN (service principal name, см. https://msdn.microsoft.com/en-us/library/ms677949(v=vs.85).aspx). Его довольно часто можно собрать из URL, взяв хост и приписав к нему, например, 'HTTP/'.

Если Negotiate в аналогичных условиях передать SPN, он может для формирования токенов выбрать алгоритм Kerberos, а если не передать - то точно выберет NTLM ( https://msdn.microsoft.com/en-us/library/ee498156.aspx).

Итого, чтоб всё это завелось, пришлось
1) добавить в конструктор класса аутентификации аргумент MethodName, и прокидывать в него значение из IdHTTP.pas при вызовах после поиска посредством FindAuthClass. При создании объекта пакета в TIndySSPIClient.Create стал вместо конечного наследника с зашитым именем создавать его родительский класс, с передачей в конструктор этого имени метода в качестве имени пакета. В спецификацию обработчика TIdOnSelectAuthorization пришлось тоже добавить имя метода.
1.1) попутно заметил, что вызовы LAuth.AuthParams := лучше б делать перед вызовами метода Authentication у этого объекта, чтоб Authentication мог потенциально опираться на актуальные сведения. Правда, собственно опираться не понадобилось пока.
2) добавить в TIdSSPINTLMAuthentication обработчик SetRequest, и поменять ему в базовом классе AUri со string на TIdURI, чтоб таки передавал хост. А то был только путь на сервере.
3) добавить регистрацию этого класса ещё и для метода MICROSOFT_KERBEROS_NAME (эта константа объявлена в c:\program files (x86)\embarcadero\studio\18.0\source\Indy10\Protocols\IdSSPI.pas)

Затем, уже в косметических целях, повыкидывал NTLM из имён вида TIdSSPINTLMAuthentication (чтоб было, в этом примере, TIdSSPIAuthentication), заменил fNTLMInfo на fSPPIInfo, добавил TIdSSPIAuthentication.SetServicePrincipalName для возможности установки более специфических SPN, поменял местами имена у TSSPIPackage и TCustomSSPIPackage, чтоб Custom было приписано у класса-предка, а не у того класса, экземпляр которого в итоге создаётся, и убил более не нужный класс TSSPINTLMPackage, инкапсулировавший лишь инициализацию родительского класса константой с именем пакета.

В общем, после этого у меня программа авторизовалась в режиме SSO по протоколу Negotiate.

Изменённые файлы прикладываю.