Archives par étiquette : freeradius

Freeradius – ActiveDirectory

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.