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:
- SFB-client tries to login using current windows name;
- SFB-client gets error 0xC3E93EE4(SIP_E_AUTH_NTLMMISMATCH) from server (because on server "Require 128-bit encryption" is ON);
- SFB-client handling error from step 2 and goes on;
- 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:
- SFB-client tries to login using current windows name;
- SFB-client gets error "Credentials provided are not authorized to act as specified from URI <domain\username>" from server;
- 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);
- 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