Question

Rio Deployment - Separate Environments

Laserfiche Licensing Directory Server

Updated November 22, 2016

asked on June 14, 2016

Hi All,

With Laserfiche Rio you of course get the ability to have unlimited servers for different environments, which is ace providing those environments can talk to each other.

What if the customer has their environment configured in such a way that they are physically separate and the other servers cannot communicate with LFDS. I know you get the ‘7 day’ grace period but this means you will have to re-generate a license every 7 days in LFDS and re-implement into the test environment, not ideal.

Is there a way to setup a hosted solution or where the other servers can communicate directly with Laserfiche over the internet to validate their license. If not, can this be made a feature request going forward?

The other option would be to host LFDS externally and try and point the servers over a URL or something but I don’t think the customer would be too happy about this from a security point of view.

Anything in the pipeline to handle this scenario?

Cheers!

0 0

Answer

SELECTED ANSWER

replied on June 16, 2016

So, the LFDS machine, wherever it may be, would have a public IP. The app servers would need to be able to access it.

The licenses generated by LFDS have the server name in an XML element that looks like this:

LicenseServer="v-qa-release101.laserfiche.com"

Since this is outside the domain, it's likely the app servers wouldn't be able to resolve it properly without help (since they'd be looking within the domain). This is where the Windows HOSTS file comes in. You would add an entry to the file with the name of the license server mapped to LFDS's public IP.

Ports 5048 and 5049 would need to be open to incoming traffic on the LFDS server.

1 0

Replies

replied on June 15, 2016

There are a variety of ways to have your machines in another environment communicate with LFDS; such as setting an entry in a hosts file, having a proxy machine, or a firewall hole.

You may also want to contact your regional manager for additional options.

0 0

View 2 previous replies

replied on June 15, 2016

Thanks for the reply Marisa,

Just to confirm as I'm struggling to get my head around this. Will any of these options work if the 2 networks are physically separate? Both test and production networks (for example) have access to the internet but cannot see each other?

Cheers!

0 0

replied on June 15, 2016

They'd work as long as the applications in each one can communicate with LFDS so they can "call home" and validate the license periodically.

0 0

replied on June 16, 2016

Yes, thats the problem. Here is a crude diagram of what the setup would be:-

The issue here is that the networks are physically seperate, how can you get LFDS to "call home" over the internet?

Thanks Miruna!

0 0

SELECTED ANSWER

replied on June 16, 2016

So, the LFDS machine, wherever it may be, would have a public IP. The app servers would need to be able to access it.

The licenses generated by LFDS have the server name in an XML element that looks like this:

LicenseServer="v-qa-release101.laserfiche.com"

Ports 5048 and 5049 would need to be open to incoming traffic on the LFDS server.

1 0

replied on June 16, 2016

Top stuff. Thanks Miruna.

0 0

replied on June 28, 2016

Hi Miruna,

One quick question which has come up regarding this.

If you were to have LFDS presented as a public IP and hosted in a different DMZ or cloud based, how does LFDS communicate with Active Directory on the 2 networks?

Cheers!

0 0

View 4 previous replies

replied on June 28, 2016

When you register identity providers, you specify a username and password to be used when logging into the domain.

0 0

replied on June 28, 2016

Sorry maybe I didn't explain what I mean.

If the 2 networks both have internet access, and the LFDS server is hosted with a public IP. What would you enter as the host name for the Active directory? You would surely have to present your AD server externally as well in order for LFDS to see it?

0 0

replied on July 7, 2016

Not sure if you missed this Miruna but still not found a way around this?

Cheers!

0 0

replied on July 7, 2016

Sorry, it was on my to-do list, but I got sidetracked.

So, LFDS would have to be able to find the domain and authenticate. You could make the domain public, but, obviously, nobody wants that. You could have a read-only domain controller in the DMZ or you could set up a proxy in the DMZ to forward the traffic to the internal domain controller.

0 0

replied on July 8, 2016

Thanks Miruna, all seems a bit......much.

All this aside, is there any plans in the pipeline to have a Rio activation solution hosted from Laserfiche? So that customers LF servers can communicate with Laserfiche directly for the LFDS authentication?

Cheers!

0 0

replied on November 9, 2016

Hi Miruna,

Coming back to this, was having the Laserfiche licensing hosted by Laserfiche ever a consideration?

Cheers!

0 0

replied on November 22, 2016

I have a related question regarding AD authentication. In the scenario Chris describes, the Laserfiche server in the test network is not part of any domain/AD but does have a communication channel through to LFDS via the internet.

Would LFDS (or the Firewall, but that isn't a question for you) accept anonymous authentication or would the server in the test network need to be part of a trusted domain?

In the current setup the Laserfiche Server service on the test server is running as a local machine account and we are not able to specify an AD account for it to run as as the AD is not accessible from this machine.

0 0

You are not allowed to follow up in this post.

Question

Question

Rio Deployment - Separate Environments

Answer

Replies

Sign in to reply to this post.