Web Ticket error.

Help
Jason
2012-11-16
2013-03-28
  • Jason
    Jason
    2012-11-16

    When I try to use Pidgin for Lync connectivity, I get the following error:
    Web ticket request to https://webdir0b-ext.online.lync.com:443/CertProv/CertProvisioningService.svc failed

    I tried various configuration settings and have read every forum post on connection issues.
    I have root access on the Debian machine I run pidgin on and the Windows machine with Lync, but I'm not much of a Windows user. So I can run just about any diagnostic tool, but could use better instructions for any Windows ones.
    I ran pidgin in debug mode and tried connecting to Lync. The log is at the bottom.
    Any help is greatly appreciated.

    The systems in question:
    Debian testing x86_64 (Running in VMWare 8.0.4 on top of Windows 7)
    pidgin 2.10.6-1+b1 x86_64
    pidgin-sipe 1.13.1-2 x86_64

    Windows 7 x86_64
    Lync 2010
    pidgin 2.10 (same problems as on Debian, but available for testing if needed)

    pidgin -debug output

     
  • Stefan Becker
    Stefan Becker
    2012-11-17

    login.microsoftonline.com rejects the account "jmajors@meteorcomm.com" with the error message "The credential is blocked". Is there something wrong with your account? You could try to login with this account on the Microsoft Office 365 login page.

    Just out of curiosity, what do you get when you execute:

    wget -O - 'https://login.microsoftonline.com/getuserrealm.srf?login=jmajors@meteorcomm.com&xml=1
    
     
  • Stefan Becker
    Stefan Becker
    2012-11-17

    Dooh, too early in the morning:

    <RealmInfo Success="true">
     <NameSpaceType>Federated</NameSpaceType>
     <DomainName>METEORCOMM.COM</DomainName>
     <AuthURL>https://adfs1.meteorcomm.com/adfs/ls/</AuthURL>
     <IsFederatedNS>true</IsFederatedNS>
     <STSAuthURL>https://adfs1.meteorcomm.com/adfs/services/trust/2005/usernamemixed</STSAuthURL
     <FederationBrandName>ADFS1.METEORCOMM.COM</FederationBrandName>
     <AllowFedUsersWLIDSignIn>false</AllowFedUsersWLIDSignIn>
     <MEXURL>https://adfs1.meteorcomm.com/adfs/services/trust/mex</MEXURL>
    </RealmInfo>
    

    So your company has installed an ADFS server to generate federated authentication tokens from internal accounts to Office365. Let me guess: on Windows you have a service named "MSOIDSVC" (from msoidcli.msi package) running to get Lync to login?

    SIPE does currently not support setups with ADFS. I'm in discussion with another user with the same problem, but despite having provided several decrypted logs from MITM attacks, I haven't had any success understanding the protocol.

     
  • Stefan Becker
    Stefan Becker
    2012-11-18

    FYI: this is tracked in this feature request ticket.

     
  • Stefan Becker
    Stefan Becker
    2012-11-28

    Please try the latest code from git.

     

  • Anonymous
    2012-11-29

    I tried getting the code from git.
    When I run this command:
    git clone -n git+ssh://mob@repo.or.cz/srv/git/siplcs.git

    I get this error:
    bash: line 0: cd: sipe: No such file or directory
    fatal: destination path 'siplcs' already exists and is not an empty directory.
    Remote process exited with status: 128.

    sipe is the current directory. There is no siplcs directory anywhere in my home directory.

     

  • Anonymous
    2012-11-29

    I managed to get the source, build it, and run it.
    I'm still getting a ticket error.

    Here is the debug output:
    http://pastebin.com/3RZsERv0

     

  • Anonymous
    2012-11-29

    FYI, my git pull is the latest as of the following commit:
    commit 5def2a869cb283e90315caeeba064e1a31859f7f
    Author: Jakub Adam <jakub.adam@ktknet.cz>
    Date:   Wed Nov 28 21:57:09 2012 +0100

     
  • bhakta79
    bhakta79
    2012-11-30

    I am no expert at this but it appears from your logs that your ADFS authentication went fine, got the fed bearer token (8 hours validity) and then proceeded to the regular OCS registration phase… 

    can you try username@company in both Username and Login name (it appears that you have domain\username in login-name).

    (13:38:21) account: Connecting to account jmajors@meteorcomm.com,meteorcommlan\jmajors.

     

  • Anonymous
    2012-11-30

    Here's the debug log for using my email address as the login:
    http://pastebin.com/CAqNk5he

     
  • Stefan Becker
    Stefan Becker
    2012-11-30

    The login name will be ignored for ADFS authentication, i.e. only the user name will be used. I'm not sure if this will be correct for all installations but it was correct for bhakta79's and your case. I.e. both the logs you provided are identical.

    The log shows that the new ADFS support is actually working in your case, i.e. you are successfully logged into the Office365 frontend server and are redirected to your home server:

    MESSAGE START <<<<<<<<<< SIP - 2012-11-29T21:38:26.853152Z
    SIP/2.0 301 Redirect request to Home Server
    ..
    Contact: <sip:sippoolsn20b06.infra.lync.com:443;transport=TLS>
    

    The certificate handshake for the home server was also completed successfully:

    MESSAGE END <<<<<<<<<< HTTP - 2012-11-29T21:38:29.284830Z
    (13:38:29) sipe: sipe_svc_https_response: code 200
    (13:38:29) sipe: get_and_publish_cert: received valid SOAP message from service https://webpoolsn20b06.infra.lync.com/CertProv/CertProvisioningService.svc/WebTicket_Proof_SHA1
    (13:38:29) sipe: get_and_publish_cert: found certificate
    (13:38:29) sipe: get_and_publish_cert: certificate for target 'SN20B06FES03.infra.lync.com' added
    (13:38:29) sipe: do a full reauthentication
    

    But then it happens: SIPE sends out the REGISTER to the home server and the server simply drops the SSL connection:

    MESSAGE START >>>>>>>>>> SIP - 2012-11-29T21:38:29.285851Z
    REGISTER sip:meteorcomm.com SIP/2.0
    ..
    MESSAGE END >>>>>>>>>> SIP - 2012-11-29T21:38:29.285851Z
    (13:38:29) sipe: Read error: Connection reset by peer (104)
    (13:38:29) connection: Connection error on 0x7f2ff3efe170 (reason: 0 description: Read error)
    (13:38:29) sipe: Server has disconnected
    

    I can only assume that your home server hasn't been updated to the latest server SSL code and therefore doesn't like the NSS security fix. Please try to run pidgin with

    NSS_SSL_CBC_RANDOM_IV=0 pidgin --debug
    

    The only other reason I could think of would be an incorrect User-Agent string, but the log shows that you already have set this to a M$ Lync 2010 string, which should be OK.

     

  • Anonymous
    2012-11-30

    That works. Do you need the debug log for anything?

     
  • Stefan Becker
    Stefan Becker
    2012-12-01

    Good that it works for you now. I wish M$ would push the SSL update to all their servers…

    No log required, I have seen everything I need from the logs you already provided. You can now run pidgin without -debug.