How do you access Directory Server remotely?

replied on May 18, 2022

What's the scenario here? The phrase "access Directory Server [web admin interface] from a workstation not on the network" immediately throws security red flags. Ensuring your LFDS admin page isn't accessible from the internet is really high on the list of what I'd consider mandatory security controls, with few exceptions.

3 0

View 5 previous replies

replied on May 19, 2022

Does LFDS even have an option to prevent it being accessed from the internet? When you install it, it hosts itself like any other website. I prefer License Manager as it is far more secure, seems LFDS was made specifically to be accessible from anywhere, otherwise why make it a web based app.

0 0

replied on May 19, 2022 • Show version history

I wouldn't consider preventing external access to be the responsibility of the application layer as much as I would associate that with the server and network security/configuration. I think the fact that the LFDS STS pages can be installed independently is a good indicator because that allows you to facilitate authentication from the Internet without exposing LFDS itself.

Web apps would only be accessible from outside the network if you hosted them on a server that was accessible from the Internet and that typically requires intentional efforts, especially when you're using Active Directory authentication.

In our environment, anything we can access from the Internet either needs to be hosted on a DMZ server or have a reverse proxy configured with the express intent of making it accessible from the outside.

I also wouldn't associate the decision to make something a web app as being related to whether or not I want it to be accessible from the Internet. We build pretty much all of our in-house applications as web apps and the vast majority are only accessible from within our network.

The reasons for making them web-based are numerous, such as easier updates, making performance far less dependent on client-side resources, avoiding the need to install the application on multiple devices, etc.

If you want to provide external users, like remote employees, access to internal resources like LFDS, that's usually something you accomplish with VPN, not by making the site accessible from the public Internet.

2 0

replied on May 19, 2022

It's not really up to an application to decide if it should be accessible from outside the network - applications can't reliably know where the end user is. It's more of a network design decision to allow outside traffic to route to a particular machine or endpoint. Sam's point is that the IT staff should not allow that for LFDS. This is the main motivation for separating the STS component out - there are use cases where you do want to make that accessible from outside the network.

1 0

replied on May 19, 2022

Understood but LFDS is now being pushed to every client of every size, including many single server clients. What your mentioning is deploying multiple operating systems, just to host the configurator that licenses the products.

In any case, sounds like accessing it via typing in your crednetials is not a supported feature. I know it can be made to work, because I have seen others do it, but I don't know how.

Is the vulnerability that the credentials are sent in plain text even if the site is using SSL?

0 0

SELECTED ANSWER

replied on May 19, 2022 • Show version history

The simplest way to restrict access to the /LFDS web app on a server that is otherwise exposed to the internet is using the IIS IP and Domain Restrictions feature. This approach requires no additional servers, software, or security appliances. Restrict access to the /LFDS web app to at minimum only private network IP address space:

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

I highly advise doing this for single-server systems that must have other Laserfiche web apps internet accessible. It takes less than five minutes to configure and effectively closes a significant attack surface. Consider doing the same for /FormsConfig, (WebLink) /Designer, and other backend/admin IIS web apps that shouldn't be publicly exposed. Anyone who needs to access these backend/admin web apps can do so through a VPN or other such secure access method to the internal network.

Restricting web app access to internal IP ranges using this feature doesn't make it impossible for an outside attacker to reach, though it does make it significantly harder because they have to pull off a TCP IP spoofing attack before reaching the authentication step.

In any event, it technically possible to remotely authenticate to LFDS over the internet from a workstation on an untrusted domain by entering AD credentials in UPN format for a user with LFDS web admin access rights into the 401 auth challenge prompt. Just did so with one of my test servers. The credentials were sent in plaintext using NTLM because Kerberos doesn't work over the internet.

The customer may have global AD WinAuth security controls that block authentication from outside networks (a very rational thing to implement), the LFDS IIS web app may be configured in a way (custom app pool identities, etc.) that's breaking WinAuth, or something else.

2 0

replied on May 19, 2022 • Show version history

I would argue that regardless of organization size, core application servers like this should never really be hosted in the DMZ just like you wouldn't want a primary Active Directory Domain Controller hosted in the DMZ (even a RODC instance will raise eyebrows).

That being the case, I don't think the issue is really about hosting multiple operating systems just to host the licensing system, I think it's about hosting multiple operating systems to mitigate the serious security risks associated with exposing critical business infrastructure to the Internet.

Defense-in-depth is an important consideration, and situations like this could be a symptom of broader security concerns. When you balance the cost of one more server against the potentially catastrophic impact/cost of a security breach in the most vulnerable part of an organization's network, it tilts pretty hard one way.

3 0

replied on May 19, 2022

Well said Jason.

If an organization is in a position where the additional infrastructure necessary for defense-in-depth is genuinely burdensome, they should seriously consider migrating to Laserfiche Cloud (if feasible) and thereby offload the problem entirely.

1 0

replied on May 19, 2022

Samuel, thanks, this IIS config is really great to know when we have our security discussions with IT upon deployment. Although we do leave security up to them after notifying them of where the vulneratibilies are.

Of course most clients go with Cloud not just to save on security efforrts, but also cooling, power, maintenance, and consulting. This is why we are happy to see LF put so much focus into a web based SAAS solution. About 95% of our new clients use Cloud now, but on-prem clients are stuck at the moment with no workflow migration utility and hundreds of workflows.

We tried logging in with the fully qualified domain name and password into the prompt, but it doesn't work so maybe they have security preventing it. It also concerns me if it is being sent plain text, so I am planning to recommend not using it.

I agree Jason, configuration utilities are better left off running from the local server or maybe just on the internal network, when possible. It doesn't mean people never remotely access internal configs without a VPN though, many VPNs I have used are just a set of credentials thoughk, some even use the same AD credentials your worried about someone obtaining. 2 Factor is the best way to secure your data, it is very difficult for someone to intercept a text when connecting from a new device.

0 0

Question

Question

How do you access Directory Server remotely?

Answer

Replies

Sign in to reply to this post.