Я думаю, это может быть связано с тем, как учетные данные сохраняются в диспетчере учетных данных.
Пример только SspiPromptForCredentials
, который я могу найти в MSDN, использует просто бесполезную строку ("Target"
).
Для CredUIConfirmCredentials
MSDN говорит:
Указатель на завершающуюся нулем строку, которая содержит имя цели для учетных данных, обычно имя домена или приложения сервера.
Это должно быть то же значение, которое передано как pszTargetName в CredUIPromptForCredentials или CredUICmdLinePromptForCredentials
CredUICmdLinePromptForCredentials
имеет аналогичный параметр и для этого MSDN говорит:
Указатель на завершающуюся нулем строку, содержащую имя цели для учетных данных, обычно имя сервера.
Параметр pszTargetName используется для идентификации целевой информации и используется для хранения и получения учетных данных .
...
Учетные данные хранятся в диспетчере учетных данных на основе целевого имени. Каждое целевое имя хранится в максимально возможной степени, не конфликтуя с учетными данными, уже сохраненными в диспетчере учетных данных. Важным эффектом сохранения учетных данных по имени цели является то, что конкретный пользователь может иметь только одну учетную запись на цель, сохраненную в диспетчере учетных данных.
Эти другие функции CredUI, возможно, являются низкоуровневыми, но я думаю, что использование параметров такое же.
MSDN говорит о переговорах:
Чтобы разрешить Negotiate выбрать поставщика безопасности Kerberos, клиентское приложение должно предоставить имя участника-службы (SPN), имя участника-пользователя (UPN) или имя учетной записи NetBIOS в качестве целевого имени . В противном случае Negotiate всегда выбирает провайдера безопасности NTLM.