You are viewing limited content. For full access, please sign in.



Looking for suggestions on the LF 10 S4U UPN versus Office365 SMTP based UPN conundrum

asked on December 7, 2016 Show version history

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



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:

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: 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:, 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!

2 0


replied on December 16, 2016

I think there's probably a bit of confusion on how logging in works. LFDS (and the LF Server for LDAP/eDirectory profiles) uses the "@" sign to figure out which identity provider it should use to authenticate the user. LFDS also adds an identity provider for the domain the LFDS server is on.

Your case notes indicate there are 2 types of users:

  1. domain name matches UPN domain suffix (domain\user1, UPN: user1@Domain)
  2. domain name does not match UPN domain suffix (domain\user2, UPN: user@SomeOtherDomain)


For the first one, authentication would work because LFDS would match the domain suffix to the one in its identity providers list. For the second one, LFDS doesn't know what to match it against, so authentication fails.

Identity Providers are matched by name, so if you create a second one named for SomeOtherDomain but with the same host and settings as the domain LFDS is on, I think authentication through the UPN should work for the second category of users too.

1 0
You are not allowed to follow up in this post.

Sign in to reply to this post.