We recently went to upgrade a client to LF 10, and found they could not authenticate due to their UPN names being based on their SMTP mail address instead of their sAMAccountName and domain.
I.e. :
AccountName: mydomain\JSmith
UPN: john.smith@mydomain.com
There's a reason they've made this change... it's because they are using Office 365 with Directory Sync/Federation, and the widely held best practice is to update your users' UPNs to match their mail address. Reasons why are noted in the "What If We Don't Change the UPN" section of this article: http://blogs.perficient.com/microsoft/2015/07/office-365-why-your-upn-should-match-your-primary-smtp-address/
From our client's perspective, before they changed to the mail based UPN, they verified they had no applications leveraging AD for authentication that were using the UPN, so they were clear to make this change.
With LF 10, Laserfiche has changed the authentication method to S4U which makes use of the UPN (discussed here: http://answers.laserfiche.com/questions/105178/Reason-for-UPN-to-be-placed-in-AD).... this mismatching of UPN to logon account name triggers the login failure.
Options explored:
- to add an additional UPN suffix, however that wouldn't resolve the issue as (in my example above) "john" doesn't match "john.smith".
- implementing an Alternate Login ID that allows you to use an attribute other than UPN for your Office365 login (like the mail attribute), but that feature comes with limitations (discussed here: http://blogs.perficient.com/microsoft/2015/02/office-365-the-limitations-of-alternate-login-id/), and makes this a hard solution to pitch to a client.
So... I'm posting this discussion in hopes someone either more creative or more AD-knowledgeable might have some ideas I haven't come across yet, or see something I missed.
We did engage LF Support on this, who helped us identify the underlying issue, but the only solution provided was to revert their UPNs back from the mail names.
This change to S4U seems fraught with trouble given the rate of adoption of Office365 by our clients, so I'm hoping this discussion bears some fruit!