I think the LDAP method is the right direction - you configure your LDAP server profile to point to your domain controller, then each user is given an LDAP account that is associated with their domain account. The upside is that the account authentication happens in the LF server so the user's machine does not need to be on the domain. There are a couple downsides:

1. the LDAP account known to Laserfiche is a different account than their domain account (different SIDs), which causes the issue of the user not inheriting their domain account's groups. To remedy this, you can use LF groups that are linked to domain accounts through LDAP. For example, domain\group1 and group1@domain are both members of the group1 group in the LF repository, and the group1 group is what is assigned in the LF entry/field/etc security.
   1. Note: in LF Rio you can configure LFDS to use LDAP authentication with a "use real SID" option that removes this limitation.
2. The login credentials are sent over the network, so you should have SSL configured required (as it appears you do already).

See this help page for more information on configuring LDAP in Laserfiche.

I agree that LDAP is probably the best answer but still no luck.  

In LFDS I:

1. Added LDAP & checked the use real SID option
2. Removed the license for the AD test account
3. Added LDAP test account manually and granted it a license

In the Admin Console I:

1. Added LDAP (same settings as those for LFDS)
2. Added the same test account as trusted with all Feature Rights

In the client I:

1. Added the test account with View permissions to the top folder & immediate documents

While on the network I was able to connect successfully with the LDAP account by:

• Doing a Run As a Different User on the client and then logging onto the repository with the via Windows Authentication
• It saw all folders/documents that its AD account is associated with.

While not on the network it failed to login with the LDAP account when:

• Choosing Password Authentication and entering the LDAP credentials
• Gave an "Permission denied. Access denied. [9013]" error

While not on the network I cannot do the Run As option and received the same results when using Password Authentication.  It appears that via Password Authentication it is unable to verify it has a license in LFDS.  Unfortunately the LDAP accounts do not have the column "Named User" like we have in Windows Account so we can see if it is pulling a license at the repository level and since it is Rio it can't be directly allocated there.

In looking at the error logs on the LF server:

• When I connect successfully using the Run As a Different User it connects and logs say: Logon Type=2, Impersonation Level=Impersonation, Process Name=C:\Windows\System32\svchost.exe, Logon Process=seclogo, and Authentication Package=Negotiate.
• When I try the Password Authentication and it fails to connect the logs say:  Logon Type=3, Impersonation Level=Identification, Process Name=C:\Program Files\Laserfiche\Directory Server\LFDS.exe, Logon Process=C, and Authentication Package=Kerberos.

Any suggestions on what to try next?

When you log in with the LDAP credentials method, make sure you use the format username@ldapprofile, for example if your ldap account in lfadmin is "test user" and the ldap profile is named "mydomain" it would be test user@mydomain. If that doesn't work, please open a support case so we can troubleshoot the issue.