sipe-1.15.1 for adium does not authenticate against lync corporate adfs installations. Useragent field is not populated in accounts.xml and gets overwritten after manually editing the file to add the useragent.
Please provide the debug log or a URL to a pastebin copy. The error message by itself is useless.
BTW: the Useragent string is only used for SIP messages not for HTTPS messages, because it is not required for the latter. HTTPS is used for e.g. TLS-DSK, ADFS and calendar information.
As you mentioned in your forum entry that Windows pidgin-sipe works OK, I doubt that the Useragent string is the real root cause for your problems.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
summary: adium-sipe-1.15.1 fails to authenticate against corporate adfs for offfice365 lync2010 --> fails to authenticate against corporate adfs for offfice365 lync2010
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This has absolutely nothing to do with useragent. The real error is that after SIPE has acquired the ADFS ticket and sent it to login.microsoft.com, the SSL connection is simply terminated:
after setting the environment variable, still does not work. My win7 and ubuntu pidgin need the useragent set otherwise I get the same error. (Or at least with the useragent set its working :) )
Unfortunately error messages mean nothing, because for the same root cause you can see a variety of different error messages.
The log shows the exact same error. Are you 100% sure that the Adium process had the variable set?
Anyway, this is not a SIPE bug. SIPE just tells libpurple to open a SSL connection and gets called when there is input data. The problem happens at a lower layer, maybe in the Adium<->libpurple glue, or even lower at the OS level.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To be sure that is not caused by NSS I would enable NSS debugging. Please be aware that you'll need to put the debug level very high (e.g. 99) and that there will be a lot of data to wade through. I would use SSLDEBUGFILE to separate this data out in an extra file.
If the variable NSS_SSL_CBC_RANDOM_IV is not an effect, then you'll see that NSS will split SSL records in two 1 + N-1 sized messages.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just installed pidgin with macports and compiled the sipe plugin. The main difference from what i can tell from UI is that I had to accept a certificate and without the Useragent set the lync site refused to authenticate. Once useragent was set I could login.
For some reason I can't get any SSLDEBUG or TRACE written to the file I've specified. Do I need to set something else? In the NSS env var page it mentioned the code needed to be complied with debug/trace option on.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The other option is that Adium isn't compiled with NSS for the SSL backend (Pidgin can also be compiled with GnuTLS). Or Adium has implemented a SSL backend to use some OS SSL library? Please check.
Other SSL stacks also have implemented the security fix.
You could verify SSLDEBUG/TRACE with a program that definitely uses NSS. Or write a short test program that opens a SSL connection with NSS. There are some example programs on the Internet.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think we have now established that this is not a SIPE problem, as you can get it working with Pidgin on your Mac.
Just for completeness: can you attach logs from Pidgin with and without Useragent string set? Then I can verify that without Useragent string you get a different error flow than with Adium.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm not convinced that the issue is a caused due to NSS or SSL, the module connects fine to the lcs server we have. I'm going back to the issue that the useragent is not populated in the accounts.xml file. If I do not specify user-agent on pidgin the login to lync fails with same error message.
Can we fix the user-agent issue first and then further investigate nss?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The useragent string is not the issue in the Adium log, because the message we sent just before the SSL connection gets dropped is a HTTPS message, where SIPE DOES NOT add Useragent: header.
PLEASE provide the logs from the Pidgin run with and without Useragent string set. Then we can compare the two sets of debug logs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
which simply means your installation uses a "allowed client" filter and tells you to download the official Lync client.
BTW: this Pidgin version was compiled against GnuTLS, not NSS. That's probably why you don't see the SSL problem there.
I'm going to close this, because you'll will have to take this up with the Adium folks. They should know how SSL backend is implemented and how to disable the security fix that Microsoft SSL code doesn't grok.
BTW: all of this is Microsoft's fault. It's unbelievable that they still haven't rolled out the fix to their SSL code in over 1.5 years.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I opened https://trac.adium.im/ticket/16356 against Adium 1.5.6 so it should be fixed in the next Adium release (or the current source code if you compile against trunk).
Alternatively, as a temporary workaround, you can alter purple-transport.c in SIPE and use a larger BUFFER_SIZE_INCREMENT. I've found that 8192 and 16384 both work, where 4096 will elicit the error you're seeing.
Last edit: KwikSilvr 2013-06-08
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@KwikSilvr: thanks. So the root cause for error #1 was indeed in the Adium code.
@Sasha: I doubt that you'll have any luck with your Adium ticket #16402.
Error #1/2: you applied the Adium fix from #16356 and you still get a read error? If not then please clarify this on your ticket.
Error #2/2: the Useragent value set on the Adium UI is not being forwarded to the SIPE core. As this in the SIPE Adium UI part, and not Adium, the Adium project will divert your error to the SIPE project.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
a. 1.5.6 was released on 3-18-13
b. 16356 was opened on 3-25-13 (by me)
c. 16356 fix was committed on 3-26-13
The reason i wrote 16356 against "1.5.4" is that the versions are presented
in a drop down box in the ticketing system and "1.5.6" was not yet
available as an option. I'm not familiar with navigating the mercurial web
interface (or how adium manages their source tree), but you can download
the 1.5.6 source from the previous releases page and verify the fix is not
present: https://trac.adium.im/wiki/PreviousReleases
I dont use the "official" Adium interface offered by SIPE currently, but
i'll see if i can look around and figure out why the useragent does not
seem to be propagating.
Status: closed-invalid Created: Tue Jun 04, 2013 05:11 PM UTC by Sascha Buxhofer Last Updated: Mon Jun 10, 2013 03:42 AM UTC Owner: nobody
sipe-1.15.1 for adium does not authenticate against lync corporate adfs
installations. Useragent field is not populated in accounts.xml and gets
overwritten after manually editing the file to add the useragent.
But Adium project is strange: 1.5.7 has the fix, it has been bookmarked, but it hasn't been released by the project?
@Sasha: you will need to fetch the Adium 1.5.7 source code from Mercurial, compile it and then retry to see in the --debug log that you reach the same place as the macports pidgin + pidgin-sipe without Useragent.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Useragent: UCCAPI/4.0.7577.314 OC/4.0.7577.314
Error: Error: Web ticket request to https://webpoolbl20b02.infra.lync.com:443/CertProv/CertProvisioningService.svc failed
Please provide the debug log or a URL to a pastebin copy. The error message by itself is useless.
BTW: the Useragent string is only used for SIP messages not for HTTPS messages, because it is not required for the latter. HTTPS is used for e.g. TLS-DSK, ADFS and calendar information.
As you mentioned in your forum entry that Windows pidgin-sipe works OK, I doubt that the Useragent string is the real root cause for your problems.
logs attached
This has absolutely nothing to do with useragent. The real error is that after SIPE has acquired the ADFS ticket and sent it to login.microsoft.com, the SSL connection is simply terminated:
I'm assuming that you have NSS 3.13.x installed on your Mac and are not setting NSS_SSL_CBC_RANDOM_IV=0. Please see the FAQ.
I will close this as notabug very soon.
Hi Stefan,
after setting the environment variable, still does not work. My win7 and ubuntu pidgin need the useragent set otherwise I get the same error. (Or at least with the useragent set its working :) )
new debugs attached.
Unfortunately error messages mean nothing, because for the same root cause you can see a variety of different error messages.
The log shows the exact same error. Are you 100% sure that the Adium process had the variable set?
Anyway, this is not a SIPE bug. SIPE just tells libpurple to open a SSL connection and gets called when there is input data. The problem happens at a lower layer, maybe in the Adium<->libpurple glue, or even lower at the OS level.
I've added the variable in /etc/launchd.conf and I see it when I grep in the terminal after rebooting the machine.
sbuxhofer@jnpr-mbp:~$ env | grep NSS
NSS_SSL_CBC_RANDOM_IV=0
Are there any other logs or debugs I can take?
Last edit: Sascha Buxhofer 2013-06-04
To be sure that is not caused by NSS I would enable NSS debugging. Please be aware that you'll need to put the debug level very high (e.g. 99) and that there will be a lot of data to wade through. I would use
SSLDEBUGFILEto separate this data out in an extra file.If the variable
NSS_SSL_CBC_RANDOM_IVis not an effect, then you'll see that NSS will split SSL records in two 1 + N-1 sized messages.I just installed pidgin with macports and compiled the sipe plugin. The main difference from what i can tell from UI is that I had to accept a certificate and without the Useragent set the lync site refused to authenticate. Once useragent was set I could login.
For some reason I can't get any SSLDEBUG or TRACE written to the file I've specified. Do I need to set something else? In the NSS env var page it mentioned the code needed to be complied with debug/trace option on.
The other option is that Adium isn't compiled with NSS for the SSL backend (Pidgin can also be compiled with GnuTLS). Or Adium has implemented a SSL backend to use some OS SSL library? Please check.
Other SSL stacks also have implemented the security fix.
You could verify SSLDEBUG/TRACE with a program that definitely uses NSS. Or write a short test program that opens a SSL connection with NSS. There are some example programs on the Internet.
If Pidgin is compiled with NSS as SSL backend then you can see the ssl-nss module, e.g. on Linux:
$ rpm -ql libpurple | fgrep ssl- /usr/lib64/purple-2/ssl-nss.soI think we have now established that this is not a SIPE problem, as you can get it working with Pidgin on your Mac.
Just for completeness: can you attach logs from Pidgin with and without Useragent string set? Then I can verify that without Useragent string you get a different error flow than with Adium.
Hi Stefan,
I'm not convinced that the issue is a caused due to NSS or SSL, the module connects fine to the lcs server we have. I'm going back to the issue that the useragent is not populated in the accounts.xml file. If I do not specify user-agent on pidgin the login to lync fails with same error message.
Can we fix the user-agent issue first and then further investigate nss?
The useragent string is not the issue in the Adium log, because the message we sent just before the SSL connection gets dropped is a HTTPS message, where SIPE DOES NOT add
Useragent:header.PLEASE provide the logs from the Pidgin run with and without Useragent string set. Then we can compare the two sets of debug logs.
I think you maybe correct, I get a different "not authorized message". Here are the log w and w/o the Useragent setting.
debug w/o useragent set. Client was not able to sign in.
Yep, both logs are "identical" up to the response to the last REGISTER handshake. Without the Useragent string your client is rejected:
which simply means your installation uses a "allowed client" filter and tells you to download the official Lync client.
BTW: this Pidgin version was compiled against GnuTLS, not NSS. That's probably why you don't see the SSL problem there.
I'm going to close this, because you'll will have to take this up with the Adium folks. They should know how SSL backend is implemented and how to disable the security fix that Microsoft SSL code doesn't grok.
BTW: all of this is Microsoft's fault. It's unbelievable that they still haven't rolled out the fix to their SSL code in over 1.5 years.
I opened https://trac.adium.im/ticket/16356 against Adium 1.5.6 so it should be fixed in the next Adium release (or the current source code if you compile against trunk).
Alternatively, as a temporary workaround, you can alter purple-transport.c in SIPE and use a larger BUFFER_SIZE_INCREMENT. I've found that 8192 and 16384 both work, where 4096 will elicit the error you're seeing.
Last edit: KwikSilvr 2013-06-08
@KwikSilvr: thanks. So the root cause for error #1 was indeed in the Adium code.
@Sasha: I doubt that you'll have any luck with your Adium ticket #16402.
Error #1/2: you applied the Adium fix from #16356 and you still get a read error? If not then please clarify this on your ticket.
Error #2/2: the Useragent value set on the Adium UI is not being forwarded to the SIPE core. As this in the SIPE Adium UI part, and not Adium, the Adium project will divert your error to the SIPE project.
hmm, if the fix for #16356 is in Adium 1.5.7 then I have not applied it yet. Are there nightly builds for Adium?
According to these links
the socket read fix is already in 1.5.6 (or I don't understand Mercurial). Please either
I am sure the fix isnt it 1.5.6:
a. 1.5.6 was released on 3-18-13
b. 16356 was opened on 3-25-13 (by me)
c. 16356 fix was committed on 3-26-13
The reason i wrote 16356 against "1.5.4" is that the versions are presented
in a drop down box in the ticketing system and "1.5.6" was not yet
available as an option. I'm not familiar with navigating the mercurial web
interface (or how adium manages their source tree), but you can download
the 1.5.6 source from the previous releases page and verify the fix is not
present: https://trac.adium.im/wiki/PreviousReleases
I dont use the "official" Adium interface offered by SIPE currently, but
i'll see if i can look around and figure out why the useragent does not
seem to be propagating.
On Mon, Jun 10, 2013 at 3:03 AM, Stefan Becker stefanb2@users.sf.netwrote:
Related
Bugs:
#196@KwikSilvr: looks like you need to look at the Mercurial "bookmarks" to get the same thing as "tags" under git.
But Adium project is strange: 1.5.7 has the fix, it has been bookmarked, but it hasn't been released by the project?
@Sasha: you will need to fetch the Adium 1.5.7 source code from Mercurial, compile it and then retry to see in the --debug log that you reach the same place as the macports pidgin + pidgin-sipe without Useragent.