Политика FreeRADIUS для ограничения попыток определенных пользователей войти на определенное устройство

Что у меня есть: freeradius 2.1.10 на debian, настроен на использование базы данных.

Как это работает сейчас: В сети много устройств и пользователей, пользователи входят в устройства, чтобы настроить их, и так далее. Пользователи могут войти в систему во что угодно. Например, на некоторых устройствах (ciscos) учетная запись пользователя на radius имеет привилегии (cisco-avpair атрибут), которые ограничивают то, что этот человек может и не может делать на устройствах cisco.

Что я хочу, чтобы freeradius делал в дополнение, для конкретного особого случая: Есть специальное устройство, на котором только избранные пользователи могут проходить аутентификацию. Всем остальным нужно просто запретить доступ. (так что более строго, чем пример cisco выше).

Я думаю, что мне следует сначала определить свой собственный атрибут, например company-special-privilege так что я могу установить это для некоторых пользователей в базе данных со значением 0 или 1. Затем определите политику в policy.conf.

Что я спрашиваю: Политики никогда не выполнялись, и я не понимаю, где они применяются в остальной части конфигурации freeradius (где мне разместить special_access политика). Также не знаю, как это сформулировать, но следующий псевдокод должен представлять то, что я хочу:

special_access {
    if (request to log in $special_device_ip) {
        if ($username company-special-privilege) {
            reject #
        }
    }
}

Из вышесказанного я не знаю, как получить IP-адрес устройства или атрибут, установленный пользователем. Я не делаю == 1 для атрибута во втором условии, если у пользователя нет атрибута, поскольку я не знаю, что это будет означать, но любой пользователь, у которого нет 1, должен быть отклонен.

freeradius

Вы должны положить это в raddb/policy.conf внутри policy {} строфа. Затем на них можно ссылаться (по их имени), как на обычный модуль, при авторизации, аутентификации, пост-авторизации и т. Д.

Политики в FreeRADIUS по сути являются макросами, это не функции, они не принимают аргументов.

Определение специального атрибута для управления политическими решениями - это нормально, сделайте это в raddb/dictionary если у вас нет номера IANA и вы не хотите создавать собственный словарь. Более простой способ - напрямую запросить SQL.

Я не уверен, что именно вы хотите сделать, но вот пример, который может помочь ... При необходимости измените

special_access {
    if ("%{Called-Station-ID}" == 'special device') {
        if ("%{sql:SELECT special_priv FROM table WHERE username = '%{User-Name}'}" != '1') {
            reject
        }
    }
}

Благодаря некоторой информации, которую я нашел на http://linotp.org/doc/2.6/part-installation/integration/index.html вы можете использовать следующую конфигурацию, если используете таблицу nas в базе данных MySQL. в nas В таблице у вас есть диапазоны IP-адресов для каждой группы устройств, поэтому, если ваше устройство находится в определенном диапазоне IP-адресов, будет использоваться политика:

mysql> SELECT * FROM nas WHERE is = '1'; 
+----+------------------+-------------+-------+------------+----------------------------------+
| id | nasip            | shortname   | type  | secret     | description                      |
+----+------------------+-------------+-------+------------+----------------------------------+
|  1 | 192.168.1.0/24   | restricted  | other | *********  | only some users have access      |
+----+------------------+-------------+-------+------------+----------------------------------+

В файле sites-enabled/default вы ссылаетесь на политику;

authorize {
 ...
 update request {
     FreeRADIUS-Client-Shortname = "%{Client-Shortname}"
 }
 my_policy
 ...
}

и в policy.conf вы пишете свою политику. Эта политика сначала проверяет nas стол для ограниченный префикс, а затем проверяет, есть ли у пользователя достаточные права

...
  my_policy {
    if (FreeRadius-Client-Shortname =~ /^restricted/) {
      if ("%{sql:SELECT moreaccess FROM radusergroup WHERE username = '%{User-Name}'}" != '1') {
        update reply {
          Cisco-AVPair := "shell:priv-lvl=1"
        }
      }
    }
  }
...

И конечно в твоей radusergroup В таблице, на которую вы ссылаетесь в своем SQL-запросе, вы добавляете дополнительный столбец, в котором вы разрешаете определенным пользователям с дополнительными правами.

mysql> SELECT * FROM radusergroup WHERE username like 'peter%';
+------------------+--------------+----------+------------+
| username         | groupname    | priority | moreaccess |
+------------------+--------------+----------+------------+
| peter            | super-rights |        1 |       NULL |
| peter1           | super-rights |        1 |          1 |
| peter2           | super-rights |        1 |          0 |
+------------------+--------------+----------+------------+

В данном случае я написал политику так:

Обычно уже получают высокую привилегию: Cisco-AVPair := "shell:priv-lvl=15"
Итак, если у пользователя в этом случае стоит 1 peter1 просто получает нормальные права.
Если у пользователя нет «1» (!= '1'), он получит право, указанное в политике.
- Вместо того, чтобы использовать update reply ты можешь использовать reject чтобы полностью заблокировать доступ для этого (peter и peter2) пользователи.

это может быть довольно сложно, но это работает для меня.