Политика Unlang FreeRadius 3.0.1 для динамического сопоставления пользователя -> Клиент -> Группа LDAP

У меня есть Радиус, работающий с AD + Google OTP, работает нормально. То, что я пытаюсь сделать сейчас, — это указать «пользователь-клиент-ADgroup» в политике и/или unlang в файле post-auth.

Как это работает сегодня:

  • клиент выполняет запрос
  • Radius отправляет первую половину пароля в AD
  • Radius отправляет вторую половину пароля в Google OTP
  • Если оба возвращаются хорошо, то авторизация прошла успешно
  • Пост-аутентификация выполняет некоторую проверку, является ли пользователь членом ADgroup -> назначить класс -> принять
  • ИЛИ, если не является частью ADgroup -› отклонить

В части, с которой мне нужна помощь, у меня более 30 сайтов с оборудованием на каждом. Мы различаем наших пользователей в зависимости от доступа к сайту. Например. NetworkAdmin01 имеет доступ к site01, но не к site02. Поэтому единственный способ, которым я могу думать об этом:

  • Каждый сайт имеет свой виртуальный сервер (VS)

  • У каждого клиента установлен атрибут виртуального сервера

  • В каждом VS есть unlang после аутентификации, например:

     if (LDAP-Group == "NetworkAdmins_site01") {
   [do something] (update control, update reply, etc..)
  else
   reject

Эта установка потребует, чтобы на Radius работало более 30 VS, и это неуправляемо.

Если бы мне удалось запустить это в течение нескольких VS (разделенных в зависимости от поставщика оборудования), я хочу в пост-авторизации предоставить/назначить на основе;

   if (%{client:shortname} =~ /regex/) #grab the portion of the variable between "." (site01)
    if (LDAP-Group =~ /regex/) # grab the portion of the variable after last "_" (site01)
      if (%{0} == %{1}) {
        if (LDAP-Group == NetworkAdmins_site01) {
          update reply {
            Juniper-Local-User-Name := "admins_group"
          }
         }
        else {
          update control {
            Auth-type := "Reject"
          }
         }
       }
       }
       }

freeradius
person bwinchell    schedule 09.07.2020    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Итак, после долгих поисков оказалось, что динамические переменные времени выполнения являются самым большим ограничением для создания политик/правил любого типа. поэтому я пошел в другом направлении. Я в основном сопоставил NAS-IP-адрес с IP-подсетью/сайтом, от которого, как я ожидаю, будет поступать запрос. Таким образом, это помещается в раздел Post-Auth каждого VS. Не самый удобный способ, когда у вас более 30 сайтов, но лучший, который я смог найти на данный момент (без запуска 30+ VS).

      #  SITE01 site
      if (&NAS-IP-Address < 10.1.0.0/16) {  
        if (LDAP-Group == "Radius_NetworkAdmins_SITE01") {
          update reply {
            Juniper-Local-User-Name := "ad-super-users"
          }
        }
        elsif (LDAP-Group == "Radius_NetworkAdminsRO_SITE01") {
          update reply {
            Juniper-Local-User-Name := "ad-readonly-users"
          }
        }
      }
      #  SITE02 site
      if (&NAS-IP-Address < 10.2.0.0/16) {  
        if (LDAP-Group == "Radius_NetworkAdmins_SITE02") {
          update reply {
            Juniper-Local-User-Name := "ad-super-users"
          }
        }
        elsif (LDAP-Group == "SG_Uni_Radius_NetworkAdminsRO_SITE02") {
          update reply {
            Juniper-Local-User-Name := "ad-readonly-users"
          }
        }
      }
    else {
      update reply {
        Reply-Message := "Not authorized to access this system"
      }
      update control {
        Auth-Type := "Reject"
      }
    }
    #
      Post-Auth-Type REJECT {
        -sql
        attr_filter.access_reject
        eap
        remove_reply_message_if_eap
        }
      }
      Post-Auth-Type Challenge {
      }
#
    pre-proxy {
    }
#
    post-proxy {
      eap
    }
person bwinchell    schedule 10.07.2020