notempty
- Updated layout adjustment and screenshots
Introduction
If the OTP method is activated, login is only possible by entering a correct OTP.
notemptyAn exception on a per-user basis is not possible. This also applies to authentication at the user web interface and to SSL-VPN and IPSec-Xauth.
SSL-VPN:
Since re-authentication takes place every hour with the SSL-VPN, a new OTP must also be entered every hour.
Renegotiation can be increased accordingly or disabled completely.
Disabling it is, of course, not recommended. A change is made on the UTM for all SSL-VPN clients of this instance.
After the change, the SSL-VPN service is restarted automatically.
Saving the password in the SSL-VPN client is not possible because the password to be passed is composed of the static user password and the OTP.
If this is not available, access to the UTM is only possible with physical access directly at the device (keyboard and monitor at the UTM).
It is recommended to print this code for the administrators and file it to the documentation as described in OTP Secret.
The time of the UTM system can be checked in three ways:
- Through the administration web interface: the time is in the widget selection if it is not expanded, or in the Network menu under the Server Settings menu item in the Time settings section.
- Using the CLI with the command system date get
- Using the root console with the command date
The system time can then be set using the following options:
- Via the administration web interface in the Network menu under the Server settings section in the Time settings section.
- Via the CLI with the command system date set date then with space separated the current date and time in the format YYYY-MM-DD hh:mm:ss
User authentication via the UTM with Active Directory via OTP
Attributes in Active Directory
The UTM is connected to the Active Directory. Instructions for this can be found in this Wiki article Active Directory Connection. An unused attribute in the Active Directory schema is required. The secret code is stored in it.
A list of attributes can be found in the Active Directory under Active Directory Users and Computers.
But for this it is necessary to activate the menu item Advanced Features under View.
Open "Properties" for the desired user. Switch to the tab Attribute Editor. There is the list with the attributes.
In this example the attributes extensionAttribute1 - 15 are available. Select one of these attributes by storing the OTP secret code for the user.
Enter attribute in the UTM
The attribute of the AD with the OTP secret code must be entered into the UTM.
In the menu switch to the dialog Extended.
| Caption | Value | Description |  |
|---|---|---|---|
| OTP-Attribute: | extensionAttribute10 | The attribute selected in AD is entered. The value entered there is simply overwritten. | |
Generate OTP secret code
Since the AD attribute extensionAttribute10 should now contain a 16-digit base32 key code, this must be generated somehow. This can be done by the UTM.
Simply create a user in the menu Authentication under User - here with the name otp_dummy_user. This user does not have to belong to a group and does not need any permissions.
If this user is edited again, the tab OTP is located on the right side.
On the one hand, a secret code created by random generator is already located here, on the other hand also a QR code created from this.
The secret code can simply be copied and pasted into the Active Directory attribute.
This of course also applies to a 40-digit HEX(60) key of a hardware token.
Please note:
When using a hardware token, the prefix (e.g. hex(60) )must be specified in the AD attribute before the PSK. .
The QR code can be saved as an image simply by clicking the right mouse button, and then send it to the user in a suitable way. Instructions on how to set this up in a software token such as Google Authenticator can be found here.
Of course, each user should get his own OTP key.
A new randomly generated key and QR code is created simply by clicking the 
button.
Create a group for AD authentication
The users in question must be grouped in the Active Directory, as individual users cannot be detected by the UTM.
Finally, a user group must be created on the UTM that controls the permissions of the OTP-AD group on the UTM.
This in turn is then linked to the Active Directory group in question.
Now the user can log on to the service of the UTM with his Windows domain name, password and the additional OTP password, which he receives via the OTP token, without having to be additionally entered as a local user on the UTM.