Comments 18
Задумывался над настройкой доменной аутентификации для сетевого оборудования, останавливает вероятность возникновения ситуации, когда контроллер домена будет недоступен с циски.
Пришел к выводу, что в моей ситуации (мало устройств и два равноправных админа) — смысла настраивать нет. При аварии причины можно установить по сислогу (в том числе время авторизации админа, ip адрес с которого она происходила и изменения конфигурации).
Пришел к выводу, что в моей ситуации (мало устройств и два равноправных админа) — смысла настраивать нет. При аварии причины можно установить по сислогу (в том числе время авторизации админа, ip адрес с которого она происходила и изменения конфигурации).
пару раз теряли доступ к цискам в такой ситуации, благо консольный доступ был на внутренней авторизации
Паследнее слово 'local' в строчке конфигурации у автора 'aaa authetication… local' — в случае недоступности сервера позволяет аутентифицироваться пользователям настроенным локально на устройстве. Об этом автор также упоминает в коменте.
Если паролем не пользоваться — его забудешь. Хранить его в сейфе на бумажке можно, но опять таки специфика: час простоя телемеханики приводит к разбирательствам на уровне ростехнадзора, сейчас в случае аварии достаточно одного из админов (возможно хватит удалённого входа), а если пароль в сейфе — потребуется ещё и человек с ключом от сейфа, да и с доступом из дома ничего не получается.
Я не хочу сказать, что данный метод плох, при большом количестве устройств и/или администраторов — единой базы необходима, но в моих условиях работы это не лучший вариант.
Я не хочу сказать, что данный метод плох, при большом количестве устройств и/или администраторов — единой базы необходима, но в моих условиях работы это не лучший вариант.
Хм, вроде читал в описании 15.1 версии — что там есть возможность аутентикации напрямую в AD, без радиус сервера. Я что-то неверное прочитал или такое таки-да, возможно?
Поддержка Kerberos появилась задолго до версии 15.1, но мне тоже было бы интересно почитать про его настройку с примерами.
Там речь шла только про LDAP сервер судя по описанию. А вобще ситуация там такая SSH через Kerberos есть, но совсем не Kerberos-way. Ты можешь залогинься на роутер, с помощью пароля, но нельзя допустим получить доступ без ввода пароля когда у тебя уже есть тикет, например: kinit nshopik/admin и потом ssh nshopik/admin@switch без ввода пароля
А.
Любопытно.
А для впн можно керберос таки пользовать? Мне бы для этого LDAP бы пользовать, и вроде именно об этом я читал в релиз нотисах… я уже не помню =)
Любопытно.
А для впн можно керберос таки пользовать? Мне бы для этого LDAP бы пользовать, и вроде именно об этом я читал в релиз нотисах… я уже не помню =)
www.cisco.com/en/US/docs/ios/15_1/release/notes/151TNEWF.html#wp42593 — вот эту строку вы читали скорее всего.
LDAP этож хранилище лишь, оно не управляет выдачей паролей тикетов. Да и я как-то слабо представляю себе ваш кейс, обычно VPN устанавливают чтобы получить доступ к домен контролеру, т.е. вы никак не можете получить Kerberos Тикет прежде чем установите VPN :)
Если в вашем понимании просто использовать единую базу паролей, то я думаю тут нет никаких паролей чтобы использовать AD, чтобы пользователь использова свой логин и пароль. Тут и правда не нужен Kerberos достаточно RADIUS, мне так кажеться.
LDAP этож хранилище лишь, оно не управляет выдачей паролей тикетов. Да и я как-то слабо представляю себе ваш кейс, обычно VPN устанавливают чтобы получить доступ к домен контролеру, т.е. вы никак не можете получить Kerberos Тикет прежде чем установите VPN :)
Если в вашем понимании просто использовать единую базу паролей, то я думаю тут нет никаких паролей чтобы использовать AD, чтобы пользователь использова свой логин и пароль. Тут и правда не нужен Kerberos достаточно RADIUS, мне так кажеться.
Да, именно ее и читал =) Как раз полез искать, чтобы указать.
По логике — действительно, тикет не получить до VPN, а значит впн не будет без тикета.
Просто для VPN тогда надо прикручивать RADIUS сервер, я думал попробовать обойтись без этого. А оно никак оказывается, на Microsoft AD то.
По логике — действительно, тикет не получить до VPN, а значит впн не будет без тикета.
Просто для VPN тогда надо прикручивать RADIUS сервер, я думал попробовать обойтись без этого. А оно никак оказывается, на Microsoft AD то.
Друзья, а никто не занимался скрешиванием Cisco ASA и Cisco AD Agent для аутентификации и авторизации пользователей ломящихся в интернет? Нет людей успешно реализовавших эту схему?
Однозначно — в избранное. Спасибо за статью.
Прочитал эту статью в журнале «Системный администратор», хорошая статья, добро пожаловать )))
Sign up to leave a comment.
Аутентификация на сетевых устройствах CISCO средствами Active Directory