We are using the Sharepoint.OpenDocuments.EditDocument2 ActiveX control and method.
The method is being called from JavaScript in an IE6 client on a Windows XP SP3 client (fully patched).
The server is running IIS6 on Windows Server 2003 SP1
Fronting the IIS server is Tivoli Access Manager (TAM) which proxies access to the web applications sitting behind it. Similar to forms authentication, it creates a session cookie for authentication purposes, that must be present for the HTTP request to reach the IIS server.
In front of TAM is an F5/BigIP load balancer and SSL encryption offloader, which enforces that incoming requests use the HTTPS protocol.
What is happening is that HTTP requests issued by this control do not contain any session cookies that were present in the browser. It drops the ASP.NET session cookie, the ASP.NET forms authentication cookie and the TAM cookie
Because the TAM cookie is missing the request is redirected to the TAM login page, which then shows up via HTML conversion in Word or Excel.
The API documentation at http://msdn.microsoft.com/en-us/library/ms440037.aspx mentions nothing about security or appropriate usage scenarios for this control.
Should these controls work in an ASP.Net Forms Authentication scenario or are they only supported with Windows Authentication. If Forms Authentication is supposed to function, how do we get the control to include the necessary session cookies in its requests?
The answer as provided by Microsoft Support.
This control merely forwards the URL of the document being retrieved to the appropriate office application.
The office application attempts to negotiate authentication with Sharepoint Server (full version). If no Sharepoint, the Office application does a simple get on the URL.
Ultimately, this means that this control does not support authentication scenarios that rely on session cookies.
Related
Using IIS server with NTLM authentication. Where can I modify the session timeout settings?.
I'm afraid it is almost impossible to control the lifetime of your NTLM ticket from server side.So windows authentication should be implemented in a trusted environment.
I think the only way to log out windows authentication is clean cache in server side and re-open web browser.
If you need kind of authentication that ticket timeout can be controlled all the time, you could use custom form authentication instead.
https://learn.microsoft.com/en-us/aspnet/web-forms/overview/older-versions-security/introduction/an-overview-of-forms-authentication-cs
I am trying to access O365 site with Windows Live authentication from windows application. With Web Browser control I am able to do it. The problem is this tool runs for more than 15 hrs and within this time frame FedAuth cookies expires and I need to again refresh the cookies without bringing up the Web Browser control. And the other reason why I cannot have Web Browser control is that this application also supports windows service mode.
We have automated the ADFS authentication through Http Requests but for Windows Live authentication there are some javascript involved to actually do the login.
I have tried the SOAP approach mentioned here How to do Windows Live Authentication (RST) via SOAP, it returns the Request Security Token but it is not in the same format which ACS (Azure Control Service) returns.
Please suggest any work around or technique I can use to achieve this goal.
I'm trying to add Active Directory single-sign-on support to an existing SOAP server. Since it is written in C++ using third party transport components, adding AD SSO doesn't appear to be easy.
Therefore I am thinking to require IIS as a trusted reverse-proxy and let it do the Active Directory authentication for the SOAP server. That is, offload all authentication duties to IIS, and just rely on the X-Remote-User HTTP header at the SOAP server. Since the SOAP client is using the WinInet API, all of the authentication is done for us, and this give the SOAP server single-sign-on for free.
client
-> IIS (Active Directory authentication)
-> SOAP server (with X-Remote-User: USERID header)
This appears that it should be a fairly common problem space, however although I have found a few IIS proxy programs, I thought that this may be something built into IIS.
Is this sort of functionality built into IIS or do I need to build a proxy myself?
Is there a better option than requiring IIS?
I'm interested to know what methods people use to secure their webservices from unauthorized web service consumers.
There is a protocol specifically for web services security WS-Security. I've used parts of it in the past but at the time there was not a lot of support for it in .Net so it was a lot of work.
Currently with .Net I use SOAP Extension Headers. I have one web service call to authenticate and get a session token and then include that token in a SOAP header for every subsequent call, somewhat similar to this example. Of course all the request must travel over TLS to keep them from being compromised.
I usually require either a user id/password to be sent each time, or return a token from the first authenticated connection that can be used subsequently.
Nothing fancy. Pretty similar to standard web app login.
I've used both SOAP headers and method parameters to pass user credentials -- .NET makes using the SOAP headers pretty easy, but I had issues with this using Java (several months back). I also do some IP-based filtering if the service is not intended for client (browser) use, but rather from backend web servers. Public, browser consumable web services are often protected by session cookies -- i.e, requires a valid logon to the web site, then the standard session authentication mechanism is used for requests via AJAX to web services.
You can use network appliances such as IBM's DataPower or Vordel if you don't want to handle in your own application.
We have a SQUID reverse proxy and a MOSS 2007 portal. All sites are using NTLM.
We cannot get it working with SQUID as a reverse proxy.
Any ideas where to start?
Can you switch to Kerberos instead of NTLM?
You're encountering the "Double-Hop Issue", whereby NTLM authentication cannot traverse proxies or servers.
This is outlined at this location:
http://blogs.msdn.com/knowledgecast/archive/2007/01/31/the-double-hop-problem.aspx
And over here:
http://support.microsoft.com/default.aspx?scid=kb;en-us;329986
Double-Hop Issue
The double-hop issue is when the ASPX page tries to use resources that are located on a server that is different from the IIS server. In our case, the first "hop" is from the web browser client to the IIS ASPX page; the second hop is to the AD. The AD requires a primary token. Therefore, the IIS server must know the password for the client to pass a primary token to the AD. If the IIS server has a secondary token, the NTAUTHORITY\ANONYMOUS account credentials are used. This account is not a domain account and has very limited access to the AD.
The double-hop using a secondary token occurs, for example, when the browser client is authenticated to the IIS ASPX page by using NTLM authentication. In this example, the IIS server has a hashed version of the password as a result of using NTLM. If IIS turns around and passes the credentials to the AD, IIS is passing a hashed password. The AD cannot verify the password and, instead, authenticates by using the NTAUTHORITY\ANONYMOUS LOGON.
On the other hand, if your browser client is authenticated to the IIS ASPX page by using Basic authentication, the IIS server has the client password and can make a primary token to pass to the AD. The AD can verify the password and does authenticate as the domain user.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
264921 (http://support.microsoft.com/kb/264921/) How IIS authenticates browser clients
If switching to Kerberos is not an option, have you investigated the Squid NTLM project?
http://devel.squid-cache.org/ntlm/
you can use HAProxy for load balancing