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

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

0 голосов
/ 10 июля 2020

Мой радиус работает с AD + Google OTP работает нормально. То, что я пытаюсь выполнить sh сейчас, - это указать группу «пользователь-клиент-AD» в политике и / или изменить язык в пост-аутентификации.

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

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

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

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

  • Каждый клиент имеет " набор атрибутов виртуального сервера

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

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

Для этой настройки мне потребуется 30+ VS работают на Radius и не поддаются управлению.

Если бы я смог запустить это в нескольких 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"
          }
         }
       }
       }
       }

1 Ответ

0 голосов
/ 10 июля 2020

Итак, после долгого осмотра выясняется, что динамические c переменные среды выполнения являются самым большим ограничением для создания любого типа политик / правил. поэтому я пошел в другом направлении. Я в основном сопоставил IP-адрес NAS с 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
    }
...