FreeRadius исскуственный параметр для проверки на этапе auth

[switchua]

Здравствуйте. Переработываю под свои нужды связку FreeRadius + mariadb-server + mpd5

Для авторизации и аккаунтинга подключений из mpd5 использую стандартный модуль rlm_sql для FreeRadius.

 

Возникла необходимость явно блокировать абонентов на этапе авторизации используя свой выдуманный атрибут, как пример HLink-Blocked. Прописал атрибут в словари, определил для него значение, но почему-то когда этот атрибут присутствует в sql-таблице, то radiusd не авторизует абонента и выдает сообщение в отладке:

Found Auth-Type = MSCHAP
# Executing group from file /usr/local/etc/raddb/sites-enabled/default
+group MS-CHAP {
[mschap] No Cleartext-Password configured.  Cannot create LM-Password.
[mschap] No Cleartext-Password configured.  Cannot create NT-Password.
[mschap] Creating challenge hash with username: hubbs
[mschap] Client is using MS-CHAPv2 for hubbs, we need NT-Password
[mschap] FAILED: No NT/LM-Password.  Cannot perform authentication.
[mschap] FAILED: MS-CHAP2-Response is incorrect
++[mschap] = reject
+} # group MS-CHAP = reject
Failed to authenticate the user.

 

Если же я убераю параметр из sql-таблицы, то авторизация проходит

Found Auth-Type = MSCHAP
# Executing group from file /usr/local/etc/raddb/sites-enabled/default
+group MS-CHAP {
[mschap] Creating challenge hash with username: hubbs
[mschap] Client is using MS-CHAPv2 for hubbs, we need NT-Password
[mschap] adding MS-CHAPv2 MPPE keys
++[mschap] = ok
+} # group MS-CHAP = ok

 

Атрибут я явно пытался инициализировать на этапе authorize.

update control {
  Hlink-Blocked := allowed
}

Все конфигурационные файлы и SQL-таблицы прилагаются.

rad-nag.tgz 94 KB

 

 

Прошу вашей помощи. Заранее благодарен.

Edited May 25, 2014 by switchua

[terrible]

Вы добавляете новый RADIUS атрибут, однако он не фигурирует в схеме RADIUS Server - RADIUS Client

По логике вещей он вообще нигде не должен фигурировать, акромя SQL выборки.

 

	authorize_check_query = "SELECT a.id, a.username, a.attribute, a.value, a.op \
         FROM ${authcheck_table} AS a \
  INNER JOIN ${authcheck_table} AS b ON (b.username = a.username AND b.attribute = `Hlink-Blocked` AND b.value = 0)
         WHERE a.username = '%{SQL-User-Name}' AND a.attribute != `Hlink-Blocked`\
         ORDER BY a.id"
authorize_reply_query = "SELECT id, username, attribute, value, op \
         FROM ${authreply_table} \
         WHERE username = '%{SQL-User-Name}' AND attribute != `Hlink-Blocked`\
         ORDER BY id" 

 

Исключаем Hlink-Blocked вообще из RADIUS запросов check и reply, но проверяем его значение на check.

В запросах мог ошибиться с кавычками.

[switchua]

Вы добавляете новый RADIUS атрибут, однако он не фигурирует в схеме RADIUS Server - RADIUS Client

В том то и дело, что я бы хотел внести этот атрибут в схему. Я не вижу принципиальной разницы этого атрибута с другими подобными. Я даже попытался его проинициализировать на этапе authorize. Все таки я хочу сделать работающую схему завязанную на этом атрибуте. Если этого невозможно, укажите где я не прав с точки зрения Radius-идиологии.

 

По логике вещей он вообще нигде не должен фигурировать, акромя SQL выборки.

 

 

	authorize_check_query = "SELECT a.id, a.username, a.attribute, a.value, a.op \
         FROM ${authcheck_table} AS a \
  INNER JOIN ${authcheck_table} AS b ON (b.username = a.username AND b.attribute = `Hlink-Blocked` AND b.value = 0)
         WHERE a.username = '%{SQL-User-Name}' AND a.attribute != `Hlink-Blocked`\
         ORDER BY a.id"
authorize_reply_query = "SELECT id, username, attribute, value, op \
         FROM ${authreply_table} \
         WHERE username = '%{SQL-User-Name}' AND attribute != `Hlink-Blocked`\
         ORDER BY id" 

 

Исключаем Hlink-Blocked вообще из RADIUS запросов check и reply, но проверяем его значение на check.

В запросах мог ошибиться с кавычками.

 

Ваш вариант будет работать. Но мне кажется не совсем элегантное решение. С точки зрения оптимальность SQL-запросов. Но благодарю за альтернативный вариант.

[terrible]

А как вы его в словарях прописали?

 

Если вам нужно тупо отсечь звонящего на MPD5 - можете добавить вот это в таблицу radreply:

 

36  hubbs  Framed-Protocol	:=	VLAN

 

Но мне кажется не совсем элегантное решение. С точки зрения оптимальность SQL-запросов.

Добавьте индексы - работать будет быстро (0.00001 сек), и пох на элегантность

 

Но мне кажется не совсем элегантное решение.

Элегантнее было бы завести отдельную таблицу с логинами (телефонами, адресами) и отдельную с параметрами, в которой и будет указано, что они могут, а что нет. И любой каприз будет решаться на уровне очень быстрых SQL запросов с разных таблиц.

 

У меня вот так сделано:

authorize_check_query = "SELECT a.id, a.login as UserName, a.Attribute, a.Value, a.op \
FROM ${authcheck_table} as a INNER JOIN billing_groups as g ON (g.id = a.localgroup) \
LEFT JOIN billing_servers as s ON (s.remoteid = '%{Agent-Remote-Id}' AND g.server = s.id) \
WHERE a.login = '%{SQL-User-Name}' \
AND (a.auth like '\%%ip=[%i]%' OR a.auth like '\%%mac=[%i]%' OR a.auth like '\%%ip=[%{NAS-IP-Address}]%' \
OR a.auth like '\%%client-mac-address=[${mac}]%' OR a.arpcallctrl > now() \
OR (g.impbpb = 1 AND a.portno = '%{Agent-Circuit-Id}')) \
AND a.priv = '0' AND a.status = 1 Limit 1";

[switchua]

В словарях прописано как

ATTRIBUTE	Hlink-Blocked	201	integer

VALUE	Hlink-Blocked	allowed	0
VALUE	Hlink-Blocked	deny 	1

 

С Framed-Protocol тоже неплохое решение.

Edited May 26, 2014 by switchua