Description of problem: After upgrade to Fedora 34 the pidgin-sipe has problem to obtain authorization certificate from the Skype for business infrastructure. Same configuration was working before on Fedora 33. Using the pidgin "Debug Window": ... (16:48:52) proxy: Connecting to lyncserver.example.com:443. (16:48:52) proxy: Connected to lyncserver.example.com:443. (16:48:53) nss: SSL version 3.3 using 128-bit AES-GCM with 128-bit AEAD MAC Server Auth: 2048-bit RSA, Key Exchange: 256-bit ECDHE, Compression: NULL Cipher Suite Name: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (16:48:53) nss: subject=... (16:48:53) nss: subject=... (16:48:53) nss: subject=... (16:48:53) certificate/x509/tls_cached: Starting verify for lyncserver.example.com (16:48:53) certificate/x509/tls_cached: Checking for cached cert... (16:48:53) certificate/x509/tls_cached: ...Found cached cert (16:48:53) nss/x509: Loading certificate from /home/mambroz/.purple/certificates/x509/tls_peers/lyncserver.example.com (16:48:53) certificate/x509/tls_cached: Peer cert matched cached (16:48:53) nss/x509: Exporting certificate to /home/mambroz/.purple/certificates/x509/tls_peers/lyncserver.example.com (16:48:53) util: Writing file /home/mambroz/.purple/certificates/x509/tls_peers/lyncserver.example.com (16:48:53) nss: Trusting CN=... (16:48:53) certificate: Successfully verified certificate for lyncserver.example.com (16:48:53) sipe: sipe_http_transport_connected: 'lyncserver.example.com:443'(0x556c49ddf060) (16:48:54) connection: Connection error on 0x556c4a13bce0 (reason: 2 description: Web ticket request to https://lyncserver.example.com:443/CertProv/CertProvisioningService.svc failed) (16:48:54) account: Disconnecting account michal.ambroz, (0x556c4927bc00) (16:48:54) connection: Disconnecting connection 0x556c4a13bce0 (16:48:54) sipe: sip_transport_drop: 'sipaccess.example.com:443'(0x556c49db9870) (16:48:54) GLib: g_hash_table_destroy: assertion 'hash_table != NULL' failed (16:48:54) connection: Destroying connection 0x556c4a13bce0 (16:48:56) util: Writing file accounts.xml to directory /home/mambroz/.purple (16:48:56) util: Writing file /home/mambroz/.purple/accounts.xml Version-Release number of selected component (if applicable): $ rpm -q pidgin pidgin-sipe purple-sipe pidgin-2.14.1-3.fc34.x86_64 pidgin-sipe-1.25.0-10.fc34.x86_64 purple-sipe-1.25.0-10.fc34.x86_64 How reproducible: 100% Steps to Reproduce: 1. run pidgin (having pidging-sipe plugin) 2. Use connection using "Office Communicator" protocol Basic Options: Username: user Advanced Options: Server: empty to use autodetect or lyncserver.example.com, fails for both User Agent: UCCAPI/16.0.6965.5308 OC/16.0.6965.2117 Authentication Scheme: TLS-DSK 3. Try to connect to server Actual results: Web ticket request to https://lyncserver.example.com.com:443/CertProv/CertProvisioningService.svc failed Expected results: Connected to skype for business infrastructure Additional info:
I tried my SfB test account with pidgin on Fedora 34 and login still works. So there doesn't seems to be something fundamentally changed in Fedora 34. Active development on SIPE code has been stopped, so the code base for Fedora 33 and Fedora 34 is the same. @rebus can you please attach the detailed debug output from pidgin --debug Please disable all other accounts to limit the size of the log file. Thank you.
Same problem here. Downgrading to gssntlmssp-0.9.0-2.fc33.x86_64 "solves" the problem. I can connect now.
(In reply to Christophe GRENIER from comment #2) > Downgrading to gssntlmssp-0.9.0-2.fc33.x86_64 "solves" the problem. I can connect now. If that is the root issue, then this explains why my test account still works: it doesn't use NTLM for authentication. From the Fedora update system I see that gssntlmssp-1.0.0 was only provided for F34+, so again if that is the root cause that would explain why there are no problems on F33. Reporter: Ping. I'm still waiting for the detailed log file. Thank you.
Created attachment 1780397 [details] Log with the downgraded gssntlmssp
Created attachment 1780398 [details] Log with the gssntlmssp gssntlmssp-1.0.0-1.fc34.x86_64
Cristophe: thanks for your logs, maybe they will help Simo. But I still need the logs from the original reporter before I can conclude that his issue has the same root cause and move the bug to gssntlmssp. @rebus please attach the requested log. Thank you.
Can you please export GSSNTLMSSP_DEBUG=/a/log/file before running pidgin and collect debug logs from the new gssntlmssp (and the old one if you have the patience).
Created attachment 1780603 [details] Log from gssntlmssp-0.9.0-2.fc33.x86_64.rpm
Created attachment 1780604 [details] Log from gssntlmssp-1.0.0-1.fc34.x86_64
Sadly the logs do not show any difference, except the 1.0 logs show that the operation is repeated identically multiple times.
I don't know if the function has been renamed but it looks like get_enterprise_name() isn't called anymore. Is there any way to increase the logging level ?
get_enterprise_name() is a new function we added between 0.9 and 1.0 as we rearranged the code that parses names. Depending on how pidgin-sipe constructs names, there is a small chance that this change may cause some issues, but I do not have a good way to analyze that w/o either adding additional debugging, or reproducing locally somehow. We could rebuild a package with all the 1.0 changes except the name change to test if we can norrw the issue to a specific change I guess.
Hello, Hello Simo, thanks for the hint. I finally got to working configuration. Something changed regarding the user name/login with the upgrade to F34. For successfull TLS-DSK authentication, after migration to Fedora 34 I have to use samAccountName for the "Login" field instead of the principal/email, which I used before. For completeness - I was using configuration: Basic options: Protocol: Office communicator Username: michal.ambroz (Active directory principal name) Login: empty or michal.ambroz Advanced Options: Server: empty to use autodetect or lyncserver.example.com, fails for both User Agent: UCCAPI/16.0.6965.5308 OC/16.0.6965.2117 Authentication Scheme: TLS-DSK For successfull TLS-DSK authentication, after migration to Fedora 34 I have to use configuration in form: Basic options: Protocol: Office communicator Username: michal.ambroz (Active directory principal name / email) Login: mambroz (samAccountName in Active directory) Best regards Michal Ambroz