RADIUS Сервери

Во овој дел се дадени основни упатства за конфигурирање на различни RADIUS имплементации, почнувајќи со Radiator како институционален сервер, потоа Freeradius, Navis, Vital, АА и MS -IAS.

Бидејќи eduroam инфраструктурата се базира на RADIUS сервери, следната слика која го прикажува протокoт на пораки во еден институцонален RADIUS сервер би можелa да бидe кориснa.

Слика 1: Проток на порака во RADIUS сервер - систем за менаџмент на идентитет.

1. Radiator институционален сервер

Пример скрипта за конфигурација на Radiator институционален сервер е достапна на следниов линк: http://www.eduroam.org/downloads/docs/eduroamcookbook-scripts.zip.

2. FreeRadius институционален сервер

2.1 Поставување на FreeRADIUS

FreeRADIUS (http://www.freeradius.org) е многу моќен, конфигурабилен, лесно и слободно достапен Radius сервер со отворен код. Пример конфигурациите се базирани на Free RADIUS 2.0.3. RPM инсталациони пакети кои се достапни за разни дистрибуции под името freeradius или freeradius-server. Користењето на верзиите 1.x не е препорачливо. Пожелно е да се симне најновата верзија од FreeRADIUS веб сајтот [www.freeradius.org] и да се искомпајлира од овие извори.

Сите конфигурациски датотеки за FreeRADIUS се сместени во /etc/raddb директориумот. Конфигурацијата се состои од повеќе датотеки.

Најважните за eduroam сервис провајдерот (SP) се:

• clients.conf - дефинирање на клиентски уреди кои се поврзуваат на серверот (види 2.2)
• proxy.conf - дефинирање на други сервери и области (realms) за проксирање (види 2.3)
• sites-enabled/eduroam - дефиниција на виртуелен сервер (види 2.4)
• radiusd.conf - главна конфигурациската датотека (види 2.5)

За eduroam провајдерот на идентитет (IdP), дополнително, важна е следнава датотека :

• eap.conf - дефинирање на EAP автентикацијата (види 2.6)

Во овој дел е дадена пример конфигурација на сервер со следниве карактеристики:

• Се однесува како Service Provider
  - Прифаќа барања од пристапни точки.
  - Проксира барања до IdPs во eduroam инфраструктурата.
• Се однесува како Identity Provider
  - Користи EAP-TTLS/PAP и PEAP/MSCHAPv2 истовремено за автентикација на клиентите.
  - Опционално: надворешениот идентитет го подесува во anonymous@domain.tld.
• Внесени се неколку статички тест кориснички сметки во една датотека.
• Корисниците се автентицираат преку LDAP именик, со користење на eduPerson шемата. Корисничките имиња се чуваат во eduPersonPrincipalName атрибутот, а лозинките во чист текстуален формат во userPassword атрибутот.
• Податоците од аccounting-от се чуваат во MySQL база на податоци
• Опционално, може да биде поставена скрипта за ажурирање на сметководствената (accounting>) SQL табела со информации од доделени IP адреси.

2.2 Дефинирање на клиенти - Пристапни точки и RADIUS сервери во clients.conf

Пристапните точки, RADIUS серверите и други RADIUS клиенти (NAS уреди, RADIUS скрипти за тестирање) се дефинирани во датотеката /etc/raddb/clients.conf. Оваа датотека ги листа уредите кои може да испратат барања до серверот. Еден пример е даден подолу, а може да се симне и од http://www.eduroam.org/downloads/docs/eduroam-cookbookscripts.zip.

Овој пример дефинира група на пристапни точки со заедничкa лозинка (shared secret): 158.64.254.0 - 158.64.254.7 (поради мрежна маска = 29) се дефинираaт како клиенти и се доделува лозинката verysharedsecret. Овие клиенти ќе се појават во датотеките за евиденција со нивното заедничко кратко име eduroam-ap-v4. Сите дојдовни побарувања од страна на овие клиенти ќе бидат опслужени од страна на виртуелниот сервер eduroam.

client descriptivename {

ipaddr = 158.64.254.0
netmask = 29
secret = verysharedsecret
require_message_authenticator = no
shortname = eduroam-ap-v4
nastype = other
virtual_server = eduroam

}

За прилагодување на датотеката на конкретна конфигурација, потребно е да се коментираат или пак да се избришат постоечките записи и да се додадат пристапните точки:

Може да се додадат произволен број на вакви клиентски секции во датотеката. Преку задавање на мрежна маска = 32 може да се дефинираат и индивидуални IP адреси со сопствени лозинки.

За Cisco пристапни точки, nastype се поставува на "cisco", за други NAS уреди вредноста треба да се постави поинаку. Ако нема соодветна вредност за nastype за дадена пристапната точка, тогаш nastype треба да биде поставено на "other". Препорачливо е да се користат различни лозинки за секоја пристапна точка. Лозинката мора да биде внесена и во пристапната точка. За случајно генерирње на лозинка може да се користи mkpasswd. Лозинките во RADIUS се прилично слаби, па од криптографски причини, се препорачуваат лозинки со должина од 16 бајти.

Бидејки на поврзан RADIUS сервер се гледа како на RADIUS клиентски уред, исто така треба да се додадат записи и за поврзаните RADIUS сервери во оваа датотека. Затоа е потребно за сите сервери да се знаат или нивните DNS имиња или нивните IP адреси. За институционален сервер треба да се додадат барем неговите uplink RADIUS сервери од федерацијата (во повеќето случаи, тоа се федерациските RADIUS сервери (FLRS)). Клиентските секции исто така може да дефинираат и IPv6 клиенти. На пример, во пример датотеката од посочената архива (http://www.eduroam.org/downloads/docs/eduroam-cookbook-scripts.zip) дефинирани се два FLRS uplink-ови (FLRS серверите на Луксембург) - еден за IPv6 и еден за IPv4 клиенти.

Дефинирањето на loopback клиент може да биде корисно за извршување тест-скрипти, па дури е и задолжително за тунелирани автентикациски методи како TTLS и PEAP, па потребно е параметрите да се постават правилно. Localhost лозинката не треба да се сподели со никого, тaа е таму само проформа и дури може да се остави стандардната "testing123". Пример може да се најде во архивата http://www.eduroam.org/downloads/docs/eduroam-cookbook-scripts.zip.

2.3 Конфигурирање на управувањето со областите (realms) и проксирањето: proxy.conf

RADIUS барањата од локалните корисници мора да се третираат локално, додека пак барањата на роаминг корисниците мора да се проксираат до националниот FLRS RADIUS сервер. За дадена организација со домен domain.tld, сите барања за *.domain.tld се препраќаат од националниот RADIUS сервер до RADIUS серверот на таа организација, којшто е задолжен за филтрирање на невалидните домени преку правилото на "црна дупка", за да се спречи кружење на невалидни барања за автентикација во јамка. Проксирањето се конфигурира во датотеката /etc/raddb/proxy.conf, при што важи првото наведено правило кое ќе даде погодок. Конфигурациската датотека содржи многу пример-дефиниции. Тие не се неопходни и може да се избришат.

Пример датотеката е дадена во архивата: http://www.eduroam.org/downloads/docs/eduroam-cookbook-scripts.zip. Важни напомени:

• domain.tld се заменува со вашата доделена област како IdP. За SPs битна е само предефинираната област ( DEFAULT ).
• proxy.conf содржи една мала конфигурациска секција за прокси сервер за опции кои важат низ целиот систем:

proxy server {

default_fallback = yes

}

Овие поставки значат дека ако автентикациското барање содржи област којашто не е експлицитно наведена во натамоШните секции од оваа датотека, барањето се проксира до предефинираната област.

• Конфигурациската датотека исто така треба да содржи и home_server записи. Тие одговараат на клиентските секции од погоре: други RADIUS сервери со нивните IP адреси и лозинки. Две такви пример секции (за FLRS проксирање на непознати области) се вклучени во пример-датотеката.
• Параметрите response_window, zombie_period и revive_interval се параметри за подесување и првично треба да останат непроменети. Се препорачува користење на status_check = status-server, но само ако серверот на другиот крај е конфигуриран да ги прифаќа таквите статус-сервер барања. Ова однесување се конфигурира во radiusd.conf.
• Домашните сервери се групирани во пулови (т.е. сите сервери со иста функција, како на пример сите FLRS сервери, се групираат заедно). Ова се дефинира многу едноставно со home_server_pool дефиниција.
• Сите области познати на серверот се наведени во realm секции.
• nostrip командата специфицира дека доменот не се изоставува од корисничкото име (корисничките имиња секогаш се во форма short_username@domain.tld - и за локалните и за роаминг корисниците)

2.4 Дефиниција на Виртуелен сервер за eduroam: sites-enabled/eduroam

За SP, дефиницијата на фактичкиот сервер (делот што ги процесира дојдовните пакети од дефинираните клиенти и ги препраќа до дефинираните прокси-сервери) е многу едноставна, бидејќи самиот сервер не треба да врши никаква автентикација.

Конфигурацијата на серверските секции се врши во посебна датотека која се наоѓа во поддиректориумот sites-available. Датотеката се наоѓа во архивата http://www.eduroam.org/downloads/docs/eduroam-cookbook-scripts.zip. Постои симболичка врска во директориумот sites-enabled која покажува кон дефинициите во sites-available.

Датотеката содржи единствена сервер - секција со неколку подсекции. Барањата за автентикација се обработуваат преку следниве секции, редоследно:

• authorize: Собирање информации за корисникот од RADIUS клиентот.
• pre-proxy : Подготовка за проксирање кон друг сервер.
• post-proxy : Обработка на одговорот од другиот сервер.
• post-auth : Последна инспекција на пакетот пред испраќање на одговор кон RADIUS клиентот.

Сметководствените барања се обработуваат како што следува:

• preacct: Собирање информации за сесијата за која се врши евиденција.
• pre-proxy : Подготовка за проксирање кон друг сервер.
• post-proxy : Обработка на одговорот од другиот сервер.

Овие секции ги содржат имињата на модулите кои се конфигурираат во radiusd.conf и се објаснети во следната точка. Целосната серверска конфигурација за SP е дадена подолу (authenticate секцијата е празна, бидејќи самиот сервер не врши никаква автентификација како SP):
При процесирање на скриптата, се извршуваат следниве акции:

• authorize/auth_log: Пакетот со барањето се запишува во датотека за евиденција.
• authorize/suffix: Се парсира корисничкото име за да се одреди областа.
• authorize/if: Се детектира и превентира рутирачка јамка во случај на лажен поддомен.
• pre-proxy/attr_filter.pre-proxy: Се филтрираат атрибутите кои не треба да се пратат надвор (пр. VLAN).
• pre-proxy/pre_proxy_log: Се запишува барањето на диск пред да биде проксирано.
• post-proxy/post_proxy_log: Се запишува барањето на диск откако ќе се добие одговор од прокси-серверот.
• post-proxy/attr_filter.post-proxy: Се филтрираат несаканите атрибути од проксито (пр. VLAN).
• post-auth/reply_log: Конечниот одговор за клиентот се запишува во датотека.

За сметководствените барања, се извршуваат следните чекори:

• preacct/detail: Пакетот со барањето се запишува во датотека за евиденција.
• preacct/suffix: Се парсира корисничкото име за да се одреди областа.
• preacct/if: Се детектира и превентира рутирачка јамка во случај на лажен поддомен.
• pre-proxy/attr _filter.pre-proxy: Се филтрираат атрибутите кои не треба да се пратат надвор (пр. VLAN).
• pre-proxy/pre_proxy_log: Се запишува барањето на диск пред да биде проксирано.
• post-proxy/post_proxy_log: Се запишува барањето на диск откако ќе се добие одговор од прокси-серверот.
• post-proxy/attr_filter.post-proxy: Се филтрираат несаканите атрибути од проксито (пр. VLAN).

2.5 Главна конфигурациска датотека: radiusd.conf

Оваа датотека содржи многу генерички RADIUS конфигурациски елементи. Сепак, предефинираните елементи обично се соодветни за eduroam, и затоа нема да се дискутираат. Дискутирани се само конфигурациските елементи за кои треба соодветно да се променат.

• Следниве линии во предефинирата датотека не се коментирани:

  user = radiusd
  group = radiusd

  Ако линиитe не се искоментираат, FreeRADIUS ќе работи под root. Ова генерално не се препорачува. Затоа се препорачува да се креира radiusd корисник и radiusd група, а потоа да се стартува серверот како radiusd корисник. Меѓутоа, ако тоа се направи, треба да им се обезбеди на овој корисник и група пристап за читање и запишување до сите датотеки кон кои серверот пристапува.

• Почнувајќи од верзија 2, FreeRADIUS поддржува IPv4 и IPv6. Следните четири секции овозможуваат процесирање на автентикацијата и сметководството со IPv4 и IPv6:

  listen {

  type = auth
  ipaddr = *
  port = 1812

  }
  
  listen {

  type = auth
  ipv6addr = ::
  port = 1812

  }
  
  listen {

  type = acct
  ipaddr = *
  port = 1813

  }
  
  listen {

  type = acct
  ipv 6addr = ::
  port = 1813

  }

• Следниве редови се важни за функционирањето на eduroam; гореспоменатaта можност за користење на статус-сервер барања се овозможува во делот security, а потоа се вчитуваат сите дефинирани клиентски дефиниции, прокси сервер дефиниции и виртуелни сервери. Исто така тука е дефинирано и малото подмножество на модули кои се користат во виртуелниот сервер eduroam:

  security {

  max_attributes = 200
  reject_delay = 0
  status_server = yes

  }
  
  proxy_requests = yes
  $INCLUDE proxy.conf
  $INCLUDE clients.conf
  $INCLUDE sites-enabled/

• detail модулите примаат име на датотеката како аргумент за да се одреди каде ќе се впишува содржината на пакетите. Изборот на името на датотеката е произволно. Горенаведеното име - %Y%m%d се експандира во датум и на тој начин се креира нов поддиректориум секој ден. Ова овозможува едноставно дебагирање и бришење на старите датотеки. Овој модул се јавува во повеќе варијации во пример-конфигурацијата на серверот (различни имиња на датотеки): auth_detail,detail, pre_proxy_detail, post_proxy_detail, reply_detail.

  detail auth_log {

  detailfile = ${radacctdir}/%Y%m%d/eduroam/auth-detail
  detailperm = 0600

  }

• Следниoв модул утврдувa кој дел од User-Name е името, а кој е областа. Дефиницијата на eduroam кориснички имиња го користи @ знакот како разграничувач и делот зад @ се зема како област (што е и препорачана шема за именување во RFC4282).

  realm suffix {

  format = suffix
  delimiter = "@"

  }

• Следниов модул овозможува филтрирање на несаканите атрибути. Еден пример за ова е доделувањето на VLAN-и. Доделувањето на VLAN е само од локално значење, и затоа нема смисла оддалеченот сервер да одлучува за VLAN членство. Всушност, ова може да биде дури и штетно, затоа VLAN атрибутите не треба да бидат испраќани од страна на IdPs и исто така треба да бидат филтрирани од страна на SPs. Модулот се однесува на датотeки во главниот конфигурациски директориум. Самите датотеки содржат дополнителна документација за тоа како да се специфицира кои атрибути се дозволени а кои не. Почнувајќи од верзијата FreeRADIUS 2.0.4, серверот доаѓа со предефинирани вредности кои се компатибилни со eduroam без потреба за дополнителни модификации.

  attr_filter attr_filter.pre-proxy {

  attrsfile = ${confdir}/attrs.pre -proxy

  }

• Останатите делови во виртуелниот сервер, if (...) update( ... ), не се посебни модули туку конфигурациски јазик. Детали за користење на овој конфигурациски јазик се достапни на неговата man страна - man unlang.

2.6 Корисничка автентикација: конфигурирање на eduroam IdP

Конфигурирање на IdP вклучува:

• Конфигурирање на серверот како EAP крајна точка.
• Конфигурирање на локалната backend база на податоци.

Конфигурирањето на EAP се врши во датотеката eap.conf (преземање од http://www.eduroam.org/downloads/docs/eduroam-cookbook-scripts.zip). Оваа пример-датотека eap.conf е конфигурирана да прифаќа и TTLS и PEAP барања и да ги процесира на ист backend. Следните забелешки се однесуваат на различните модули од датотеката:

• Во tls делoт се дефинира серверскиот сертификат им се презентира на корисниците за време на автентикацијата. certdir, private_key_ ... треба да покажуваат кон соодветните датотеки на серверот. Збунувачки е за повеќето нови администратори тоа што tls треба да се дефинира иако EAP-TLS не се користи за автентикација. Тоа е затоа што ttls и peap секциите ги делат параметрите за сертификатот и се потпираат на постоењето на tls секцијата. Несаканата EAP-TLS автентикација може да се спречи со тоа што cadir ќе покажува кон непостоечки Издавач на сертификати (како оној што се создава при првото стартување на серверот), кој никогаш не издава валидни клиентски сертификати.


• ttls и peap секциите одредуваат дедициран виртуелен сервер кој ќе ги прифаќа и процесира барањата од внатрешниот тунел (ова се случува откако ќе заврши TLS ракувањето со супликантот). Забележете дека мора да има празна mschapv2 секција во eap.conf за да работи PEAP - ова се должи само на внатрешна работа на серверот.


• За да се вклучи EAP во виртуелниот сервер eduroam, треба да се додадат само две линии; новиот виртуелен сервер "eduroam-inner-tunnel " (кој е дефиниран претходно во eap.conf) треба да биде подесен за автентикацијата на корисниците и модулот eap треба да биде наведен на крајот од authorize и authenticate секциите:



server eduroam-inner-tunnel {

authorize {

auth_log
files
ldap
mschap
pap

}
authenticate {

Auth-Type LDAP{

ldap

}
Auth-Type PAP{

pap

}
Auth-Type MS-CHAP{

mschap

}

}
preacct {

}
accounting {

detail
sql

}
session {

}
post-auth {

reply_log
Post-Auth-Type REJECT {

reply_log

}

}
pre-proxy {

}
post-proxy {

}

}

Најзабележителна разлика меѓу внатрешниот и надворешниот сервер е дека внатрешниот тунел не врши EAP. Наместо тоа, тој го користи ldap модулот во authorize и authenticate секциите за автентикација на корисниците врз база на податоците од LDAP backend-от. Забележете дека ldap модулот е конфигуриран во radiusd.conf. Таму мора да се внесат потребните информации за конекцијата со LDAP серверот и да се отворат соодветните порти во firewall-от од RADIUS серверот до LDAP серверот, ако тоа е потребно.

Исто така треба да се напомене дека овој виртуелен сервер не го повикува suffix модулот. Ова значи дека внатрешното барање не се проксира понатаму. Ова е стандардна мерка за безбедност во eduroam.

Дефиницијата на виртуелен сервер исто така го вклучува и files модулот. За LDAP автентикација, ова е опционално. Во пример-датотеката, овој модул се користи за овозможување на тест корисници во датотека "users", со цел овозможување на дебагирање на автентикацијата. Откако проверката на автентификацијата со помош на users датотека ќе помине и откако ќе се воспостави LDAP-конекцијата, files модулот е потребен само за напредните поставувања како на пример доделување на VLAN-и.

• За првичното подесување на датотеката users може да се избришат сите постоечки записи и да се додаде само следнава линија во датотеката:
  
  test@domain.tld Cleartext-Password := "<test password>"
  
  Со ова се креира тест корисник test@domain.tld и лозинка, кој може да се користи за тестирање на автентикацијата.


• Во случај кога имаме доделување на VLAN-и, users датотеката треба да ги содржи соодветните RADIUS атрибути, како во следниот пример за VLAN 313:

  DEFAULT <услови за доделувањето> Tunnel-Type = VLAN,
  Tunnel-Medium-Type = IEEE-802,
  Tunnel-Private-Group-Id = 313

• Конфигурацијата на самиот LDAP модул се врши во radiusd.conf. Оваа конфигурациска секција е опширно документирана во датотеката, па подолу е даден само едноставен пример на конфигурација (врз основа на eduPerson LDAP шема).

  modules {

  
  ...
  
  ldap {

  server = "localhost "
  identity = "cn =RADIUS ,dc =domain ,dc =tld "
  password = "<secret for identity dn >"
  basedn = "ou =student ,dc =domain ,dc =tld "
  filter = "(eduPersonPrincipalName =%{User -Name })"
  start _tls = no

  }
  
  ...

  }

• Доколку е потребно логување на сметководствените барање во база на податоци (видете подолу), препорачливо е да се прошири сметководствениот клуч во acct_unique модулот со цел поголема робустност на сметководствената евиденција.

  acct_unique {

  key = "User-Name, Acct-Session-Id, Calling-Station-Id,\
  Called-Station-Id, NAS-IP-Address, NAS-Port"

  }

2.7 Поставување на accounting во SQL база на податоци

Сите сметководствени информации се запишуваат во MySQL база на податоци. Конфигурациската датотека е /etc/raddb/sql.conf. Содржината на оваа датотека треба да се замени со содржината на соодветната датотека од архивата: http://www.eduroam.org/downloads/docs/eduroam-cookbook-scripts.zip.

2.8 Логување на клиентски IP адреси како Сервис Провајдер (опционално)

IP адресите на клиентите се логуваат во DHCP датотека за евиденција. Сепак овие информации може да се чуваат и во ACCOUNTING табелата со други сметководствени податоци, со што се обезбедува лесен пристап до податоците. Администраторот треба да постави скрипта за ажурирање на SQL базата на податоци со информации за доделените IP адреси. IP адресата на клиентот се определува со tailing (unix команда tail) на DHCP датотека за евиденција и следење на сите доделени IP адреси. Скриптата исто така врши мониторинг на активни врски и чистење на застерени логови за врски. Потребен е SNMP пристап до пристапната точка (Access Point).

Скриптата може да се превземе од архивата http://www.eduroam.si/uploads/CN/eC/CNeCC3Uc7XI9Tw_dLtwYZg/eduroam_monitor-20060809.tar.bz2

Пристапните точки (Access Points) треба да бидат регистрирани во скриптата. Ова се прави со внесување на потребните податоци за пристапна точка во базата на податоци:

USE radius;
create table access_points (

`IP address` varchar(100) PRIMARY KEY NOT NULL,
`snmp secret` varchar(100) NOT NULL default ' ',
`radius secret` varchar(100) NOT NULL default ' ',
`root username` varchar(100) NOT NULL default ' ',
`root password` varchar(100) NOT NULL default ' '

) TYPE = MyISAM;

2.9 Повеќе информации

Оригиналната техничка спецификација за словенскиот eduroam и пример конфигурации: http://www.eduroam.si

Електронска пошта за техничка поддршка на ARNES AAI aaa-podpora@arnes.si

FreeRADIUS датотеки http://www.eduroam.org/downloads/docs/eduroam-cookbook-scripts.zip

Eduroam-in-a-box веб конфигурациска алатка http://eduroam.sourceforge.net

3. VitalAAA Институционален и национален сервер

3.1 Институционален VitalAAA Сервер (ver. 5.2.0+)

За поставување на локален RADIUS сервер како Институционален VitalAAA, потребно е да се променат следниве конфигурациски датотеки:

• server_properties
• method_dispatch
• clients

Исто така потребно е да се симнат следниве датотеки од http://www.eduroam.org/downloads/docs/eduroam-cookbookscripts.zip:

• error.pf
• proxy.pf
• acct.pf
• prepare.pf
• local.pf

Потребно е да се направат следниве промени во server_properties датотеката:

Radius-Acct-Address = "*:1813"
Radius-Auth-Address = "*:1812"
Database-Address = "0"
Radius-CharSet = UTF8
Delimiter-Precedence = "@"
Suffix-Delimiters = "@"

Потребно е да се направат следниве промени во method_dispatch датотеката:

radius     Auth     1     prepare     setWorkingVars
radius     acct     4     acct         dumpAcct

Потребно е да се додадат следниве редови со информации за националниот прокси-сервер во clients датотеката:

<192.168.1.10    national_server_secret>
<192.168.1.20    national_server_secret>
…

3.2 Национален VitalAAA Сервер (ver. 5.2.0+)

За поставување на Национален RADIUS прокси сервер за VitalAAA потребно е да се променат следниве конфигурациски датотеки:

• server_properties
• method_dispatch
• clients

Исто така потребно е да се симнат следниве датотеки од http://www.eduroam.org/downloads/docs/eduroam-cookbookscripts.zip

• aaa.pf
• error.pf
• proxy.pf
• prepare.pf

Потребно е да се направат следниве промени во server_properties датотеката.

Radius-Acct-Address = "*:1813"
Radius-Auth-Address = "*:1812"
Database-Address = "0"
Radius-CharSet = UTF8
Delimiter-Precedence = "@"
Suffix-Delimiters = "@"

Потребно е да се направат следниве промени во method_dispatch датотеката.

radius     Auth     1     prepare     setWorkingVars
radius     acct     4     aaa        dropRadiusAcct

Потребно е да се додадат следниве редови со информации за eudoroam прокси-серверот и локалните RADIUS сервери во clients датотеката

192.87.106.34    <eduroam_secret>
130.225.242.109    <eduroam_secret>
<192.168.1.10>    <local_server_secret>
<192.168.1.20>    <local_server_secret>
…

4. Microsoft интернет сервис за автентикација како институционален сервер

Интернет Сервисот за Идентификација (IAS) во Microsoft Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition и Windows Server 2003, Datacenter Edition е имплементација на Microsoft за RADIUS сервер и прокси. IAS во Windows Server 2003, Standard Edition може да се конфигурира со максимум 50 RADIUS клиенти и максимум 2 далечински RADIUS серверски групи. RADIUS клиентите може да се дефинираат со целосно квалификувани имиња на домени или со IP адреси, но не е можно дефинирање на групи на RADIUS клиенти со специфицирање на опсег од IP адреси. Во Enterprise и Datacenter Edition на Windows Server 2003 овие ограничувања не постојат.

4.1 Инсталирање на IAS

Со deafault-ната инсталација на Windows Server 2003 IAS не се инсталира. Тој мора да се инсталира одделно на следниов начин:

1. Изберете Control Panel > Add or Remove Programs > Add/Remove Windows Components > Networking Services:



2. Изберете Internet Authentication Service и кликнете OK:



Откако ќе заврши инсталацијата, отворете ја IAS административната конзола:

3. Изберете Administrative Tools



4. Кликнете на Internet Authentication Service во старт менито за да ја стартувате IAS конзолата:



Потоа треба да го конфигурирате IAS како што е објаснето во секцијата која следува.

4.2 Конфигурирање на далечински (remote) RADIUS сервер

Националниот RADIUS прокси сервер мора да се додаде кон далечинскиот RADIUS сервер:



Мора да се специфицира адресата на далечинскиот RADIUS сервер:



Мора да se внесе автентикациската порта на RADIUS серверотот (обично 1812) и лозинката (shared secret) на далечинскиот RADIUS прокси сервер како и accounting портата на далечинскиот RADIUS сервер. По потреба може да наведат и различни лозинки (shared secrets) за accounting:



4.3 Конфигурирање на IAS како Универзитетски RADIUS сервер во eduroam хиерархијата

Конфигурирање на IAS за пристапни точки (access points) и upstream проксија (proxies)

За секоја пристапна точка и upstream прокси (пр. национален eduroam RADIUS сервер) треба да се конфигурираат параметрите на RADIUS клиентите:

При додаватњето на нова пристапна точка се појавува волшебник (wizard) кој ќе побара име и IP адреса на RADIUS клиентот (т.е. пристапната точка (аccess point), switch-от или upstream RADIUS проксито):



Тогаш мора да се специфицира лозинката (shared secret) помеѓу RADIUS клиентот и RADIUS серверот (IAS):



Може да се изберат повеќе произведители на RADIUS клиенти, но во повеќето случаи треба да се користи RADIUS Standard.

Конфигурирање на полиса за процесирање на барања за конекција

Процесирањето на областите (realms) треба да се конфигурира во согласност со eduroam хиерархијата, што значи:

1. Конфигурирање на полиса која ги опфаќа локалните области.

2. Конфигурирање на далечински RADIUS сервер

3. Конфигурирање полиса која ги препраќа сите останати барања кон upstream прокси серверот.


Постапките се објаснети подолу.

Конфигурирање на полиса за локална област

1. Конфигурирајте полиса за процесирање на барањата за конекција која ќе ги опфати сите кориснички имиња кои се користат за пристап до локални области користејќи го условот “.*@yourrealm.tld ”.



2. Кликнете на Edit Profile и специфицирајте дека автентикацијата се изведува на локалниот сервер:



3. Кликнете на јазичето Attributes и проверете дали RADIUS параметрите се процесираат точно, на пример во случај на поклопување на името на областа, името на областа мора да се испушти:



Конфигурирање полиса за upstream RADIUS прокси сервер

1. Конфигурирајте полиса за процесирање на барања за конекција која ќе ги опфати сите кориснички имиња кои можеби се користат за роаминг ( roaming ) co условот “.*@.*”.



2. Кликнете на Edit Profile и специфицирајте дека барањата за автентикација мора да се препратат до националниот прокси сервер за овој профил:



3. Од листата изберете ја групата далечински RADIUS сервери.

4.4 Конфигурација за корисниците на даден домен (domain users) да можат да користат eduroam со своите кориснички сметки (credentials) на Windows домен

Со основните поставки (default), корисниците конфигурирани во Windows домен не можат да ги користат своето корисничко име и лозинка за автентикација кон IAS. За eduroam, ова би требало да биде овозможено во доменот за да им се овозможи пристап на домен корисниците (remote access permission). Ова може да се направи со користење на Интерфејсот за управување со корисниците (User Management interface) или на Интерфејсот за управување со доменот (Domain Manager interface) со следниве поставки:



4.5 Конфигурирање на автентикациски методи

Автентикациските методи се конфигурираат во Remote Access Policies во Profile поставките. Во најмала рака треба да биде овозможено PEAP под ЕАР методите, но корисно е да се овозможи и PAP за дебагирање (на пример за тест корисниците).



Автентикација со PEAP е најлесниот начин за интеграција со eduroam под Windows. Интегрирање на EAP-TLS може да биде многу напорно:



4.6 Troubleshooting

Најкорисни информации може да се добијат од Eventviewer:



Но информации исто така може да се добијат од датотеките за евиденција (log files):



4.7 Референци

IAS Ресурси: http://technet2.microsoft.com/WindowsServer/en/Library/f6985d5d-d4c5-49e2-bbc7-385e105bfe281033.mspx?mfr=true

IAS: http://technet2.microsoft.com/WindowsServer/en/Library/d98eb914-258c-4f0bad04-dc4db9e4ee631033.mspx?mfr=true

IAS синтакса за pattern matching: http://technet2.microsoft.com/WindowsServer/en/Library/6e5ce48d-e662-435ca74e-0dce305914ce1033.mspx?mfr=true