Сброс пароля на Cisco ASA без простоя для схемы active/standby failover

Недавно столкнулся с проблемой: у клиента две Cisco ASA 5512-x, которые работают в режиме active/standby. Клиент забыл обновить пароли, и у всех пользователей истек срок действия пароля. ASA при попытке залогиниться только лишь сообщает об истечении срока действия и не даёт возможности сменить пароль. Так как срок действия истек у всех пользователей, то каким-либо способом подключиться и сменить пароль не представлялось возможным. Всегда был железный вариант сбросить пароль при помощи изменения регистра, но тут без простоя не обойтись. Такой вариант не подходил. Было решено использовать standby ASA, чтоб избежать простоя. Но и там были свои нюансы:

1) Если просто перезагрузить standby ASA, зайти в ROMMON mode, поменять регистр и загрузиться, то мы получим доступ и сможем сменить пароли, но как только выполним

copy startup-config running-config

то сразу standby ASA найдет активную ноду и уже будет синхронизировать конфиг оттуда.

2) Если же отключить синхронизацию и только потом загрузить конфигурацию, то standby ASA возьмет себе активные ip адреса и у нас будет конфликт.

После размышлений был придуман следующий план:

1. Перезагружаем standby ASA, заходим в ROMMON, меняем регистр на 0x41 и загружаемся:

rommon #1> confreg 0x41

rommon #2> boot

2. Теперь отключаем все интерфейсы standby ASA (можно на коммутаторе, куда подключена ASA или просто выдернуть все сетевые кабели из самой ASA).

3. Входим в privileged EXEC mode:

hostname> enable

и загружаем рабочую конфигурацию:

hostname# copy startup-config running-config

Тут standby ASA без активных интерфейсов не сможет ни синхронизировать данные, ни навредить конфликтом ip адресов, если посчитает себя активной нодой. Заходим в конфигурацию и добавляем нового пользователя для дальнейшего доступа:

hostname# configure terminal
hostname(config)# username test password test

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

hostname(config)# interface interface_id
hostname(config-if)# shutdown

5. Возвращаем регистр по умолчанию, сохраняем конфигурацию и перезагружаемся.

hostname(config)# no config-register
hostname(config)# write

Теперь standby ASA после рестарта загрузится с конфигом и необходимым нам пользователем test. Найти активную ноду для синхронизации standby ASA не сможет, так как интерфейсы выключены, а став активной ничего не испортит по той же причине.

6. Теперь, после загрузки с нужной конфигурацией, мы можем подключиться пользователем test. Подключаемся и входим в privileged EXEC mode. Далее, включаем интерфейс или интерфейсы, которые были предназначены для failover. После чего, наша standby ASA найдет активную ноду, синхронизирует конфиги и перейдет в standby режим. В этом случае, наш пользователь test будет удален, но так как в этот момент мы уже находим в privileged EXEC mode, то наша сессия останется. Если в этот момент выйти, то зайти мы уже не сможем, поэтому здесь надо быть предельно внимательным. Также включатся все остальные интерфейсы из-за синхронизации конфигурации с активной ноды.

Менять пароли пользователей мы можем только на активной ноде, но доступа у нас к ней все еще нет. Выход сделать нашу stanby ASA активной с нашим уже существующим доступом. Когда наша standby ASA перейдет в состояние standby ready после синхронизации с активной нодой, то можно сделать переключение. Посмотреть состояние можно при помощи команды:

hostname(config)# show failover state

А при помощи второй команды переключимся с Active ASA на Standby ASA:

hostname(config)# failover active

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

Таким образом, мы можем сбросить пароли без простоя в данной схеме. Учитывать надо только задержку при переключении с активной ноды на резервную.
Share post
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 17

    0
    Странный у вас клиент… додумался выстрелить себе в ногу, но зарядил холостой патрон. Намекните ему, что бы в следующий раз было ещё интереснее добавить авторизацию вводимых команд.
      0
      Учитывать надо только задержку при переключении с активной ноды на резервную.

      Очень надо. Был прецедент — собрали на асе-5505 локалку помимо hot standby-конфигурации, потом навернули на неё прорву всего, в результате failover выполнялся дольше двух минут, локалка порвалась, вместе с ней упал двухнодовый кластер Microsoft, собранный, естественно, с нарушениями. (Точнее, переехали ресурсы кластера как при катастрофе из-за потери связности внутри кластера).

        0
        Не встречался с таким, при запланированном переходе не наблюдалось большой задержки или разрыва сессий. Спасибо за замечание, надо быть осторожнее.
          0
          Failover был дольше двух минут при ручном переключении или при отказе узла?
            0
            При ручном переключении через ASDM.
          0
          Статья в копилку знаний!
            0
            Всю статью можно уложить в одно предложение.
            «Внимание, перед восстановлением пароля отключите синхронизацию в кластере!»
              +1
              Если отключить, то после рестарта standby возьмет себе активные ip адреса.
                0
                … и выключите все интерфейсы (кроме консольного).
                  0
                  А потом правильно включить сихнронизацию и правильно получить доступ к активной ноде.
                0
                «никогда не используйте локальную авторизацию на сетевых устройствах, кроме одного локального аккаунта на случай потери связи»
              0
              Не на чем сейчас протестировать, но, мне кажется, должна сработать такая процедура:

              1) Standby ASA отправляем в ребут и меняет конф регистр.
              2) Она загружается без конфига, спокойно заходим в enable
              3) Загружаем конфиг в running
              4) Теперь у нас опять кластер из двух ASA, для которых мы не знаем пароль, но при этом мы находимся в enable на Standby ASA.
              5) Делаем failover active, и вот мы на Active ASA в enable режиме
              6) Меняем пароли

              Т.е. не очень понятно для чего нужно отключать интерфейсы и делать вторую перезагрузку.
                0
                С п.3 могут возникнуть проблемы.
                  0
                  Ответил ниже. Команда на третьем шаге copy startup-config running-config отрабатывала некорректно при тестированиях.
                  0
                  За статью спасибо, но я не понял зачем создавать пользователя и ребутаться, если попасть в привелигированный режим можно сразу после загрузки через rommon.
                    0
                    При тестирование возникли проблемы при горячей загрузке start-up config-a, то есть команда copy startup-config running-config отрабатывала некорректно. Возможно, на различных конфигах отрабатывает по-разному. Но как правильно, всегда лучше забутиться сразу со startup-config-ом.
                      0
                      «Copy startup-config running-config» — очень специфическая команда, для которой очень мало практического применения.
                      В cisco для «горячей» замены конфигурации используют «configure replace».
                      Но в ASA этот механизм, на сколько мне известно, (ещё) не реализован.

                  Only users with full accounts can post comments. Log in, please.