Windows Local Users and Computers Out Of Domain
This tutorial will explain to you how to configure WebADM/OpenOTP servers and OpenOTP Credential Provider for Windows to authenticate local users using 2-factor authentication. We will also explain how to authenticate your users with OpenOTP and OpenOTP Credential Provider for Windows on a computer out of the domain.
Both scenarios require an LDAP server to store user metadata (Token metadata needs to be stored on a user account in WebADM even for local account authentication).
Each scenario require OpenOTP Credential Provider for Windows. The OpenOTP Credential Provider for Windows is a component that integrates the RCDevs OpenOTP one-time password authentication into the Windows login process. RCDevs OpenOTP Authentication Server is a WebApp that is tightly coupled to the RCDevs WebADM application server.
2. General Prerequisites
2.1 Prerequisites for Local Users Authentication
In this scenario, users credentials (Username and password) will be checked locally on the Windows machine and the OTP will be checked remotely on the OpenOTP server. To check the OTP password, OpenOTP has to know which user is trying to authenticate to be able to check Token metadata on the user account. That’s why a concordance between the local user and the LDAP user should be present. This concordance is done by the username information.
To have a WebADM instance working properly, an LDAP datastore configured with WebADM is mandatory. In this scenario, we will show you how to authenticate Windows local users with a WebADM/OpenOTP instance already configured with an LDAP server.
In this case, you have 2 possibilities:
Your local users on the Windows machines are also present in the LDAP server configured with WebADM. (with the same username on both side).
Your local users on the Windows machines are not present in the Active Directory (or other LDAP server) configured with WebADM. In this case, you will have to create the same user on the AD or through the WebADM interface. From an organizational point of view, you can create a fresh Organizational Unit, and create your “local users” in this OU to be able to identify “local and LDAP” users easily.
For local user accounts, the password is not inevitably the same on both side because the user password will not be checked by OpenOTP but locally by the Windows machine.
When this part is done, you can assign a Token to the user account. To do this, please follow this documentation.
3. Authenticate a Windows Local User
3.1 OpenOTP Credential Provider Configuration
You can follow the Credential Provider documentation, follow the installation and configuration part until the Configuration 3⁄4 screenshot. When you are at the 3⁄4 configuration step, you can find a setting named “Remote LDAP password Check”. Set this setting to “No” like below:
That means, the LDAP password will not be sent to OpenOTP and will be checked locally by the Windows machine.
Click on the
Finish buttons to finish the installation.
You can now continue with the WebADM configuration.
3.2 WebADM Configuration
3.2.1 Windows Machine In A Domain
If the Windows machine where the OpenOTP Credential Provider is installed is in a Windows domain, you have nothing to change in WebADM configuration. Your default configuration should be enough. If the authentication failed, please have a look in webadm logs, the most common error is “Domain not found”. If you encounter this error, please read the next part and add the domain found in the WebADM logs in the domain aliases field in your local domain configuration.
3.2.2 Windows Machine Out Of Domain
If the Windows machine where the OpenOTP Credential Provider is installed is NOT in a Windows domain, you have to perform some change through the WebADM GUI because, in the authentication request sent to OpenOTP, the domain name (by default) or the Workgroup (when no domain is configured on the target machine) is passed. In this scenario, the Workgroup will be passed in the authentication request.
To perform these changes, log in on the WebADM GUI as super_admin, click on the
Local Domains. Now you have 2 possibilities:
- Create a new WebADM domain, name it like your workgroup name and configure the user search base of your “local user”.
To perform this, click on
Add Domain button.
I named my new domain like my workgroup (by default it’s WORKGROUP), and I click on
You are now on the local domain configuration page.
The only settings who interest us here are the
User Search Base and the
Domain Name Aliases.
I previously configure a fresh Organizational Unit on my LDAP server and add my local user accounts in this fresh OU. I’ve decided to put my local users in a specific OU for an organizational point of view.
Here, my user search base will be
Domain Name Aliases field, I put every Windows workgroup of my machines.
If a Windows machine is in the workgroup named WORKGROUP4, I have to add WORKGROUP4 in the
Domain Name Aliases field else, you will have an error in WebADM logs saying “domain not found”.
This is the proper way to perform this integration.
The other way is simply to add every workgroup names in the default domain configuration. Be careful with the User Search Base.
4. Auto Create Local Account
OpenOTP Credential Provider for Windows is able to auto create a local account when you perform a login.
That means, when you configure this setting to
Yes, the Credential Provider will automatically create the same account locally if the account is not already present in case of the remote authentication is a success.