Question

NTLM vs Kerberos and Public Portal.

WebLink

Updated April 13, 2015

asked on April 6, 2015 • Show version history

I have a customer that has one server for Laserfiche and another server for WebLink. The Laserfiche server is on their domain but the public portal server is not on a domain at all. The customer would like to use windows authentication to login to the system through the WebLink. It seems that kerberos will have to be used for this setup but the 2nd server is not on a domain so it couldn't be setup as a trusted domain. The other option would be NTLM correct? or are there other factors at play here that will prevent NTLM from working?

Can anyone explain to me the best method to this setup? The way I understand the setup guides it that the LF server and WebLink are typically on the same box. From a security standpoint I dont see how this would ever be acceptable... but im probably interpreting the text incorrectly.

So along with my initial question can someone explain to me the best way to set this up for future reference?

p.s. their customer is using WebLink, Public Portal, Web Access & Mobile all through the same server.

Thanks!

0 0

Replies

replied on April 6, 2015

Any kind of Windows authentication requires that the web server understand the identity so that it can impersonate the user. This means there has to be some kind of trust relationship between domains. In addition, Kerberos requires that the client machine (i.e. the browser) be able to contact the domain controller to get a Kerberos ticket, but that usually can't work in a public portal environment. On the other hand, with NTLM the identity tokens are not usable for delegation, so while the user could identity themselves to the Web Access server, that identity can't be used to create a session with the Laserfiche server.

What might work is if the users type their Windows credentials into the login dialog. WebLink can use that token to log into Laserfiche, but it still does require that the identity be valid on the WebLink machine (i.e. you need a trust relationship).

Can you explain your uses cases a bit more? It can be challenging to combine public access and Windows authentication because the machines are on different domains. Is VPN an option?

Related question.

0 0

replied on April 6, 2015

Thanks for the reply.

To clarify only one the Laserfiche server is on a domain. The WebLink server is not. Does this need to change?

This account has judges, adoption prospects, lawyers and state governments reading records from their system. They need to have the ability to give access for a limited amount of time on specific folder structure that may change from time to time. They also want their case managers to be able to connect to the web client when they are out of the office. I dont believe VPN is an option.

The account is trying to limit the amount of repository users created for the use of public access but allow its employees to connect to the system from the outside.

0 0

replied on April 6, 2015

Yes, WebLink has to be on a domain for its users to authenticate to LFS using Windows authentication. This is true of any application that wants to connect to LFS. If you want external users to use Windows authentication, the two main options that come to mind are:

Set up a domain in your DMZ that has a trust relationship with your internal domain.
Install WebLink on your internal network with an http proxy in your DMZ.

0 0

replied on April 13, 2015

Is it possible to make the WebLink box a domain box? or does this pose its own set of challanges.

0 0

replied on April 13, 2015

If you mean can you add it to the domain, then that is technically possible as long as you allow the required traffic through the firewall. But the point of a DMZ is to be a separate untrusted network, so I'd doubt that the network admin would allow it, especially since you'd have to also trust that machine for delegation.

0 0

You are not allowed to follow up in this post.

Question

Question

NTLM vs Kerberos and Public Portal.

Replies

Sign in to reply to this post.