Web authentication using desktop ldap - security

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.

Related

SMB authentication via domain accounts from non-domain machine

I would like to ask if somebody could explain me how exactly user/account is authenticated in following scenario:
SMB File Server is part of the domain
access to the File server is granted via domain accounts
Client is outside of the domain and firewalled only to see the File Server.
Client is going to use domain credentials to authenticate to the File Server.
My question is how the Kerberos tickets are created if Client is not having visibility to KDC/Domain Controllers? is it going to be the File Server acting as a client for the KDC or relay the request if yes how the credentials are stored on the File Server? Or will be other authentication method used in this case e.g. NTLM?
Thanks!
Tomas

WebDav Windows Authentication on non domain join web server

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.

How to connect Ejabberd or MongooseIM with Node.js (or Django)

I want to develop a backend server for a chat application using node.js (or Django) and Ejabberd or MongooseIM. And consume this API on a React Native app that should have push notifications.
The idea is to manage the user profile and metadata and also the authentication ( OAuth 2.0 - social login ) through my own server, then let the management of the chat stuff to the Ejabberd or MongooseIM server.
The problems come on how to make the connection between the servers. I want to login through my server and don't make the user aware of the existing Ejabberd or MongooseIM server.
Any idea on how can I make the connection between the servers?
The problems come on how to make the connection between the servers. I
want to login through my server and don't make the user aware of the
existing Ejabberd server.
I think it's not a right way
Here is how I see it and how I implemented it in some projects:
1) a user logins via App Server REST API and obtains some session token or something like this and user_id
2) then this user uses this user_id to build a JID for ejabberd, e.g. #yourejabberdserver.com
3) then this user uses this JID and session token as a password and connect to Ejabberd.
4) Ejabberd in this case verifies the session token (it goes to your App Server DB and verify or if you use a JWT token then it just verifies it). In Ejabberd you can do it by implementing external script auth:
https://docs.ejabberd.im/admin/configuration/#authentication
https://docs.ejabberd.im/admin/configuration/#external-script
This approach saves you from 2nd account registration (at Ejabberd side), so you use the same user credentials in both apps (Server App & Ejabberd)

Windows authentication through a reverse proxy problem

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").

Has anyone been able to get SharePoint using NTLM working with SQUID as a reverse proxy?

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

Resources