Access Server игнорирует скрипт post_auth, который вы изменили на диске

Изменённый mac.py, который ничего не меняет, — обычный первый симптом. Файл на диске не то, что выполняет Access Server; служба аутентификации загружает скрипт из базы конфигурации сервера, и именно эта сохранённая копия решает вопрос о входе. Пока сохранённое значение не заменено, любая проверка доказывает лишь то, что старый скрипт всё ещё работает.

Работу определяют три условия: попадало ли значение когда-либо в базу конфигурации, получала ли служба команду перечитать его, и действительно ли изменённый код выполняется при каждом подключении. У каждого свой симптом, и исправление не того условия тратит окно обслуживания.

Файл — источник, а не работающая копия

Access Server хранит скрипт post-auth под ключом auth.module.post_auth_script. Правка файла обновляет только вашу рабочую копию. Демон читает сохранённое значение, поэтому изменение остаётся невидимым, пока вы не удалите старую запись и не положите новый файл на её место. Это сохранённое значение — единственная копия, к которой обращается служба аутентификации.

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

./sacli -k auth.module.post_auth_script ConfigGet

Замените сохранённую копию, затем примените её

Удаление перед записью — не украшение. ConfigPut с --value_file заменяет значение за один шаг, а ConfigDel сначала делает невозможным оставить устаревшую или повреждённую запись. Сохраните копию работающего скрипта вне каталога скриптов, прежде чем начать.

./sacli -k auth.module.post_auth_script ConfigDel
# store the file, then apply it
./sacli -k auth.module.post_auth_script --value_file=/root/post_auth.py ConfigPut
./sacli start

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

Используйте абсолютный путь к файлу значения и убедитесь, что root может его прочитать. Путь, который разрешается из вашей оболочки, но не из учётной записи службы, даёт сохранённое значение, которое выглядит правильным в ConfigGet и отказывает при первом входе. Проверьте сохранённый результат ещё раз после sacli start, а не до него.

Охват модуля или на каждое подключение: где должно быть обращение

Python выполняет инструкции уровня модуля один раз, при загрузке скрипта. Поэтому запрос к базе, написанный в начале файла, читает таблицу во время загрузки и сохраняет этот ответ для каждого последующего подключения. Это вторая причина, по которой изменение кажется бездейственным: код выполняется, но не тогда, когда вы ожидаете.

Поместите запрос внутрь обработчика post_auth, чтобы он выполнялся при каждой аутентификации. Сохраните документированную подпись, скорректируйте результат аутентификации, который получает обработчик, и верните тот же объект, а не голое число.

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

Два пути отказа, один владелец

Если решение — локальный запрос, результатом владеет обработчик Python. Если это внешняя проверка по HTTP, пусть код возврата команды несёт ответ: обёртка, завершающаяся ненулевым кодом, отклоняет вход, и статус последней команды становится статусом скрипта без явного exit.

Держите секрет вне списка процессов. Файл, читаемый root, или значение окружения, переданное службой, безопаснее аргумента, который любой локальный пользователь может прочитать из ps. Закрепите конечную точку в переменной до вызова, чтобы опечатка проявлялась при настройке, а не во время чьего-то входа. Меняйте этот секрет так же, как любые другие учётные данные.

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

Примените без блокировки администратора

Две меры делают изменение обратимым: второй аккаунт администратора, не зависящий от скрипта, и известная исправная копия вне каталога скриптов. Примените изменение в окно обслуживания, затем до отключения посмотрите на один тестовый вход и один намеренный отказ. Если журнал показывает синтаксическую ошибку вместо решения об аутентификации, сохранённый скрипт повреждён и любой вход будет неудачным.

Два условия говорят подождать: вы не можете прочитать файл значения как root или у вас нет второго пути в интерфейс администратора. Оба превращают небольшое изменение в блокировку, и ни одно не стоит проверки на рабочем сервере в конце дня. Документация Access Server описывает интерфейс post-auth и поддерживаемые им поля.