Bug 1955937 - pdgin-sipe has problems to connect to Skype for business infrastructure after upgrade to Fedora 34
Summary: pdgin-sipe has problems to connect to Skype for business infrastructure after...
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: pidgin-sipe
Version: 34
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Stefan Becker
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-05-01 15:02 UTC by Michal Ambroz
Modified: 2021-05-08 13:14 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-05-08 13:14:33 UTC
Type: Bug


Attachments (Terms of Use)
Log with the downgraded gssntlmssp (42.34 KB, text/plain)
2021-05-06 16:50 UTC, Christophe GRENIER
no flags Details
Log with the gssntlmssp gssntlmssp-1.0.0-1.fc34.x86_64 (49.66 KB, text/plain)
2021-05-06 16:51 UTC, Christophe GRENIER
no flags Details
Log from gssntlmssp-0.9.0-2.fc33.x86_64.rpm (1.04 KB, text/plain)
2021-05-07 06:43 UTC, Christophe GRENIER
no flags Details
Log from gssntlmssp-1.0.0-1.fc34.x86_64 (4.15 KB, text/plain)
2021-05-07 06:44 UTC, Christophe GRENIER
no flags Details

Description Michal Ambroz 2021-05-01 15:02:01 UTC
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@example.com, (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@example.com
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:

Comment 1 Stefan Becker 2021-05-03 13:34:29 UTC
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@seznam.cz 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.

Comment 2 Christophe GRENIER 2021-05-06 07:36:55 UTC
Same problem here.
Downgrading to gssntlmssp-0.9.0-2.fc33.x86_64 "solves" the problem. I can connect now.

Comment 3 Stefan Becker 2021-05-06 15:56:01 UTC
(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.

Comment 4 Christophe GRENIER 2021-05-06 16:50:18 UTC
Created attachment 1780397 [details]
Log with the downgraded gssntlmssp

Comment 5 Christophe GRENIER 2021-05-06 16:51:20 UTC
Created attachment 1780398 [details]
Log with the gssntlmssp gssntlmssp-1.0.0-1.fc34.x86_64

Comment 6 Stefan Becker 2021-05-06 17:51:31 UTC
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@seznam.cz please attach the requested log. Thank you.

Comment 7 Simo Sorce 2021-05-06 20:50:19 UTC
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).

Comment 8 Christophe GRENIER 2021-05-07 06:43:57 UTC
Created attachment 1780603 [details]
Log from gssntlmssp-0.9.0-2.fc33.x86_64.rpm

Comment 9 Christophe GRENIER 2021-05-07 06:44:29 UTC
Created attachment 1780604 [details]
Log from gssntlmssp-1.0.0-1.fc34.x86_64

Comment 10 Simo Sorce 2021-05-07 13:41:19 UTC
Sadly the logs do not show any difference, except the 1.0 logs show that the operation is repeated identically multiple times.

Comment 11 Christophe GRENIER 2021-05-07 15:17:09 UTC
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 ?

Comment 12 Simo Sorce 2021-05-07 16:16:10 UTC
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.

Comment 13 Michal Ambroz 2021-05-08 13:14:33 UTC
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@example.com (Active directory principal name)
    Login:    empty or michal.ambroz@example.com

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@example.com (Active directory principal name / email)
    Login:    mambroz (samAccountName in Active directory)


Best regards 
Michal Ambroz


Note You need to log in before you can comment on or make changes to this bug.