Was tun, wenn man die Zwei-Faktor-Authentifizierung möchte, aber keine Hardwaretokens hat und man dazu aufgefordert wird, optimistisch zu bleiben?
Diese Lösung ist nichts Außergewöhnliches, eher eine Mischung aus verschiedenen Ansätzen, die im Internet zu finden sind.
Also, es ist gegeben
Domain Active Directory.
Domänenbenutzer, die über VPN arbeiten, wie viele heutzutage.
Als VPN-Gateway dient Fortigate.
Das Speichern des Passworts für den VPN-Client ist durch die Sicherheitsrichtlinie verboten.
Die Richtlinie Fortinet in Bezug auf eigene Tokens kann man kaum als weniger geschäftstüchtig bezeichnen – es gibt 10 kostenlose Tokens, die anderen sind zu einem sehr unverschämten Preis erhältlich. RSASecureID, Duo und ähnliche habe ich nicht in Betracht gezogen, da ich Open-Source-Lösungen bevorzuge.
Vorbedingungen: Host *nix mit installiertem freeradius, sssd — in die Domain eingefügt, Domänenbenutzer können sich darauf problemlos authentifizieren.
Zusätzliche Pakete: shellinabox, figlet, freeeradius-ldap, Schriftart rebel.tlf aus dem Repository .
In meinem Beispiel – CentOS 7.8.
Die Logik funktioniert so: Beim Verbinden mit dem VPN muss der Benutzer seinen Domänen-Login und OTP anstelle des Passworts eingeben.
Konfiguration der Dienste
In /etc/raddb/radiusd.conf Nur der Benutzer und die Gruppe, unter deren Namen gestartet wird, ändern sich freeradius, da der Dienst radiusd in der Lage sein muss, Dateien in allen Unterverzeichnissen zu lesen /home/.
user = root
group = root
Damit Gruppen in den Einstellungen verwendet werden können Fortigate, muss übergeben werden Vendor Specific Attribute. Zu diesem Zweck erstelle ich in dem Verzeichnis raddb/policy.d eine Datei mit folgendem Inhalt:
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 := "Willkommen Admin"
}
}
else {
update reply {
&Reply-Message := "Nicht autorisiert für vpn"
}
reject
}
}
Nach der Installation freeradius-ldap wird im Verzeichnis raddb/mods-available eine Datei erstellt ldap.
Es muss ein symbolischer Link im Verzeichnis raddb/mods-enabled.
ln -s /etc/raddb/mods-available/ldap /etc/raddb/mods-enabled/ldaperstellt werden. Ich bringe ihren Inhalt in folgende 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 den Dateien raddb/sites-enabled/default und raddb/sites-enabled/inner-tunnel im Abschnitt authorize die Bezeichnung der Richtlinie hinzufügen, die verwendet werden soll — group_authorization. Wichtig ist, dass der Name der Richtlinie nicht durch den Dateinamen im Verzeichnis bestimmt wird policy.d, sondern durch eine Anweisung innerhalb der Datei vor den geschweiften Klammern.
Im Abschnitt authenticate müssen in diesen Dateien die Zeile pam.
In der Datei clients.conf die Parameter angeben, mit denen verbunden werden soll Fortigate:
client fortigate {
ipaddr = 192.168.1.200
secret = testing123
require_message_authenticator = no
nas_type = other
}
Konfiguration des Moduls pam.d/radiusd:
#%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
Standardoptionen für die Integration von freeradius mit google authenticator gehen davon aus, dass der Benutzer Anmeldeinformationen im Format eingibt: benutzername/passwort+OTP.
Angesichts der Vielzahl an Problemen, die durch die Verwendung der Standardkonfiguration entstehen könnten, freeradius mit Google Authenticator, wurde die Entscheidung getroffen, die Modulkonfiguration zu verwenden, pam um lediglich das Token zu prüfen. Google Authenticator.
Bei der Benutzerauthentifizierung passiert Folgendes:
- Freeradius überprüft, ob der Benutzer im Domänenverzeichnis und in einer bestimmten Gruppe vorhanden ist und führt bei Erfolg eine Überprüfung des OTP-Tokens durch.
Alles schien gut zu laufen, bis ich mir die Frage stellte: „Wie registriere ich OTP für über 300 Benutzer?“
Der Benutzer muss sich auf dem Server mit freeradius und seinem Benutzerkonto anmelden und die Anwendung Google Authenticator, starten, die den QR-Code für die Anwendung generiert. Hier kommt shellinabox in Kombination mit .bash_profile.
[root@freeradius ~]# yum install -y shellinabox
Die Konfigurationsdatei des Daemons befindet sich unter /etc/sysconfig/shellinabox.
Ich gebe dort den Port 443 an und kann mein eigenes Zertifikat angeben.
[root@freeradius ~]#systemctl enable --now shellinaboxdDer Benutzer muss lediglich den Link aufrufen, die Domain-Anmeldedaten eingeben und den QR-Code für die Anwendung erhalten.
Das Verfahren ist wie folgt:
- Der Benutzer meldet sich über den Browser am Gerät an.
- Überprüfung, ob der Benutzer zu einer Domäne gehört. Wenn nicht, werden keine weiteren Maßnahmen ergriffen.
- Wenn der Benutzer zu einer Domäne gehört, wird geprüft, ob er zur Administratorgruppe gehört.
- Wenn der Benutzer kein Administrator ist, wird geprüft, ob Google Authenticator eingerichtet ist. Falls nicht, wird ein QR-Code generiert und der Benutzer wird abgemeldet.
- Wenn der Benutzer kein Administrator ist und Google Authenticator eingerichtet ist, erfolgt lediglich die Abmeldung.
- Wenn der Benutzer Administrator ist, wird erneut geprüft, ob Google Authenticator eingerichtet ist. Falls nicht, wird ein QR-Code generiert.
Die gesamte Logik wird unter Verwendung von /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-Einstellung:
- Wir erstellen Radius-Server
- Wir erstellen die erforderlichen Gruppen, falls eine Zugangsbeschränkung nach Gruppen erforderlich ist. Der Gruppenname muss Fortigate mit der Gruppe übereinstimmen, die in Vendor Specific Attribute Fortinet-Group-Name.
- bearbeitet werden muss. SSL-Portale.
- Fügen Sie die Gruppen zu den Richtlinien hinzu.
Vorteile dieser Lösung:
- Es besteht die Möglichkeit der Authentifizierung per OTP mit einer Fortigate Open-Source-Lösung.
- Die Eingabe des Domainpassworts durch den Benutzer bei der VPN-Verbindung entfällt, was den Verbindungsprozess erleichtert. Ein 6-stelliger Code ist einfacher einzugeben als das, was durch die Sicherheitsrichtlinien vorgegeben ist. Infolgedessen verringert sich die Anzahl der Support-Tickets mit dem Thema: „Kann mich nicht mit VPN verbinden“.
P.S. Geplant ist, diese Lösung zu einer vollwertigen Zwei-Faktor-Authentifizierung mit Challenge-Response auszubauen.
Update:
Wie versprochen, habe ich es tatsächlich auf die Variante mit Challenge-Response umgesetzt.
Also:
In der Datei /etc/raddb/sites-enabled/default Abschnitt authorize es sieht folgendermaßen aus:
authorize {
filter_username
preprocess
auth_log
chap
mschap
suffix
eap {
ok = return
}
files
-sql
#-ldap
expiration
logintime
if (!State) {
if (&User-Password) {
# Wenn !State und User-Password (PAP), dann zwinge LDAP:
update control {
Ldap-UserDN := "%{User-Name}"
Auth-Type := LDAP
}
}
else {
reject
}
}
else {
# Wenn State, dann Proxy-Anfrage:
group_authorization
}
pap
}
Abschnitt authenticate hat jetzt folgendes Aussehen:
authenticate {
Auth-Type PAP {
pap
}
Auth-Type CHAP {
chap
}
Auth-Type MS-CHAP {
mschap
}
mschap
digest
# Versuche Authentifizierung mit einer direkten LDAP-Bindung:
Auth-Type LDAP {
ldap
if (ok) {
update reply {
# Erstelle ein zufälliges State-Attribut:
State := "%{randstr:aaaaaaaaaaaaaaaa}"
Reply-Message := "Bitte geben Sie den OTP ein"
}
# Rückgabe des Access-Challenge:
challenge
}
}
pam
eap
}
Jetzt erfolgt die Benutzerüberprüfung nach folgendem Algorithmus:
- Der Benutzer gibt die Domain-Anmeldedaten im VPN-Client ein.
- Freeradius überprüft die Gültigkeit des Kontos und des Passworts.
- Wenn das Passwort korrekt ist, wird eine Anfrage für ein Token gesendet.
- Es erfolgt eine Token-Überprüfung.
- Profit).
Quelle: habr.com
