When my users are using the AD Federation single sign on server, they must go to the full path of the login. Ex: https://login.example.com/adfs/fs/SingleSignOn.aspx
Instead I am wanting them to connect to https://login.example.com, which I am wanting to be the directory for the login page. I could either move the login path to be the index file for the subdomain, or I could simply have https://login.example.com/ redirect to https://login.example.com/adfs/fs/SingleSignOn.aspx.
Is this possible to do in any way only using AD Federation? I know using IIS would be a simple solution, but these machines are not supposed to be running IIS or anything similar.
I am very new to using AD Federation and have very limited experience, so any help would be greatly appreciated.
There is no way to do this with ADFS out of the box. You will need to put a proxy infront of ADFS with a rewrite rule. As you already guessed, this should not be run on the same server as ADFS, as they should never be directly exposed to the internet. It is recommend, at the minimum, to use a web application proxy anyway.
We are building a system on windows where we centrally (server) need to do fopen to either local files or remote smb resources. The idea is to authenticate in the case of remote resources before doing fopen (with unc paths).
We need to authenticate with the credentials the user (client application) supplied for this resource on that remote share. We don't want to copy any resources.
Using the Win Net Api this works smoothly since it stores the given credentials so that subsequent fopens in the same or in different processes succeed.
But there is a problem:
Many of you probably know the following message from windows when trying to connect to a smb share with different credentials then the ones used for a previous connection:
"Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again."
See http://support.microsoft.com/kb/938120 for the defined limitation and possible "work arounds".
Since we have a central server application running as a service ('Local System' account) we hit this limitation with having already two different users :).
Closing the previously established connection to allow for the 2nd one is not an option (ongoing processing).
On the one hand it's great that windows caches authentication information on the other hand it's too limited.
Modifying the hosts file for each user does not look very nice.
Using smb client libraries (like libsmb++, impacket) doesn't seem to be the solution since we need "over process" authentication.
Configuring a "master" smb share user is also not wanted.
Maybe passing windows user auth tokens around is a way?
This problem is of general nature (i.e. independent of language) and I'm convinced that there are people out there who solved it (in a more or less elegant way ;))
I hope my explanation is understandable.
Thanks in advance for any hint.
felix
I have the following problem to solve:
I few months ago I startet a website where you can watch youtube videos which aren't available in your country. Everythings works fine but now I want to offer a new method where I route all the requests directly over my server. Therefore I will later use a custom DNS-Server. Right now I use the hosts file for testing but I have really no idea how i can identify the user. I can promp the user user to login on a website but I will that it works systemwide so if he use a youtube downloader for example it have to work there either and not only in the browser where I could use a session system with cookies. I want a solution where the user can identify himself once in a time like a website or something like this but how can my server detect if this is a user which is logged in or if he is not?
There are several ways that this could be accomplished with varying levels of difficulty.
standard proxy server over https. Your service could simply be a proxy server and then every "client" would update their browser to point to your proxy server. You could also simplify this by using a proxy PAC file (proxy auto config).
An anonomyzing interface. The end user would not be able to use their standard search tools etc, instead they would have to use a web page much like what google translate does.
A browser plugin. There are already firefox plugins which do something similar to this. They change the way that the browser resolves DNS. This may be the best bet for you but would require development work.
An actual install utility that you have your users install on their machines which update the dns servers.
I do automation testing for a company that is trying to implement a single sign on via an iFrame; a third party site will include our page in an iFrame and we will do an authorization.
We had to rework the way this worked because of Firefox defaulting to 3rd Party Cookies being off. For manual testing, we have hosted the page on a different domain, but this domain requires certain usernames and passwords we cannot expose in code, so this is difficult to automate.
Is there a way I can trick Firefox into thinking that mydomain.com is not actually mydomain.com? This sounds impossible, because if I can trick Firefox into thinking I'm actually on mydomain2.com, then I can effectively just put on a 3rd party cookie, but since I'm doing it on my own instance of Firefox, are there any settings I can change in my profile to confuse it?
Yes, this is incredibly easy and we do this all the time.
Log onto the test machine (the computer that will be running the browser) and edit the hosts file, located in c:\windows\system\drivers\etc
Add an entry for the site you wish to be confused, using a different domain name but the correct IP address. Because it's a different domain, it'll look like a third party site, but because the IP address is the same, the requests will actually be sent to the same web server.
Example:
Assume your web server is running on the local host (which has address 127.0.0.1)
Add host entries for
127.0.0.1 FirstPartyDomain.com
127.0.0.1 ThirdPartyDomain.com
Access your site via http://FirstPartyDomain.com
Site contains an iFrame
<iframe src="ThirdPartyDomain.com/SetNastyCookies">
The request in the iFrame will go to the same server (local host) but in the context of a third party site.
What about using DNSMasq? Most open-sourced routers such as DD-WRT support this option. If you need to test it via https, you could also temporarily store security certificate exceptions as well during your testing.
I heard that on Windows you can login from a web browser to the web server without going through the usual login entering username and password but using instead the credentials from Windows directly, using the NTLM protocol.
How is this achieved? Does the web server need to support some additional authentication?
Update: I'm asking for a generic web server, not just IIS. How to do that on Apache for instance?
The webserver just needs to be configured to support Windows authentication (which will be NTLM, or - better - Kerberos if both client and server are W2K or later). I believe that IIS or Apache can be configured to do that.
The browser also has to support this - at least IE does so (not sure about the others, it may be possible). edit: looks like firefox has some support for this too, and safari on MacOS
edit: for details on apache, google modules for NTLM authentication. Kerberos modules also exist. as per other answers, this really only works on an Intranet - not just because the browser needs to be in an Intranet zone (only applies to IE), but because any intervening firewall will typically stop this working, and because the necessary interdomain trusts will probably not exist. It's also a bit trickier to make work if the apache server is on UNIX, and especially if you also have Kerberos servers on UNIX in the mix, but still possible.
It will only be seamless in a specific situation; namely the webserver needs to support NTLM (for example, IIS), and it needs to be in a zone that the client is configured to trust (The "Intranet Zone" in IE parlance, unless the end user has tweaked their settings)
If your webserver and client pc's are on a network secured by Active Directory or similar, you can set 'Windows Integrated Security' in IIS on the web server for the website which automatically logs in all I.E clients (That are allowed).
As stated previously, NTLM is typically used if your back end is Windows Managed (MS Active Directory). However, there are also modules available for Apache that will tie into this: mod_ntlm.
Since this is it's own protocol, it is required that the browser is able to understand this protocol and reply to the authentication challenges. I don't know which browsers support this off hand, but my assumption would be that most do.
From my experience, kerberos is more of a prefered method, but I have not worked with it much, so unfortunately, I don't have much advise as far as that goes.
On a side note, I recall reading somewhere that the JRE also has ways of tying into NTLM on your web server in order to obtain identity information for the authenticated user. As stated previously, .NET has support for this as well.
Also, Firefox does not support NTLM by default but it can be configured using the following tut: http://www.crossedconnections.org/w/?p=89
If you set the IIS settings to require authentication then your users will need to log in to access the page. They then have any rights (if not an interface) to anything on that server that they would if they logged in the normal way (from the console).
Other than this, I am not sure what you are referring to.
Yes this is possible. It is often used in intranet applications where users are. windows uses NTLM or Kerberos to authorize the user against a central service, typically Active Directory on the windows platform. On the .NET platform the current user information can be accessed through the System.Threading.Thread.CurrentPrincipal.Identity instance.
You might also want to look into Jespa. It seems a little bit more straight forward than Kerberos but provides good ntlm sso capabilities.
I was looking for more information about Kerberos (because NTLM, even v2, become deprecated with AD 2008), and I found this article, explaining how make it work with Apache (as you mentionned it).
http://blog.scottlowe.org/2006/08/10/kerberos-based-sso-with-apache/
This question is probably outdated (or at least solved), but if it can help someone ...