Исторически говоря (как 17 лет назад):
Если процесс, работающий на сервере B, когда пользователь U хочет подключиться к серверу C как тот же пользователь, то протокол аутентификации между серверами требует, чтобы сервер Bзнает пароль пользователя U.
Если пользователь U вошел в систему на сервере B, это не проблема (пользователь должен был ввести пароль).
Однако предположим, что пользователь U являетсяфактически вошел в систему на клиенте A и подключается к серверу B (который может быть, скажем, почтовым сервером).Затем сервер B может безопасно определить, что он действительно подключается пользователем U, но сервер B никогда не видит пароль U, поэтому он не может подключиться к серверу C от имени U.
Это различие естественно создает два вида пользовательских токенов:
- Основной токен, представляющий пользователя, который "действительно" вошел в систему и может подключаться к другим сетевым ресурсам.
- Маркер олицетворения, представляющий аутентифицированного пользователя, который фактически вошел в систему на другом компьютере, тактокен нельзя использовать для доступа к другим сетевым ресурсам (поскольку ОС не знает пароля, а это требуется протоколом межсерверной аутентификации).
В наши дни всеболее сложный, потому что, например, аутентификация Kerberos поддерживает делегирование на нескольких серверах, но если вы явно не включите это, все те же ограничения, изложенные выше, будут по-прежнему применяться.
Возвращаясь к вашему вопросу, упомянутые вами ограничения применяются, только если вы спроситеза LOGON32_LOGON_NETWORKмаркер.Как говорится в документации, это быстрый вход для сетевых серверов, которым не требуется доступ к другим сетевым ресурсам;если вам нужен такой доступ, выберите другой тип входа.
Для дальнейшего чтения эта статья устарела, но охватывает различные варианты олицетворения и делегирования.