Skype for business 2016 using current windows user name if I input other user name in sfb interface

Lamer Drv 101 Reputation points
2020-10-14T16:38:04.55+00:00

There are two domains in our corp - in headquarter and in branch office. There is the SFB-server in headquarter domain. SFB-server "knows" only headquarter domain users.
We had created accounts for branch office users in headquarter domain.
When a branchdomain\user in branch office runs client sfb 2016, sfb doesn't connect right away. Then user inputs sip-name, headquarter\username and password in sfb-client interface. And sfb-client sign in. This is not convenient but it's OK.

Several branch office users can't sign in sfb. In sfb-client log I see

403 Forbidden
...
ms-diagnostics: 4004;reason="Credentials provided are not authorized to act as specified from URI";AuthenticatedIdentity="BRANCH\nonEnglishUserName";source="Lync-Srv02.msk.headquarter.local"
ms-diagnostics-public: 4004;reason="Credentials provided are not authorized to act as specified from URI";AuthenticatedIdentity="BRANCH\nonEnglishUserName"
...
IP_MESSAGE::ConstructDiagnosticsInfo Parsing failed for header: 80070459 - skipping header 4004...

This known problem for SFB - non-english symbols in the userlogonname.

But why sfb-client using name of current windows user if I input other username in sfb-client interface ?

Only several users have this problem (from approx. 30 users). Most of branch office users connect in sfb successfully. All 30 branch office users have non-English userlogonnames. And I can't find difference in user or computer configurations.

Skype for Business
Skype for Business
A Microsoft communications service that provides communications capabilities across presence, instant messaging, audio/video calling, and an online meeting experience that includes audio, video, and web conferencing.
630 questions
0 comments No comments
{count} votes

Accepted answer
  1. Lamer Drv 101 Reputation points
    2021-01-17T13:29:41.097+00:00

    Some time ago I've found cause of unsuccessful SFB login (after compare logs on "good" and "bad" workstations countless times):
    "Network Security: Minimum session security for NTLM SSP based (including secure RPC) clients" - "Require 128-bit encryption" - on SFB servers
    "Network Security: Minimum session security for NTLM SSP based (including secure RPC) servers" - "Require 128-bit encryption" - on SFB clients

    It seems side effect + bug.

    On SFB servers "Network Security: Minimum session security for NTLM SSP based (including secure RPC) servers" - "Require 128-bit encryption" is ON.

    On "good" workstations "Require 128-bit encryption" option was OFF. As result:

    1. SFB-client tries to login using current windows name;
    2. SFB-client gets error 0xC3E93EE4(SIP_E_AUTH_NTLMMISMATCH) from server (because on server "Require 128-bit encryption" is ON);
    3. SFB-client handling error from step 2 and goes on;
    4. SFB-client tries to login using name and password which user inputs in SFB-client interface.

    On "bad" workstations "Require 128-bit encryption" option was ON. As result:

    1. SFB-client tries to login using current windows name;
    2. SFB-client gets error "Credentials provided are not authorized to act as specified from URI <domain\username>" from server;
    3. SFB-client handling error from step 2 and ... "stucks" if username includes non-english symbols (because username encoded with win-1251 instead utf-8 in server answer);
    4. SFB client puts in log-file
      "ERROR :: ParseMsDiagnosticsAttributes Failed to copy attribute value"
      and
      shows error messagebox about wrong SFB version - this message tells nothing about true cause of error.

    The key point - errors from server on step 2 in two these scenarios are different.

    Summarizing:
    "Require 128-bit encryption" on server is ON + "Require 128-bit encryption" on client is ON + non-eglish windows name = unsuccessful login

    "Require 128-bit encryption" on server is ON + "Require 128-bit encryption" on client is OFF + non-eglish windows name = successful login

    0 comments No comments

3 additional answers

Sort by: Most helpful
  1. JimmyYang-MSFT 53,851 Reputation points Microsoft Vendor
    2020-10-15T08:50:29.993+00:00

    Hi @Lamer Drv ,

    Do you mean this issue is only persist in non-English user in Skype for Business?

    Are there any error event logs in the event viewer?

    In this case, we recommend you try to disable these users in Skype for Business control Panel and restart the Master Replica replicator and the Replica replicator agent service on the frontend. Then enable these users again to see if this issue can be fixed.

    For more details about this error, you can refer to:

    http://lyncdude.com/2015/11/06/lync-skype-for-business-ls-user-replicator-event-id-30020/index.html


    If the response is helpful, please click "Accept Answer" and upvote it.

    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

    0 comments No comments

  2. Lamer Drv 101 Reputation points
    2020-10-15T17:09:07.037+00:00

    Do you mean this issue is only persist in non-English user in Skype for Business?

    No. This issue is only persist in several non-English windows users
    More precisely: 30 users have non-English userLogonName. 5 users - have problem, 25 users - don't have problem.
    Here is simple scenario:

    1. I have domain headquarter.local with two users (headquarter.local\Alice, headquarter.local\John) and there is skype for business server in this domain.
    2. I have second domain branch.local with two users (branch.local\Алиса, branch.local\Джон - userLogonNames in russian).
    3. users from branch.local domain can't sign in to SFB-server right away with their domain accounts - SFB-server "knows" only users from headquarter.local
    4. user branch.local\Алиса runs sfb-client and inside sfb-client interface inputs:
    • sip-name - alice@headquarter.ru
    • username - headquarter.local\Alice
    • password - password for headquarter.local\Alice account
      And sfb-client sign in successfully

    5) user branch.local\Джон does same - runs sfb-client and inside sfb-client interface inputs :

    • sip-name - john@headquarter.ru
    • username - headquarter.local\John
    • password - password for headquarter.local\John account
      And get error in sfb-client

    reason for error is userLogonName with non-english symbols (branch.local\Джон)

    And... it's raising questions:

    1. why first user (on first computer) can sign in with sfb-client, but second user (on second computer) can't ?
    2. why on second computer sfb using name of current windows user if I explicitly input other credentials in sfb-client interface ?

    This problem is contained by computer.

    Are there any error event logs in the event viewer?

    Yes.
    Event id: 9; Source: Lync

    In this case, we recommend you try to disable these users in Skype for Business control Panel and restart the Master Replica replicator and the Replica replicator agent service on the frontend. Then enable these users again to see if this issue can be fixed.

    I think the problem "sits" inside individual computers in branch.local domain.
    On Alice's computer in branch office I can sign in SFB (by entering any valid credentials from headquarter.local domain in sfb-client interface).
    On John's computer in branch office I can't sign in SFB. (Well... I can create branch.local\TestUser - with english userLogonName. Then I can sign in SFB. But this is not solution)


  3. Lamer Drv 101 Reputation points
    2020-10-22T17:32:51.73+00:00

    Yes.
    And two domains trust each other.

    I have tried to draw the process. But I am not sure about picture quality in bwoser window. Can you download picture?

    34250-skypesigninprocess.jpg


Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.