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

Question

Question

Avante AD integrated LFDS installation, Do not want users to have to enter the domain as part of user name

asked on May 10, 2022

Our implementation of LFDS Version 11, requires our educational and named users to prefix their usernames with our domain.  We would like to remove that requirement as we only have one identity provider (our on-premise AD domain, as there is no Google SAML yet).  We have only one identity provider set up and only one STS Site setup.  Our end users are about 98% Mac users with only about 30+ PC users.  We are trying to increase the district buy in on using Laserfiche processes, due to the purchase of enough educational user licenses to cover our entire staff, but the teaching staff gets confused with all the different logins they are expected to use and asking them to use one that does not fit any of the other templates will be a deal-breaker.  We have experimented with saved user names and passwords using Clever, but the username within that system is having issues with the backslash required as part of the user name.

 

Any assistance or guidance on what we need to change within our configuration so that we do not need the domain as part of the username would be great.

Current Login required:

What we would like to be able to use is:

 

0 0

Answer

SELECTED ANSWER
replied on May 16, 2022 Show version history

Hi Kip,

I made a modified version that adds a "LFDS Laserfiche User" checkbox that toggles the auto domain prefixing off when checked. You can have your one outside user check that box when they log in so they can use their LFDS Laserfiche account. It looks like this and you can make the display text say whatever makes sense for your use case.

The attached Login.cshtml file is for Laserfiche Directory Server 11 Update 2 (build 11.0.2204.1467, released 4 May 2022). Had to add a ".txt" extension for Answers' file type restrictions. Do not use that file as a drop-in replacement for any other build of LFDS.

There are two blocks of changes:

  1. Login function modification, from the start through the "var isPublicComputer" bit. It's similar to before and adds the conditional handler for the new checkbox. As before, update the "DOMAIN" placeholder with the correct value.
    function login(authType, identityProviderName) { // identityProviderName is currently only relevant with a federation authentication authType
    	//var rememberMe = document.forms["loginForm"]["rememberMeCheckbox"].checked;
    	//Original username variable construction below
    	//var username = document.forms["loginForm"]["nameField"].value;
    	//Updated username variable that automatically adds a hardcoded domain prefix to the username variable used in the login function
    	var username = "DOMAIN\\" + document.forms["loginForm"]["nameField"].value;
    	var password = document.forms["loginForm"]["passwordField"].value || '';
    	var organizationName = document.forms["loginForm"]["orgField"].value || document.forms["loginForm"]["orgDropdown"].value;
    
    	var isPublicComputer = document.forms["loginForm"]["isPublicComputer"].checked &&
    						   document.getElementById("publicComputer").style.display != "none";
    
    	var isLaserficheAccount = document.forms["loginForm"]["isLaserficheAccount"].checked &&
    						   document.getElementById("laserficheAccount").style.display != "none";
    
    	//Enables LFDS "Laserfiche" user login by not prepending the domain to the username string
    	if (isLaserficheAccount)
    	{
    		username = document.forms["loginForm"]["nameField"].value;
    	}
  2. Adding the new "laserficheAccount" checkbox element in-between the existing "publicComputer" and "mfaGroup" ones around line 819. Update the "YOUR MESSAGE HERE" string between the <span> tags with the display text of your choice.
    <!--public computer checkbox-->
    <div id="publicComputer">
    	<label>
    		<input type="checkbox" id="isPublicComputer" />
    		<span id="ThisIsPublicComputerStr"></span>
    	</label>
    </div>
    <!--LFDS Laserfiche account checkbox-->
    <div id="laserficheAccount">
    	<label>
    		<input type="checkbox" id="isLaserficheAccount" />
    		<span id="IsLaserficheAccountStr">YOUR MESSAGE HERE - I am not a District employee</span>
    	</label>
    </div>

     

Hopefully that could be a good solution. The only person who has to do anything different during login is the one outside user checking the box.

1 0

Replies

replied on May 10, 2022

Hi Kip,

So just to be clear, these are AD user accounts logging in from domain-joined MacOS devices?

My first question is what happens when they select the "Windows Authentication" option? If there's only one domain you don't need to prefix the username string with domain\ because it's implicit in the WinAuth dialog.

If that doesn't work for whatever reason, Apple appears to have a Kerberos SSO (WinAuth) extension that sounds like it should make WinAuth work. See: Kerberos Single sign-on extension with Apple devices

If you get WinAuth working for the MacOS folks, you can then (likely) enable an automagical SSO experience for the users by going to https://localhost/LFDSSTS/configuration wherever STS is installed and selecting the "Always use Windows Authentication" option.

If the WinAuth approach doesn't work out, the easiest immediate thing to do is modify the STS login page to have helpful guidance text like so:

and/or write some JavaScript that automatically pre-fills the Username field with "ncsd\", though that might not play nice with password managers / autofill.

Finally, there are two valid ways of specifying an AD user in the Username field:

  1. domain\username
  2. username@domain.com (UPN format)

 

I'm not sure what exactly Clever is, but if it's a credential manager of sorts, I'd bet it doesn't have any issues with the UPN format because so many systems use email addresses as usernames and UPNs have exactly the same format. If that works, you can still modify the STS login page with helpful guidance text.

Hope that helps.

Cheers,
Sam

1 0
replied on May 11, 2022 Show version history

I am not a Mac user at work, so this is second-hand information, when I have tested it recently it has been on freshly refreshed macs and they are still talking to AD.  But what I am told is that an AD bound Mac occasionally, and will eventually lose its binding but still allow the user to authenticate as long as their AD password has not been changed outside their laptop.  How they notice is if they do select the windows authentication button, they get a message about no domain found, I have looked for a screenshot but seem to have deleted them all.  But will try to get one.

 

As for the UPN format, I did think about that but it is problematic in its own way.  Our email addresses and what most of our users are familiar with does not match our AD domain in any way.  Our Network manager is terrified of making a change to the AD forest to bring our AD domain in line with either of our Google domain names.

 

I will look into the WinAuth extension and STS settings, that might be helpful.

 

Thank you!

1 0
replied on May 11, 2022 Show version history

Hey Kip,

We looked into this a little more and it's actually trivial to automatically add the domain prefix on the "backend" with no user interaction required.

PLEASE NOTE: This custom workaround will functionally prevent interactive logins with LFDS "Laserfiche" user accounts because it always injects the domain prefix before the value entered into the Username field. If you have some LFDS Laserfiche users, don't implement this change.

Instructions:

  1. Navigate to the STS login page web file located at "C:\Program Files\Laserfiche\Directory Server\Web\WebSTS\Views\Home\Login.cshtml" and make a backup copy. Name it something like "Login-Original.cshtml".
     
  2. Open the "Login.cshtml" file in a text editor running as Administrator (necessary to make edits).
     
  3. Find the line starting with:
    function login(authType, identityProviderName)
  4. A few lines into the function, you'll see a line with:
    var username = document.forms["loginForm"]["nameField"].value;
  5. Replace it with the following four lines:
    //Original username variable construction below
    //var username = document.forms["loginForm"]["nameField"].value;
    //Updated username variable that automatically adds a hardcoded domain prefix to the username variable used in the login function
    var username = "DOMAIN\\" + document.forms["loginForm"]["nameField"].value;

    Replacing the "DOMAIN" value in the last line with your actual domain.
     

  6. Save the Login.cshtml file.
     

  7. Open IIS Manager -> Application Pools and recycle the LicenseManagerSTSAppPool to make the change take effect.
     

  8. If and when you upgrade Laserfiche Directory Server to a new version, it will likely overwrite the old Login.cshtml file with a clean new one. You will need to re-implement this customization after the upgrade.

1 0
replied on May 16, 2022

Samuel,

 

We did consider that but we do have one outside user that is using a forms participant user to participate in some of our counseling processes.  So I am not sure it would be a good solution for us at this time.

 

Thank you ,  Kip

0 0
SELECTED ANSWER
replied on May 16, 2022 Show version history

Hi Kip,

I made a modified version that adds a "LFDS Laserfiche User" checkbox that toggles the auto domain prefixing off when checked. You can have your one outside user check that box when they log in so they can use their LFDS Laserfiche account. It looks like this and you can make the display text say whatever makes sense for your use case.

The attached Login.cshtml file is for Laserfiche Directory Server 11 Update 2 (build 11.0.2204.1467, released 4 May 2022). Had to add a ".txt" extension for Answers' file type restrictions. Do not use that file as a drop-in replacement for any other build of LFDS.

There are two blocks of changes:

  1. Login function modification, from the start through the "var isPublicComputer" bit. It's similar to before and adds the conditional handler for the new checkbox. As before, update the "DOMAIN" placeholder with the correct value.
    function login(authType, identityProviderName) { // identityProviderName is currently only relevant with a federation authentication authType
    	//var rememberMe = document.forms["loginForm"]["rememberMeCheckbox"].checked;
    	//Original username variable construction below
    	//var username = document.forms["loginForm"]["nameField"].value;
    	//Updated username variable that automatically adds a hardcoded domain prefix to the username variable used in the login function
    	var username = "DOMAIN\\" + document.forms["loginForm"]["nameField"].value;
    	var password = document.forms["loginForm"]["passwordField"].value || '';
    	var organizationName = document.forms["loginForm"]["orgField"].value || document.forms["loginForm"]["orgDropdown"].value;
    
    	var isPublicComputer = document.forms["loginForm"]["isPublicComputer"].checked &&
    						   document.getElementById("publicComputer").style.display != "none";
    
    	var isLaserficheAccount = document.forms["loginForm"]["isLaserficheAccount"].checked &&
    						   document.getElementById("laserficheAccount").style.display != "none";
    
    	//Enables LFDS "Laserfiche" user login by not prepending the domain to the username string
    	if (isLaserficheAccount)
    	{
    		username = document.forms["loginForm"]["nameField"].value;
    	}
  2. Adding the new "laserficheAccount" checkbox element in-between the existing "publicComputer" and "mfaGroup" ones around line 819. Update the "YOUR MESSAGE HERE" string between the <span> tags with the display text of your choice.
    <!--public computer checkbox-->
    <div id="publicComputer">
    	<label>
    		<input type="checkbox" id="isPublicComputer" />
    		<span id="ThisIsPublicComputerStr"></span>
    	</label>
    </div>
    <!--LFDS Laserfiche account checkbox-->
    <div id="laserficheAccount">
    	<label>
    		<input type="checkbox" id="isLaserficheAccount" />
    		<span id="IsLaserficheAccountStr">YOUR MESSAGE HERE - I am not a District employee</span>
    	</label>
    </div>

     

Hopefully that could be a good solution. The only person who has to do anything different during login is the one outside user checking the box.

1 0
replied on May 16, 2022

Hey Kip-

A quick (maybe) thing to investigate is how the password changes are handled. I recall one environment I worked with a few years ago where users wouldn't change their passwords and then eventually AD would get to the point of "you can't use things until you change the password". But I don't think that showed too easily on the Macs, so I would have them manually reboot or at least lock and unlock in order to force setting a new password. Then they could use Laserfiche again.

Note that I was remote and didn't see it in person, but I believe these were Mac users in office (pre-COVID) who left their machines unlocked all the time.

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

Sign in to reply to this post.