[M-a-x-Z]

Завёл на железке пользователя с минимальными правами

username test password test privilege 1

При помощи privilege show дал ему необходимые права просмотра.

Но почему-то этому пользователю доступна команда enable и он может подниматься на 15 уровень.

Можно ли как-то запретить пользователю команду enable? Устроит, если суметь запретить её всем - администратор на железку ходит через админский контекст. В рабочем контексте ндао сохранить только урезанного юзера-мониторищика.

[sol]

Вроде как нельзя совсем запретить enable.

 

Но, можно никому не говорить пароль.

[M-a-x-Z]

Ну да, так можно.

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

 

И я очень удивлен тем, что значение привилегии для пользователя фактически игнорируется. Какой смысл её указывать 1 или 15, если в любом случае пользователь всегда входит с 1 и получает 15 при помощи энейбла, даже если ему администратор указал 1-й уровень как максимальный...

[sol]

и получает 15 при помощи энейбла, даже если ему администратор указал 1-й уровень как максимальный...

И НЕ ПОЛУЧАЕТ enable т.к. не знает пароля.

[M-a-x-Z]

и получает 15 при помощи энейбла, даже если ему администратор указал 1-й уровень как максимальный...

И НЕ ПОЛУЧАЕТ enable т.к. не знает пароля.

Ну в теории - да.

Но какой тогда вообще смысл содержания разных комбинаций для пользователя логин/пароль, если максимальные привилегии получают при помощи одного ОБЩЕГО пароля, общего для всех и не зависящего от изначального уровня пользователя? Только для правильного журналирования действий?

Изменено 19 ноября, 2016 пользователем M-a-x-Z

[sol]

Смысл в том, что enable и user level это разные механизмы и для разного.

 

enable это исторически первый механизм. Что-то вроде рута и простого пользователя в unix. Сразу максимальные привелегии, минуя все сложности. Часто это желаемое поведение (админ/пользователь) и всех устраивает.

 

Уровни пользователей появились позже и это ДРУГОЙ, более гибкий механизм. Он позволяет разграничить пользователям их права и иметь гибкую систему разрешений/запрещений. И не отменяет первого механизма а дополняет его.

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

 

Но какой тогда вообще смысл содержания разных комбинаций для пользователя логин/пароль

смысл в назначении разных прав разным пользователям.

если максимальные привилегии получают при помощи одного ОБЩЕГО пароля, общего для всех и не зависящего от изначального уровня пользователя?

И НЕ ПОЛУЧАЮТ никаких привелегий сверх того, что им разрешено, т.к. не знают enable пароля.

 

Только для правильного журналирования действий?

А это тут причём?

 

Для общего развития рассмотрите организацию с сотней-другой железок и десятком админов разной заточки, которые до кучи ещё и увольняются и нанимаются новые. Чтобы не иметь гемороя с перенастройкой пары сотен железок при увольнении/наёме и повышении/понижении статуса про enable просто забывают а юзеров-пароли-привелегии хранят или в фирменном tacacs или в кросплатформенном radius. И всё файн. Наняли/уволили, на сервере реквизиты поменяли и всё.

Ну и про локального бекдор пользователя забывать не надо, в то при обрыве связи локально с ноутбука будет не попасть. Вот локальному пользователю enable и пригодится, чтобы "перескочить" сложные политики доступа, оставшиеся на ставшем таким недоступным сервере, и сразу стать самым-самым. И приступить к траблшуту.

[M-a-x-Z]

Смысл в том, что enable и user level это разные механизмы и для разного.

 

enable это исторически первый механизм. Что-то вроде рута и простого пользователя в unix. Сразу максимальные привелегии, минуя все сложности. Часто это желаемое поведение (админ/пользователь) и всех устраивает.

 

Уровни пользователей появились позже и это ДРУГОЙ, более гибкий механизм. Он позволяет разграничить пользователям их права и иметь гибкую систему разрешений/запрещений. И не отменяет первого механизма а дополняет его.

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

 

Но какой тогда вообще смысл содержания разных комбинаций для пользователя логин/пароль

смысл в назначении разных прав разным пользователям.

если максимальные привилегии получают при помощи одного ОБЩЕГО пароля, общего для всех и не зависящего от изначального уровня пользователя?

И НЕ ПОЛУЧАЮТ никаких привелегий сверх того, что им разрешено, т.к. не знают enable пароля.

 

Только для правильного журналирования действий?

А это тут причём?

 

Для общего развития рассмотрите организацию с сотней-другой железок и десятком админов разной заточки, которые до кучи ещё и увольняются и нанимаются новые. Чтобы не иметь гемороя с перенастройкой пары сотен железок при увольнении/наёме и повышении/понижении статуса про enable просто забывают а юзеров-пароли-привелегии хранят или в фирменном tacacs или в кросплатформенном radius. И всё файн. Наняли/уволили, на сервере реквизиты поменяли и всё.

Ну и про локального бекдор пользователя забывать не надо, в то при обрыве связи локально с ноутбука будет не попасть. Вот локальному пользователю enable и пригодится, чтобы "перескочить" сложные политики доступа, оставшиеся на ставшем таким недоступным сервере, и сразу стать самым-самым. И приступить к траблшуту.

Эти рассуждения верны для классического IOS. В ASA же принципиально нельзя обеспечить вход админа с уровнем привилегий 15 (хоть что будет написано в username). Если прописать пользователя 15, то ему при входе на ASA всё-рано придётся вводить пароль enable, единый для всех юзеров. И пароль этот такаксом не сменить. Т.е., получается, что при понижении роли админа - надо всем менять пароль enable.

[resetsa]

Смысл в том, что enable и user level это разные механизмы и для разного.

 

enable это исторически первый механизм. Что-то вроде рута и простого пользователя в unix. Сразу максимальные привелегии, минуя все сложности. Часто это желаемое поведение (админ/пользователь) и всех устраивает.

 

Уровни пользователей появились позже и это ДРУГОЙ, более гибкий механизм. Он позволяет разграничить пользователям их права и иметь гибкую систему разрешений/запрещений. И не отменяет первого механизма а дополняет его.

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

 

Но какой тогда вообще смысл содержания разных комбинаций для пользователя логин/пароль

смысл в назначении разных прав разным пользователям.

если максимальные привилегии получают при помощи одного ОБЩЕГО пароля, общего для всех и не зависящего от изначального уровня пользователя?

И НЕ ПОЛУЧАЮТ никаких привелегий сверх того, что им разрешено, т.к. не знают enable пароля.

 

Только для правильного журналирования действий?

А это тут причём?

 

Для общего развития рассмотрите организацию с сотней-другой железок и десятком админов разной заточки, которые до кучи ещё и увольняются и нанимаются новые. Чтобы не иметь гемороя с перенастройкой пары сотен железок при увольнении/наёме и повышении/понижении статуса про enable просто забывают а юзеров-пароли-привелегии хранят или в фирменном tacacs или в кросплатформенном radius. И всё файн. Наняли/уволили, на сервере реквизиты поменяли и всё.

Ну и про локального бекдор пользователя забывать не надо, в то при обрыве связи локально с ноутбука будет не попасть. Вот локальному пользователю enable и пригодится, чтобы "перескочить" сложные политики доступа, оставшиеся на ставшем таким недоступным сервере, и сразу стать самым-самым. И приступить к траблшуту.

Эти рассуждения верны для классического IOS. В ASA же принципиально нельзя обеспечить вход админа с уровнем привилегий 15 (хоть что будет написано в username). Если прописать пользователя 15, то ему при входе на ASA всё-рано придётся вводить пароль enable, единый для всех юзеров. И пароль этот такаксом не сменить. Т.е., получается, что при понижении роли админа - надо всем менять пароль enable.

откройте уже для себя команду login. поставьте очень длинный enable пароль.

и гляньте в сторону

aaa authorization exec LOCAL auto-enable

[M-a-x-Z]

откройте уже для себя команду login. поставьте очень длинный enable пароль.

и гляньте в сторону

aaa authorization exec LOCAL auto-enable

Доступные мне прошивки на auto-enable ругаются.

А в этих интернетах пишут, что отключить этот механизм нельзя.

Правда оказалось, что при определённых настройках пароль enable заменяется на повторный ввод пользователем своего же пароля (наподобие sudo) и сообщает пользователю его максимальный уровеь привилегий: 2,3,4 и т.д.

Но я пока не смог понять, какая комбинация команд это включила.