Bulk installation, upgrade and reconfiguration for 'Login for Windows'

Version Affected:  9.2+

Description:  
This article walks through how to setup Group Policy to deploy, update and/or reconfigure Login for Windows

Cause:  
Installing and updating or reconfiguring Login for Endpoints can be time consuming if carried out on a machine by machine basis, it is sometimes better to do this in bulk via automated processes. Software package deployment via Active Directory Group Policy is one of the ways this can be carried out.

Resolution:  
1) Configure a Realm to accept Login for Windows connections and create a Login for Windows configuration file. To do this simply follow one of the below articles -
9.2 / 9.3 - https://docs.secureauth.com/0902/en/login-for-windows-v20-03-01-configuration-guide.html#login-for-windows-installer-configuration
19.07.01 / 20.06 - https://docs.secureauth.com/1907/en/login-for-windows-v20-09-01-configuration-guide.html
21.04 - https://docs.secureauth.com/2104/en/configure-identity-platform-and-login-for-endpoints.html
22.02 - https://docs.secureauth.com/2202/en/configure-identity-platform-and-login-for-endpoints.html
22.12 - https://docs.secureauth.com/2212/en/configure-identity-platform-and-login-for-endpoints.html
23.07 - https://docs.secureauth.com/2307/en/configure-identity-platform-and-login-for-endpoints.html
24.04 - https://docs.secureauth.com/2404/en/configure-identity-platform-and-login-for-endpoints.html

2) Download a copy of Login for Windows from the below location
https://www.secureauth.com/support/product-downloads/

3) Create a Network Share on the Network which will hold the Login for Windows Installer and the newly created configuration file
Ensure the Network Share has the correct permissions assigned to it, ensuring all the users required have at least Read access to it
Once created you need to place the Login for Windows Installer and the configuration file in the Network Share, make sure you can get to the Network share from a Client machine and that you can see the files



(Optional but strongly recommended)
4) On a Client Computer browse to the Network Share and double click the 'SecureAuthLogin.....msi' file to ensure the package installs successfully
Test the installation by ensuring the users logging into the Computer, after installing Login for Windows, are prompted to use MFA if required

Once you are happy the configuration works as expected when installing manually it is time to setup a Software Package Deployment via a Group Policy in Active Directory, this will need to be carried out by the Active Directory Team or whoever has the required permissions within Active Directory

5) Creating the Software Package Deployment within Active Directory
Although the below is an example of how to create a Software Package Deployment within Group Policy, Microsofts documenation on this subject can be found here - https://learn.microsoft.com/en-us/troubleshoot/windows-server/group-policy/use-group-policy-to-install-software


Example
(If you are unsure of what you are doing within Active Directory log a case with Microsoft to ensure it is carried out correctly)

i - Create, or edit, a GPO within Group Policy Management Editor to install Login for Windows and link it to the required OU in Active Directory (where Computer Objects to have the Policy applied to them will be placed)
ii - Open the GPO and go to 'Computer Configuration - Policies - Software Settings - Software Installation'
iii - Right click, choose 'New - Package' and provide the UNC path to the Package (do not browse to it and double click it - our example path would be '\\dc\L4E\SecureAuthLogin-22.12.00-x64.msi')
iv - Click 'OK'
v - Close the Group Policy Management Editor
This will leave you with a GPO that will install the Login for Windows application for any Computers which are in the OU this GPO is linked to  (Software installation will occur the next time the Computer restarts on the Domain network)

Example of a Software Deployment Package

6) Upgrading and/or Reconfiguring Login for Windows
One example of how this can be done is to use Group Policy again but to have a new Deployment Package 'overwrite/replace' the existing Package
(Following the below steps ensures the old package is removed at the same time as the new package/configuration is applied)

i - Create a new Folder within the same Network Share as you created above and place the new MSI and Login for Windows Configuration file within that folder (if its a reconfiguration deployment simply copy the same version of the MSI with the new Configuration File into the folder)




ii - Open the GPO created in Step 5 and go to 'Computer Configuration - Policies - Software Settings - Software Installation'
iii - Right click, choose 'New - Package' and provide the UNC path to the MSI in the folder you created in 6i above (do not browse to it), in our example that would be '\\dc\l4e\UpdatedConfiguration01\SecureAuthLogin-22.12.00-x64.msi'
iv - Choose 'Assigned' and click 'OK'
v - Right click the 'Old' Deployment Package and choose 'All Tasks - Remove...'
vi - On the Remove Software window select 'Immediately uninstall the software from users and computers' and click 'OK'   (See the Special Considerations footnote)



viii - Close the Group Policy Management Editor
ix - Restart the affected Computers whilst on the Domain network for the Group Policy change to take effect

Special Considerations (optional as needed):  

 - As with all Group Policy changes, this will only take effect once the Machines are logging onto the Domain network and can contact a Domain Controller to pick up the Group Policy change.
As that is the case, if an old package and/or configuration is already applied to a machine, this will still apply to that machine until it is able to log onto the Domain network to pick up the changes to Group Policy

** Making changes in Active Directory can be extremely harmful on a company wide scale. If you are unsure in any way it is recommeded to contact Microsoft to aquire expert help on the matter **

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.