LFDS should be on a domain: workgroups are not considered supported and lack some functionality --- including, I believe, this scenario. However, since it is not a supported configuration, I cannot say for certain.

Putting LFDS on the customer's domain is the simplest solution, but not specifically required.

If you put LFDS on a domain that is not the customer's domain, you will either need to (1) set up domain trust and configure security such that the LFDS service user can authenticate, or (2) manually specify an AD user that can authenticate to the customer's domain (such as an AD user from within the customer's domain).

We do attempt to verify the connection on saving changes, so you should be able to tell quickly whether or not the specified user can successfully authenticate to the directory.

Note that this user is only used for automated actions like AD group sync. If an administrator wishes to connect to a directory manually within the LFDS UI (e.g., add AD groups to an LFDS group, add AD users individually), they must provide their own AD credentials that can authenticate to the customer's domain.