Have a IIS Reverse proxy redirect on specific request on WebSite with windows authentication and impersonation to another local site with win.auth + impersonation.
Reverse proxy and the web application placed on a different machines and iis versions (proxy- IIS 7.5 , webApp IIS6) and the same domain.
Requests through the reverse proxy does not allow the user to be authenticated on the remote server. has an infinite authentication request.
This is inherent to the way windows authentication (NTLM) works: the password is never sent, authentication is done with a salted hash of the password, so the first server can authenticate the user but cannot re-use those credentials to impersonate the same user on a remote server (since without the password it cannot authenticate).
Look at this blog post to get more information about this problem (which is known as "double-hop problem").
Related
I am running IIS and Node in parallel on a Windows Server. Is it possible to allow IIS intercept HTTPS requests, authentic them using Windows Authentication (Negotiate/NTLM), then proxy the requirements onto Node as HTTP requests with username and security groups in the header for Node to process?
As far as I know, it is possible to use windows authentication before proxy request. Windows authentication is to authenticate people through the local Windows network. There is no proxy server or even a proxy server. Protocol does not authenticate HTTP sessions, but authenticates the underlying TCP connection.
IIS can also proxy the request to Node, as long as the request is rewritten using ARR and URL rewrite.
However, IIS itself cannot obtain the user name and security group information, and requires the help of ASP.NET applications.
Is it possible to setup IIS Webdav with windows authentication and SSL on a non domain joined web server?
The web server is hosted in azure and accessible via https 443. The clients are domain users and need to authenticate with their domain credentials in order to read/write on the web server over the internet.
My logic tells me this is not possible as the web server doesn't have a authentication provider without being domain joined?
Many thanks for any answers...
I don't think you would be able to use Windows Authentication, but if you have LDAP access to your AD environment from the server, you could do Forms Authentication and authenticate the user via LDAP in the back end. It would require the users to type in their credentials though.
You can test access to any one of the LDAP ports in PowerShell with:
Test-NetConnection -ComputerName domain.com -Port 389
The LDAP ports are:
389: LDAP
636: LDAP over SSL
3268: Global Catalog - same as LDAP but reads the whole AD forest
3269: GC over SSL
Any one of those would do.
I'm currently working on a project with complex requirements and I do not feel comfortable with the solution I'm considering.
The main idea is to secure existing applications (which do not include security themselves) without modifying them. These applications are not accessible from outside and will be accessible only through a reverse proxy (OpenResty).
Users do not have access to all applications and the solution to identify users is Keycloak.
The main components are :
An angular portal : the entry point
A reverse proxy that redirect the user on the chosen application
The IAM : Keycloak
All the available application
this schema explain it
The idea is :
The user click sign in on Keycloak and gets back to the portal with an access token (JWT) that contains his roles (application he has access to)
The user click on an application on the portal and he is redirected to the targeted application through the reverse proxy
The reverse proxy check the validity of the token (exp, iss and the roles)
I know this is not a proper way to do some SSO between application, but the requirement here is that the application, that are not secured can't be edited bu have to be protect by an upfront system (the reverse-proxy here)
My question is : ok this will work for the first call, because the user have his JWT token on the portal and hits the application with it the first time, but after when the user will click on a link in this app.. there is no more token. This kind of architecture works well to protect REST API bu for a web application, sounds to me a little incertain.
Generally, you would have reverse proxy server to handle user authentication instead of login to keycloak first.
Flow will be like this:
User access portal.
Portal redirects user to application through reverse proxy.
The reverse proxy will first redirect user to keycloak for
authentication, and build a security session between browser and
reverse proxy server.
The reverse proxy forward request to your application
server.
For all subsequent requests, user always go through reverse proxy server.
Try to use github.com/gambol99/keycloak-proxy. It stores token in the cookie, which is better option for web apps.
!!! Warning: I guess any auth proxy can use only Authorization Code Flow, however Implicit Flow is recommended for Single-Page Application (Angular). It really depends what's your Angular app. Analyze sec. pros and cons first, to be secure.
Problem: I want users from my corporate client to authenticate with my web server by using their local LDAP credentials. Users have a local desktop client that can authenticate with the local LDAP server. My server and the LDAP server do not talk to each other.
I know it is possible to authenticate on a web server using LDAP if the web server relays the LDAP request to a LDAP server. (User/desktop client connects to web server, sends credentials and web server interacts with LDAP server for authentication)
But is there a way for a desktop client to authenticate with a local LDAP server and then connect to a web server sending a token that would grant access to the web server? (user auths with ldap, sends ldap response to webserver)
I am not talking Oauth, which requires both servers to talk. In this case, the LDAP server is isolated from outside contact.
The big problem here is that you should never trust the client, even if you have written it yourself. Something like public/private authentication would (probably) not work as well, since the problem is not the encryption, but making sure the message came as "OK" from the LDAP server. A rogue client could fake the OK and sign it anyway.
If I understand your problem correctly, you're looking for a way to make your desktop client talk to your web application using the user's domain credentials.
This should be easy to do using something like ADFS. If you run ADFS inside your clients Active Directory domain, your desktop client can get a token from it using Kerberos. It can then use this token to authenticate with your web application.
You will need to configure your web application to trust tokens issued by the ADFS instance in your clients domain.
ADFS may work, but it is unnecessary. You should look into using SPNEGO as it does not require a ADFS infrastructure.
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