Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

Lync / Office365 login problem

Help
2012-04-26
2013-03-28
1 2 > >> (Page 1 of 2)
  • Bill Hayden
    Bill Hayden
    2012-04-26

    After many long hours trying to get the latest pidgin/sipe to talk to our Office365 Lync server, I feel like I'm getting close.  But I am stuck on this error:
    Connection error on 0x233ad2e8 (reason: 2 description: Web ticket request to https://webdir0b-ext.online.lync.com:443/CertProv/CertProvisioningService.svc failed)

    Server: sipdir.online.lync.com:443 (note: leaving this blank does NOT work, it tries to connect our company domain)
    Connection: SSL/TLS
    User Agent: UCCAPI/4.0.7577.256 OC/4.0.7577.280 (Microsoft Lync 2010)

    Here is the full debug log, in case that's helpful:
    (11:03:36) account: Connecting to account bill.hayden@xyz.com,bill.hayden@xyz.com.
    (11:03:36) connection: Connecting. gc = 0x233ad2e8
    (11:03:38) dnsquery: Performing DNS lookup for sipdir.online.lync.com
    (11:03:38) dns: Wait for DNS child 14443 failed: No child processes
    (11:03:38) dns: Created new DNS child 14448, there are now 1 children.
    (11:03:38) dns: Successfully sent DNS request to child 14448
    (11:03:38) dns: Got response for 'sipdir.online.lync.com'
    (11:03:38) dnsquery: IP resolved for sipdir.online.lync.com
    (11:03:38) proxy: Attempting connection to 65.55.127.25
    (11:03:38) proxy: Connecting to sipdir.online.lync.com:443 with no proxy
    (11:03:38) proxy: Connection in progress
    (11:03:38) proxy: Connecting to sipdir.online.lync.com:443.
    (11:03:38) proxy: Connected to sipdir.online.lync.com:443.
    (11:03:38) nss: subject=CN=*.online.lync.com,OU=UCG,O=Microsoft,L=Redmond,ST=Washington,C=US issuer=CN=Microsoft Secure Server Authority,DC=redmond,DC=corp,DC=microsoft,DC=com
    (11:03:38) nss: subject=CN=Microsoft Secure Server Authority,DC=redmond,DC=corp,DC=microsoft,DC=com issuer=CN=Microsoft Internet Authority
    (11:03:38) nss: subject=CN=Microsoft Internet Authority issuer=CN=GTE CyberTrust Global Root,OU="GTE CyberTrust Solutions, Inc.",O=GTE Corporation,C=US
    (11:03:38) nss: subject=CN=GTE CyberTrust Global Root,OU="GTE CyberTrust Solutions, Inc.",O=GTE Corporation,C=US issuer=CN=GTE CyberTrust Global Root,OU="GTE CyberTrust Solutions, Inc.",O=GTE Corporation,C=US
    (11:03:38) certificate/x509/tls_cached: Starting verify for sipdir.online.lync.com
    (11:03:38) certificate/x509/tls_cached: Checking for cached cert…
    (11:03:38) certificate/x509/tls_cached: …Found cached cert
    (11:03:38) nss/x509: Loading certificate from /home/billh/.purple/certificates/x509/tls_peers/sipdir.online.lync.com
    (11:03:38) certificate/x509/tls_cached: Peer cert matched cached
    (11:03:38) nss/x509: Exporting certificate to /home/billh/.purple/certificates/x509/tls_peers/sipdir.online.lync.com
    (11:03:38) util: Writing file /home/billh/.purple/certificates/x509/tls_peers/sipdir.online.lync.com
    (11:03:38) certificate: Successfully verified certificate for sipdir.online.lync.com
    (11:03:38) stun: using server
    (11:03:38) stun: using server
    (11:03:38) stun: using server
    (11:03:38) stun: using server
    (11:03:38) stun: using server
    (11:03:38) dnsquery: Performing DNS lookup for webdir0b-ext.online.lync.com
    (11:03:38) dns: Successfully sent DNS request to child 14448
    (11:03:38) dns: Got response for 'webdir0b-ext.online.lync.com'
    (11:03:38) dnsquery: IP resolved for webdir0b-ext.online.lync.com
    (11:03:38) proxy: Attempting connection to 65.55.127.26
    (11:03:38) proxy: Connecting to webdir0b-ext.online.lync.com:443 with no proxy
    (11:03:38) proxy: Connection in progress
    (11:03:38) proxy: Connecting to webdir0b-ext.online.lync.com:443.
    (11:03:38) proxy: Connected to webdir0b-ext.online.lync.com:443.
    (11:03:38) nss: subject=CN=*.online.lync.com,OU=UCG,O=Microsoft,L=Redmond,ST=Washington,C=US issuer=CN=Microsoft Secure Server Authority,DC=redmond,DC=corp,DC=microsoft,DC=com
    (11:03:38) nss: subject=CN=Microsoft Secure Server Authority,DC=redmond,DC=corp,DC=microsoft,DC=com issuer=CN=Microsoft Internet Authority
    (11:03:38) nss: subject=CN=Microsoft Internet Authority issuer=CN=GTE CyberTrust Global Root,OU="GTE CyberTrust Solutions, Inc.",O=GTE Corporation,C=US
    (11:03:38) nss: subject=CN=GTE CyberTrust Global Root,OU="GTE CyberTrust Solutions, Inc.",O=GTE Corporation,C=US issuer=CN=GTE CyberTrust Global Root,OU="GTE CyberTrust Solutions, Inc.",O=GTE Corporation,C=US
    (11:03:38) certificate/x509/tls_cached: Starting verify for webdir0b-ext.online.lync.com
    (11:03:38) certificate/x509/tls_cached: Checking for cached cert…
    (11:03:38) certificate/x509/tls_cached: …Not in cache
    (11:03:38) certificate: Checking signature chain for uid=CN=*.online.lync.com,OU=UCG,O=Microsoft,L=Redmond,ST=Washington,C=US
    (11:03:38) certificate: …Good signature by CN=Microsoft Secure Server Authority,DC=redmond,DC=corp,DC=microsoft,DC=com
    (11:03:38) certificate: …Good signature by CN=Microsoft Internet Authority
    (11:03:38) certificate: …Good signature by CN=GTE CyberTrust Global Root,OU="GTE CyberTrust Solutions, Inc.",O=GTE Corporation,C=US
    (11:03:38) certificate: Chain is VALID
    (11:03:38) certificate/x509/tls_cached: Checking for a CA with DN=CN=GTE CyberTrust Global Root,OU="GTE CyberTrust Solutions, Inc.",O=GTE Corporation,C=US
    (11:03:38) certificate/x509/tls_cached: Also checking for a CA with DN=CN=GTE CyberTrust Global Root,OU="GTE CyberTrust Solutions, Inc.",O=GTE Corporation,C=US
    (11:03:38) nss/x509: Exporting certificate to /home/billh/.purple/certificates/x509/tls_peers/webdir0b-ext.online.lync.com
    (11:03:38) util: Writing file /home/billh/.purple/certificates/x509/tls_peers/webdir0b-ext.online.lync.com
    (11:03:38) certificate: Successfully verified certificate for webdir0b-ext.online.lync.com
    (11:03:39) dnsquery: Performing DNS lookup for webdir0b-ext.online.lync.com
    (11:03:39) dns: Successfully sent DNS request to child 14448
    (11:03:39) dns: Got response for 'webdir0b-ext.online.lync.com'
    (11:03:39) dnsquery: IP resolved for webdir0b-ext.online.lync.com
    (11:03:39) proxy: Attempting connection to 65.55.127.26
    (11:03:39) proxy: Connecting to webdir0b-ext.online.lync.com:443 with no proxy
    (11:03:39) proxy: Connection in progress
    (11:03:39) proxy: Connecting to webdir0b-ext.online.lync.com:443.
    (11:03:39) proxy: Connected to webdir0b-ext.online.lync.com:443.
    (11:03:39) nss: subject=CN=*.online.lync.com,OU=UCG,O=Microsoft,L=Redmond,ST=Washington,C=US issuer=CN=Microsoft Secure Server Authority,DC=redmond,DC=corp,DC=microsoft,DC=com
    (11:03:39) nss: subject=CN=Microsoft Secure Server Authority,DC=redmond,DC=corp,DC=microsoft,DC=com issuer=CN=Microsoft Internet Authority
    (11:03:39) nss: subject=CN=Microsoft Internet Authority issuer=CN=GTE CyberTrust Global Root,OU="GTE CyberTrust Solutions, Inc.",O=GTE Corporation,C=US
    (11:03:39) nss: subject=CN=GTE CyberTrust Global Root,OU="GTE CyberTrust Solutions, Inc.",O=GTE Corporation,C=US issuer=CN=GTE CyberTrust Global Root,OU="GTE CyberTrust Solutions, Inc.",O=GTE Corporation,C=US
    (11:03:39) certificate/x509/tls_cached: Starting verify for webdir0b-ext.online.lync.com
    (11:03:39) certificate/x509/tls_cached: Checking for cached cert…
    (11:03:39) certificate/x509/tls_cached: …Found cached cert
    (11:03:39) nss/x509: Loading certificate from /home/billh/.purple/certificates/x509/tls_peers/webdir0b-ext.online.lync.com
    (11:03:39) certificate/x509/tls_cached: Peer cert matched cached
    (11:03:39) nss/x509: Exporting certificate to /home/billh/.purple/certificates/x509/tls_peers/webdir0b-ext.online.lync.com
    (11:03:39) util: Writing file /home/billh/.purple/certificates/x509/tls_peers/webdir0b-ext.online.lync.com
    (11:03:39) certificate: Successfully verified certificate for webdir0b-ext.online.lync.com
    (11:03:39) dnsquery: Performing DNS lookup for login.microsoftonline.com
    (11:03:39) dns: Successfully sent DNS request to child 14448
    (11:03:39) dns: Got response for 'login.microsoftonline.com'
    (11:03:39) dnsquery: IP resolved for login.microsoftonline.com
    (11:03:39) proxy: Attempting connection to 157.55.59.213
    (11:03:39) proxy: Connecting to login.microsoftonline.com:443 with no proxy
    (11:03:39) proxy: Connection in progress
    (11:03:39) proxy: Connecting to login.microsoftonline.com:443.
    (11:03:39) proxy: Connected to login.microsoftonline.com:443.
    (11:03:39) nss: subject=CN=login.microsoftonline.com,OU=WLID-Org,O=Microsoft Corporation,OID.2.5.4.9=One Microsoft Way,L=Redmond,ST=Washington,postalCode=98052,C=US,serialNumber=600413485,OID.2.5.4.15=Private Organization,OID.1.3.6.1.4.1.311.60.2.1.2=Washington,OID.1.3.6.1.4.1.311.60.2.1.3=US issuer=CN=VeriSign Class 3 Extended Validation SSL CA,OU=Terms of use at https://www.verisign.com/rpa (C)06,OU=VeriSign Trust Network,O="VeriSign, Inc.",C=US
    (11:03:39) nss: subject=CN=VeriSign Class 3 Extended Validation SSL CA,OU=Terms of use at https://www.verisign.com/rpa (C)06,OU=VeriSign Trust Network,O="VeriSign, Inc.",C=US issuer=CN=VeriSign Class 3 Public Primary Certification Authority - G5,OU="(C) 2006 VeriSign, Inc. - For authorized use only",OU=VeriSign Trust Network,O="VeriSign, Inc.",C=US
    (11:03:39) nss: subject=CN=VeriSign Class 3 Public Primary Certification Authority - G5,OU="(C) 2006 VeriSign, Inc. - For authorized use only",OU=VeriSign Trust Network,O="VeriSign, Inc.",C=US issuer=CN=VeriSign Class 3 Public Primary Certification Authority - G5,OU="(C) 2006 VeriSign, Inc. - For authorized use only",OU=VeriSign Trust Network,O="VeriSign, Inc.",C=US
    (11:03:39) certificate/x509/tls_cached: Starting verify for login.microsoftonline.com
    (11:03:39) certificate/x509/tls_cached: Checking for cached cert…
    (11:03:39) certificate/x509/tls_cached: …Found cached cert
    (11:03:39) nss/x509: Loading certificate from /home/billh/.purple/certificates/x509/tls_peers/login.microsoftonline.com
    (11:03:39) certificate/x509/tls_cached: Peer cert matched cached
    (11:03:39) nss/x509: Exporting certificate to /home/billh/.purple/certificates/x509/tls_peers/login.microsoftonline.com
    (11:03:39) util: Writing file /home/billh/.purple/certificates/x509/tls_peers/login.microsoftonline.com
    (11:03:39) certificate: Successfully verified certificate for login.microsoftonline.com
    (11:03:39) connection: Connection error on 0x233ad2e8 (reason: 2 description: Web ticket request to https://webdir0b-ext.online.lync.com:443/CertProv/CertProvisioningService.svc failed)
    (11:03:39) account: Disconnecting account bill.hayden@xyz.com,bill.hayden@xyz.com (0x22800f88)
    (11:03:39) connection: Disconnecting connection 0x233ad2e8
    (11:03:39) GLib: g_hash_table_destroy: assertion `hash_table != NULL' failed
    (11:03:39) connection: Destroying connection 0x233ad2e8

     
  • Stefan Becker
    Stefan Becker
    2012-04-26

    Unfortunately this is the normal log, not the -debug log. The last connection was to login.microsoft.com, so my best guess is that either your user name or password is wrong.

    I suggest to retry with pidgin -debug and put the log up on a pastebin service. Please make sure to delete your password from the log, because login.microsoft.com only accepts passwords in cleartext.

     
  • icnocop
    icnocop
    2012-04-26

    I was running into the same issue yesterday and earlier today.

    For me, it seems to be related to the fact that my password expired and I had to change it yesterday.

    Bill Hayden, did you also change your password recently around the time these errors started happening?

     
  • The Wu
    The Wu
    2012-05-04

    I have to ask…  Has anyone gotten this working with Office 365?  I have seen tutorials for BPOS and Lync Server stuff, but nothing that explicitly says "Hey guys got it with Office 365!"

    @Haydentech

    I have couple things for you that may or may not be helpful(more likely the later, but info is info)….

    First the auto-discovery piece should find your server.  Mine works just find in auto, but with that said the results are the same when I enter the same server name as you did.  So I think it's negotiating with the right place.

    For the UserAgent…   You have used a really old one actually and apparently it works just fine.  I am using the current UserAgent which is below.  I found this by watching the Lync communication logs.

    UserAgent: UCCAPI/4.0.7577.4072 OC/4.0.7577.4087 (Microsoft Lync 2010)

    I did some research on this string and found a wiki that was sorta useful (http://en.wikipedia.org/wiki/Microsoft_Lync), which had a listing of the Lync Versons

    Microsoft Lync 2010 - Ver 4.0.7577.0
    Microsoft Lync 2010 - Cumulative Update 1 - Ver 4.0.7577.108 (Jan 2011)
    Microsoft Lync 2010 - Cumulative Update 2 - Ver 4.0.7577.253 (Apr 2011)
    Microsoft Lync 2010 - Cumulative Update 2.1 - Ver 4.0.7577.256 (Apr 2011)
    Microsoft Lync 2010 - Cumulative Update 2.2 - Ver 4.0.7577.275 (Apr 2011)
    Microsoft Lync 2010 - Cumulative Update 2.3 - Ver 4.0.7577.280 (May 2011)
    Microsoft Lync 2010 - Cumulative Update 3 - Ver 4.0.7577.314 (Jul 2011)
    Microsoft Lync 2010 - Cumulative Update 3.1 - Ver 4.0.7577.330 (Sep 2011)
    Microsoft Lync 2010 - Cumulative Update 3.2 - Ver 4.0.7577.336 (Oct 2011)
    Microsoft Lync 2010 - Cumulative Update 4 - Ver 4.0.7577.4051 (Dec 2011)
    Microsoft Lync 2010 - Cumulative Update 4.1 - Ver 4.0.7577.4061 (Mar 2012)

    The string I am using appears to be even more current then the March version

    The whole thing still brings me back to the question "Does this work with Office 365?".  Well my logs are kinda telling as to where this could be breaking down.

    (09:04:32) certificate: Successfully verified certificate for login.microsoftonline.com
    (09:04:32) connection: Connection error on 0636ADD8 (reason: 2 description: Web ticket request to https://webdir0e-ext.online.lync.com:443/CertProv/CertProvisioningService.svc failed)
    

    login.microsoftonline.com has a couple options in the authentication process right here.  If you are using a straight O365 authentication maybe you can make it work, but I am using ADFS which redirects the authentication back to my servers.  I did try this with an account that was handled by office 365 security, but the results where the same.  I thought about setting up a test O365 Account that didn't have ADFS to see if that does the trick, but I wasn't sure if that was a stretch.

    Again I want to stress I don't how helpful any of this is, but the thread hasn't seen any action in a week and right now this is the only place I have seen info on my error.

     
  • Bill Hayden
    Bill Hayden
    2012-05-04

    The autodiscovery only works if your IT people have set up the DNS correctly, which apparently ours haven't.  That's a minor problem in the whole scheme of things though.  I discovered the server address by logging network activity on my Windows machine while logging in using Lync.

    I wish I had more to report, but I am still stuck here as well.  I do not believe this is a login/password problem, but then again I don't know what it is.  I'm using the same login/password as on Windows with Lync, which obviously works there.

     
  • Stefan Becker
    Stefan Becker
    2012-05-04

    I wouldn't be surprised if there is an web ticket authentication method the code doesn't cover, as all of this is basically not documented by Microsoft. The missing knowledge was reversed-engineered from logs taken with man-in-the-middle attacks on the Lync client. As you can see from sipe-webticket.c we only recognize the methods "WebTicketServiceWinNegotiate" (internal installation) and "WsFedBearer" (login.microsoft.com, i.e. Office365 accounts).

    Unless you can provide logs from the Lync client for your type of accounts, this won't change.

     
  • icnocop
    icnocop
    2012-05-04

    Yes, I have an Office 365 account and it works! :)  The only issue I have is that sometimes I have to manually reconnect because of the "Authentication failed" errors mentioned in this topic.  It only happens maybe once every day or two, so it is not too major for me.

     
  • The Wu
    The Wu
    2012-05-04

    Well he is my environment and hopefull this helps.

    OS:  Windows 7 Enterprise
    Client: Microsoft Lync 2010
    O365 Account:  Office 365 E3 Plan
    User Agent: UCCAPI/4.0.7577.4072 OC/4.0.7577.4087 (Microsoft Lync 2010)

    I have a log of my O365 logging into Lync, but it's almost a 1MB log file…  I have removed my account info, but it's too big for a single pastebin unless I have a pro account…

    Lync Authentication Log 1
    http://pastebin.com/mW6D3Qhb

    Lync Authentication Log 2
    http://pastebin.com/0kgRJy1K

    Hopefully this stuff is helpful.

    @icnocop

    What are you using for settings?  Maybe I could try what you are doing?

    Thanks

     
  • icnocop
    icnocop
    2012-05-04

    Microsoft Lync 2010
    v4.0.7577.4087
    Automatic configuration

    Pidgin 2.10.3
    pidgin-sipe-1.13.1-pidgin-2.10.1-win32-nsis-no-sspi.exe
    SIPE Connection type: Auto
    User Agent: UCCAPI/4.0.7577.314 OC/4.0.7577.314 (Microsoft Lync 2010)
    Authentication scheme: TLS-DSK

     
  • The Wu
    The Wu
    2012-05-04

    I have been trying a different user agent, but everything else is the same as mine.

    When did you company go to Office 365?  Did you start with BPOS or directly with O365?

    Thanks for the speedy responses too..

     
  • icnocop
    icnocop
    2012-05-04

    Yes, we started with Microsoft Online Services (BPOS) and then moved to Office 365 near the end of January, 2012.

    I am running on Windows 7 Ultimate 64-bit.

     
  • Bill Hayden
    Bill Hayden
    2012-05-04

    icnocop,

    What do you have in the username and login fields in your account settings?  I've been using my full e-mail address in both, since my e-mail address is what I use to log in on Lync 2010 in Windows.

     
  • icnocop
    icnocop
    2012-05-04

    The "Sign-in address" in Lync is the same as the Username and "Login user" in pidgin.
    my_first_name@my_company_name.com

    I also have Lync and Outlook running on the same machine.

     
  • Bill Hayden
    Bill Hayden
    2012-05-04

    Then I can't see any difference between your working setup and my non-working setup.  I even tried it on the exact Windows version of pidgin that you are using, on a machine that works with Lync.  Same "web ticket" error.

    The only difference I can think of is that we never used BPOS.  We started straight from 365 last month, so maybe the accounts are set up differently.

     
  • icnocop
    icnocop
    2012-05-04

    What version of pidgin sipe?  Are you using the one with or without sspi?

    In pidgin, my server field is blank so that it will automatically be discovered.
    The connection type is set to Auto and not SSL/TLS, like you mentioned having that as your setting before.
    What authentication scheme are you using?
    My local alias is also blank.
    My proxy is set to "Use Global Proxy Setting"

     
  • icnocop
    icnocop
    2012-05-04

    I also have an msn account with the same username, but a different password.  I'm not sure what the relationship is between msn.com and office365.com.
    My msn account is also setup in pidgin.

     
  • Stefan Becker
    Stefan Becker
    2012-05-05

    @krakensole: Lync doesn't log the web ticket stuff in its normal log. So what your log shows is the normal SIP stuff after it published the client certificate to the server. Actually your log shows that it didn't have to run the web ticket stuff, because it still had a valid client certificate cached:

    05/04/2012|15:42:23.728 2160:2004 INFO  :: REGISTER sip:company.com SIP/2.0
    ...
    From: <sip:USER@DOMAIN.COM>;tag=28c998c37b;epid=8e654cccc6
    ...
    User-Agent: UCCAPI/4.0.7577.4072 OC/4.0.7577.4087 (Microsoft Lync 2010)
    ...
    05/04/2012|15:42:23.728 2160:2004 INFO  :: End of Sending Packet - 207.46.5.50:443 (From Local Address: 10.0.5.155:12556) 781 bytes
    ...
    05/04/2012|15:42:23.792 2160:2004 INFO  :: SIP/2.0 401 Unauthorized
    ...
    WWW-Authenticate: TLS-DSK realm="SIP Communications Service", targetname="SN20B01FES07.infra.lync.com", version=4, sts-uri="https://webpoolsn20b01.infra.lync.com:443/CertProv/CertProvisioningService.svc"
    From: <sip:USER@DOMAIN.COM>;tag=28c998c37b;epid=8e654cccc6
    ...
    05/04/2012|15:42:23.792 2160:2004 INFO  :: End of Data Received - 207.46.5.50:443 (To Local Address: 10.0.5.155:12556) 637 bytes
    ...
    05/04/2012|15:42:23.798 2160:2004 INFO  :: REGISTER sip:intertech.com SIP/2.0
    ...
    From: <sip:USER@DOMAIN.COM>;tag=28c998c37b;epid=8e654cccc6
    ...
    User-Agent: UCCAPI/4.0.7577.4072 OC/4.0.7577.4087 (Microsoft Lync 2010)
    Authorization: TLS-DSK qop="auth", realm="SIP Communications Service", targetname="SN20B01FES07.infra.lync.com", gssapi-data="FgMBAH4BAAB6AwFP.......ACAQA=", version=4
    

    I'm not aware of a method to log the web ticket stuff with Lync. That's why we had to revert to a man-in-the-middle attack on the SSL connections that Lync creates to the servers. In your case, after you cleared your local certificate cache, it would create a SSL connection to host webpoolsn20b01.infra.lync.com, port 443.

     
  • The Wu
    The Wu
    2012-05-05

    I also started with Office 365 and didn't have BPOS…  It wouldn't surprise me if M$ still handles some of the BPOS people different with the login process.  My pidgin version is 2.10.13.

     
  • cmatters
    cmatters
    2012-06-04

    I am having the same problem (Web Ticket.)  Since I only run Linux (no windows), I am limited in my options.   It looks like there is no way currently to figure out the problem?

    I'm not aware of a method to log the web ticket stuff with Lync. That's why we had to revert to a man-in-the-middle attack on the SSL connections that Lync creates to the servers.

    I do have an android phone and I am able to log in to Office365 Lync using android.  I was also able to get a Lync log of a successful login. Perhaps this may be of some help?

    You can find the log HERE.  Please let me know if this was useful.

    Thanks,
    Lowell

     
  • Stefan Becker
    Stefan Becker
    2012-06-05

    @cmatters: thanks for the logs, but I'm not sure it is going to help. Obviously the Android client is using some form of HTTP protocol, not SIP. So I'm not sure that the web ticket stuff will apply in the end to a SIP account.

    But I think the crucial problem is this:

    Jun 4, 2012 2:55:32 PM INFO TRANSPORT:Need to create a new liveId instnce
    Jun 4, 2012 2:55:32 PM INFO TRANSPORT:Waiting on the token
    Jun 4, 2012 2:55:42 PM INFO TRANSPORT:Successfully retrieved a liveid token
    ...
    Jun 4, 2012 2:55:47 PM INFO TRANSPORT:Request to retrieve token for https://webpoolsn20b02.infra.lync.com/webticket/webticketservice.svc/wsfed_bearer received
    Jun 4, 2012 2:55:47 PM INFO TRANSPORT:Creds: SignInName is username@somedomain.com
    Jun 4, 2012 2:55:47 PM INFO TRANSPORT:Attempting to retreive new token for liveid
    Jun 4, 2012 2:55:47 PM INFO TRANSPORT:Derived service name is https://webpoolsn20b02.infra.lync.com
    Jun 4, 2012 2:55:47 PM INFO TRANSPORT:Using an existing liveId instance
    Jun 4, 2012 2:55:47 PM INFO TRANSPORT:Waiting on the token
    ...
    Jun 4, 2012 2:55:54 PM INFO TRANSPORT:Successfully retrieved a liveid token
    Jun 4, 2012 2:55:54 PM INFO APPLICATION:Serialized sipuri=sip:username@somedomain.com intUcwa= extUcwa= intADRoot= extADRoot= location=1 networkType=0
    ...
    Jun 4, 2012 2:55:54 PM INFO TRANSPORT:Web-Ticket retrieval for url https://webpoolsn20b02.infra.lync.com/webticket/webticketservice.svc/wsfed_bearer completed with status 0
    

    I think the authentication method for the web ticker server is Microsoft LiveID, but the log doesn't show how to aquire that.

     
  • Stefan Becker
    Stefan Becker
    2012-06-06

    Let's hope login.live.com understands the same protocol as login.microsoftonline.com. The URL at least looks similar.

    I tested my Office365 test account and I get an error message from login.live.com.

    Please test this for your account: get the SIPE source code, edit src/core/sipe-svc.c and change this line

    "https://login.microsoftonline.com:443/RST2.srf",
    

    to

    "https://login.live.com/RST2.srf",
    

    Compile & install the plugin, then retry to login to your account. Does that work?

    The other option is to use a binary editor on libsipe.dll/so, search for the string and replace it.

     
  • Stefan Becker
    Stefan Becker
    2012-06-06

    That is  'srf",' not 'srf";,", i.e. ignore the ; the SF message board has inserted into my code.

     
  • croolyc
    croolyc
    2012-06-09

    @stefanb2 - your tip doesn't work

    ...
    (08:31:31) sipe: transport_connect - hostname: login.live.com port: 443
    (08:31:31) sipe: using SSL
    (08:31:31) dnsquery: Performing DNS lookup for login.live.com
    (08:31:31) sipe: http_conn_close: closing http connection: User initiated
    (08:31:31) dns: Successfully sent DNS request to child 14771
    (08:31:31) dns: Got response for 'login.live.com'
    (08:31:31) dnsquery: IP resolved for login.live.com
    (08:31:31) proxy: Attempting connection to 65.54.186.47
    (08:31:31) proxy: Connecting to login.live.com:443 with no proxy
    (08:31:31) proxy: Connection in progress
    (08:31:31) proxy: Connecting to login.live.com:443.
    (08:31:31) proxy: Connected to login.live.com:443.
    (08:31:32) nss: subject=CN=login.live.com,OU=Passport,O=Microsoft Corporation,STREET=One Microsoft Way,L=Redmond,ST=Washington,postalCode=98052,C=US,serialNumber=600413485,businessCategory=Private Organization,incorporationState=Washington,incorporationCountry=US issuer=CN=VeriSign Class 3 Extended Validation SSL CA,OU=Terms of use at https://www.verisign.com/rpa (c)06,OU=VeriSign Trust Network,O="VeriSign, Inc.",C=US
    (08:31:32) nss: subject=CN=VeriSign Class 3 Extended Validation SSL CA,OU=Terms of use at https://www.verisign.com/rpa (c)06,OU=VeriSign Trust Network,O="VeriSign, Inc.",C=US issuer=CN=VeriSign Class 3 Public Primary Certification Authority - G5,OU="(c) 2006 VeriSign, Inc. - For authorized use only",OU=VeriSign Trust Network,O="VeriSign, Inc.",C=US
    (08:31:32) nss: subject=CN=VeriSign Class 3 Public Primary Certification Authority - G5,OU="(c) 2006 VeriSign, Inc. - For authorized use only",OU=VeriSign Trust Network,O="VeriSign, Inc.",C=US issuer=CN=VeriSign Class 3 Public Primary Certification Authority - G5,OU="(c) 2006 VeriSign, Inc. - For authorized use only",OU=VeriSign Trust Network,O="VeriSign, Inc.",C=US
    (08:31:32) certificate/x509/tls_cached: Starting verify for login.live.com
    (08:31:32) certificate/x509/tls_cached: Checking for cached cert...
    (08:31:32) certificate/x509/tls_cached: ...Found cached cert
    (08:31:32) nss/x509: Loading certificate from /home/zajonc/.purple/certificates/x509/tls_peers/login.live.com
    (08:31:32) certificate/x509/tls_cached: Peer cert matched cached
    (08:31:32) nss/x509: Exporting certificate to /home/zajonc/.purple/certificates/x509/tls_peers/login.live.com
    (08:31:32) util: Writing file /home/zajonc/.purple/certificates/x509/tls_peers/login.live.com
    (08:31:32) certificate: Successfully verified certificate for login.live.com
    (08:31:32) sipe: 
    MESSAGE START >>>>>>>>>> HTTP - 2012-06-09T06:31:32.149637Z
    ...
    MESSAGE END >>>>>>>>>> HTTP - 2012-06-09T06:31:32.149637Z
    (08:31:32) sipe: transport_input_common: new buffer length 4096
    (08:31:32) sipe: process_input: body too short (0 < 2266, strlen 392) - ignoring message
    (08:31:32) sipe: transport_input_common: new buffer length 8192
    (08:31:32) sipe: 
    MESSAGE START <<<<<<<<<< HTTP - 2012-06-09T06:31:32.345526Z
    ...
    MESSAGE END <<<<<<<<<< HTTP - 2012-06-09T06:31:32.345526Z
    (08:31:32) sipe: sipe_svc_https_response: code 200
    (08:31:32) connection: Connection error on 0x7f63c143d240 (reason: 2 description: Żądanie zgłoszenia WWW do https://webdir0e-ext.online.lync.com:443/CertProv/CertProvisioningService.svc się nie powiodło)
    (08:31:32) sipe: http_conn_close: closing http connection: Server closed connection
    (08:31:32) account: Disconnecting account zajonc@some.tld,zajonc@some.tld (0x7f63bf108bc0)
    (08:31:32) connection: Disconnecting connection 0x7f63c143d240
    (08:31:32) GLib: g_hash_table_destroy: assertion `hash_table != NULL' failed
    (08:31:32) connection: Destroying connection 0x7f63c143d240
    
     
1 2 > >> (Page 1 of 2)