eduroam не поставя изисквания за използването на конкретна реализация на
RADIUS сървър. Достатъчно е тя да съответства на стандартите, дефинирани в
RFC 2865 и RFC 2869,
да поддържа 802.1X аутентификация и методите (поне) TTLS и PEAP. В настоящия документ е използван
за пример FreeRADIUS (версия 1.0.2) – мощен, с широки възможности
за конфигуриране и свободно достъпен RADIUS сървър.
Най-новата версия на FreeRADIUS може да бъде изтеглена от тук.
Инсталирането става по стандартната за базирани на GNU инструментите програми процедура: ./configure *
make
make install
* Възможно е да се наложи използването на определени
опции в зависимост от желаната функционалност.
Всички конфигурационни файлове на FreeRADIUS се съхраняват в директорията
[PREFIX]/etc/raddb (обикновено /etc/raddb
или /usr/local/etc/raddb). Конфигурирането на сървъра е донякъде сложно,
поради наличието на голямо количество файлове (част от които оставени за съвместимост с по-ранни версии), но не би трябвало
да представлява твърде голям проблем. Ключовите стъпки са следните:
1. Дефиниране на клиентите.
Точките за безжичен достъп, RADIUS сървърите и евентуалните други RADIUS клиенти са
дефинирани във файла clients.conf. По подразбиране там фигурира само
локалната машина. Добавянето на Access Points става по следния начин:
########################
# APs and other devices
########################
client ‹DNS name/IP address 1› {
secret = ‹shared secret 1›
shortname = ‹short name 1›
nastype = cisco
}
[...]
client ‹DNS name/IP address N› {
secret = ‹shared secret N›
shortname = ‹short name N›
nastype = cisco
}
nastype може да има и друга стойност, ако използвания АР
не е Cisco (допустимите типове описани в коментарите към файла). При добавяне на ключ с възможности за 802.1Х
аутентификация nastype се пропуска.
# Network Access Server 1
client ‹DNS name/IP address X› {
secret = ‹shared secret X›
shortname = ‹short name X›
}
Препоръчва се използването на различна споделена ключова дума
(secret) за всяко отделно устройство.
Добавянето на TLD сървърите за зоната .bg
става по следния начин:
########################
# RADIUS servers
########################
# Top-Level Radius Server 1
client btlr1.eduroam.acad.bg {
secret = ‹TLD shared secret 1›
shortname = btlr1
nastype = other
}
# Top-Level Radius Server 2
client btlr2.eduroam.acad.bg {
secret = ‹TLD shared secret 2›
shortname = btlr2
nastype = other
}
Споделените ключови думи за комуникация с тях следва да бъдат уговорени с
Националния роуминг център.
По аналогичен начин могат да бъдат добавени и други свързани RADIUS сървъри. Препоръчва се
също loopback адреса да бъде оставен за тестване:
########################
# Loopback (for testing)
########################
client 127.0.0.1 {
secret = ‹shared secret for Loopback›
shortname = loopback
nastype = other
}
2. Дефиниране на областите (realms).
RADIUS заявките от локални потребители следва да бъдат обслужени локално, докато заявки от външни
потребители следва да бъдат пренасочени към националните RADIUS сървъри (които съответно могат да ги пренасочат и към
европейските TLD сървъри, ако това е необходимо). Този механизъм на пренасочване (proxying) се конфигурира във
файла proxy.conf:
realm domain.bg {
}
realm subdomain.domain.bg {
}
realm NULL {
}
realm DEFAULT {
type = radius
authhost = btlr1.eduroam.acad.bg:1812
accthost = btlr1.eduroam.acad.bg:1813
secret = ‹TLD shared secret 1›
ldflag = round_robin
nostrip
}
realm DEFAULT {
type = radius
authhost = btlr2.eduroam.acad.bg:1812
accthost = btlr2.eduroam.acad.bg:1813
secret = ‹TLD shared secret 2›
ldflag = round_robin
nostrip
}
На променливата ldflag се присвоява
стойност round_robin с цел по-равномерно натоварване на
TLD сървърите. nostrip пък указва да не се извършва изчистване
на домейн частта от потребителските имена, защото тя е важна за правилното адресиране на заявките.
В този файл също така трябва да се промени параметъра
dead_time в конструкцията proxy
server {} от 120 на 0:
proxy server {
[...]
dead_time = 0
[...]
}
3. Обслужване на аутентификацията и областите.
Един от най-важните конфигурационни файлове е users.
Той съдържа статично дефинирани потребители (най-често за тестване, но може и работни, когато броят им е малък),
определя как биват обслужвани заявките и чрез кои модули следва да бъдат извършвани аутентификациите.
##########################################################
# Users with a NULL realm should be rejected
##########################################################
DEFAULT Realm == NULL, Auth-Type := Reject
##########################################################
# Static test account for the NREN
##########################################################
‹name› Realm == domain.bg, User-Password == "‹password›"
Обикновени потребители могат да се добавят по подобие на тестовия акаунт.
4. Главна конфигурация на RADIUS сървъра.
Основният конфигурационен файл на FreeRADIUS е radiusd.conf.
Той определя кои модули да бъдат използвани и как да се извършва аутентификацията по принцип. Ключовите записи, за
които трябва да се провери дали присъстват във файла от дистрибуцията са:
# authorize: what to do with incoming auth requests:
authorize {
preprocess # optional: packet mangling if necessary
auth_log # log the packet
suffix # look up its realm; proxy if realm is configured for that
files # if the request wasn't proxied, look into the users file
}
# authenticate: supported methods; none on TLD servers because
# EAP is detected automatically and nothing else is allowed
authenticate {
}
# preacct: what to do with incoming accounting packets
preacct {
preprocess # optional: packet mangling if necessary
acct_unique # optional: generate a unique accounting handle
suffix # look up realm and proxy packets according to realm config
}
accounting { # the TLD server only is for proxying
# accounting, doesn't handle packets itself
}
post-auth {
reply_log
}
pre-proxy {
pre_proxy_log
}
# post-proxy: what to do with replies we got from a remote
# server
post-proxy {
post_proxy_log # log them
attr_filter # only allow the attributes defined in attrs to pass
}
5. Настройване на EAP (Extensible Authentication Protocol).
EAP е основният протокол за аутентификация, който RADIUS използва.
Неговите настройки, включително различните методи за аутентификация, са отделени във файла
eap.conf. Поддръжката на методите EAP-PEAP/MSCHAPv2,
EAP-TTLS/EAP-MD5-Challenge, EAP-TTLS/MSCHAPv2, EAP-TTLS/MSCHAP, EAP-TTLS/PAP, EAP-TTLS/CHAP
с метод по подразбиране EAP-PEAP/MSCHAPv2 предполага следното примерно съдържание:
eap {
default_eap_type = peap
timer_expire = 60
ignore_unknown_eap_types = no
cisco_accounting_username_bug = no
# Supported EAP-types
md5 {
}
leap {
}
gtc {
- auth_type = PAP
}
tls {
- private_key_password = whatever
- private_key_file = ${raddbdir}/certs/cert-srv.pem
- certificate_file = ${raddbdir}/certs/cert-srv.pem
- CA_file = ${raddbdir}/certs/demoCA/cacert.pem
- dh_file = ${raddbdir}/certs/dh
- random_file = ${raddbdir}/certs/random
}
ttls {
- default_eap_type = md5
- copy_request_to_tunnel = yes
- use_tunneled_reply = yes
}
peap {
- default_eap_type = mschapv2
}
mschapv2 {
}
}
6. Тестване на конфигурацията.
Тестването може да се раздели на две части – тестване на локалната работоспособност на
RADIUS сървъра (т.е. способността му да аутентифицира правилно локални потребители) и тестване в
рамките на eduroam йерархията (коректна аутентификация както на външни потребители от
локалния сървър, така и на локални потребители в чужди RADIUS области).
| 
English
