It's big surprise that WTA works at all with russian user names - according to standard CURRENT_USER must be ASCII. I have no quick idea what can be done here before 3.0, where we will be able to map OS users to database users.
But may be the problem is not SO awful? Please, check - does it work correctly with UTF16 charset?
"The declared type of CURRENT_USER, CURRENT_ROLE, SESSION_USER, SYSTEM_USER, CURRENT_
CATALOG, CURRENT_SCHEMA, and CURRENT_PATH is character string. Whether the
character string is fixed length or variable length, and its length if it is fixed length or maximum length if
it is variable length, are implementation-defined. The character set of the character string is SQL_IDENTIFIER."
"SQL_IDENTIFIER is an implementation-defined character repertoire consisting of the <SQL language
character>s and all other characters that the SQL-implementation supports for use in <regular identifier>s."
So, in our case, it corresponds to UNICODE_FSS. And we do conform, as CURRENT_USER is described as ttype_metadata, which is UNICODE_FSS.
I suppose the issue is caused by the fact that AuthSspi returns the user name in the ANSI encoding (CP1251 for Russia) and it's not transliterated into UTF-8 when passed via DPB (or later, when written into usr_user_name, I'm not sure which one is correct).
The main problem is how does windows context authentication API return non-ascii user name. When user name contains ascii only characters this is definitely ascii. Taking into an account that we use QueryContextAttributesA to query user name, I hardly imagine how can it be UNICODE. Converting from national character sets like win1251 requires knowledge what character set is used for this particular windows version.
May be the best way is to use QueryContextAttributesU instead and always convert resulting string to UNICODE_FSS?