authentication failed: Intermedia Hosted Lync

Help
Rob A
2013-03-26
2014-03-19
1 2 3 > >> (Page 1 of 3)
  • Rob A

    Rob A - 2013-03-26

    This worked until Intermedia set up a similar "Single Sign On" app for our company's in-office users as well, which was sometime last year, on pidgin-sipe 1.13. Today I got the urge to fix it again, and downloaded 1.15, and compiled with "-with-krb5 -prefix=/usr" as my notes showed 1.13 requried -with-krb5 being needed previously, but I didn't note *why* I needed that option.

    Now, I get one of three errors, depending on my configuration:
    1) Authentication Failed
    2) Failed to authenticate to the server
    3) Web ticket request to https://LyncPool1.exch026.serverdata.net:443/CertProv/CertProvisioningService.svc failed

    I have 3 pastebin logs I'll post in a followup comment, the first from my lync 2013 client, which works from Windows 8.  That system is connected to the same kerberos realm as my Ubuntu laptop, and that realm is *NOT* my company's realm.

     
  • Rob A

    Rob A - 2013-03-26

    And here's a link to the "single sign on" app from intermedia: https://exchange.intermedia.net/singlesignon/app/

    I only just installed it on one of my 3 VMs today, so I haven't traced out what kinds of voodoo it's attempting.

     
  • Stefan Becker

    Stefan Becker - 2013-03-26

    Your Ḿ$ Lync client log shows

    User-Agent: UCCAPI/15.0.4481.1000 OC/15.0.4481.1000 (Microsoft Lync)
    

    Is this by any chance a Lync 2013 client? This would be the first confirmed case I've seen in the wild…

    I think you might have triggered the bug I fixed in git HEAD:

    ccc4df5 security: set private flags acquire_cred_func()
    

    As a work-around please try this with 1.15.0:

    Username:       username@company.com
    Login:          exch026\username_company
    Password:       <password for exch026 account>
    Server:Port:    <leave empty>
    Useragent:      UCCAPI/15.0.4481.1000 OC/15.0.4481.1000 (Microsoft Lync)
    Authentication: NTLM
    Single Sign-On: OFF
    

    Your log shows:

    (22:04:59) sipe: webticket_metadata: metadata for service https://lyncpool1.exch026.serverdata.net/WebTicket/WebTicketService.svc/mex retrieved successfully
    (22:04:59) sipe: webticket_metadata: WebTicket Windows Negotiate Auth URI https://lyncpool1.exch026.serverdata.net/WebTicket/WebTicketService.svc
    

    so your NTLM credenials (Login & Password) must be correct for lyncpool1.exch026.serverdata.net.

     
  • Stefan Becker

    Stefan Becker - 2013-03-26

    BTW: Authentication "Kerberos" will only work if you join your box to the same Kerberos domain which lyncpool1.exch026.serverdata.net is in. Your current log shows

    (22:05:00) sipe: sip_sec_init_sec_context__krb5: started
    (22:05:00) sipe: sip_sec_krb5: GSS-API error in gss_init_sec_context (GSS): Unspecified GSS failure.  Minor code may provide more information
    (22:05:00) sipe: sip_sec_krb5: GSS-API error in gss_init_sec_context (Mech): Cannot resolve servers for KDC in realm "TOTALNETSOLUTIONS.NET"
    (22:05:00) sipe: sip_sec_krb5_initialize_context: failed to initialize context (ret=851968)
    

    My guess that means that you haven't set up Kerberos on the box.

     
  • Stefan Becker

    Stefan Becker - 2013-03-26

    Dohh, of course this won't work you. You'll need to download and compile git HEAD and then use:

    Username:       username@company.com
    Login:          exch026\username_company
    Password:       <password for exch026 account>
    Server:Port:    <leave empty>
    Useragent:      UCCAPI/15.0.4481.1000 OC/15.0.4481.1000 (Microsoft Lync)
    Authentication: TLS-DSK
    Single Sign-On: OFF
    

    SIPE should then fallback pick "Negotiate" for lyncpool1.exch026.serverdata.net and after the Kerberos failure fall back to NTLM.

     
  • Rob A

    Rob A - 2013-03-26

    Yes, I have Lync 2013, running on both Windows 8 and Windows 7.  Want some extra info from it, let me know how to contact you.

    Pulling git HEAD now, will post results…

     
  • Stefan Becker

    Stefan Becker - 2013-03-26

    Thanks for confirming that this was Lync 2013. I've update the Useragent section on the FAQ page.

     
  • Rob A

    Rob A - 2013-03-26

    No luck - same errors using NTLM or TLS-DSK.  I was surprised to see the autonegotiation work - I didn't think we had the SRV records set up in DNS.

    http://pastebin.stonekeep.com/12635

    I tried a few times.  The exact settings you asked for are at the bottom, after I retyped my password, to be sure.

     
  • Stefan Becker

    Stefan Becker - 2013-03-26

    The log shows that your first 2 tries where with NTLM, which doesn't work for you. So don't even try.

    The TLS-DSK attempt is truncated:

    ><sp:Header Name="To" Namespace="http://www.w3.org/2
    

    Please provide a fresh log with only TLS-DSK and make sure your pastebin provider doesn't have a length restriction!

     
  • Rob A

    Rob A - 2013-03-26

    Well, the last 9 lines got dropped, but that's just the unloading of pidgin, so I think it should be ok:

    http://pastebin.stonekeep.com/12636

     
  • Stefan Becker

    Stefan Becker - 2013-03-26

    Are you sure you are using the recompiled plugin? The log shows the same error for NTLM fallback as before.

    Please make sure pidgin loads the NEW plugin.

     
  • Rob A

    Rob A - 2013-03-26

    FYI: I'm getting what appears to be the same log if I do NOT use the "export NSS_SSL_CBC_RANDOM_IV=0" workaround.  I can remove that now, if I read correctly?

     
  • Stefan Becker

    Stefan Becker - 2013-03-26

    I hope that M$ has fixed their SSL code for Lync 2013, as this has been known to them for over year! So yes, it should work without disabling the NSS security fix. But that's a different issue with a totally different error message: the SSL connection is simply dropped by the server in the middle of the communication.

     
  • Stefan Becker

    Stefan Becker - 2013-03-26

    Please make sure that Pidgin loads the right plugin. You should see in the log

    (10:39:49) sipe: sip_sec_create_context: type: 3, Single Sign-On: no, protocol: HTTP
    (10:39:49) sipe: sip_sec_acquire_cred__negotiate: entering
    (10:39:49) sipe: sip_sec_acquire_cred__krb5: started
    (10:39:49) sipe: http_conn_process_input_message: init context target 'HTTP/lyncpool1.exch026.serverdata.net' token '<NULL>'
    (10:39:49) sipe: sip_sec_init_sec_context__negotiate: entering
    (10:39:49) sipe: sip_sec_init_sec_context__krb5: started
    (10:39:49) sipe: sip_sec_krb5: GSS-API error in gss_init_sec_context (GSS): Unspecified GSS failure.  Minor code may provide more information
    (10:39:49) sipe: sip_sec_krb5: GSS-API error in gss_init_sec_context (Mech): Server not found in Kerberos database
    (10:39:49) sipe: sip_sec_krb5_initialize_context: failed to initialize context (ret=851968)
    (10:39:49) sipe: sip_sec_init_sec_context__negotiate: fallback to NTLM
    (10:39:49) sipe: sip_sec_init_sec_context__ntlm: in use
    (10:39:49) sip_sec_ntlm_message_describe: Negotiate message is:\n
    ...
    
     
  • Rob A

    Rob A - 2013-03-26

    Thanks Stefan - I may be doing something stupid, so let's be sure I'm not.  I'm using ubuntu's "checkinstall" to do the "make install" and packaging of a .deb file for me.  I was building 1.15 stable from ~, but all my git repos are in ~/workspace - it makes for a clean differentiation.

    It appears that I've successfully removed all instances of siplcs:
    rob@kubuntu4:~$ sudo updatedb
    rob@kubuntu4:~$ locate siplcs |grep -v home
    rob@kubuntu4:~$ locate sipe |grep -v home

    So let's reinstall the package I made just this morning from git:
    rob@kubuntu4:~$ cd workspace/siplcs/
    rob@kubuntu4:~/workspace/siplcs$ sudo dpkg -i pidgin-sipe_1.15.0a-1_amd64.deb
    Selecting previously unselected package pidgin-sipe.
    (Reading database … 224026 files and directories currently installed.)
    Unpacking pidgin-sipe (from pidgin-sipe_1.15.0a-1_amd64.deb) …
    Setting up pidgin-sipe (1.15.0a-1) …
    rob@kubuntu4:~/workspace/siplcs$ cd ~

    Now we'll run it without the NSS SSL workaround:
    rob@kubuntu4:~$ /usr/bin/pidgin -debug 2>&1 > pidgin-log.txt

    and to verify that things are in the right places now:
    rob@kubuntu4:~$ sudo updatedb
    rob@kubuntu4:~$ locate siplcs |grep -v home
    rob@kubuntu4:~$ locate sipe |grep -v home
    /usr/lib/purple-2/libsipe.la
    /usr/lib/purple-2/libsipe.so
    /usr/share/locale/ar/LC_MESSAGES/pidgin-sipe.mo
    /usr/share/locale/cs/LC_MESSAGES/pidgin-sipe.mo
    /usr/share/locale/da/LC_MESSAGES/pidgin-sipe.mo
    /usr/share/locale/de/LC_MESSAGES/pidgin-sipe.mo
    /usr/share/locale/es/LC_MESSAGES/pidgin-sipe.mo
    /usr/share/locale/fi/LC_MESSAGES/pidgin-sipe.mo
    /usr/share/locale/fr/LC_MESSAGES/pidgin-sipe.mo
    /usr/share/locale/hi/LC_MESSAGES/pidgin-sipe.mo
    /usr/share/locale/hu/LC_MESSAGES/pidgin-sipe.mo
    /usr/share/locale/it/LC_MESSAGES/pidgin-sipe.mo
    /usr/share/locale/ja/LC_MESSAGES/pidgin-sipe.mo
    /usr/share/locale/ko/LC_MESSAGES/pidgin-sipe.mo
    /usr/share/locale/nb/LC_MESSAGES/pidgin-sipe.mo
    /usr/share/locale/nl/LC_MESSAGES/pidgin-sipe.mo
    /usr/share/locale/pl/LC_MESSAGES/pidgin-sipe.mo
    /usr/share/locale/pt/LC_MESSAGES/pidgin-sipe.mo
    /usr/share/locale/pt_BR/LC_MESSAGES/pidgin-sipe.mo
    /usr/share/locale/ro/LC_MESSAGES/pidgin-sipe.mo
    /usr/share/locale/ru/LC_MESSAGES/pidgin-sipe.mo
    /usr/share/locale/sv/LC_MESSAGES/pidgin-sipe.mo
    /usr/share/locale/ta/LC_MESSAGES/pidgin-sipe.mo
    /usr/share/locale/tr/LC_MESSAGES/pidgin-sipe.mo
    /usr/share/locale/zh_CN/LC_MESSAGES/pidgin-sipe.mo
    /usr/share/locale/zh_TW/LC_MESSAGES/pidgin-sipe.mo
    /usr/share/pixmaps/pidgin/protocols/16/sipe.png
    /usr/share/pixmaps/pidgin/protocols/22/sipe.png
    /usr/share/pixmaps/pidgin/protocols/24/sipe.png
    /usr/share/pixmaps/pidgin/protocols/32/sipe.png
    /usr/share/pixmaps/pidgin/protocols/48/sipe.png
    /usr/share/pixmaps/pidgin/protocols/scalable/sipe.svg
    /var/lib/dpkg/info/pidgin-sipe.conffiles
    /var/lib/dpkg/info/pidgin-sipe.list
    /var/lib/dpkg/info/pidgin-sipe.md5sums
    rob@kubuntu4:~$ cd workspace/siplcs/
    rob@kubuntu4:~/workspace/siplcs$ git pull
    Already up-to-date.
    rob@kubuntu4:~/workspace/siplcs$

    log at: http://pastebin.stonekeep.com/12637

     
  • Stefan Becker

    Stefan Becker - 2013-03-26

    I guess the package didn't get installed. You log shows:

    (10:55:23) sipe: sipe_core_allocate: signin_name 'username@company.com'
    

    whereas git HEAD has this updated line of code:

    SIPE_DEBUG_INFO("sipe_core_allocate: SIPE version " PACKAGE_VERSION " signin_name '%s'", signin_name);
    

    So there should be a version number.

    I would unpack the generated .deb package and then run sha1sum on libsipe.so from that and /usr/lib/purple-2/libsipe.so.

    Maybe you simply can use dpkg to install the recompiled package? Sorry, not a big Debian/dpkg/apt fan or expert….

     
  • Stefan Becker

    Stefan Becker - 2013-03-26

    BTW: git should show:

    rob@kubuntu4:~/workspace/siplcs$ git log --oneline 1.15.0^..
    729b79d transport: clear address_data with service_data
    4c2e361 l10n: sync translations with transifex.net (ro)
    cf4ac2b ntlm: add a message analyzer tool
    c209341 core: add SIPE version to debug log
    ccc4df5 security: set private flags acquire_cred_func()
    3db0ac8 adium: Get bundle version strings from preprocessor macros
    a4a8bbb Merge branch 'mob' of git+ssh://repo.or.cz/srv/git/siplcs into mob
    fafb8e7 adium: Pull in version number from GCC_PREPROCESSOR_DEFINITIONS
    ca4addf Don't use my work email in AUTHORS
    0546a14 Merge branch 'mob' of git+ssh://repo.or.cz/srv/git/siplcs into mob
    79d04f8 Release 1.15.0 -- Authentication & Autodiscovery Update
    a2d2dfe adium: General fixes in preparation for release
    
     
  • Rob A

    Rob A - 2013-03-26

    I'm doing something stupid, but don't know how to fix it:

    rob@kubuntu4:~/workspace$ rm -Rf siplcs/
    rob@kubuntu4:~/workspace$ git clone git+ssh://mob@repo.or.cz/srv/git/siplcs.git
    Cloning into 'siplcs'…
    remote: Counting objects: 18389, done.
    remote: Compressing objects: 100% (3577/3577), done.
    remote: Total 18389 (delta 14648), reused 18381 (delta 14644)
    Receiving objects: 100% (18389/18389), 5.98 MiB | 1.02 MiB/s, done.
    Resolving deltas: 100% (14648/14648), done.
    rob@kubuntu4:~/workspace$ cd siplcs/
    rob@kubuntu4:~/workspace/siplcs$ grep -r 'SIPE_DEBUG_INFO("sipe_core_allocate' *
    src/core/sipe-core.c:   SIPE_DEBUG_INFO("sipe_core_allocate: signin_name '%s'", signin_name);
    src/core/sipe-core.c:   SIPE_DEBUG_INFO("sipe_core_allocate: user '%s' domain '%s'", user_domain, user_domain);
    rob@kubuntu4:~/workspace/siplcs$ git pull
    Already up-to-date.
    rob@kubuntu4:~/workspace/siplcs$

    That line of code isn't in the sources I have pulled.

     
  • Rob A

    Rob A - 2013-03-26

    Sometimes, Rob, actually pasting the *exact text from the FAQ* rather than what you think they mean, makes things magically work.

    Hold please…

     
  • Stefan Becker

    Stefan Becker - 2013-03-26

    You forgot to checkout the branch (instructions):

    rob@kubuntu4:~/workspace$ rm -Rf siplcs/
    rob@kubuntu4:~/workspace$ git clone git+ssh://mob@repo.or.cz/srv/git/siplcs.git
    rob@kubuntu4:~/workspace$ cd siplcs/
    rob@kubuntu4:~/workspace$ git checkout -b mob --track origin/mob
    

    remote branch master doesn't work in this repo. Don't ask, I didn't set up the repository…

     
  • Rob A

    Rob A - 2013-03-26

    yeah, I was checking out "origin/HEAD"

    rob@kubuntu4:~/workspace/siplcs$ git checkout -b head -track origin/HEAD
    Branch head set up to track remote branch fixer from origin.
    Switched to a new branch 'head'
    rob@kubuntu4:~/workspace/siplcs$ git pull
    Already up-to-date.

    I re-read the instructions, found the problem as you were posting, and have the correct version line in the log.  Same error though:
    line 430:
    (11:21:50) sipe: sip_sec_krb5: GSS-API error in gss_init_sec_context (GSS): Unspecified GSS failure.  Minor code may provide more information
    (11:21:50) sipe: sip_sec_krb5: GSS-API error in gss_init_sec_context (Mech): Server not found in Kerberos database
    (11:21:50) sipe: sip_sec_krb5_initialize_context: failed to initialize context (ret=851968)
    (11:21:50) sipe: sip_sec_init_sec_context__negotiate: fallback to NTLM
    (11:21:50) sipe: sip_sec_init_sec_context__ntlm: in use

    and line 646:
    (11:21:51) connection: Connection error on 0x7f10e0ed9400 (reason: 2 description: Web ticket request to https://LyncPool1.exch026.serverdata.net:443/CertProv/CertProvisioningService.svc failed)
    (11:21:51) sipe: http_conn_process_input_message: Authentication failed
    (11:21:51) sipe: http_conn_close: closing http connection: User initiated
    (11:21:51) account: Disconnecting account username@company.com,exch026\username_company (0x7f10e00e77e0)

    part 1: http://pastebin.stonekeep.com/12638
    part 2: http://pastebin.stonekeep.com/12639

    Now we have:

     
  • Stefan Becker

    Stefan Becker - 2013-03-26

    OK, you have the right code running now, i.e. the log shows the fallback to NTLM. But the NTLM response is rejected by the server:

    MESSAGE START <<<<<<<<<< HTTP - 2013-03-26T16:21:51.344495Z
    HTTP/1.1 401 Unauthorized
    ...
      <h2>401 - Unauthorized: Access is denied due to invalid credentials.</h2>
      <h3>You do not have permission to view this directory or page using the credentials that you supplied.</h3>
    

    You'll have to figure out what the NTLM credentials for you are on that server. Maybe *that* server has access to your Windows AD and you need <windows domain>\&lt;windows account> + <windows password>

     
  • Rob A

    Rob A - 2013-03-26

    I'm following the logic.  I'm not sure what to try.

    I have a Windows 8 box joined to my home lab (not part of any federation, might as well be unjoined).  When I load Lync 2013 on that, I have to enter EXCH026\username_company and that account's password.  That's what I have filled into pidgin.  That's what's in this log from the opening post from Lync: http://pastebin.stonekeep.com/12631

    If I don't have any other available Windows credentials, when using Lync 2013 in that situation, what other ones would be used for Pidgin?

    To flip your question around: when I use Lync 2013, it doesn't ask for my Windows AD credentials, only my hosted exchange/Outlook creds.

     
  • Rob A

    Rob A - 2013-03-26

    Followup: I tried every account combination I have at this company (3) in NT4 format in the "Login:" box, and I'm still getting the same logs.

     
1 2 3 > >> (Page 1 of 3)

Log in to post a comment.