Web ticket request error - SIP URI mismatch

Help
2013-03-21
2014-12-05
  • Finn E. Gundersen

    Pidgin 2.10.7, SIPE 1.15.0 (for 2.10.7).
    I have read the FAQ and this forum throughly (I believe), as well as other sites on this problem.
    My Lync is Microsoft Lync 2013 connected to Office 365 (Office 365 seems not to be lync server 2013 yet).

    I am running pidgin with:
    set NSS_SSL_CBC_RANDOM_IV=0
    pidgin -debug

    In general settings: I am using my username@organization.no as username, blank logon name (although have tried it there as well), have the correct password (getting a different error message if it is wrong), no local alias.

    In advanced setttings: no server (although have tried the two usual suspects), automatic connection type, useragent UCCAPI/4.0.7577.314 OC/4.0.7577.314 (Microsoft Lync 2010) and auth scheme TLS-DSK. No single sign-on.

    The GUI shows error
    Web ticket request to https://webdir0e-ext.online.lync.com:443/CertProv/CertProvisioningService.svc failed

    While the debug output says:The SIP URI in the claim type requirements of the web ticket request does not match the SIP URI associated with the presented credentials.

    I have not seen this error reported elsewhere. I am using my username in Office 365, but I have an alias that is more commonly used as my email address, and I can see that Lync itself has this alias as username. However I have tried both, and also mixing them in the logon and username and alias fields. Both are of the form username@domain.no

    There was one post about using a different username of the form RED001\\username_companyname etc as username. I found my credentials manager under user accounts in control panel of win8. But none of my credentials look like this.

    Does anyone have any input on this? I would like to dig deeper and solve this.

    Full XML-dump from debug: http://pastebin.com/czyLAcyR

     
  • Stefan Becker

    Stefan Becker - 2013-03-21

    Please provide full -debug log. The provided log is useless as it only shows the final error message.

     
  • Stefan Becker

    Stefan Becker - 2013-03-21

    Thanks (also for removing your password :-)

    The basic account settings seem to be correct. At least the initial communication doesn't show any errors. You have a hosted Lync installation without ADFS. So SIPE tries to authenticate directly via https://login.microsoftonline.com:443//RST2.srf. That also succeeds, i.e. the Office365 account "fegu@systorvest.no" + "<PASSWORD>" is accepted and we receive a FedBearer Token for https://webdir0e-ext.online.lync.com//WebTicket/WebTicketService.svc.

    SIPE then tries to use that token to acquire a WebTicket for sip:fegu@systorvest.no, which is rejected.

    So I can only assume that "sip:fegu@systorvest.no" is not your Lync user name.

    Have you tried to login via https://login.microsoft.com and check your settings? Maybe the SIP user name is first.last@systorvest.no? i.e.

    username: first.last@systorvest.no
    login: fegu@systorvest.no
    password: <PASSWORD>

     
  • Finn E. Gundersen

    I have spent some time working on this but the results are exactly the same. I posted a support request with Microsoft and got a very helpful support representative to look at it (even if they don't support pidgin as a client, he tried to help me anyway). He suggested downloading the exact same pidgin and sipe versions that others have reported working. I did, and the errors are the same. I have replicated several known-good configurations to no avail. The Microsoft support representative confirmed that my Office 365 SIP is the same as my Office 365 username. My Office 365 user works well in other respects. I am close to giving up, if anyone else gets this error and solves it, please post about it.

     
  • Stefan Becker

    Stefan Becker - 2013-03-25

    The only option left is a Man-In-The-Middle attack on the M$ Lync client to collect decrypted logs of a successful Web Ticket exchange. Only then can I check if there is something different in the messages.

    Starting point would be the decrypted communication to login.microsoft.com:443…

     
  • Finn E. Gundersen

    After a heroic performance lasting several hours from a Microsoft support engineer, this case has just been solved. I will post further information with more details in a few hours so others can benefit as well. But Pidgin is now running and logged in.

     
  • Finn E. Gundersen

    The problem was caused by my Office365 primary email address being different from my Office365 username. This might have several reasons, but Lync signed in with my primary email while all my other services (Outlook, Sharepoint) signed in with my username. A positively heroic effort by a Microsoft support engineer found the problem. There were two solutions, but the simplest one was to change my username to match my primary email adress. More details and screenshots in my blog post http://www.gundersen.net/pidgin-and-lync-problem-solved/

     
  • Stefan Becker

    Stefan Becker - 2013-03-26

    I think I finally figured out why this didn't work for you. For the request to l.m.c the login ID is hard-coded to the SIP user name. So whatever was in the Login name field got simply ignored. But in your case SIP user name is A and the l.m.c login ID should have been B. We couldn't see this, because l.m.c login was also successful with A, but it provided an invalid security token.

    I might have to rethink this bit of code…

     
  • Stefan Becker

    Stefan Becker - 2013-03-27

    git commit 9bfc193 would have probably solved your issue. I've updated the FAQ with the error message from your log.

     
  • Oskar Senft

    Oskar Senft - 2014-11-18

    I'm afraid I encountered a similar problem again. We're using Lync via Office 365 and an external authentication provider (Okta). Unfortunately our main e-mail address that uses in Office 365 does not match our login ID for Okta. I'm using the latest version 1.18.4 of the SIPE plug-in. As "username" I used the Office 365 e-mail address (as I would in the Lync client) and as "login" I used the Okta login ID (as I would in the Lync client).

    In the logs I see the following set of events:
    1) SIPE starts the SIP conversation with lync.com and eventually gets an "unauthorized".
    2) After requesting additional information via HTTP, it eventually calls out to login.microsoftonline.com/getuserrealm.srf?login=[username]&xml=1
    This returns a RealmInfo pointing to an Okta authentication server.
    3) SIPE then requests an authentication token from the Okta server using the information that was returned in step #2. However, it also sets the wsse:Username to the [login] information.
    4) Okta authentication fails since the information from step #2 provided in step #3 does not match the wsse:Username.

    The next was to set both the "username" and the "login" to the Okta login ID. In this case I get a bit further:
    4) Okta return an authentication token.
    5) SIPE then continues the conversation with lync.com using the authentication token from step #4.
    6) Lync.com eventually fails with the notorious "The SIP URI in the claim type requirements of the web ticket request does not match the SIP URI associated with the presented credentials."

    I figured that if I would change my configuration back to having a separate "username" and "login" and at step #2 SIPE would send the [login] ID, everything should work as expected. I managed to recompile SIPE and made the following code change:

    --- siplcs/src/core/sipe-svc.c.orig     2014-11-18 08:41:20.203590200 -0500
    +++ siplcs/src/core/sipe-svc.c  2014-11-17 15:23:12.578930800 -0500
    @@ -626,7 +626,7 @@
                                gpointer callback_data)
     {
            gchar *realminfo_uri = g_strdup_printf("https://login.microsoftonline.com/getuserrealm.srf?login=%s&xml=1",
    -                                              sipe_private->username);
    +                                              sipe_private->authuser ? sipe_private->authuser : sipe_private->username);
            gboolean ret = sipe_svc_https_request(sipe_private,
                                                  session,
                                                  realminfo_uri,
    

    This allowed me to get past the problem and I can now use Lync via Office 365 and Okta.

    Would it make sense to add this code change to the "official" SIPE sources, or could that cause issues with other authentication providers?

    I can provide the logs if necessary.

     
    • Stefan Becker

      Stefan Becker - 2014-11-18

      I don't think your patch is correct. This will fail for users that use DOMAIN\authuser as login. I assume that your login is authuser@domain.com and that's why it probably works for you.

       
    • Stefan Becker

      Stefan Becker - 2014-11-22

      I looked at the code now and unfortunately your explanation doesn't compute. Your change only makes sense if the STSAuthURL XML node in the realminfo response is different when requesting with

      • username (Office 365) or
      • login (Okta)

      I.e. Okta has two different ADFS servers running or two different ADFS services running on the same machine. As you have not provided any --debug log output, I can't tell.

       
      Last edit: Stefan Becker 2014-11-22
  • Oskar Senft

    Oskar Senft - 2014-11-18

    URL encoding is missing ... you're right! Is that what you meant?

    And yes, we have authuser@domain.com.

     
    Last edit: Oskar Senft 2014-11-19
    • Stefan Becker

      Stefan Becker - 2014-11-19

      I'm not sure if URI encoding is required, because the parameter has to be a valid RFC-822 address.

      But that is not what I meant. For the Windows AD case DOMAIN\authuser you'll end up with

      https://login.microsoftonline.com/getuserrealm.srf?login=authuser&xml=1
      
       
      • Oskar Senft

        Oskar Senft - 2014-11-19

        I'm sorry, I don't get it. Why would that not be correct?

        Or are you saying that there are cases where we need to use the authuser and there are cases where the username would be correct? How would we know that in the code? Or do we need to introduce a new option for the user to set? At the same time, the original Lync client seems to figure that out somehow ...

        Any suggestions?

         
  • Stefan Becker

    Stefan Becker - 2014-12-05

    As I didn't get any logs from you I had to take a guess. Please try if git commit 0000548 fixes your problem.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks