у меня были проблемы, когда звонки в LogonUser Функция Windows API возвращается к NTLM аутентификация, а не использовать предпочтительный, по умолчанию, Kerberos аутентификация.
Исследуя проблему, у парня есть предложение:
Что нужно сделать, это выяснить, почему код использует NTLM вместо Kerberos в первую очередь, поскольку Kerberos используется по умолчанию, и попытаться посмотреть, можно ли его изменить, чтобы он использовал Kerberos. На ум приходит пара вещей:
- Клиентский компьютер должен быть присоединен к домену для использования Kerberos
Теперь у меня есть никогда слышал о being domain joined to use Kerberos. Либо вы присоединены к домену Active Directory, либо нет, верно?
В этом случае машина является присоединен к домену Active Directory, например:
contoso.local
Что значит быть "домен присоединен для использования Kerberos"; и как мне убедиться, что моя машина в порядке?
Чтобы понять комментарии @TheCleaner и @HarryJohnston, потребовался сон.
Точка зрения первоначального автора была настолько очевидна, что мой мозг искал истинный смысл.
Проверка подлинности Kerberos работает только в домене Active Directory (далее именуемом домен).
Machine Joined to Logon Types available
===================== ================================
Workgroup NTLM
Windows NT 4 domain NTLM
Active Directory domain Kerberos (with fallback to NTLM)
Единственный способ, которым вы можете даже надеяться на использование Kerberos, - это присоединиться к домену Active Directory.
Я бы подумал, что это настолько фундаментально, что даже не подлежит сомнению.
Но есть совет.
Всякий раз, когда я слышал или использовал термин «присоединенный к домену», он имел в виду «состояние присоединения к домену Active Directory».
Чтобы узнать, использует ли машина аутентификацию Kerberos, вы можете использовать "Kerberos Tray" и klist и посмотрите, видите ли вы KTG (билет на выдачу билетов Kerberos). Если вы видите это, это означает, что вы «присоединены» к домену Kerberos.
Лоток Kerberos и список Kerberos klist входят в состав Windows Server 2003 Resource Kit и Windows 2000 Resource Kit.
Смотрите также: http://technet.microsoft.com/en-us/library/cc738673%28v=ws.10%29.aspx
Я столкнулся с проблемой, когда откат NTLM был вынужден из-за блокировки порта 88, это была странная конфигурация в DMZ, которая не имела отношения к вашей проблеме, но полезный момент заключается в том, что мы определили причину отката с помощью делаем трассировку сети. Мы могли точно определить IP-адрес и порт, по которым выполнялась попытка запроса Kerberos (и не удалось), 3 набора пакетов, за которыми следует запрос NTLM при восстановлении после сбоя. В ЭТОМ случае нам просто нужно открыть порт, ваша ситуация, вероятно, будет другой, но информация в трассировке должна помочь вам найти причину отката.