[alibek]

Решил наконец сделать вход на сетевое оборудование (коммутаторы) централизованным.

Поставил FreeRADIUS 2.1.12.

Настроил примерно так.

/etc/freeradius/radiusd.conf

...
listen {
 type = auth
 ipaddr = 10.1.128.100
...
}

/etc/freeradius/clients.conf

...
client 10.1.0.0/16 {                                                                                                                                                                                           
 secret = secret123
 shortname = access-mgmt
 nastype = other
}
...

/etc/freeradius/users

...
$INCLUDE users.d/ (также пробовал $INCLUDE users.d/* и $INCLUDE users.d/mgmt-access)
...

/etc/freeradius/users.d/mgmt-access

test123
 Cleartext-Password := "test123"
 Service-Type = Administrative-User,
 Cisco-AVPair = "shell:priv-lvl=15"

 

# radtest -x test123 test123 10.1.128.100 1812 secret123
Sending Access-Request of id 249 to 10.1.128.100 port 1812
       User-Name = "test123"
       User-Password = "test123"
       NAS-IP-Address = 10.1.128.13
       NAS-Port = 1812
       Message-Authenticator = 0x00000000000000000000000000000000
rad_recv: Access-Reject packet from host 10.1.128.100 port 1812, id=249, length=20

В логах "Auth: Login incorrect: [test123] (from client access-mgmt port 1812)".

 

Нет идей, почему не опознается логин test123?

[alibek]

Кстати, если содержимое файла users.d/mgmt-access перенести в users, то авторизация работает.

То есть почему-то не срабатывает $INCLUDE.

[vop]

Может так:

 

$INCLUDE ${confdir}/users.d/

[alibek]

В остальных местах пути всегда указывались относительные.

Ок, попробую так.

[wildmoon]

Отпишитесь потом

[alibek]

Не помогло.

Если прописываю пользователей непосредственно в users, то все работает.

Если указываю $INCLUDE, то не работает, сервер возвращает reject.

Возможно не поддерживаются вложенные $INCLUDE.

[Ivan_83]

А ты не гадай, запусти фрирадиус в отладочном режиме чтобы на консоль всё сам писал и быстро разберёшься.

[myth]

radiusd -X

 

Ну и в целях самообразования несколько вопросов:

1. А зачем это нужно? Кроме возможности быстро сменить логины-пароли на всем оборудовании.

2. В случае недоступности радиуса по любым причинам останется возможность авторизоваться локально? Если да, то что мешает при доступном radius авторизоваться локально?

[orlik]

2. В случае недоступности радиуса по любым причинам останется возможность авторизоваться локально? Если да, то что мешает при доступном radius авторизоваться локально?

 

А тут все зависит от настроек. Но обычно настраивается так что если недоступен радиус то авторизация локальная. А если доступен и прислал reject то дальше уже все :)

Хотя тут конечно можно по разному настроить , кому как нравится

 

P.S. както видел контору где стояло 100+ свичей с локальным доступом и на каждом свой индивидуальный пароль(пароли лежали в базе ... ). И был там инженер , который эти все пароли помнил :)

Мне было лень запоминать и я поднял tac_plus

[alibek]

А ты не гадай, запусти фрирадиус в отладочном режиме чтобы на консоль всё сам писал и быстро разберёшься.

Так в логах ничего нет, чтобы что-то прояснилось.

Единственное место в логах, где упоминается users:

Module: Instantiating module "files" from file /etc/freeradius/modules/files
 files {
       usersfile = "/etc/freeradius/users"
       acctusersfile = "/etc/freeradius/acct_users"
       preproxy_usersfile = "/etc/freeradius/preproxy_users"
       compat = "no"
 }

Более ничего нет, т.е. директива $INCLUDE как будто игнорируется.

 

1. А зачем это нужно? Кроме возможности быстро сменить логины-пароли на всем оборудовании.

2. В случае недоступности радиуса по любым причинам останется возможность авторизоваться локально? Если да, то что мешает при доступном radius авторизоваться локально?

 

1. Централизованная авторизация, в первую очередь именно для этого.

Ну а кроме того, некоторое оборудование позволяет конфигурировать сеанс с помощью RADIUS-атрибутов (правда на доступе мне такое не попадалось).

 

2. Я настраиваю именно так — авторизация через RADIUS, а если он недоступен, то локальная авторизация.

На каких-то устройствах способы авторизации параллельные (т.е. можно использовать локальную авторизацию при работающем RADIUS-сервере), но обычно локальные учетные записи доступны только при недоступности RADIUS-сервера (т.е. если RADIUS доступен и ответил reject, то локально не авторизуешься).

[myth]

1. Централизованная авторизация, в первую очередь именно для этого.

А какие плюшки от этого?

[alibek]

Э... Даже затрудняюсь сказать.

Например добавить/поменять/удалить учетку разом для всех устройств доступа.

Бонусом идет то, что все сеансы входа регистрируются на RADIUS-сервере (даже если выключен или не настроен syslog).

[orlik]

Не забываем про аккаунтинг, чтоб знать кто что и когда.

[alibek]

Кстати, что дает аккаунтинг?

Я его не использовал, длительность сеансов мало что дает.

А "кто, что и когда" это скорее syslog.

[orlik]

Кстати, что дает аккаунтинг?

Я его не использовал, длительность сеансов мало что дает.

А "кто, что и когда" это скорее syslog.

Не помню как на счет радиуса, но в такакс можно слать все выполненые команды. Чтоб не собирать это через сислог, где у каждого вендора будет свой формат записи .

[alibek]

Не помню как на счет радиуса

Вроде бы в настройках коммутаторов я такого не встречал.

Я команды протоколирую именно через syslog.

[zhenya`]

У циски такое есть и даже можно запретить команды.

[orlik]

У циски такое есть и даже можно запретить команды.

Ну ограничение команд, это да. А аккаунтинг команд точно можно через радиус ?

[FATHER_FBI]

alibekустанавливай сразу 3 версию FreeRADIUS в связке с MySQL/MariaDB + DaloRADIUS

Ну ограничение команд, это да. А аккаунтинг команд точно можно через радиус ?

Если оборудование поддерживает аккаутинг команд через radius, он как правило аккаутинг больше запилян в tacacs

[alibek]

Было несколько причин, почему сильно желателен был именно RADIUS.

Но похоже, что придется использовать TACACS.

И некоторые устройства уж в очень куцем виде поддерживают RADIUS.

И возможность авторизовать отдельные команды очень интересная.

[FATHER_FBI]

Было несколько причин, почему сильно желателен был именно RADIUS.

Но похоже, что придется использовать TACACS.

И некоторые устройства уж в очень куцем виде поддерживают RADIUS.

И возможность авторизовать отдельные команды очень интересная.

Если выбор пал на Tacacs, тогда используйте tacacs mavis, он более гибкий нежели стандартный tacacs

[alibek]

Спасибо за наводку, поизучаю.

Но мне и стандартного достаточно.

Толку с возможностей, если железо на доступе этого не умеет.

[FATHER_FBI]

Спасибо за наводку, поизучаю.

Но мне и стандартного достаточно.

Толку с возможностей, если железо на доступе этого не умеет.

tac_mavis логи складывает по каждому свичу отдельно, более гибкие ACL, группы и так далее..

Наверное лучше показать в примерах

Вот как в стандартном tacacs

 

В стандартном tacacs ключ объявляется глобально, в шапке конфига

key = "TEST"

 

В mavis ключ объявляется в каждой группе хостов, примерно как в радиус

host = TEST_HOST {
	address = 8.8.8.8
	enable 15 = clear secret
	key = TEST_KEY
}

 

В стандартном tacacs пользователь может находиться только в одной группе и если не подключена ACL с описанием хостов, тогда пользователь может заходить куда угодно

В mavis все по другому, тут создается список групп в которых описываются хосты, далее создаются группы пермишенов

group = admin {
	default service = permit
	service = shell {
		default command = permit
		default attribute = permit
		set priv-lvl = 15
	}
}

group = support {
	default service = permit
	enable = deny
	service = shell {
		default command = permit
		default attribute = permit
		set priv-lvl = 4
	}
}

 

Ну а дальше пользователь подключается к группам хостов через пермишен группы

user = TEST_USER{ 
	login = crypt $1$a
	member = admin@TEST_GROUP1
	member = admin@TEST_GROUP2
	member = support@TEST_GROUP3
}

 

То есть таким образом можно пользователя к одной группе устройств пускать с административными правами а к другой группе устройств только как user

Далее можно группы хостов объединять в группы, которые потом можно подключать к пользователю (Привет Active Directory)

Короче mavis это смесь tacacs+radius+AD+LDAP

[alibek]

Понятно.

С тем, что я не могу определить группы хостов или подсетей, я уже столкнулся, это действительно неудобно.

То что пользователь может находится только в одной группе, это вообще выглядит как баг — группы ведь могут быть вложенными (это уже реализовано), то есть явно предполагалось, что из отдельных групп-шаблонов будут собираться составные группы и пользователи будут включаться уже в них.

 

Да, кстати, я правильно понял, что в ACL указываются адреса NAS, а не адреса подключающихся пользователей?

То есть в ACL я фактически указываю, *на* какие устройства пользователь может зайти, а не *откуда* он заходит?

[FATHER_FBI]

То есть в ACL я фактически указываю, *на* какие устройства пользователь может зайти, а не *откуда* он заходит?

Все верно, в ACL указывает хосты/подсети на которые пользователю разрешено/запрещено подключаться.