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 = false
Ré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.