Cet article montre les étapes nécessaires à l’utilisation de Freeradius sur une Debian Wheezy pour authentifier les utilisateurs sur un serveur ActiveDirectory (Windows Server 2012).
Les requêtes EAP seront encapsulées en TTLS ou en PEAP, l’authentification sera effectuée via un challenge EAP MSCHAP v2.
La partie proxy sera aussi configurée pour permettre l’authentification via d’autres serveurs radius disposant de leurs propres bases d’utilisateurs.
Informations générales
- domaine DNS : test.example.org
- domaine NetBios : TEST
- nom du serveur AD : ad.test.example.org
- adresse du DNS de l’AD : 10.0.0.1
Une parfaite résolution DNS est essentielle à tout système, en particulier quand il y a un annuaire ActiveDirectory. On modifie donc les paramètres DNS de la Debian pour utiliser le DNS de l’AD.
#/etc/hosts
127.0.0.1 radius.test.example.org localhost radius
#/etc/resolv.conf
domain test.example.org
search test.example.org
nameserver 10.0.0.1
De même une synchronisation horaire précise est essentielle. On modifie donc la configuration NTP pour utiliser le serveur AD comme source de temps. Ici j’utilise openntp :
#/etc/openntpd/ntpd.conf
servers test.example.org
J’utilise le nom du domaine de l’AD pour profiter du RR DNS.
On redémarre le serveur pour bien prendre en compte les modifications.
Intégration du serveur dans l’ActiveDirectory
Installation des paquets
aptitude install samba winbind samba-common-bin krb5-user
Kerberos
L’utilisation de Kerberos n’est pas indispensable pour joindre une machine à l’AD, mais elle est recommandée.
Configuration
La casse est importante dans le protocole Kerberos, par convention on utilise le nom DNS en majuscule pour les royaumes.
#/etc/krb5.conf
[libdefaults]
default_realm = TEST.EXAMPLE.ORG
krb4_config = /etc/krb.conf
krb4_realms = /etc/krb.realms
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true
v4_instance_resolve = false
v4_name_convert = {
host = {
rcmd = host
ftp = ftp
}
plain = {
something = something-else
}
}
fcc-mit-ticketflags = true
[realms]
TEST.EXAMPLE.ORG = {
kdc = ad.test.example.org:88
admin_server = ad.test.example.org
default_domain = test.example.org
}
[domain_realm]
.test.example.org = TEST.EXAMPLE.ORG
test.example.org = TEST.EXAMPLE.ORG
[login]
krb4_convert = true
krb4_get_tickets = falseRécupération d’un ticket Kerberos
kinit administrator@TEST.EXAMPLE.ORG
Vérification du ticket
klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: administrator@TEST.EXAMPLE.ORG
[...]
Samba
Configuration
#/etc/samba/smb.conf
[global]
workgroup = TEST
server string = %h server
dns proxy = no
log file = /var/log/samba/log.%m
max log size = 1000
syslog = 0
panic action = /usr/share/samba/panic-action %d
security = ads
realm = TEST.EXAMPLE.ORG
password server = ad.test.example.org
winbind use default domain = yes
domain master = no
local master = no
preferred master = no
winbind enum groups = yes
winbind enum users = yes
winbind use default domain = no
encrypt passwords = true
Redémarrage de Samba
service samba restart
Intégration dans l’AD
net ads join -U administrator
Si le ticket Kerberos est valide, vous devriez obtenir le message suivant :
Using short domain name -- TEST
Joined 'RADIUS' to realm 'test.example.org'
Dans le cas contraire, ou en l’absence de Kerberos, vous obtiendrez ceci :
Using short domain name -- TEST
Joined 'RADAD' to realm 'test.example.org'
DNS Update for radius.test.example.org failed: ERROR_DNS_GSS_ERROR
DNS update failed!
Les 2 dernières lignes indiquent que l’ajout du serveur dans le DNS de l’AD a échoué, cela n’a rien d’anormal si vous n’utilisez pas Kerberos ou si vos DNS n’acceptent pas la création dynamique d’objets, il vous suffit d’aller créer manuellement une entrée pour votre serveur Linux dans le DNS de l’AD.
Si vous obtenez autre chose, c’est probablement qu’il y a un problème de résolution de nom ou de configuration.
Redémarrage de WinBind
service winbind restart
Tests de la liaison avec l’annuaire
Test de la connexion RCP :
wbinfo -t
checking the trust secret for domain TEST via RPC calls succeeded
Lister les utilisateurs de l’annuaire (attention si vous avez un grand nombre de comptes) :
wbinfo -u
TESTadministrator
TESTguest
TESTkrbtgt
[...]
Test d’authentification :
wbinfo -a testuser%passtest
plaintext password authentication failed
Could not authenticate user testuser%passtest with plaintext password
challenge/response password authentication succeeded
Les 2 premières lignes indiquent que l’authentification en clair a échoué, ce qui est normal, c’est la dernière ligne qui est importante, elle indique que l’authentification par Challenge/Response est valide.
Freeradius
Installation des paquets
aptitude install freeradius freeradius-utils
Autorisation pour le ntlm
L’authentification sur l’annuaire est effectuée en NTLM, il faut donc que le service radius ait le droit d’utiliser winbind.
addgroup freerad winbindd_priv
Configuration de Freeradius
La configuration de Freeradius est très complexe car très complète. Elle couvre par défaut une très grande variété de cas d’utilisation. Il est donc recommandé de ne pas la modifier, mais juste de l’adapter.
Dans le cas présent, j’ai choisi de ne pas respecter cette recommandation pour éviter de poster plus de 5000 lignes de configuration, c’est environ le nombre de lignes des différents fichiers de configuration.
Il n’y a normalement que 4 fichiers à modifier :
- /etc/freeradius/eap.conf : il contient la configuration des méthodes EAP
- /etc/freeradius/modules/mschap : c’est ce module qui fera l’authentification sur l’AD
- /etc/freeradius/proxy.conf : sert à relayer les requêtes sur d’autres serveurs radius
- /etc/freeradius/clients.conf : c’est ici que sont déclarés les NAS autorisés à utiliser le radius
Configuration de l’EAP
#/etc/freeradius/eap.conf
eap {
default_eap_type = ttls
timer_expire = 60
ignore_unknown_eap_types = no
cisco_accounting_username_bug = no
max_sessions = 4096
tls {
certdir = ${confdir}/certs
cadir = ${confdir}/certs
private_key_password = whatever
private_key_file = ${certdir}/server.key
certificate_file = ${certdir}/server.pem
CA_file = ${cadir}/ca.pem
dh_file = ${certdir}/dh
random_file = /dev/urandom
CA_path = ${cadir}
cipher_list = "DEFAULT"
make_cert_command = "${certdir}/bootstrap"
ecdh_curve = "prime256v1"
cache {
enable = no
lifetime = 24 # hours
max_entries = 255
}
}
ttls {
default_eap_type = mschapv2
copy_request_to_tunnel = yes
use_tunneled_reply = yes
virtual_server = "inner-tunnel"
}
peap {
default_eap_type = mschapv2
copy_request_to_tunnel = yes
use_tunneled_reply = yes
virtual_server = "inner-tunnel"
}
mschapv2 {
}
}Configuration du MS-CHAP v2
#/etc/freeradius/modules/mschap
mschap {
use_mppe=yes
require_encryption = yes
require_strong = yes
with_ntdomain_hack = yes
ntlm_auth = "/usr/bin/ntlm_auth --request-nt-key --username=%{%{Stripped-User-Name}:-%{%{User-Name}:-None}} --challenge=%{%{mschap:Challenge}:-00} --nt-response=%{%{mschap:NT-Response}:-00}"
}Dans certaines configuration, il faudra ajouter votre nom de domaine à la commande ntlm_auth avec la directive suivante : –domain=TEST
Configuration du proxy radius
#/etc/freeradius/proxy.conf
proxy server {
default_fallback = no
}
realm NULL {
}
realm LOCAL {
}
realm example.org {
authhost = LOCAL
accthost = LOCAL
}
realm test.example.org {
authhost = LOCAL
accthost = LOCAL
}
realm DEFAULT {
type = radius
authhost = 1.1.1.1
accthost = 1.1.1.1
secret = proxysharedsecret
nostrip
}Les requêtes des utilisateurs précisant un domaine d’authentification qui n’est pas le notre seront transmises à un autre serveur radius (1.1.1.1 dans l’exemple).
Déclaration des NAS
On déclare ici les NAS qui pourront interroger notre serveur radius
#/etc/freeradius/clients.conf
client 10.1.1.1/32 {
secret = secretnas1
shortname = nas1
}
client localhost {
ipaddr = 127.0.0.1
secret = testing123
require_message_authenticator = no
nastype = other
}Redémarrage du service
service freeradius restart
Test local
radtest -t mschap testuser passtest 127.0.0.1 0 testing123
Sending Access-Request of id 83 to 127.0.0.1 port 1812
User-Name = "testuser"
NAS-IP-Address = 127.0.1.1
NAS-Port = 0
Message-Authenticator = 0x00000000000000000000000000000000
MS-CHAP-Challenge = 0xe44df59956405035
MS-CHAP-Response = 0x0001000000000000000000000000000000000000000000000000e7cb832715175c312efcb8a07922a1a23c82c715773e9216
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=83, length=84
MS-CHAP-MPPE-Keys = 0x0000000000000000490de11896511cd8de93afd472151ddd0000000000000000
MS-MPPE-Encryption-Policy = 0x00000002
MS-MPPE-Encryption-Types = 0x00000004
Conclusion
Je n’ai pas couvert le détail de la configuration, il s’agit encore une fois d’une prise de notes mise en forme.
Il faudrait compléter cette installation avec le paramétrage des journaux, l’accounting et la sécurisation de la configuration avant d’envisager une mise en production. Peut être dans un prochain article.