I need a sanity check...
I have a client with existing on-premises Rio system using Active Directory users. They are planning to move their LF environment to Azure but intend to keep that environment separate from their on-premises network and domain, meaning they will not be connecting on-prem and Azure Virtual Networks via VPN and the two domains will not have any trust. I.e.:
Azure Virtual Network
- Domain: customercloud.com
On Premises Network
- Domain: customer.com
- AD FS available
Again, no trusts between those domains, and no VPN facilitating communication between the two networks.
Authentication could be achieved by enabling AD FS on the Active Directory Identity Provider configuration in LFDS and using STS, allowing auth for any LF Web App enabled for the STS/SSO… except, once LFDS and the LF Repository Server is moved to the Azure Virtual Network, it won't have connectivity to the on premises domain and its domain controllers,,, So even though we can facilitate Authentication, anywhere those AD users are referenced (i.e. to assign Access Rights, Features, Privileges, and Trusted access to the repository) there's no way for those Laserfiche components to reach/query AD regarding those users… for example, what if they add a new employee, new AD user account, and want to grant that Trusted access to the repository… there's no path for the LF Server to query AD for the user's SID and assign is security rights, in spite of there being a path to authenticate that user (AD FS).
This seems to be due to the inability in LFDS to add AD users without requiring connectivity directly to a domain controller…
- With a SAML identity provider type, LFDS does not require a host for the IP, or connectivity to that IPs underlying directory service… just the SAML auth/endpoint, and you can get SAML accounts into LFDS accounts via CSV/import.
- With an Active Directory identity provider type, LFDS requires the "host" (domain controller) value… thus requiring communication to the dc.
It would seem that the only viable option is to add their AD/AD FS as a SAML identity provider, and then take every AD user and translate it to corresponding SAML user account in LFDS… and THEN in your repositories, changing all the security rights assignments over to reference the SAML user account.
Even trying the Proxied Provider option to proxy the SAML User to the AD user doesn't work either, as it requires the AD domain to already be defined as an Identity Provider, which requires connectivity to the host/domain controller.
This would be somewhat analogous to moving an on-premise repository that was using AD users to your Laserfiche Cloud... a transition you all achieve via your migration utility… it creates LF Cloud users for each corresponding AD user, and then rebuilds the access rights on the repository to those new LF Cloud users.
Is this (transposing all AD users to SAML accounts and then reconfiguring all security rights) truly the only path forward where there's no communication (S2S VPN) between their Azure Virtual Network and their on premises AD domain controllers?
If so, are there any utilities from Laserfiche that would facilitate the conversion of AD user accounts into SAML accounts (similar to your LF Cloud migration utility).
Or… please tell me if I'm overlooking something obvious!
I've also reviewed the FAQ on the new Enterprise Identity Management Add-on on existing and upcoming features, and don't believe I see a solution for this there in the existing features... perhaps in the upcoming SCIM features?