My company moved to Office365 solution this week and I am unable to login to Lync via Pidgin-SIPE. My company used Office communicator and sipe was working great with that.
I have gone through almost all posts related to login failure, I have tried various combination of username@company domain\username and various user agent settings with no luck.
Our support team mentioned that the deployment would require an Internal Lync server for SIPE/Pidgin to work and they have no plans to setup such a server. They couldnt tell me the reason an internal (within company) Lync server was needed?
I just need the right guidance and I am willing to do whatever it takes to debug this issue and get pidgin to work with SIPe..
Hey,
With Office 365, those settings won't work, because Single Sign-On doesn't work like it did in BPOS…
For the Server setting, try sipdir.online.lync.com:443
You need to have an Office 365 compatible User Agent setting. I recently had to change mine to be UCCAPI/4.0.7577.314 OC/4.0.7577.314 (Microsoft Lync 2010)
Lastly, you can't use the email address for the Login User setting like you do for the Username setting. The way I determined mine was to go to Credential Manager… It was in there on Windows 7, but isn't on Windows 8, so I can't tell you if it'll be there under Windows XP or not. (I never used Credential Manager in XP, I don't think it's as robust.)
My user name ended up being RED001\_. I think that's because firstname.lastname@company.com is my Username, so for you it's probably RED001\user_company (or the first 20 chars of it)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@grantbowering: the server is already automatically detected, so he doesn't need to set anything there:
(22:00:33) dnssrv: querying SRV record for company.net: _sip._tls.company.net
(22:00:33) dnssrv: found 1 SRV entries
(22:00:33) sipe: sipe_core_dns_resolved - SRV hostname: sipdir.online.lync.com port: 443
The user-agent setting is required though, because as far as I know M$ hosted OCS/Lync only allow M$ clients.
The user is rejected though:
<psf:text>Direct login to WLID is not allowed for this federated namespace
</psf:text>
@bhakta79: the SIP log from the MS Lync client is unfortunately not enough, because it doesn't show the authentication. You'll need to run a man-in-the-middle attack on the client to be able to capture the HTTPS data in plaintext.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@grantbowering: thanks for the response..
.
@stefanb2: How do I run a MITM with Lync? Can you please provide some pointers?
Based on some older posts and some searching around, I installed Cain on my computer but the Symantec Endpoint protection (which is a piece of $@#$#@) promptly deleted the tool when i ran it.. Are there any alternatives? I do have access to multiple computers if that can help..
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Did you check the Windows certificate storage, as suggested by Grant? That might give you an idea what the login name is for your SIP account. This information should also be visible somewhere in the Lync Client.
According to the Wikipedia article Cain & Abel doesn't offer SSL connection proxying, i.e. funneling HTTPS connections done by the Lync Client through itself, thus being able to record the plaintext. The one method I know is to set up a ssltunnel pair on another (virtual) machine, listening to port X and then hacking the hosts file on the WIndows machine so that a HTTPS connection attempt to some.host.com:X is diverted to <IP of sstunnel host>:X. Then you can use e.g. tcpdump to record the plaintext conversation between the ssltunnel pair.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
on M$ Lync client, I use user@company.net for both login and username and enter my AD password and it connects. Are you guys saying that Lync would internally translate this to a different Login name?
@stefanb2: I have this windows machine on which I run Lync and another Linux machine with root access..What tools do you recommend to setup ssltunnel pairs?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@bhakta79: with the provided information I would say your SIPE setup using user@company net for both is correct. BTW: if user and login name are the same, you can leave the login name empty as SIPE then does this automatically.
So the problem must be that SIPE uses the wrong authentication service to get the initial authentication token for the first Web Ticket Service. SIPE currently implements (see src/core/sipe-webticket.c) "WebTicketServiceWinNegotiate" (HTTPS to internal server, using negotiate with Windows credentials) and "WsFedBearer" (M$ Passport protocol via login.microsoftonline.com). Your log shows that the former is missing and therefore SIPE tries the latter but fails.
Mind you, all of this is based on logs taken by MITM attacks on M$ Lync clients from an internal OCS installation and a M$-hosted OCS installation. As I don't have anything to go on but the logs (documentation, what documentation M$?) this is most likely incomplete.
Your are the 4th or 5th person with this kind of failure ("Direct login to WLID is not allowed for this federated namespace") and although I've asked all of them to provide logs, the discussion usually ended at the mentioning of "ssltunnel". I hope you are finally going to be the one that will provide those logs…
What you'll need:
* be able to clear the certificate store on the Windows machine (I guess the "OCS" certificate in your list) so that M$ Lync client is forced to run the authentication
* WireShark (or something similar) on the Windows machine to find out what network connections the M$ Lync client creates during the authentication handshake
* edit host file on the WIndows machine so that accesses to "some.server.com" can be mapped to the IP address of your Linux box (you could also use router or ARP spoofing magic to achieve that)
* package "stunnel" (sorry had the wrong name in mind) on the Linux box.
* package "openssl" on the Linux box to be able to generate fake certificates for the M$ Lync services so that the M$ Lync client will create HTTPS connections to your fake stunnel path
* package "tcpdump" on the Linux box to record the plaintext traffic between the stunnel pair
Once everything is in place you run on the Linux box to capture the connection from the M$ Lync client to some.server.com:443 with
and you get the plaintext in "dump.pcap". I just noticed that these old instructions I have are most likely for stunnel version 3. For stunnel version 4 you'll need to use configuration files instead. But I guess we better take this offline via e-mail to discuss details.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Do I need to provide this information too? I am getting the following error:
(14:30:38) sipe: sipe_svc_https_response: code 500
(14:30:38) connection: Connection error on 0xa0fc278 (reason: 2 description: Web ticket request to https://webpoolsn20b04.infra.lync.com:443/CertProv/CertProvisioningService.svc failed)
Again on o365. Here's the soap resonse:
<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">ID3242: The security token could not be authenticated or authorized.</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:
Please do not use old threads for new problems. Most likely your issue has nothing to do with the things discussed here.
Please don't expect your issue to be solved based on fragmentary information. We would need to see the full --debug log. Please follow the instructions in the FAQ.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@steanb2: Thanks.. I already have a wireshark capture of M$ Lync. What is the best way to share it? I don't want to put it on a public site at this point..
my email is same id (bhakta79) "a - t" google.com.. Please send me a mail so I can send these captures (as well as the ones I will get with ssltunnel in the next step.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just to update the thread for the benefit for others who might be following it. This is now fixed in latest git and I am able to login to Lync with the fix..
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Error : Web ticket request to https://webdir0f-ext.online.lync.com:443/CertProv/CertProvisioningService.svc failed
Greetings,
My company moved to Office365 solution this week and I am unable to login to Lync via Pidgin-SIPE. My company used Office communicator and sipe was working great with that.
I have gone through almost all posts related to login failure, I have tried various combination of username@company domain\username and various user agent settings with no luck.
Our support team mentioned that the deployment would require an Internal Lync server for SIPE/Pidgin to work and they have no plans to setup such a server. They couldnt tell me the reason an internal (within company) Lync server was needed?
I just need the right guidance and I am willing to do whatever it takes to debug this issue and get pidgin to work with SIPe..
OS: WinXP
Pidgin: pidgin-2.10.5
SIPE: pidgin-sipe-1.13.3-pidgin-2.10.5-win32-nsis-no-sspi.exe
These settings in pidgin-sipe are same as that I use in Lync
username: user@company.net
Login user : user@company.net
Password: <pwd>
In addition , I have the following on pidgin-sipe protocol settings:
Server : _Left Empty_
Proxy: None
Auth: TLS-DSK
To avoid creating a huge post, I have saved the logs in pastebin..
pidgin -debug logs: http://pastebin.com/wb0WpJg8
Office lync client logs : http://pastebin.com/QuYfH6H1
Any help is greatly appreciated…
Hey,
With Office 365, those settings won't work, because Single Sign-On doesn't work like it did in BPOS…
For the Server setting, try sipdir.online.lync.com:443
You need to have an Office 365 compatible User Agent setting. I recently had to change mine to be UCCAPI/4.0.7577.314 OC/4.0.7577.314 (Microsoft Lync 2010)
Lastly, you can't use the email address for the Login User setting like you do for the Username setting. The way I determined mine was to go to Credential Manager… It was in there on Windows 7, but isn't on Windows 8, so I can't tell you if it'll be there under Windows XP or not. (I never used Credential Manager in XP, I don't think it's as robust.)
My user name ended up being RED001\_. I think that's because firstname.lastname@company.com is my Username, so for you it's probably RED001\user_company (or the first 20 chars of it)
@grantbowering: the server is already automatically detected, so he doesn't need to set anything there:
The user-agent setting is required though, because as far as I know M$ hosted OCS/Lync only allow M$ clients.
The user is rejected though:
@bhakta79: the SIP log from the MS Lync client is unfortunately not enough, because it doesn't show the authentication. You'll need to run a man-in-the-middle attack on the client to be able to capture the HTTPS data in plaintext.
@grantbowering: thanks for the response..
.
@stefanb2: How do I run a MITM with Lync? Can you please provide some pointers?
Based on some older posts and some searching around, I installed Cain on my computer but the Symantec Endpoint protection (which is a piece of $@#$#@) promptly deleted the tool when i ran it.. Are there any alternatives? I do have access to multiple computers if that can help..
update: I got around the Symantec issue. Would Cain be able to do MITM with Lync?
Did you check the Windows certificate storage, as suggested by Grant? That might give you an idea what the login name is for your SIP account. This information should also be visible somewhere in the Lync Client.
According to the Wikipedia article Cain & Abel doesn't offer SSL connection proxying, i.e. funneling HTTPS connections done by the Lync Client through itself, thus being able to record the plaintext. The one method I know is to set up a ssltunnel pair on another (virtual) machine, listening to port X and then hacking the hosts file on the WIndows machine so that a HTTPS connection attempt to some.host.com:X is diverted to <IP of sstunnel host>:X. Then you can use e.g. tcpdump to record the plaintext conversation between the ssltunnel pair.
I couldnt find a credential manager in winXP.. I used Cain to dump credentails and I found this..
Resource: Microsoft_OC1:uri=my_userid@company.net:specific:CER:1
User: COMPANY\my_userid
Password: my_password
Type: Generic
Flags: 0x00000000
Alias:
Comment:
Set: Enterprise
Last Time Modified: 11/03/2012 - 12:36:53
Resource: Microsoft_OC1:uri=my_userid@company.net:specific:RGS:1
User: my_userid@company.net
Password: my_password
Type: Generic
Flags: 0x00000000
Alias:
Comment:
Set: Enterprise
Last Time Modified: 11/03/2012 - 00:22:30
Resource: Microsoft_OC1:uri=my_userid@company.net:specific:EWS:1
User: my_userid@company.net
Password: my_password
Type: Generic
Flags: 0x00000000
Alias:
Comment:
Set: Enterprise
Last Time Modified: 11/03/2012 - 00:22:25
Resource: Microsoft_OC1:uri=my_userid@company.net:specific:OCS:1
User: my_userid@company.net
Password:
Type: Generic
Flags: 0x00000000
Alias:
Comment:
Set: Enterprise
Last Time Modified: 11/03/2012 - 00:19:00
Resource: Microsoft_OC1:uri=my_userid@company.net:specific:ABS:1
User: my_userid@company.net
Password: my_password
Type: Generic
Flags: 0x00000000
Alias:
Comment:
Set: Enterprise
Last Time Modified: 11/03/2012 - 00:18:10
Resource: MicrosoftOnlineServices:target=virtualapp/didlogical
User: 02*******f
Password: .***********1
Type: Generic
Flags: 0x00000000
Alias:
Comment: Microsoft_MicrosoftOnlineServices:authstate:1558
Set: Local
Last Time Modified: 11/03/2012 - 12:54:35
Any idea what the Microsoftonline services account is? Irrespective of the user-name/password I supply, I always see the "Web ticket request to https://webdir0f-ext.online.lync.com:443/CertProv/CertProvisioningService.svc failed" error..
on M$ Lync client, I use user@company.net for both login and username and enter my AD password and it connects. Are you guys saying that Lync would internally translate this to a different Login name?
@stefanb2: I have this windows machine on which I run Lync and another Linux machine with root access..What tools do you recommend to setup ssltunnel pairs?
@bhakta79: with the provided information I would say your SIPE setup using user@company net for both is correct. BTW: if user and login name are the same, you can leave the login name empty as SIPE then does this automatically.
So the problem must be that SIPE uses the wrong authentication service to get the initial authentication token for the first Web Ticket Service. SIPE currently implements (see src/core/sipe-webticket.c) "WebTicketServiceWinNegotiate" (HTTPS to internal server, using negotiate with Windows credentials) and "WsFedBearer" (M$ Passport protocol via login.microsoftonline.com). Your log shows that the former is missing and therefore SIPE tries the latter but fails.
Mind you, all of this is based on logs taken by MITM attacks on M$ Lync clients from an internal OCS installation and a M$-hosted OCS installation. As I don't have anything to go on but the logs (documentation, what documentation M$?) this is most likely incomplete.
Your are the 4th or 5th person with this kind of failure ("Direct login to WLID is not allowed for this federated namespace") and although I've asked all of them to provide logs, the discussion usually ended at the mentioning of "ssltunnel". I hope you are finally going to be the one that will provide those logs…
What you'll need:
* be able to clear the certificate store on the Windows machine (I guess the "OCS" certificate in your list) so that M$ Lync client is forced to run the authentication
* WireShark (or something similar) on the Windows machine to find out what network connections the M$ Lync client creates during the authentication handshake
* edit host file on the WIndows machine so that accesses to "some.server.com" can be mapped to the IP address of your Linux box (you could also use router or ARP spoofing magic to achieve that)
* package "stunnel" (sorry had the wrong name in mind) on the Linux box.
* package "openssl" on the Linux box to be able to generate fake certificates for the M$ Lync services so that the M$ Lync client will create HTTPS connections to your fake stunnel path
* package "tcpdump" on the Linux box to record the plaintext traffic between the stunnel pair
Once everything is in place you run on the Linux box to capture the connection from the M$ Lync client to some.server.com:443 with
and you get the plaintext in "dump.pcap". I just noticed that these old instructions I have are most likely for stunnel version 3. For stunnel version 4 you'll need to use configuration files instead. But I guess we better take this offline via e-mail to discuss details.
Do I need to provide this information too? I am getting the following error:
(14:30:38) sipe: sipe_svc_https_response: code 500
(14:30:38) connection: Connection error on 0xa0fc278 (reason: 2 description: Web ticket request to https://webpoolsn20b04.infra.lync.com:443/CertProv/CertProvisioningService.svc failed)
Again on o365. Here's the soap resonse:
<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">ID3242: The security token could not be authenticated or authorized.</s:Text></s:Reason></s:Fault></s:Body></s:Envelope>
Please do not use old threads for new problems. Most likely your issue has nothing to do with the things discussed here.
Please don't expect your issue to be solved based on fragmentary information. We would need to see the full
--debuglog. Please follow the instructions in the FAQ.Some more googleing:
Man-in-the-middle attach with stunnel
stunnel3 wrapper script for stunnel version 4 Either use this or study it to see how to create the config files you need.
@steanb2: Thanks.. I already have a wireshark capture of M$ Lync. What is the best way to share it? I don't want to put it on a public site at this point..
my email is same id (bhakta79) "a - t" google.com.. Please send me a mail so I can send these captures (as well as the ones I will get with ssltunnel in the next step.
typo.. email id is at gmail.com (not google.com
Just to update the thread for the benefit for others who might be following it. This is now fixed in latest git and I am able to login to Lync with the fix..