Protocol plugin for Office 365/Lync/OCS / Bugs / #263 ADFS fails when user and login name differ

Stefan Becker - 2014-09-02

Your log is unfortunately useless, because it has been generated without --debug (see FAQ). You should also disable your jabber account while recording a log.

IMHO this is not a bug, see again FAQ

Closing as NOTABUG

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Stefan Becker - 2014-09-02

status: open --> closed-invalid
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Jay Thorne - 2014-09-02

Oops. That was one error. We fixed the SIP address to be correct, and now it shows

<s:envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing">
<s:header>
<a:action s:mustunderstand="1">http://www.w3.org/2005/08/addressing/soap/fault</a:action>
</s:header>
<s:body>
<s:fault>
<s:code>
<s:value>s:Sender</s:value>
<s:subcode>
<s:value xmlns:a="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">a:FailedAuthentication</s:value>
</s:subcode>
</s:code>
<s:reason>
<s:text xml:lang="en-US">At least one security token in the message could not be validated.</s:text>
</s:reason>
</s:fault>
</s:body>
</s:envelope>

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Jay Thorne - 2014-09-02

So it doesn't like the token as presented. And you seem pretty intent on closing all bugs as notabug.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Stefan Becker - 2014-09-02

Guessing won't help, only complete, unnabbreviated logs will do. If you really think this is a bug in SIPE, then please run a MITM attack on a working Lync client setup to provide the necessary HTTP logs from a succesful web ticket handshake.

Until tthen there is nothing for me to fix, hence closing of the bug.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Stefan Becker - 2014-09-02

The log provided in the other bug shows Jay.Thorne@.... Have you tried jay.thorne@...? Just being paranoid.

For MITM attacks you can use a ssltunnel pair running on another machine. Then you can set your local host file that "some.official.server" points to the IP of the machine running the ssltunnel pair. When the Lync client connects to the server, it actually connects ot the first ssltunnel, which opens to the second ssltunnel, which talks to the original server. You grab the unencrypted HTTP stuff from the connection between the ssltunnel pair. For each server:port you need an own ssltunnel pair.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Jay Thorne - 2014-09-02

I tried all three forms: the short name, the capitalized name and the uncapitalized name. The error appears to be from our adfs server. None of the other logs I've found on repeated google servers have ADFS. I'll take some time to get the MITM. This is a brand new server, and our GIS people are unsympathetic for the Linux users (of which we have about 35 in my office) I prefer a single IM client, and I find Lync 2013 to be glacially slow, so I'm interested in fixing this.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Stefan Becker - 2014-09-02

The log didn't show your password, so I guess you removed it. Unfortunately it's unencrypted in the wsse:UsernameToken node.

Please remember: the ADFS server is internal to your company, so it uses your internal system to authenticate you and then generates a security token for the external Office365 system. "Internal" means AD in Windows world.

So IMHO Jay.Thorne@... is most likely incorrect, it should by DOMAIN\account plus your AD password, like login in on any Windows machine in your AD domain. AFAIR you can try that by simple going to https://fs.ca.com with your browser. It should ask for the same authentication information.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Stefan Becker - 2014-09-02

Based on the log I guess your Login name should be CA.COM\thoja20 and not thoja20@ca.com.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Stefan Becker - 2014-09-02

Strange. The log shows that your internal ADFS server doesn't trigger a HTTP authentication challenge via NTLM or Kerberos. It just refuses your request.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Stefan Becker - 2014-09-02

Another detail I missed in your log: please switch off Single Sign-On in the account settings. You have SSO enabled and therefore login & password are ignored.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

mkoura - 2014-09-03

I've got the same problem as the original reporter (we are from the same company apparently).
I've got SSO disabled, debug log attached.

sipe_debug.log

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Stefan Becker - 2014-09-03
  
  Yes, this is the same problem.
  
  I have no idea why your ADFS server does not use HTTP authentication. BTW: this is not something SIPE triggers. This happens automatically, i.e. we receive a 401 response to our originally un-authenticated HTTP request.
  
  I can only assume that the password is wrong. Did your use your AD password? Do you have a different password for the Lync account?
  
  What happens when you go to https://fs.ca.com/adfs/ with your Browser? Does your browser ask for username & password?
  
  Paranoia suggests: maybe the ADFS admins check User-Agent: Sipe/xxx and deliberately disable HTTP authentication for such requests?
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

mkoura - 2014-09-03

I figured that I can get past the ADSF when changing "Username" to "kouma02@ca.com" (instead of "Martin.kourim@ca.com"). But I'm still stuck as it fails later with

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

Lync username seems to be set to "sip:kouma02@ca.com" which may not be correct, altough I'm able to login to https://login.microsoftonline.com/ using "kouma02@ca.com" as login name (I'm redirected to my company SSO page).

Changing "Login" (to "martin.kourim@ca.com", etc.) doesn't have any effect.

New log attached.

sipe_debug02.log
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Stefan Becker - 2014-09-03
  
  I wonder if in your case, i.e. when HTTP authentication is not in use, you have to use the login name for ADFS and not the user name. You could try this by changing one line in the code in src/core/sipe-svc.c:
  
  :::c gboolean sipe_svc_webticket_adfs(struct sipe_core_private *sipe_private, struct sipe_svc_session *session, const gchar *adfs_uri, sipe_svc_callback *callback, gpointer callback_data) { return(request_user_password(sipe_private, session, "urn:federation:MicrosoftOnline", adfs_uri, // old: sipe_private->username, /* new: */ sipe_private->authuser, /* ADFS is special, *sigh* */
  
  and then switch back to user name Martin.Kourim@ca.com and login name kouma02@ca.com or CA.COM/kouma02.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Jay Thorne - 2014-09-03

I'd have thought the domain\account form was correct too, but the internal email advised us to use First.Last@ca.com

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Maurizio Garzelli - 2014-09-03

Hi all, firstly apologies for HUGE log, but this is from start to finish,
I have the same issue as Jay (hi Jay, how is it going? I guess the coworker is JayMac ;) well you have another coworker with the same issue) and I am using pidgin-sipe version 1.18.3 and it still ignores anything that I am putting in the login field:
it just uses the username, for everything and the following message should have the login instead, as you can see, I use maurizio.garzelli as the login and it does come out in the logs at the begining, but nothing happens after that:

(21:02:03) account: Connecting to account garma2226@ca.com,maurizio.garzelli.
(21:02:03) connection: Connecting. gc = 0x7f80efb28510
(21:02:03) sipe: sipe_purple_login: username 'garma2226@ca.com,maurizio.garzelli'
(21:02:03) sipe: sipe_purple_login: login 'maurizio.garzelli'
(21:02:03) sipe: sipe_purple_login: auth domain '' user 'maurizio.garzelli'
(21:02:03) sipe: sipe_core_allocate: SIPE version 1.18.3 signin_name 'garma2226@ca.com'
(21:02:03) sipe: sipe_core_allocate: user 'garma2226' domain 'ca.com'
(21:02:03) sipe: sipe_cert_crypto_init: generate key pair, this might take a while...
(21:02:04) sipe: sipe_cert_crypto_init: key pair generated
....
....
<soap:body><wst:requestsecuritytoken context="8a068fd2-3a92-534b-a9e7-35743ce56c21"> <wst:tokentype>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1</wst:tokentype> <wst:requesttype>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</wst:requesttype> <wsp:appliesto> <wsa:endpointreference> <wsa:address>https://webpoolbn11a03.infra.lync.com/CertProv/CertProvisioningService.svc/WebTicket_Proof_SHA1</wsa:address> </wsa:endpointreference> </wsp:appliesto> <wst:claims dialect="urn:component:Microsoft.Rtc.WebAuthentication.2010:authclaims"> <auth:claimtype uri="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/uri" optional="false"> <auth:value>sip:garma2226@ca.com</auth:value> </auth:claimtype> </wst:claims> <wst:entropy> <wst:binarysecret>H...=</wst:binarysecret> </wst:entropy> <wst:keytype>http://docs.oasis-open.org/ws-sx/ws-trust/200512/SymmetricKey</wst:keytype></wst:requestsecuritytoken></soap:body>
MESSAGE END >>>>>>>>>> HTTP - 2014-09-03T19:02:06.902688Z
(21:02:06) sipe: sipe_schedule_remove: action name=<+http-timeout>
(21:02:06) sipe: sipe_schedule_allocate timeouts count 2 after addition
(21:02:06) sipe: scheduling action <+http-timeout> timeout 60 seconds
(21:02:06) sipe: sipe_http_transport_input: server requested close 'login.microsoftonline.com:443'
(21:02:06) sipe: transport_deferred_destroy: 0x7f80ef203dc0
(21:02:07) sipe:
MESSAGE START <<<<<<<<<< HTTP - 2014-09-03T19:02:07.124873Z
HTTP/1.1 500 Internal Server Error
Cache-Control: private
Content-Length: 1029
Content-Type: text/xml; charset=utf-8
X-MS-Server-Fqdn: BN11A03FES09.infra.lync.com
X-MS-Correlation-Id: 2147497762
client-request-id: b3baae5a-ea96-4fa9-985a-4a878c91052d
X-Content-Type-Options: nosniff
Date: Wed, 03 Sep 2014 19:00:18 GMT

<s:envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" xmlns:a="http://www.w3.org/2005/08/addressing"><s:header><a:action s:mustunderstand="1">http://www.w3.org/2005/08/addressing/soap/fault</a:action></s:header><s:body><s:fault><faultcode xmlns:a="http://docs.oasis-open.org/ws-sx/ws-trust/200512">a:RequestFailed</faultcode><faultstring xml:lang="en-US">The SIP URI in the claim type requirements of the web ticket request does not match the SIP URI associated with the presented credentials.</faultstring><detail><ocsdiagnosticsfault xmlns="urn:component:Microsoft.Rtc.WebAuthentication.2010" xmlns:i="http://www.w3.org/2001/XMLSchema-instance"><ms-diagnostics-fault><errorid>28035</errorid><reason>The SIP URI in the claim type requirements of the web ticket request does not match the SIP URI associated with the presented credentials.</reason></ms-diagnostics-fault><namevaluepairs xmlns:b="http://schemas.microsoft.com/2003/10/Serialization/Arrays"></namevaluepairs></ocsdiagnosticsfault></detail></s:fault></s:body></s:envelope>
MESSAGE END <<<<<<<<<< HTTP - 2014-09-03T19:02:07.124873Z
(21:02:07) sipe: sipe_svc_https_response: code 500
(21:02:07) connection: Connection error on 0x7f80efb28510 (reason: 2 description: Web ticket request to https://webpoolbn11a03.infra.lync.com:443/CertProv/CertProvisioningService.svc failed)
(21:02:07) account: Disconnecting account garma2226@ca.com,maurizio.garzelli (0x7f80eefc9a00)
(21:02:07) connection: Disconnecting connection 0x7f80efb28510
(21:02:07) sipe: sipe_schedule_remove: action name=<+http-timeout>
(21:02:07) sipe: sipe_http_transport_free: destroying connection 'login.microsoftonline.com:443'
(21:02:07) sipe: sipe_http_transport_free: destroying connection 'fs.ca.com:443'
(21:02:07) sipe: sipe_http_transport_free: destroying connection 'webpoolbn11a03.infra.lync.com:443'
(21:02:07) sipe: sipe_schedule_remove: action name=<+keepalive-timeout>
(21:02:07) GLib: g_hash_table_destroy: assertion 'hash_table != NULL' failed
(21:02:07) sipe: sipe_purple_dns_query_cancel_all: entered
(21:02:07) sipe: sipe_purple_transport_close_all: entered
(21:02:07) connection: Destroying connection 0x7f80efb28510
(21:02:07) sipe: transport_deferred_destroy: 0x7f80efb07350
(21:02:07) sipe: transport_deferred_destroy: 0x7f80efad3960
(21:02:07) sipe: transport_deferred_destroy: 0x7f80efc0ae40
(21:02:08) util: Writing file accounts.xml to directory /home/mau/.purple
(21:02:08) util: Writing file /home/mau/.purple/accounts.xml

Last edit: Maurizio Garzelli 2014-09-03

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Maurizio Garzelli - 2014-09-03

Well well well,
I have to say, thank you Stefan Becker! I have
1) downloaded the (tar.gx) version of the latest plugin
2) changed the file you mentioned as indicated in your post
3) did a ./configure
4) make
5) sudo make install
6) sudo cp /usr/local/lib/purple-2/libsipe.* /usr/lib/purple-2/
7) started pidgin
8) configured the plugin accordingly (
username mau.gar@ca.com
login garma2226@ca.com
)
9) in advanced, (
connection type: auto
user agent: UCCAPI/15.0.4420.1017 OC/15.0.4420.1017
authentication type: TLS-DSK
)
It worked like a charm!

Last edit: Maurizio Garzelli 2014-09-04

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Jay Thorne - 2014-09-04

Stefan: This worked. Looks like the sipe_private->authuser thing works. My guys tried that.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Jon Mainguy - 2014-09-04

Thank you Stefan, I also work at the same company and that did the fix. Really appreciate your assistance on this one.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Stefan Becker - 2014-09-04

summary: connection: Connection error on 059C9BC0 (reason: 2 description: Web ticket request to https://webpoolbn11a03.infra.lync.com:443/CertProv/CertProvisioningService.svc failed) --> ADFS fails when HTTP authentication is not enabled

status: closed-invalid --> accepted

assigned_to: Stefan Becker
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Stefan Becker - 2014-09-04

Thanks for the feedback. Re-opening as this is now root-caused to a different issue

This is related to [feature-requests:#53]. But in this case the ADFS server doesn't use HTTP authentication.

@reporters: before I'm going to try to fix this, I need some more information. Can you please run pidgin with --debug and record the log. Please disable any other accounts and make sure to replace cleartext passwords on the logs. After the account is online and the buddy list appears, please select the menu Accounts -> SIPE account -> Republish Calendar. When the log quietens down, shut down Pidgin and store the log.

Please try this with two different account settings:

User name: First.Last@ca.com Login name 1: account@ca.com Login name 2: CA.COM/account

Please attach the two logs to your reply. Thanks

Related

Feature Requests: ~~#53~~
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Jay Thorne - 2014-09-05

Both forms work. Thanks for your efforts. One of my team created these logs.

pidgin.log

pidgin_domain_login.log

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Stefan Becker - 2014-09-05
  
  Thanks, this clarified that HTTP authentication, e.g. used for EWS, works fine in your installation, i.e. it works with both account@ca.com and CA.COM/account.
  
  I think I know how to proceed now.
  
  Last edit: Stefan Becker 2014-09-05
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Stefan Becker - 2014-09-05

summary: ADFS fails when HTTP authentication is not enabled --> ADFS fails when user and login name differ

status: accepted --> closed-fixed
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

ADFS fails when user and login name differ

for Adium, Pidgin, Miranda and Telepathy IM Framework

Group

Searches

Help

#263 ADFS fails when user and login name differ

Related

Discussion

Related