I found that the reason was that I mistyped my password. Here is the SOAP response that pidgin received in answer to SOAP authentication request (got it from the debug log):
<S:Body><S:Fault><S:Code><S:Value>S:Sender</S:Value><S:Subcode><S:Value>wst:FailedAuthentication</S:Value></S:Subcode></S:Code><S:Reason><S:Textxml:lang=\\\\\\\"en-US\\\\\\\">Authentication Failure</S:Text></S:Reason><S:Detail><psf:error><psf:value>0x80048821</psf:value><psf:internalerror><psf:code>0x80041012</psf:code>
[b]<psf:text>The entered and stored passwords do not
match.
</psf:text>[/b]
</psf:internalerror></psf:error></S:Detail></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:
I'm not really sure if this page is helping at all. As far as I can deduct from the description it tries to authenticate against YOUR domain service from the outside.
But all this discussion and the logs lead us exactly nowhere. What is needed are a) logs taken with a man-in-the-middle-attack on the Lync client for a LiveID account authentication to determine what needs to be implemented and b) a LiveID test account to be able to test the implementation. With (b) I might be able to do (a) myself.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"You cannot connect to Lync Online, or certain features do not work, because an on-premises firewall blocks the connection" http://support.microsoft.com/kb/2409256
It contains several links for testing the reliability of your internet connection to Lync services in the "How to verify that all network requirements for Lync Online are met" section.
I'm wondering if the users who are having problems can verify that they can manually login to outlook.com and then try to connect with pidgin for example.
Also if they have outlook and lync running or not and if they are running pidgin, outlook, and lync as the same user (ex. elevated Administrator or not).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This post is now much shorter than I had intended because the spam filter keeps preventing me from posting - any tips?
I had pidgin working perfectly with our Office 365 Lync online setup, thanks to everyone who worked on the sipe plugin and all the forum posts that helped me get it to work. And then we implemented single sign on. Which broke it and resulted in the same error message \\\"Web ticket request to https://webdir0e-ext.online.lync.com:443/CertProv/CertProvisioningService.svc failed\\\"
The online portal gives federated users a direct link to the federation server for authentication, sorry I can't post my tinypic url due to the spam filter.
By default the federation server uses integrated authentication, it can be configured to use forms-based as well and in fact ours is because integrated would not work. It would be useful to see if someone else with a federated domain using integrated auth can make this work.
The Microsoft Exchange Remote Connectivity Analyser (Office 365 tab, single sign-on test) clearly does some lookup to determine the federated domain and the correct URL - see http://pastebin.com/VuAr4g4E for the key part of the response.
I'm looking through Microsoft documentation to try and find the SOAP (or whatever) API call that is used to get this info.
Ben.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What is needed are a) logs taken with a man-in-the-middle-attack on the Lync client for a LiveID account authentication to determine what needs to be implemented and b) a LiveID test account to be able to test the implementation. With (b) I might be able to do (a) myself.
I can't provide LiveID credentials but I can try to do a mitma to get you some usable data. I do have Win7 and Backtrack5 in separate VMs. I do have a couple of questions, though. First, what kind of traffic/log are you looking for? Port 443? Everything? Based on your answer to that, I may not be comfortable posting the logs publicly. Would there be a private method to get you those logs? Will Ettercap provide what you need?If not, what's a better tool? I can do ARP poisoning and such, I'm just not exactly sure what type of info you're looking for.
It may take me a week or two to get this done but this is important to me. I've been threatened with having to go back to using Windows if I can't get back online with the Lync server.
Thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@cmatters: the easiest way is to use two computers: Windows with Lync client & other with 2x stunnel (server & client with a cleartext connection between them) and tcpdump.
On the Windows computer you will have do delete all certificates created by Lync to force it to create new ones for your account. Then you can monitor, e.g. with Wireshark, what connections the Lync process generates. The interesting ones are the SSL connections. To create a log for such a connection you create a local hosts entry for the name Lync tries to connect to which points to the IP of the second computer. You setup the second stunnel on the second computer to open its connection to the real address. Now the Lync computer will connect to the server stunnel on your second machine, the data goes cleartext to the client stunnel and from there encrypted to the real host. The tcpdump on the second machine can now simply record the cleartext conversation between the two stunnel processes.
You can of course use ARP spoofing instead of the local hosts entry to redirect the Lync client SSL connections to the second computer.
I think that in the case of LiveID we'll only need logs from connections to *.live.com, because the rest after we have acquired a federated authentication token should be the same. We can exchange the logs via email.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@cmatters: I will happily generate a test account in my active directory, synchronise that into Office 365 and activate a license for Lync. I can provide details by email, private message or whatever, let me know.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@benzassbangham: sounds like your setup is different again.
I'm assuming by "private AD" you mean your company's AD? To use Lync you need to add that AD account to your company's Office365 setup?
I guess in that case there must be Web Ticket service installed in your companies network that is federated with the Office365 servers, i.e. it can generate Web Tickets accepted by them. I would speculate that the authentication to that internal Web Ticket server would be with HTTPS authentication against the AD account, which is already implemented and working for companies that use an internal or hosted Lync installation.
I think in your case we need to figure out how to derive the correct web ticket server information from the Office365 Lync setup. That information should already be in the SIPE log files, i.e. you wouldn't need to run a MITM attack on the Lync client. Feel free to contact me via a SF message to start a mail thread.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Going back to haydentech's message - the error was "Direct login to WLID is not allowed for this federated namespace", this is the same issue that I have.
@stefanb2, yes private AD = company AD. There is a trust between our domain and the Office 365 cloud and account information is synchronised. You are correct that the key is determining the correct web ticket server. I guess that Office 365 supports a SOAP request to provide this information, that's why I figured that a MITM attack might be useful as Lync surely uses this mechanism.
Great if we can do it without MITMA as I got seriously confused reading up on stunnel. I'll message you; thanks :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@ctorchia87: Yes, the Office 365 accounts discussed in this thread are from hosted Lync installations with ADFS. Support for ADFS was added in SIPE 1.14.0 after one user spent a lot of time and effort to provide the decrypted logs from MITM attacks on his M$ Lync client.
I forgot to add this specific error message to the FAQ. It's there now, plus a tip how to detect if ADFS is in use for your Office 365 account.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You removed the response, so that doesn't tell me anything.
full debug http://justpaste.it/11fk
Thanks. Unfortunately there is no error string, just a number. Google hit on the number:
No idea what that means. But I guess the SOAP for LiveID is slightly different to microsoftonline.com.
Hello,
I had the same error message (reason: 2 description: Web ticket request to https://webdir0b-ext.online.lync.com:443/CertProv/CertProvisioningService.svc failed).
I found that the reason was that I mistyped my password. Here is the SOAP response that pidgin received in answer to SOAP authentication request (got it from the debug log):
lucky for U, but my passwords are same, there is no chance for mistake
At this site it is possible to get useful information if you have access to an Office 365 account:
https://www.testexchangeconnectivity.com/
all test passed!!
something wrong is with plug, I'm not a developer :(
put logs is everything what can I do
http://justpaste.it/12zr
I'm not really sure if this page is helping at all. As far as I can deduct from the description it tries to authenticate against YOUR domain service from the outside.
But all this discussion and the logs lead us exactly nowhere. What is needed are a) logs taken with a man-in-the-middle-attack on the Lync client for a LiveID account authentication to determine what needs to be implemented and b) a LiveID test account to be able to test the implementation. With (b) I might be able to do (a) myself.
I found this kb article:
"You cannot connect to Lync Online, or certain features do not work, because an on-premises firewall blocks the connection"
http://support.microsoft.com/kb/2409256
It contains several links for testing the reliability of your internet connection to Lync services in the "How to verify that all network requirements for Lync Online are met" section.
I'm wondering if the users who are having problems can verify that they can manually login to outlook.com and then try to connect with pidgin for example.
Also if they have outlook and lync running or not and if they are running pidgin, outlook, and lync as the same user (ex. elevated Administrator or not).
This post is now much shorter than I had intended because the spam filter keeps preventing me from posting - any tips?
I had pidgin working perfectly with our Office 365 Lync online setup, thanks to everyone who worked on the sipe plugin and all the forum posts that helped me get it to work. And then we implemented single sign on. Which broke it and resulted in the same error message \\\"Web ticket request to https://webdir0e-ext.online.lync.com:443/CertProv/CertProvisioningService.svc failed\\\"
The online portal gives federated users a direct link to the federation server for authentication, sorry I can't post my tinypic url due to the spam filter.
By default the federation server uses integrated authentication, it can be configured to use forms-based as well and in fact ours is because integrated would not work. It would be useful to see if someone else with a federated domain using integrated auth can make this work.
The Microsoft Exchange Remote Connectivity Analyser (Office 365 tab, single sign-on test) clearly does some lookup to determine the federated domain and the correct URL - see http://pastebin.com/VuAr4g4E for the key part of the response.
I'm looking through Microsoft documentation to try and find the SOAP (or whatever) API call that is used to get this info.
Ben.
I can't provide LiveID credentials but I can try to do a mitma to get you some usable data. I do have Win7 and Backtrack5 in separate VMs. I do have a couple of questions, though. First, what kind of traffic/log are you looking for? Port 443? Everything? Based on your answer to that, I may not be comfortable posting the logs publicly. Would there be a private method to get you those logs? Will Ettercap provide what you need?If not, what's a better tool? I can do ARP poisoning and such, I'm just not exactly sure what type of info you're looking for.
It may take me a week or two to get this done but this is important to me. I've been threatened with having to go back to using Windows if I can't get back online with the Lync server.
Thanks!
Try Office 365 for free for 30 days
http://www.microsoft.com/en-us/office365/free-office365-trial.aspx
@icnocop: accounts created on these trial Lync365 setups aren't LiveID accounts. I'm not sure if you can add LiveID accounts to those trial setups.
@cmatters: the easiest way is to use two computers: Windows with Lync client & other with 2x stunnel (server & client with a cleartext connection between them) and tcpdump.
On the Windows computer you will have do delete all certificates created by Lync to force it to create new ones for your account. Then you can monitor, e.g. with Wireshark, what connections the Lync process generates. The interesting ones are the SSL connections. To create a log for such a connection you create a local hosts entry for the name Lync tries to connect to which points to the IP of the second computer. You setup the second stunnel on the second computer to open its connection to the real address. Now the Lync computer will connect to the server stunnel on your second machine, the data goes cleartext to the client stunnel and from there encrypted to the real host. The tcpdump on the second machine can now simply record the cleartext conversation between the two stunnel processes.
You can of course use ARP spoofing instead of the local hosts entry to redirect the Lync client SSL connections to the second computer.
I think that in the case of LiveID we'll only need logs from connections to *.live.com, because the rest after we have acquired a federated authentication token should be the same. We can exchange the logs via email.
@cmatters: I will happily generate a test account in my active directory, synchronise that into Office 365 and activate a license for Lync. I can provide details by email, private message or whatever, let me know.
@benzassbangham: sounds like your setup is different again.
I'm assuming by "private AD" you mean your company's AD? To use Lync you need to add that AD account to your company's Office365 setup?
I guess in that case there must be Web Ticket service installed in your companies network that is federated with the Office365 servers, i.e. it can generate Web Tickets accepted by them. I would speculate that the authentication to that internal Web Ticket server would be with HTTPS authentication against the AD account, which is already implemented and working for companies that use an internal or hosted Lync installation.
I think in your case we need to figure out how to derive the correct web ticket server information from the Office365 Lync setup. That information should already be in the SIPE log files, i.e. you wouldn't need to run a MITM attack on the Lync client. Feel free to contact me via a SF message to start a mail thread.
Going back to haydentech's message - the error was "Direct login to WLID is not allowed for this federated namespace", this is the same issue that I have.
@stefanb2, yes private AD = company AD. There is a trust between our domain and the Office 365 cloud and account information is synchronised. You are correct that the key is determining the correct web ticket server. I guess that Office 365 supports a SOAP request to provide this information, that's why I figured that a MITM attack might be useful as Lync surely uses this mechanism.
Great if we can do it without MITMA as I got seriously confused reading up on stunnel. I'll message you; thanks :-)
This seems to be fixed in version 1.14 of pidgin-sipe
@ctorchia87: Yes, the Office 365 accounts discussed in this thread are from hosted Lync installations with ADFS. Support for ADFS was added in SIPE 1.14.0 after one user spent a lot of time and effort to provide the decrypted logs from MITM attacks on his M$ Lync client.
I forgot to add this specific error message to the FAQ. It's there now, plus a tip how to detect if ADFS is in use for your Office 365 account.