This solution is not something super original, but rather a mix of different solutions found on the Internet.
So, given
Active Directory domain .
Domain users using a VPN, like many today. Fortigate
acts as a VPN gateway . Saving the password for the VPN client is prohibited by security policy. Fortinet's policy regarding its own tokens cannot be called less than redneck - there are already 10 free tokens, the rest are at a very non-kosher price. RSASecureID, Duo and the like have not been considered, because I want open source. Prerequisites: * nix host with freeradius installed , sssd - entered into the domain, domain users can easily authenticate on it. Additional packages:
shellinabox , figlet , freeeradius-ldap , rebel.tlf font from https://github.com/xero/figlet-fonts repository .
In my example - CentOS 7.8.
The logic of work is as follows: when connecting to a VPN, a user must enter a domain login and OTP instead of a password.
Setting up services
In /etc/raddb/radiusd.conf, only the user and group, under which freeradius starts , is changed , since the radiusd service must be able to read files in all subdirectories of / home / .
user = root
group = root
To be able to use groups in the Fortigate settings , you need to pass the Vendor Specific Attribute . To do this, in the raddb / policy.d directory, create a file with the following contents:
group_authorization {
if (&LDAP-Group[*] == "CN=vpn_admins,OU=vpn-groups,DC=domain,DC=local") {
update reply {
&Fortinet-Group-Name = "vpn_admins" }
update control {
&Auth-Type := PAM
&Reply-Message := "Welcome Admin"
}
}
else {
update reply {
&Reply-Message := "Not authorized for vpn"
}
reject
}
}
After installing freeradius-ldap in directory raddb / mods-available file is created the ldap .
You need to create a symbolic link to the raddb / mods-enabled directory .
ln -s /etc/raddb/mods-available/ldap /etc/raddb/mods-enabled/ldapI bring its contents to this form:
ldap {
server = 'domain.local'
identity = 'CN=freerad_user,OU=users,DC=domain,DC=local'
password = "SupeSecretP@ssword"
base_dn = 'dc=domain,dc=local'
sasl {
}
user {
base_dn = "${..base_dn}"
filter = "(sAMAccountname=%{%{Stripped-User-Name}:-%{User-Name}})"
sasl {
}
scope = 'sub'
}
group {
base_dn = "${..base_dn}"
filter = '(objectClass=Group)'
scope = 'sub'
name_attribute = cn
membership_filter = "(|(member=%{control:Ldap-UserDn})(memberUid=%{%{Stripped-User-Name}:-%{User-Name}}))"
membership_attribute = 'memberOf'
}
}In the files raddb / sites-enabled / default and raddb / sites-enabled / inner-tunnel, in the authorize section, I add the name of the policy that will be used - group_authorization. An important point - the name of the policy is determined not by the name of the file in the policy.d directory , but by the directive inside the file before the curly braces.
In the authenticate section of the same files, uncomment the pam .
In the clients.conf file , write the parameters with which Fortigate will connect :
client fortigate {
ipaddr = 192.168.1.200
secret = testing123
require_message_authenticator = no
nas_type = other
}
Pam.d / radiusd module configuration :
#%PAM-1.0
auth sufficient pam_google_authenticator.so
auth include password-auth
account required pam_nologin.so
account include password-auth
password include password-auth
session include password-auth
The default options for implementing the freeradius bundle with the google authenticator involve the user entering credentials in the format: username / password + OTP .
After presenting the number of curses that will fall on your head, in the case of using the default freeradius bundle with Google Authenticator , it was decided to use the pam module configuration so as to check only the Google Authenticator token .
When a user connects, the following happens:
- Freeradius checks the presence of the user in the domain and in a specific group and, if successful, checks the OTP token.
Everything looked good enough until I thought, "How can I register OTP for 300+ users?"
The user must log into the server with freeradius and under his account and run the Google authenticator application , which will generate a QR code for the application for the user. This is where shellinabox comes in handy in combination with .bash_profile .
[root@freeradius ~]# yum install -y shellinabox
The daemon configuration file is located in / etc / sysconfig / shellinabox .
I indicate port 443 there and you can specify your certificate.
[root@freeradius ~]#systemctl enable --now shellinaboxdThe user only needs to follow the link, enter domain credits and receive a QR code for the application.
The algorithm is as follows:
- The user logs into the machine through a browser.
- The domain user is checked. If not, no action is taken.
- If the user is a domain user, membership in the Administrators group is checked.
- If not admin, it checks if Google Autheticator is configured. If not, then a QR code and user logout is generated.
- If not an admin and Google Authenticator is configured, then just logout.
- If the admin, then again check Google Authenticator. If not configured, then a QR code is generated.
All logic is done using /etc/skel/.bash_profile .
cat /etc/skel/.bash_profile
# .bash_profile
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
# User specific environment and startup programs
# Make several commands available from user shell
if [[ -z $(id $USER | grep "admins") || -z $(cat /etc/passwd | grep $USER) ]]
then
[[ ! -d $HOME/bin ]] && mkdir $HOME/bin
[[ ! -f $HOME/bin/id ]] && ln -s /usr/bin/id $HOME/bin/id
[[ ! -f $HOME/bin/google-auth ]] && ln -s /usr/bin/google-authenticator $HOME/bin/google-auth
[[ ! -f $HOME/bin/grep ]] && ln -s /usr/bin/grep $HOME/bin/grep
[[ ! -f $HOME/bin/figlet ]] && ln -s /usr/bin/figlet $HOME/bin/figlet
[[ ! -f $HOME/bin/rebel.tlf ]] && ln -s /usr/share/figlet/rebel.tlf $HOME/bin/rebel.tlf
[[ ! -f $HOME/bin/sleep ]] && ln -s /usr/bin/sleep $HOME/bin/sleep
# Set PATH env to <home user directory>/bin
PATH=$HOME/bin
export PATH
else
PATH=PATH=$PATH:$HOME/.local/bin:$HOME/bin
export PATH
fi
if [[ -n $(id $USER | grep "domain users") ]]
then
if [[ ! -e $HOME/.google_authenticator ]]
then
if [[ -n $(id $USER | grep "admins") ]]
then
figlet -t -f $HOME/bin/rebel.tlf "Welcome to Company GAuth setup portal"
sleep 1.5
echo "Please, run any of these software on your device, where you would like to setup OTP:
Google Autheticator:
AppStore - https://apps.apple.com/us/app/google-authenticator/id388497605
Play Market - https://play.google.com/stor/apps/details?id=com.google.android.apps.authenticator2&hl=en
FreeOTP:
AppStore - https://apps.apple.com/us/app/freeotp-authenticator/id872559395
Play Market - https://play.google.com/store/apps/details?id=org.fedorahosted.freeotp&hl=en
And prepare to scan QR code.
"
sleep 5
google-auth -f -t -w 3 -r 3 -R 30 -d -e 1
echo "Congratulations, now you can use an OTP token from application as a password connecting to VPN."
else
figlet -t -f $HOME/bin/rebel.tlf "Welcome to Company GAuth setup portal"
sleep 1.5
echo "Please, run any of these software on your device, where you would like to setup OTP:
Google Autheticator:
AppStore - https://apps.apple.com/us/app/google-authenticator/id388497605
Play Market - https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2&hl=en
FreeOTP:
AppStore - https://apps.apple.com/us/app/freeotp-authenticator/id872559395
Play Market - https://play.google.com/store/apps/details?id=org.fedorahosted.freeotp&hl=en
And prepare to scan QR code.
"
sleep 5
google-auth -f -t -w 3 -r 3 -R 30 -d -e 1
echo "Congratulations, now you can use an OTP token from application as a password to VPN."
logout
fi
else
echo "You have already setup a Google Authenticator"
if [[ -z $(id $USER | grep "admins") ]]
then
logout
fi
fi
else
echo "You don't need to set up a Google Authenticator"
fi
Fortigate setup:
- Create a Radius Server
- We create the necessary groups, if necessary, differentiate access by groups. The group name on Fortigate must match the group that is passed in the Vendor Specific Attribute Fortinet-Group-Name .
- Editing the required SSL portals.
- Add groups to policies.
The advantages of this solution:
- There is a possibility of OTP authentication on Fortigate open source solution.
- It excludes the user entering the domain password when connecting via VPN, which somewhat simplifies the connection process. The 6-digit password is easier to enter than the security policy. As a result, the number of tickets with the subject: "Can't connect to VPN" decreases.
PS We plan to screw this solution up to full-fledged two-factor authorization with challenge-response.
Update:
As promised, I finished it up to the challenge-response option.
So:
In the / etc / raddb / sites-enabled / default file, the authorize section looks like this:
authorize {
filter_username
preprocess
auth_log
chap
mschap
suffix
eap {
ok = return
}
files
-sql
#-ldap
expiration
logintime
if (!State) {
if (&User-Password) {
# If !State and User-Password (PAP), then force LDAP:
update control {
Ldap-UserDN := "%{User-Name}"
Auth-Type := LDAP
}
}
else {
reject
}
}
else {
# If State, then proxy request:
group_authorization
}
pap
}
The authenticate section now looks like this:
authenticate {
Auth-Type PAP {
pap
}
Auth-Type CHAP {
chap
}
Auth-Type MS-CHAP {
mschap
}
mschap
digest
# Attempt authentication with a direct LDAP bind:
Auth-Type LDAP {
ldap
if (ok) {
update reply {
# Create a random State attribute:
State := "%{randstr:aaaaaaaaaaaaaaaa}"
Reply-Message := "Please enter OTP"
}
# Return Access-Challenge:
challenge
}
}
pam
eap
}
Now the user is verified according to the following algorithm:
- User enters domain credits in VPN client.
- Freeradius checks the validity of the account and password
- If the password is correct, then a request for a token is sent.
- The token is verified.
- Profit).