Если вы администратор Linux и хотите максимально обезопасить свои серверы и настольные компьютеры, вы наверняка задумывались об использовании двухфакторной аутентификации. Вообще, настроить ее настоятельно рекомендуется каждому, так как двухфакторная аутентификация заметно усложняет злоумышленникам задачу получить доступ к вашим машинам.
Linux позволяет настроить компьютер так, что войти в консоль, рабочий стол или через Secure Shell будет нельзя без кода двухфакторной аутентификации, привязанного к этой машине. Рассмотрим весь процесс настройки на системе Ubuntu Server 16.04.
Введение
Прежде чем начать, нужно учесть один факт - после настройки двухфакторной аутентификации вы не сможете получить доступ к вашему компьютеру без сгенерированных третьей стороной кодов. Каждый раз, когда вы захотите войти в систему, вам понадобится либо ваш смартфон, либо экстренные коды (emergency codes), которые можно настроить в процессе.
Нам понадобится сервер или десктоп Linux. Убедитесь, что система в актуальном состоянии, а ваши данные скопированы на случай непредвиденных обстоятельств. Для создания двухфакторных кодов будем использовать стороннее приложение, например, Authy или Google Authenticator. Условно будем пользоваться Google Authenticator, которое нужно предварительно установить.
Установка
Залогиньтесь в системе и выполните следующие шаги:
- Откройте окно терминала.
- Выполните команду: sudo apt install libpam-google-authenticator .
- Введите пароль sudo и нажмите Enter.
- Если появится запрос на подтверждение, введите «y» и нажмите Enter.
- Дождитесь конца установки.
Теперь пришло время настроить компьютер на двухфакторную аутентификацию.
Конфигурация
Вернитесь в окно терминала и введите команду: sudo nano /etc/pam.d/common-auth . Добавьте следующую строку в конец файла:
Сохраните и закройте этот файл.
Теперь мы должны настроить Google Authenticator для каждого пользователя, кто должен иметь доступ в систему. Для этого нужно вернуться в окно терминала и от лица пользователя, которому планируется предоставить доступ, запустить команду google-authenticator. Здесь придется ответить на пару вопросов.
Первый вопрос: «Хотите ли вы, чтобы токены аутентификации были основаны на времени (y/n)» («Do you want authentication tokens to be time-based (y/n)»). Ответьте «y», вам будет предоставлен QR-код. Откройте на своем смартфоне двухфакторное приложение, добавьте учетную запись и отсканируйте этот QR-код.
Рисунок 1. Полученный QR-код
После того, как вы добавите код, останется ответить еще на несколько вопросов:
- Do you want me to update your "/home/jlwallen/.google_authenticator" file (y/n) - Хотите ли вы обновить файл/home/jlwallen/.google_authenticator;
- Do you want to disallow multiple uses of the same authentication token (y/n)? - Хотите ли вы отключить возможность многократного использования одного токена? Эта настройка позволяет выполнять только один вход в систему каждые 30 секунд. Если эта опция активирована, ваши шансы заметить или даже предотвратить атаку вида « » (man-in-the-middle) возрастают.
- Поскольку значением по умолчанию является 30 секунд, а время сервера и клиента может незначительно отличаться, есть возможность использовать некий дополнительный токен. Следовательно, если у вас возникают проблемы с синхронизацией, вы можете увеличить время окна примерно до 4 минут. Хотите ли вы это сделать? - Do you want to do so (y/n).
- Если вы сомневаетесь в защите вашего компьютера от атак типа брутфорс (brute-force), вы можете активировать ограничение скорости для модуля аутентификации. По умолчанию это не более 3 попыток входа в систему каждые 30 секунд. Хотите ли вы включить ограничение скорости? - Do you want to enable rate-limiting (y/n)
Ответим на каждый вопрос утвердительно, введя «y» и нажав Enter.
Настройка SSH
Следующим шагом будет настройка SSH для работы с двухфакторной аутентификацией. Если этот шаг пропустить, вы не сможете войти через SSH.
Сначала надо включить модуль PAM. Для этого набираем команду: sudo nano /etc/pam.d/sshd . Открыв файл, добавляем следующую строку в конец файла:
auth required pam_google_authenticator.so nullok
Сохраняем этот файл, а затем выполняем команду: sudo nano /etc/ssh/sshd_config . В этом файле находим:
ChallengeResponseAuthentication no
И меняем на:
ChallengeResponseAuthentication yes
Сохраняем этот файл и перезапускаем sshd - sudo systemctl restart sshd .
Вход в систему
Прежде чем осуществить выход из системы, настоятельно рекомендуем вам открыть новое окно терминала и попытаться выполнить вход через SSH. Если это сделать не удалось, повторите все описанные выше шаги, убедившись, что вы ничего не пропустили. После того, как вам удастся успешно залогиниться через SSH, вы можете завершить сеанс и снова войти в систему.
Выводы
Двухфакторная аутентификация (2FA) — это метод аутентификации, который для входа в учетную запись или на устройство требует несколько фрагментов информации. Кроме комбинации имени пользователя и пароля, 2FA требует, чтобы пользователь вводил дополнительную информацию, такую как одноразовый пароль (OTP, например шестизначный проверочный код).
В целом, 2FA требует от пользователя ввода информации разных типов:
- Что-то, что пользователь знает (например, пароль)
- Что-то, что у пользователя есть (например, код подтверждения, сгенерированный специальным приложением – аутентификатором).
2FA – это подвид многофакторной аутентификации (MFA). Метод MFA в дополнение к тому, что пользователь знает, и тому, что у него есть, требует чего-то, чем он является. Это биометрические данные: распознавание отпечатков пальцев или голоса и т. д.
2FA помогает защитить процесс аутентификации для определенного сервиса или устройства: даже если пароль был взломан, злоумышленнику также потребуется код безопасности, а для этого нужен доступ к устройству пользователя, в котором находится приложение-аутентификатор. По этой причине многие онлайн-сервисы предлагают возможность включить 2FA для учетных записей пользователей, чтобы повысить безопасность аккаунтов на уровне аутентификации.
В этом мануале вы узнаете, как настроить 2FA с помощью модуля Google PAM для пользователя без привилегий root в Ubuntu 18.04. Поскольку вы настраиваете 2FA для не-root пользователя, в случае блокировки вы все равно сможете получить доступ к компьютеру из своей учетной записи root. Инструкции мануала достаточно общие, потому их можно применить как к серверам, так и к настольным установкам, как локальным, так и удаленным.
Требования
- Сервер Ubuntu 18.04 или настольная рабочая среда. Сервер Ubuntu 18.04 нужно настроить по .
- Аутентификатор, установленный на мобильное устройство (например, Google Authenticator или Authy). С его помощью вы будете сканировать QR-коды безопасности.
1: Установка модуля Google PAM
Чтобы настроить 2FA в Ubuntu 18.04, вам нужно установить модуль Google PAM для Linux. Pluggable Authentication Module (PAM) – это механизм аутентификации, используемый Linux. Модуль Google PAM позволит вашему пользователю проходить аутентификацию 2FA, используя сгенерированные Google коды OTP.
Сначала войдите в систему как пользователь sudo, которого вы создали во время начальной настройки сервера:
ssh 8host@your_server_ip
Обновите индекс пакетов Ubuntu, чтобы получить последнюю версию аутентификатора:
sudo apt-get update
Обновив репозитории, установите последнюю версию модуля PAM:
sudo apt-get install libpam-google-authenticator
Это очень маленький пакет без каких-либо зависимостей, поэтому установка займет несколько секунд. В следующем разделе мы настроим 2FA для пользователя sudo.
2: Настройка двухфакторной аутентификации
Теперь, когда вы установили модуль PAM, запустите его, чтобы сгенерировать QR-код для вошедшего в систему пользователя. Это создаст код, но среде Ubuntu не потребуется 2FA, пока вы не включите ее.
Запустите команду google-authenticator, чтобы запустить и настроить модуль PAM:
google-authenticator
Команда задаст вам несколько вопросов о конфигурации. Сначала она спросит, хотите ли вы, чтобы токены были ограничены по времени. Токены аутентификации, ограниченные по времени, истекают через определенный интервал (он по умолчанию составляет 30 секунд в большинстве систем). Токены с ограниченным временем действия более безопасны, чем токены без такого ограничения, и большинство реализаций 2FA используют их. Вы можете выбрать здесь любой вариант, но мы рекомендуем выбрать Yes и использовать токены аутентификации, ограниченные по времени:
Do you want authentication tokens to be time-based (y/n) y
Ответив y на этот вопрос, вы увидите несколько строчек вывода в консоли:
- QR-код: это код, который необходимо сканировать с помощью приложения-аутентификатора. После того, как вы отсканировали его, приложение будет создавать новый OTP каждые 30 секунд.
- Секретный ключ: это альтернативный способ настройки приложения аутентификации. Если вы используете приложение, которое не поддерживает сканирование QR, вы можете ввести секретный ключ, чтобы настроить аутентификатор.
- Проверочный код: это первый шестизначный код, который генерирует этот конкретный QR-код.
- Аварийные скретч-коды. это одноразовые токены (также они называются резервными кодами), они позволят вам пройти аутентификацию 2FA, если вы потеряете устройство-аутентификатор. Храните эти коды в надежном месте, чтобы избежать блокировки учетной записи.
После того, как вы настроили свое приложение-аутентификатор и сохранили свои резервные коды в безопасном месте, программа спросит, хотите ли вы обновить файл конфигурации. Если вы выберете n, вам нужно будет снова запустить программу настройки. Введите y, чтобы сохранить изменения и продолжить:
Do you want me to update your "~/.google_authenticator" file (y/n) y
Далее программа спросит, хотите ли вы запретить использование кодов аутентификации более одного раза. По умолчанию вы можете использовать каждый код только один раз, даже если еще не прошло 30 секунд с момента его создания. Это самый безопасный выбор, потому что он предотвращает атаки повторного воспроизведения от злоумышленника, которому каким-то образом удалось получить ваш использованный код подтверждения. По этой причине лучше запретить использование кодов более одного раза. Ответьте y, чтобы запретить многократное использование одного и того же токена:
Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n) y
Затем нужно указать, хотите ли вы, чтобы токены аутентификации принимались некоторое время после истечения их обычного срока действия. Коды очень чувствительны ко времени, а потому они могут не сработать, если ваши устройства не синхронизированы. Эта опция позволяет обойти эту проблему, увеличив время действия кодов проверки по умолчанию, чтобы коды аутентификации были приняты в любом случае (даже если ваши устройства временно не синхронизированы). Лучше всего убедиться в том, что время на всех ваших устройствах синхронизировано, так как ответ yes немного снизит безопасность системы. Ответьте n на этот вопрос, чтобы не увеличивать срок действия токена:
By default, tokens are good for 30 seconds and in order to compensate for
possible time-skew between the client and the server, we allow an extra
token before and after the current time. If you experience problems with poor
time synchronization, you can increase the window from its default
size of 1:30min to about 4min. Do you want to do so (y/n) n
Последний вопрос: хотите ли вы включить ограничение количества попыток входа в систему. Это не позволит пользователю сделать более трех неудачных попыток входа в систему в течение 30 секунд, что усилить безопасность системы. Включите это ограничение, ответив y:
If the computer that you are logging into isn"t hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting (y/n) y
Вы настроили и сгенерировали коды 2FA с помощью модуля PAM. Теперь нужно включить 2FA в вашей среде.
3: Активация 2FA в Ubuntu
Модуль Google PAM теперь генерирует коды 2FA для вашего пользователя, но система Ubuntu еще не знает, что ей нужно использовать коды в процессе аутентификации. На этом этапе нужно обновить конфигурацию Ubuntu, чтобы настроить поддержку токенов 2FA в дополнение к обычной аутентификации.
Здесь есть два пути:
- Вы можете требовать двухфакторной аутентификации каждый раз, когда пользователь входит в систему, и каждый раз, когда пользователь запрашивает права sudo.
- Вы можете требовать 2FA только во время входа в систему, тогда при запросе прав sudo потребуется только пароль пользователя.
Первый вариант будет идеальным для общей среды, где желательно защитить любые действия, требующие привилегий sudo. Второй подход более практичен для локальной среды рабочего стола, где вы являетесь единственным пользователем в системе.
Примечание : Если вы включаете 2FA на удаленной машине, к которой вы получаете доступ по SSH, вам необходимо выполнить шаги два и три из мануала , прежде чем продолжать работу. Остальные шаги в этом мануале применимы ко всем установкам Ubuntu, но удаленные среды нуждаются в дополнительных настройках, чтобы сервис SSH знал о 2FA.
Если вы не используете SSH для доступа к установке Ubuntu, вы можете сразу же перейти к остальным шагам в этом мануале.
Запрос 2FA при входе в систему и повышении прав sudo
Чтобы система использовала 2FA во время входа и последующих запросов на повышение привилегий, вам необходимо отредактировать файл /etc/pam.d/common-auth, добавив строку в конец существующего файла.
Файл common-auth применяется ко всем механизмам аутентификации в системе, независимо от используемой среды. Он также применяется к запросам аутентификации, которые происходят после входа пользователя в систему, например, во время запроса прав sudo при установке нового пакета из терминала.
Откройте файл:
sudo nano /etc/pam.d/common-auth
В конец файла добавьте:
...
# and here are more per-package modules (the "Additional" block)
session required pam_unix.so
Эта строка включает в системе аутентификации Ubuntu поддержку 2FA при входе через модуль Google PAM. Опция nullok позволяет существующим пользователям войти в систему, даже если они не настроили аутентификацию 2FA для своей учетной записи. Другими словами, пользователи, которые настроили 2FA, должны будут ввести код аутентификации при следующем входе в систему, в то время как пользователи, которые не запустили команду google-authenticator, смогут войти в систему по своим стандартным учетным данным, пока они не настроят 2FA.
Сохраните и закройте файл.
Запрос 2FA только при входе в систему
Если вы хотите, чтобы 2FA запрашивалась только при входе в систему в среде рабочего стола, вам нужно отредактировать конфигурационный файл используемого вами менеджера рабочего стола. Имя конфигурационного файла обычно совпадает с именем среды рабочего стола. Например, файл конфигурации для gdm (среды Ubuntu по умолчанию, начиная с Ubuntu 16.04), — /etc/pam.d/gdm.
В случае headless сервера (каким является виртуальный сервер), вместо этого вам нужно отредактировать файл /etc/pam.d/common-session. Откройте соответствующий файл в зависимости от вашей среды:
sudo nano /etc/pam.d/common-session
Добавьте выделенные строки в конец файла:
#
# /etc/pam.d/common-session - session-related modules common to all services
#
...
# # and here are more per-package modules (the "Additional" block)
session required pam_unix.so
session optional pam_systemd.so
# end of pam-auth-update config
auth required pam_google_authenticator.so nullok
Теперь Ubuntu будет требовать 2FA, когда пользователь подключается к системе через командную строку (локально или удаленно через SSH), но на запуск команд с sudo это распространяться не будет.
Вы настроили Ubuntu для поддержки 2FA. Теперь пора протестировать конфигурацию и убедиться, что при входе в вашу систему Ubuntu вам будет предложено ввести код безопасности.
4: Тестирование двухфакторной аутентификации
Ранее вы настроили 2FA для генерации кодов каждые 30 секунд. Теперь попробуйте войти в свою среду Ubuntu.
Сначала выйдите из системы и снова войдите в свою среду Ubuntu:
ssh 8host@your_server_ip
Если вы используете аутентификацию на основе пароля, вам будет предложено ввести пароль пользователя:
Примечание : Если на удаленном сервере вы используете аутентификацию по сертификатам, пароль запрошен не будет. Ключ будет передан и принят автоматически. Вам нужно будет ввести только код подтверждения.
Введите пароль, после чего вам будет предложено ввести код 2FA:
Verification code:
После этого вы попадете в систему:
8host@your_server_ip: ~#
Если 2FA была включена только для входа в систему, вам больше не нужно будет вводить коды подтверждения 2FA, пока не закончится сеанс или вы не выйдете вручную.
Если вы включили 2FA через файл common-auth, вам будет предложено указать его также при каждом запросе привилегий sudo:
8host@your_server_ip: ~# sudo -s
sudo password for 8host:
Verification code:
root@your_server_ip:
Вы убедились, что конфигурация 2FA работает должным образом. Если что-то пошло не так и система не запросила у вас коды подтверждения, вернитесь к третьему разделу руководства и убедитесь, что вы отредактировали правильный файл аутентификации Ubuntu.
5: Предотвращение блокировки 2FA
На случай утери или уничтожения мобильного устройства важно предусмотреть методы резервного копирования для восстановления доступа к вашей учетной записи с поддержкой 2FA. Когда вы настраиваете 2FA в первый раз, у вас есть несколько вариантов восстановления доступа после блокировки:
- Сохраните резервную копию ваших секретных кодов конфигурации в безопасном месте. Вы можете сделать это вручную, но некоторые приложения аутентификации, такие как Authy, предоставляют функции резервного копирования кода.
- Сохраните коды восстановления в безопасном месте за пределами среды с поддержкой 2FA, к которому можно получить доступ в случае необходимости.
Если по какой-либо причине у вас нет доступа к параметрам резервного копирования, вы можете попробовать восстановить доступ к локальной среде или удаленному серверу с поддержкой 2FA другим путем.
6: Восстановление доступа к локальной среде (опционально)
Если у вас есть физический доступ к машине, вы можете загрузиться в режиме восстановления, чтобы отключить 2FA. Режим восстановления – это целевой тип (подобный уровню выполнения) в Linux, который используется для выполнения административных задач. Вам нужно будет отредактировать некоторые настройки в GRUB, чтобы войти в режим восстановления.
Чтобы получить доступ к GRUB, сначала перезагрузите компьютер:
Когда появится меню GRUB, убедитесь, что запись Ubuntu выделена. Это имя установки 18.04 по умолчанию, но оно может отличаться, если вы вручную изменили его после установки.
Затем нажмите клавишу e на клавиатуре, чтобы отредактировать конфигурацию GRUB перед загрузкой вашей системы.
Перейдите в конец появившегося файла и найдите строку, которая начинается с linux и заканчивается $vt_handoff. Перейдите в конец этой строки и добавьте systemd.unit=rescue.target. Убедитесь, что вы оставляете пробел между $vt_handoff и systemd.unit=rescue.target. Это позволит машине Ubuntu загрузиться в режиме восстановления.
После внесения изменений сохраните файл с помощью комбинации клавиш Ctrl + X. Ваша машина перезагрузится, и вы окажетесь в командной строке. Нажмите Enter, чтобы перейти в режим восстановления.
Оказавшись в командной строке, откройте конфигурационный файл Google Authenticator, который расположен в домашнем каталоге заблокированного пользователя.
nano /home/8host/.google-authenticator
Первая строка в этом файле – секретный ключ пользователя, который используется для настройки аутентификатора.
Теперь у вас есть два варианта:
- Вы можете скопировать секретный ключ и настроить аутентификатор.
- Если вы хотите начать с чистого листа, вы можете полностью удалить файл ~/.google-authenticator, чтобы отключить 2FA для этого пользователя. После повторного входа в систему вы сможете еще раз настроить 2FA и получить новый секретный ключ.
В любом случае вы можете восстановить систему после блокировки 2FA в локальной среде с помощью загрузчика GRUB. Далее мы расскажем, как восстановить доступ к заблокированной удаленной среде.
7: Восстановление доступа к удаленной среде (опционально)
Если ваш аккаунт sudoer заблокирован в удаленной среде, вы можете временно отключить или перенастроить 2FA с помощью пользователя root.
Войдите в систему как пользователь root:
ssh root@your_server_ip
После входа в систему откройте файл настроек Google Authenticator, который находится в домашнем каталоге заблокированного пользователя:
sudo nano /home/8host/.google_authenticator
Первая строка в этом файле — это секретный ключ пользователя, который вам необходим для настройки аутентификатора.
Теперь у вас есть два пути:
- Если вы хотите настроить новое или стертое устройство, вы можете использовать секретный ключ для перенастройки приложения-аутентификатора.
- Если вы хотите начать с чистого листа, вы можете полностью удалить файл /home/8host/.google_authenticator, чтобы отключить 2FA для этого пользователя. После входа в систему как пользователь sudo вы сможете еще раз настроить 2FA и получить новый секретный ключ.
При любом из этих вариантов вы сможете восстановиться после случайной блокировки 2FA, используя аккаунт root.
Заключение
В этом мануале вы настроили 2FA на машине Ubuntu 18.04. Двухфакторная аутентификация обеспечивает дополнительный уровень защиты учетной записи и системы в целом. Помимо стандартных учетных данных вам также потребуется ввести дополнительный код подтверждения для входа в систему. Это делает невозможным получить несанкционированный доступ к вашему аккаунту, даже если злоумышленнику удастся получить ваши учетные данные.
Tags: ,- Установленная система ROSA Enterprise Linux Server версии не ниже 6.8 в конфигурации «Стандартный сервер РОСА»
- Доступ к репозиториям
- Устройство Рутокен ЭЦП/Рутокен ЭЦП Flash/Рутокен ЭЦП SC вместе с ридером. На устройство должен быть записан сертификат
Для получения доступа к репозиториям получите у службы поддержки ключ и выполните следующую команду с правами администратора:
Echo <ключ> > /etc/rosa-support-id-server
Применимость
В инструкции описаны установка и настройка утилит ROSA Enterprise Linux Server, необходимых для аутентификации с использованием Рутокен ЭЦП. В примере используется архитектура AMD64; для 32-разрядной системы все действия будут аналогичны с точностью до названий папок.
После выполнения нижеприведённой процедуры аутентификация по Рутокен ЭЦП станет возможной, но не будет являться обязательной.
Установка компонентов
Установите требуемые и удалите конфликтующие утилиты (требуются права администратора):
Su yum install ccid opensc pam_pkcs11 gdm-plugin-smartcard yum remove coolkey
Установите библиотеку PKCS#11 для Рутокен ЭЦП (важно устанавливать библиотеку после установки утилит):
- Перейдите на сайт Рутокен: https://www.rutoken.ru/support/download/pkcs/ .
- Откройте вкладку «Пользователям GNU/Linux» и нажмите на ссылку «Библиотека rtPKCS11ecp для GNU/Linux RPM 64-bit (x64)».
- Скачайте и установите пакет (требуется пароль администратора).
Настройка
Проверка отображения устройства в системе и наличия на нём нужной информации
- Запустите pcscd (требуются права администратора):
- Завершите существующий процесс pcscd , если таковой имелся:
С этого момента токен должен быть вставлен в соответствующий разъём.
- Выполните:
- Откройте отдельную вкладку или окно терминала и выполните в ней следующую команду:
В выводе должны быть видны параметры и название устройства. Пример вывода приведён ниже.
- Проверьте наличие на токене нужной информации при помощи следующей команды (требуется пароль от токена):
В выводе обязан присутствовать Certificate Object . Такие параметры, как ID и label , могут отличаться от приведённых ниже.
Добавление сертификата в доверенные
- Создайте базу данных доверенных сертификатов (требуются права администратора):
- Скопируйте сертификат с токена (требуется пароль токена. Параметр ID можно взять из вывода команды pkcs11-tool --module /usr/lib64/librtpkcs11ecp.so -O -l) :
- Добавьте сертификат в доверенные (требуются права администратора):
Изменение конфигурационных файлов
Для изменения конфигурационных файлов потребуются права администратора.
pam_pkcs11.conf
- Создайте (например, на рабочем столе) текстовый файл pam_pkcs11.conf со следующим содержимым:
- Поместите файл в каталог /etc/pam_pkcs11/:
system-auth
- Подключите модуль к системе авторизации PAM:
- Откройте файл system-auth в редакторе nano или mcedit :
- Добавьте вверху следующую строку:
- Сохраните файл (
subject_mapping
- Выполните команды:
- Скопируйте вывод предыдущей команды в файл /etc/pam_pkcs11/subject_mapping и укажите, какому пользователю принадлежит сертификат.
Строка конфигурации имеет вид:
Вывод команды pkcs11_inspect -> <имя_пользователя>
Проверка аутентификации через консоль
- Откройте новое окно или вкладку консоли.
- Выполните команду su <имя_пользователя> (имя пользователя указано в subject_mapping).
Пример вывода:
После проверки работы аутентификации через консоль можно убрать режим отладки. Для этого в файле /etc/pam.d/sysauth в добавленной строке уберите слово debug , а в файле /etc/pam_pkcs11/pam_pkcs11.conf поставьте напротив debug false вместо true .
Настройка блокировки экрана
- Откройте для редактирования файл pkcs11_eventmgr (требуются права администратора):
После редактирования конфигурационный файл должен выглядеть следующим образом:
Pkcs11_eventmgr { # Run in background? Implies debug=false if true daemon = true; # show debug messages? debug = false; # polling time in seconds polling_time = 1; # expire time in seconds # default = 0 (no expire) expire_time = 0; # pkcs11 module to use pkcs11_module = /usr/lib64/librtpkcs11ecp.so; # # list of events and actions # Card inserted event card_insert { # what to do if an action fail? # ignore: continue to next action # return: end action sequence # quit: end program on_error = ignore ; } # Card has been removed event card_remove { on_error = ignore; action = "gdmflexiserver"; } # Too much time card removed event expire_time { on_error = ignore; action = "/bin/false"; } }
- Добавьте утилиту pkcs11_eventmgr в автозагрузку. Для этого отредактируйте файл.bash_profile пользователя, проходящего аутентификацию:
- Добавьте в конец файла строку, запускающую pkcs11_eventmgr .
Пример файла.bash_profile после редактирования:
При выборе аутентификации при помощи токена экран будет выглядеть примерно так.
Windows уже довольно давно поставляется в комплекте с интегрированной системой сетевой проверки подлинности и единого входа. До Windows 2000 контроллеры доменов Windows NT предоставляли клиентам Windows службы проверки подлинности, используя протокол NTLM. Хотя NTLM не был так защищен, как казалось первоначально, он был очень полезен, поскольку давал удобное решение проблеме необходимости поддерживать дубликаты учетных записей пользователя на различных серверах сети.
Начиная с Windows 2000, корпорация Майкрософт перешла с NTLM на Active Directory и ее интегрированные службы проверки подлинности Kerberos. Kerberos был значительно защищеннее NTLM, а также лучше масштабировался. К тому же, Kerberos был стандартом отрасли, уже используемым системами Linux и UNIX, что открыло врата интеграции этих платформ с Windows.
Проверка подлинности Linux
Первоначально Linux (а также средства и библиотеки GNU, работавшие на нем) не рассчитывался на единый механизм проверки подлинности. Как следствие этого, разработчики приложений Linux обычно брались за разработки собственных схем проверки подлинности. Им удавалось добиться этого либо за счет поиска хэш-кодов имен и паролей в /etc/passwd (текстовом файле, традиционно содержащем учетные данные пользователей Linux) или предоставления совершенно иного (и отдельного механизма).
Получившийся ассортимент механизмов проверки подлинности был неуправляемым. В 1995 г. компания Sun предложила механизм, именуемый подключаемыми модулями проверки подлинности (Pluggable Authentication Modules - PAM). PAM предоставляли общий набор интерфейсов API проверки подлинности, который мог использоваться всеми разработчиками приложений, а также настраиваемый администратором серверный элемент, позволяющий использовать различные «подключаемые» схемы проверки подлинности. Использование интерфейсов API PAM для проверки подлинности и интерфейсов API переключателя сервера имен (Name Server Switch - NSS) для поиска сведений о пользователе позволило разработчикам приложений Linux писать меньше кода, а администраторам Linux управлять процессом проверки подлинности и настраивать его из одного места.
Большинство выпусков Linux снабжались несколькими модулями проверки подлинности PAM, включая модули, поддерживающие проверку подлинности в каталоге LDAP и проверку подлинности с использованием Kerberos. Эти модули можно использовать для проверки подлинности в Active Directory, но на это существуют значительные ограничения, о которых я расскажу ниже в данной статье.
Samba и Winbind
Samba - это проект с открытым исходным кодом, целью которого является интеграция между средами Windows и Linux. Samba содержит компоненты, дающие компьютерам Linux доступ к службам файлов и печати Windows, а также предоставляющие службы на основе Linux, которые имитируют контроллеры доменов Windows NT 4.0. Используя клиентские компоненты Samba, компьютеры Linux могут пользоваться службами проверки подлинности Windows, предоставляемыми контроллерами доменов Windows NT и Active Directory.
Для нас особо интересна часть Samba, именуемая Winbind. Winbind - это демон («служба» в терминах Windows), работающий на клиентах Samba и действующий как прокси для связи между PAM и NSS, работающими на компьютере Linux, с одной стороны, и Active Directory, работающей на контроллере домена, с другой. В частности, Winbind использует Kerberos для проверки подлинности с помощью Active Directory и LDAP для получения информации о пользователях и группах. Winbind также предоставляет дополнительные услуги, такие, как возможность обнаруживать контролер домена, используя алгоритм, подобный DCLOCATOR в Active Directory, и возможность сбрасывать пароли Active Directory, связываясь с контроллером домена при помощи RPC.
Winbind решает ряд проблем, сохраняющихся при простом использовании Kerberos с помощью PAM. В частности, вместо жесткого кодирования контроллера домена для проверки подлинности PAM Winbind выбирает контроллер домена путем поиска по записям локатора DNS подобно тому, как это делает модуль DC LOCATOR Майкрософт.
Три стратегии проверки подлинности
Учитывая доступность LDAP, Kerberos и Winbind на компьютерах Linux, существуют три различные стратегии реализации, которые можно применить, чтобы дать компьютеру Linux возможность использовать Active Directory для проверки подлинности.
Использование проверки подлинности LDAP Простейший, но наименее удовлетворительный способ использования Active Directory для проверки подлинности - настроить PAM на использование проверки подлинности LDAP, как показано на рис. 1 . Хотя Active Directory и является службой LDAPv3, клиенты Windows используют для проверки подлинности Kerberos (с NTLM в качестве резервного варианта), а не LDAP.
При проверке подлинности LDAP (именуемой привязкой LDAP) имя пользователя и пароль передаются открытым текстом через сеть. Это небезопасно и недопустимо для большинства целей.
Рис 1. Проверка подлинности в Active Directory с использованием LDAP
Единственным способом смягчения этого риска открытой передачи учетных данных является шифрование канала связи клиент-Active Directory с использованием чего-нибудь вроде SSL. Это определенно возможно, но возлагает дополнительную нагрузку управления сертификатами SSL как на компьютер контроллера домена, так и на компьютер Linux. Вдобавок, использование модуля LDAP PAM не поддерживает изменения сброшенных или истекших паролей.
Использование LDAP и Kerberos Другой стратегией использования Active Directory для проверки подлинности Linux является настройка PAM на использование проверки подлинности Kerberos и NSS на использование LDAP для поиска информации о пользователях и группах, как показано на рис. 2 . Эта схема имеет преимущество относительной защищенности, и в ней используются «встроенные» возможности Linux. Но она не использует записи расположения службы (SRV) DNS, публикуемые контроллерами доменов Active Directory, что заставляет проверить определенный набор контроллеров домена, чтобы проверить подлинность по ним. Это также не дает особенно интуитивного способа управления истекающими паролями Active Directory или, до недавнего времени, адекватного поиска членов групп.
Рис 2. Проверка подлинности в Active Directory с использованием LDAP и Kerberos
Использование Winbind Третьим способом использования Active Directory для проверки подлинности Linux является настройка PAM и NSS на выполнение вызовов к управляющей программе Winbind. Winbind переведет различные запросы PAM и NSS в соответствующие вызовы Active Directory, используя LDAP, Kerberos или RPC, в зависимости от того, что будет наиболее подходящим. На рис. 3 приведен наглядный пример данной стратегии.
Рис 3. Проверка подлинности в Active Directory с использованием Winbind
Наш план реализации
Усовершенствованная интеграция с Active Directory заставила меня выбрать Winbind на Red Hat Enterprise Linux 5 (RHEL5) для моего проекта интеграции Linux-Active Directory. RHEL5 - текущая версия коммерческого выпуска Red Hat Linux, и она довольно популярна в корпоративных центрах обработки данных.
Чтобы RHEL5 проверял подлинность через Active Directory, нужны, по сути, пять следующих отдельных действий:
- Найти и загрузить подходящий пакет Samba и другие зависимые компоненты.
- Собрать Samba.
- Установить и настроить Samba.
- Настроить Linux, конкретно PAM и NSS.
- Настроить Active Directory.
В нескольких следующих разделах этой статьи данные действия описаны более подробно.
Поиск нужных программ
Одним из крупнейших различий между Linux и Windows является то, что Linux состоит из маленького ядра операционной системы и огромной коллекции отдельно загружаемых и устанавливаемых компонентов. Это делает возможным создание очень тщательно подобранных комплектов Linux, оптимальных для определенных задач, но также делает очень сложными настройку сервера и управление им. Различные дистрибутивы справляются с этим различными способами. Red Hat (и его некоммерческая родственница Fedora) используют для установки этих компонентом и управления ими диспетчер пакетов Red Hat Package Manager (RPM).
Компоненты Linux для Red Hat имеют две формы. Файлы RPM содержат двоичные файлы, которые были заранее скомпилированы и собраны для определенного сочетания версии компонента, выпуска Linux и архитектуры ЦП. Так что можно загрузить и установить, для примера, версию 1.3.8-5 стандартной системы печати UNIX (Common UNIX Printing System - CUPS), собранную для Fedora версии 10, работающей на ЦП архитектуры Intel x86. Учитывая наличие дюжины различных архитектур ЦП, более чем 100 выпусков Linux и тысяч пакетов и версий, можно увидеть, что выбирать приходится из невероятного количества двоичных пакетов RPM.
Исходные файлы RPM, с другой стороны, содержат реальный исходный код для данного пакета. От пользователя ожидается, что он загрузит и установит исходные файлы, настроит параметры сборки, после чего сам скомпилирует и скомпонует двоичные файлы. Идея сборки собственной операционной системы является устрашающей для специалиста по Windows, привыкшего устанавливать то, что Майкрософт предоставляет на компакт-диске установки Windows, но диспетчер пакетов делает процесс относительно безболезненным и на удивление надежным. Группа Samba выпускает обновления и исправления безопасности бешеными темпами; лишь за июль и август 2008 вышло четыре выпуска Samba 3.2, всего содержавших свыше 100 устраненных ошибок и исправлений безопасности. Для этого проекта я загрузил файлы исходного кода для последней стабильной версии Samba, версии 3.0.31.
Почему я загрузил исходный код Samba вместо заранее скомпилированного набора двоичных файлов? Поначалу я, конечно, попытался сделать первое. Но после многих часов с отладчиком я обнаружил, что загруженные мною двоичные файлы не были собраны нужным для поддержки проверки подлинности Active Directory образом. В частности, код, поддерживающий сопоставление идентификаторов Linux в Active Directory, был отключен в сборках по умолчанию, так что мне пришлось перестраивать Samba с должными параметрами сборки. Я подробно рассмотрю вопрос сопоставления идентификаторов ниже.
Даже хотя Linux, сам по себе, является маленьким ядром, в выпуске Red Hat Enterprise заранее установлено множество пакетов. Обычно это серьезно упрощает жизнь, позволяя начать с полной и работающей операционной системы, но заранее установленные пакеты порой конфликтуют с программами, которые предполагается установить позже.
Я не включил Samba в свою установку Red Hat (обычно Samba устанавливается по умолчанию), поскольку мне нужно было использовать более новую версию. Однако более новая версия Samba требует новых версий нескольких других библиотек и служебных программ, которые уже были установлены. Проблемы, связанные с подобной зависимостью, действуют на нервы, но их можно легко решить, используя RPM.
Существует множество веб-узлов, на которых размещаются двоичные пакеты RPM. Тот, что использовал я (просто потому, что он нашелся первым), именуется PBONE и расположен на rpm.pbone.net. У него имеется удобный способ поиска пакетов, и на нем есть все двоичные файлы, которые были необходимы для моей архитектуры ЦП (i386) и выпусков операционной системы (Red Hat Enterprise Linux 5/Fedora 7 и 8).
Мне пришлось загрузить и обновить пакеты, перечисленные на рис. 4 , чтобы собрать и установить последнюю версию Samba 3.0 (существует еще более новое дерево версий 3.2, работать с которым я не пробовал). Отметьте, что все эти пакеты предназначены для выпуска Fedora Core (fc). Дистрибутив Red Hat основан на тех же исходных кодах, что используются в Fedora, и полностью совместим с ней. Пакеты, собранные для Fedora Core 7 и более поздних версий, будут работать в RHEL5 без изменений. Поместите загруженные файлы RPM в каталог /usr/src/redhat/RPMS.
Рис. 4. Пакеты, необходимые для сборки и установки Samba 3.0.31
Сборка Samba
Первый этап сборки Samba заключается в загрузке верного исходного пакета RPM. Я загрузил пакет RPM исходных кодов для Samba 3.0.31 с веб-узла PBONE. Далее поместите загруженный файл RPM исходных кодов в /usr/src/redhat/SRPMS; это стандартный каталог для пакетов RPM исходных кодов в ходе процесса сборки.
Откройте сеанс терминала («окно командной строки» в терминах Windows) и перейдите к папке SRPMS. После того, как это сделано, установите пакет исходных кодов, используя команду, как показано на рис. 5 .
Рис. 5. Установка пакета RPM исходных кодов Samba
Если появится предупреждение об ошибке "user mockbuild does not exist—using root" («макетной сборки пользователя не существует - используется корень»), не волнуйтесь. Эта ошибка указывает, что служебные программы макетной сборки не установлены. Процесс сборки будет работать и без них.
Далее перейдите к каталогу /usr/src/redhat/SPECS и исправьте файл samba.spec, содержащий параметры сборки Samba. Найдите строку, начинающуюся с "CFLAGS=", и убедитесь, что параметр "--with-shared-modules=idmap_ad,idmap_rid" существует. Этот параметр гарантирует, что в процессе сборки будет включен код, правильно преобразующий уникальные идентификаторы (unique identifiers - UID) Linux для Active Directory. На рис. 6 приведен этот параметр.
Рис. 6. Параметр сборки with-shared-modules («с совместно используемыми модулями»)
Далее может понадобиться обновить некоторые из библиотек на компьютере, чтобы должным образом собрать и установить Samba; это зависит от того, какие версии библиотек уже установлены. В моем случае мне пришлось установить пакеты, перечисленные на рис. 4 , используя команду rpm -install; в некоторых случаях мне пришлось, впрочем, использовать вариант --force, чтобы преодолеть некоторые из проблем зависимости.
Чтобы собрать Samba, перейдите к каталогу /usr/src/redhat и выполните команду rpmbuild -bb SPECS/samba.spec, как показано на рис. 7 . В результате этой процедуры новый файл RPM samba-3.0.31-0.i386 останется в каталоге /usr/src/redhat/RPMS. Мы установим этот файл RPM позже по ходу проекта.
Рис. 7. Создание двоичного файла RPM Samba
Настройка работы Linux с сетью
Чтобы проверять подлинность с помощью Active Directory, компьютер Linux должен иметь возможность связываться с контроллером домена. Чтобы это могло произойти, необходимо настроить три параметра сети.
Во-первых, важно убедиться, что сетевой интерфейс на компьютере Linux настроен должным образом либо путем использования протокола DHCP, либо путем назначения ему соответствующего IP-адреса и сетевой маски с помощью команды ifconfig. В случае RHEL5 можно настроить работу с сетью, выбрав ее (Network) из меню System | Administration (Система | Администрирование), как показано на рис. 8 .
Рис 8. Настройка сети
Далее убедитесь, что служба разрешения имен DNS для компьютера Linux установлена на использование того же сервера имен DNS, который используют контроллеры домена; в большинстве случаев это контроллер домена в домене, к которому требуется присоединить компьютер Linux, предполагая, что используется DNS, интегрированная с Active Directory. Средство разрешения DNS настраивается на вкладке DNS той же служебной программы настройки сети, которая использовалась для настройки сети, как показано на рис. 9 .
Рис 9. Установка основного средства разрешения DNS
Наконец, по завершении этих действий, нужно установить имя компьютера Linux для отражения его имени в домене. Хотя это имя можно установить, используя приложение настройки сети, это, похоже, не всегда работает должным образом.
Вместо этого измените файл /etc/hosts и добавьте запись под записью localhost.localdomain в форме
Настройка синхронизации времени в Linux
Протокол Kerberos полагается на наличие у систем проверки подлинности часов с достаточно высокой точностью синхронизации. По умолчанию, Active Directory допускает максимальное отклонение по времени в пять минут. Чтобы гарантировать пребывание систем Linux и часов систем контроллеров домена в пределах этого значения, необходимо настроить системы Linux на использование службы протокола NTP контроллера домена.
Далее на сервере Linux запустите служебную программу Date & Time («Дата и время») из меню System | Administration и выберите вкладку протокола NTP. Установите флажок Enable Network Time Protocol («Включить протокол NTP») и добавьте IP-адрес контроллера домена, который нужно использовать как сетевой источник времени. Обратите внимание, что обычно это должен быть контроллер домена в домене, содержащим роль FSMO имитатора основного контроллера домена (primary domain controller - PDC). На рис. 10 приведен пример установки сетевого источника времени для Linux.
Рис 10. Настройка протокола NTP
Настройка PAM и NSS
PAM и NSS предоставляют средство соединения приложения Linux, такого как рабочая среда, и Winbind. Подобно многим службам Linux, PAM и NSS настраиваются через текстовые файлы. Сначала мы рассмотрим настройку PAM.
PAM предоставляет четыре относящихся к проверке подлинности средства использующих им приложениям. Средство проверки подлинности позволяет приложению определить, кто использует его. Средство учетных записей предоставляет функции управления учетными записями, которые не относятся прямо к проверке подлинности, такими как ограничение времени входа. Средство паролей предоставляет механизмы для запроса паролей и управления ими. Средство сеансов выполняет относящиеся к пользователю задачи установки и удаления для приложения, такие как ведение журнала или создание файлов в категории конкретного пользователя.
Файлы настройки PAM в Red Hat хранятся в каталоге /etc/pam.d, в котором будет находиться текстовый файл для каждого приложения, использующего PAM для проверки подлинности. Например, файл /etc/pam.d/gdm содержит информацию о настройке PAM для Gnome Desktop Manager (GDM), оконной среды по умолчанию в Red Hat. В каждом файла настройки PAM содержатся несколько строк, каждая из которых определяет какой-либо аспект процесса проверки подлинности PAM. На рис. 11 показано содержимое файла настройки PAM для GDM.
Рис. 11. Файл настройки РАМ для Gnome Desktop Manager
Каждая запись в файле настройки PAM имеет форму <группа управления> <элемент управления> <модуль> <параметры>, где <группа управления> соответствует средству, к которому относится запись настройки: проверки подлинности, учетных записей, паролей или сеансов. Управляющие ключевые слова, описанные на рис. 12 , говорят PAM, как обработать запись настройки. Третий столбец файла содержит имя общей библиотеки PAM в каталоге безопасности /lib/. Общие библиотеки содержат динамически загружаемый исполняемый код, подобный DLL в Windows. Дополнительные термины после имени модуля - это параметры, передаваемые модулем PAM общей библиотеке.
Рис. 12. Управляющие ключевые слова PAM
Ключевое слово | Описание |
| Required («Обязательно») | Если модуль срабатывает успешно, то PAM продолжает вычислять остающиеся записи для группы управления, и результаты будут определены результатами остающихся модулей. Если нет, то PAM продолжит вычисление, но возвратит сбой вызывавшему приложению. |
| Requisite («Необходимо») | Если модуль срабатывает успешно, PAM продолжает вычислять записи группы управления. Если нет, то PAM произведет возврат вызывавшему приложению без дальнейшей обработки. |
| Sufficient («Достаточно») | Если модуль сработает успешно, то PAM возвратит успешный результат вызывавшему приложению. Если нет, то PAM продолжит вычисление, но результаты будут определены последующими модулями. |
| Optional («Необязательно») | PAM игнорирует результаты модуля, если это не единственный модуль, указанный для группы управления. |
| Include («Включить») | PAM включает в себя содержимое файла настройки PAM, на который дается ссылка, а также содержащиеся в нем процессы и записи. |
Можно заметить, что у каждой группы управления есть несколько записей. PAM обрабатывает записи по порядку, вызывая названный модуль. Затем модуль возвращает успех либо сбой, и PAM действует в зависимости от управляющего ключевого слова.
Можно заметить, что в файле настройки PAM для GDM есть system-auth для всех групп управления. Это способ, которым PAM устанавливает поведение при проверке подлинности по умолчанию для GDM. Модифицируя system-auth, можно модифицировать это поведение для всех приложений, в которых есть файл system-auth в настройках PAM. Файл system-auth по умолчанию показан на рис. 13 .
Рис. 13. Файл system-auth модуля PAM
Модуль переключателя блока преобразования имен (NSS) скрывает конкретные сведения о хранилище данных систем от разработчика приложения, примерно так же, как PAM скрывает подробности проверки подлинности. NSS позволяет администратору указать способ, которым хранятся базы данных системы. В частности, администратор может указать, как хранится информация об имени пользователя и пароле. Поскольку нам нужно, чтобы приложения искали информацию о пользователях в Active Directory при помощи Winbind, нам нужно изменить настройку NSS, чтобы показать это.
Red Hat включает небольшую графическую программку для настройки PAM и NSS, называемую system-config-authentication. Она заботится о большинстве изменений (но не о всех), которые необходимо ввести в файлы system-auth и nss.conf.
Запустите приложение system-config-authentication, и можно будет увидеть диалог, подобный показанному на рис. 14 . Установите флажок Winbind как на вкладке User Information («Информация о пользователе», она настраивает файл nss.conf), так и на вкладке Authentication («Проверка подлинности», она модифицирует файл system-auth).
Рис. 14. Диалог systemconfig-authentication
Нажмите кнопку Configure Winbind, и будет отображен диалог, приведенный на рис. 15 . Введите имя домена, в котором должна проверяться подлинность пользователей, в поле Winbind Domain и выберите «объявления» как модель безопасности. Введите доменное имя DNS домена Active Directory в поле Winbind ADS Realm. В поле Winbind Domain Controllers введите либо имя контроллера домена, с помощью которого нужно проверять подлинность для этой системы Linux, или звездочку, указывающую, чтоWinbind следует выбрать контроллер домена, запрашивая записи SRV в DNS.
Рис. 15. Настройка диалога Winbind
Выберите подходящий интерпретатор команд по умолчанию, который должны иметь пользователи Active Directory; в данном случае я выбрал bash (Bourne-again Shell). Не пытайтесь воспользоваться кнопкой "Join Domain" («Присоединиться к домену») на этом этапе. Компьютер будет присоединен к домену позже.
В файл /etc/pam.d/system-auth необходимо внести еще одно дополнительное изменение после того, как он был модифицирован для поддержки Winbind. Когда пользователь Linux входит в систему, система требует от пользователя наличия домашнего каталога. Домашний каталог содержит многие параметры и элементы настройки конкретного пользователя во многом подобно реестру Windows. Проблема здесь состоит в том, что поскольку пользователи создаются в Active Directory, Linux не будет автоматически создавать домашний каталог пользователя. К счастью, PAM можно настроить на выполнение этого в качестве части настройки сеанса.
Откройте файл the /etc/pam.d/system-auth, затем прокрутите экран вниз и вставьте строку "session optional map_mkhomedir.so skel=/etc/skel umask=0644" перед последней строкой в разделе сеанса (см. рис. 16 ). Эта строка настраивает PAM на создание домашнего каталога для пользователя, если такового еще не существует. Она будет использовать /etc/skel в качестве «скелета» шаблона и назначит маску прав 0644 (чтение и запись для владельца, чтение для основной группы и чтение для всех остальных) новой папке.
Рис. 16. Создание домашнего каталога для пользователей
Установка и настройка Samba
Чтобы установить только что созданные двоичные файлы Samba, перейдите в каталог /usr/src/redhat/RPMS. Все файлы RPM, созданные командой rpmbuild, появятся в этом каталоге. Помните, что Samba включает двоичные файлы, позволяющие клиенту Linux получить доступ к общему хранилищу файлов Windows (или Samba), а также к коду, позволяющему системе Linux действовать как файловый сервер Windows, сервер печати Windows и контроллер домена в стиле Windows NT 4.0.
Чтобы позволить Linux производить проверку подлинности в Active Directory, всего этого не нужно; достаточно общих файлов Samba и двоичных файлов клиента Samba. Эти файлы для нашего удобства разбиты на два файла RPM: samba-client-3.0.31-0.i386.rpm и samba-common-3.0.31-0.i386.rpm. Установите файлы RPM, используя команду rpm --install. Приведу пример: rpm --install samba-common-3.0.31-0.i386.rpm. (Отметьте, что перед этим нужно установить файл RPM -common.)
После установки двоичных файлов клиента Samba необходимо модифицировать настройку Samba по умолчанию, чтобы убедиться, что Winbind обрабатывает проверку подлинности должным образом с помощью Active Directory. Всю информацию о настройке Samba (и клиента, и сервера) можно найти в текстовом файле smb.conf, который по умолчанию находится в каталоге /etc/samba. Smb.conf может содержать огромное количество параметров настройки, и полный рассказ о его содержимом выходит за рамки данной статьи. На веб-узле samba.org и в справочной системе Linux о smb.conf рассказано подробнее.
Первым этапом настройки Winbind является использование Active Directory для проверки подлинности. Модель безопасности в smb.conf необходимо установить на «объявления». Служебная программа system-config-authentication уже должна была установить это сама, но проверка никогда не помешает. Откройте для правки файл smb.conf и найдите раздел, помеченный Domain Member Options («Параметры члена домена»). Найдите строку, начинающуюся с "security" и убедитесь, что она читается как "security = ads". На следующем этапе настройки определяется, как Winbind сопоставит участников безопасности Windows, таких как пользователи и группы, с идентификаторами Linux, и это требует несколько более подробного объяснения.
Проблема сопоставления идентификаторов
У проверки подлинности пользователей Linux с помощью Active Directory существует одна большая и пока что не упомянутая мной проблема - проблема уникальных идентификаторов (UID) для пользователей и групп. Внутренне ни Linux, ни Windows не называют пользователей их реальными именами, используя вместо этого уникальный внутренний идентификатор. В Windows используются идентификаторы безопасности (Security Identifier - SID), являющиеся структурой переменной длины и дающие уникальное средство опознания каждого пользователя в домене Windows. SID также содержит уникальный идентификатор домена, чтобы Windows могла различать пользователей в различных доменах.
Схема Linux гораздо проще. Каждый пользователь на компьютере Linux имеет идентификатор UID, представляющий из себя просто 32-разрядное целое число. Но область действия идентификатора UID ограничена самим компьютером. Нет никакой гарантии, что пользователь с идентификатором UID 436 на одном компьютере Linux идентичен пользователю с идентификатором UID 436 на другом компьютере Linux. Как следствие, пользователю необходимо подключаться к каждому компьютеру, доступ к которому ему нужен, что является нежелательной ситуацией.
Сетевые администраторы Linux обычно решают эту проблему, предоставляя сетевую проверку подлинности с помощью либо сетевой информационной системы (Network Information System - NIS), либо общего каталога LDAP. Сетевая система проверки подлинности предоставляет идентификатор UID для пользователя, и все компьютеры Linux, пользующиеся этой системой, будут пользоваться теми же идентификаторами пользователя и группы. В этой ситуации я использую Active Directory для предоставления уникальных идентификаторов пользователей и групп.
Для решения этой проблемы я использую две стратегии. Первая (а также наиболее очевидная) стратегия - создать идентификатор UID для каждого пользователя и группы и сохранить этот идентификатор с помощью соответствующего объекта в Active Directory. При ее применении, когда Winbind проверяет подлинность пользователя, я могу взглянуть на его идентификатор UID и предоставить его Linux в качестве внутреннего идентификатора данного пользователя. Winbind ссылается на эту схему как на сопоставление идентификаторов Active Directory (или idmap_ad). На рис. 17 показан процесс сопоставления идентификаторов Active Directory.
Рис 17. Процесс сопоставления идентификаторов Active Directory
Единственным недостатком сопоставления идентификаторов Active Directory является необходимость предоставления механизма наличия идентификаторов у каждого пользователя и группы, а также их уникальности в пределах леса. Более подробную информацию можно найти на боковой панели «Настройка Active Directory для сопоставления идентификаторов Active Directory».
К счастью, существует еще одна стратегия сопоставления идентификаторов, влекущая гораздо меньше административных издержек. Вспомним, что идентификатор SID Windows уникально идентифицирует пользователя внутри домена, а также сам домен. Часть идентификатора SID, уникально идентифицирующая пользователя внутри домена, именуется относительным идентификатором (RID) и является на самом деле 32-разрядным целым числом. Так что Winbind может просто извлечь RID из SID при входе пользователя в систему и затем использовать RID как уникальный внутренний идентификатор UID. Winbind ссылается на эту стратегию как на сопоставление идентификаторов RID или idmap_rid. На рис. 18 показано, как реально работает сопоставление RID.
Рис. 18. Сопоставление RID
Сопоставление RID имеет преимущество нулевых административных издержек, но его нельзя использовать в многодоменной среде в силу вероятности наличия одного значения RID у пользователей в нескольких доменах. Но при наличии одного домена Active Directory сопоставление RID - это верный выбор.
Чтобы настроить стратегию сопоставления ID в Winbind, откройте файл /etc/samba/smb.conf для правки снова и добавьте строку "idmap backend = ad" для использования стратегии сопоставления Active Directory, либо "idmap backend = rid" для использования стратегии сопоставления RID. Убедитесь в отсутствии других строк, указывающих стратегию сопоставления в файле.
Существует ряд других параметров настройки, которые нужно добавить к файлу smb.conf для Winbind. Даже если PAM установлен на создание домашнего каталога для каждого пользователя при его входе в систему, необходимо сказать Winbind, что это за имя. Мы делаем это путем добавления строки "template homedir = /home/%U" к smb.conf (см. рис. 19 ). Это говорит Winbind, что домашним каталогом для каждого пользователя, удостоверившего свою подлинность с помощью Active Directory, будет /home/<имя пользователя>. Не забудьте сначала создать каталог /home.
Рис. 19. Указание имени домашнего каталога
Присоединение к домену и вход в систему
Теперь, когда сеть, PAM, NSS и Samba Winbind настроены верно, пора присоединить компьютер Linux к домену. Это можно сделать с помощью команды net программы Samba. В запросе интерпретатора команд выполните "net ads join -U <имя администратора>". Замените <имя администратора> именем учетной записи, имеющей достаточно полномочий для присоединения компьютеров к домену.
Команда net запросит пароль пользователя. Если все сработает нормально, она присоединится к нужному компьютеру в домене. Для обнаружения созданной учетной записи компьютера можно использовать оснастку «Active Directory - пользователи и компьютеры».
Протестировать состояние присоединения можно с помощью тестового средства Winbind, именуемого wbinfo. Если выполнить wbinfo -t, будут протестированы отношения доверия между компьютером и доменом. В результате выполнения wbinfo -u будут перечислены все пользователи в домене, а wbinfo -g - все группы.
В случае успешного присоединения компьютера Linux к домену следующим этапом будет попытка входа в систему с помощью учетной записи пользователя и пароля Active Directory. Выйдите из системы на компьютере Linux и войдите в систему, используя имя пользователя Active Directory. Если всё сработает верно, то возможность входа в систему должна присутствовать.
Настройка Active Directory для процесса сопоставления идентификаторов Active Directory
Эта информация применима только к тем, кто использует сопоставление идентификаторов Active Directory. Те, то решил использовать сопоставление RID, могут спокойно не обращать внимания на эту панель.
Перед тем, как войти в систему на сервере Red Hat, используя учетную запись Active Directory, необходимо внести некоторые изменения в саму Active Directory. В-первых, в схему Active Directory придется внести атрибуты, используемые Winbind для хранения информации пользователя. При работе с Windows Server 2003 R2 схема готова к применению. В случае наличия более ранней версии схемы Active Directory ее придется расширить, используя пакет служб Microsoft Services for UNIX (SFU).
Дополнительную информацию можно найти по адресу Services for UNIX на TechNet . SFU также включает дополнительную страницу свойств для пользователей Active Directory Users и оснастку консоли управления компьютерами Майкрософт (Computers Microsoft Management Console - MMC), позволяющую управлять информацией об индивидуальном и групповом модификаторах, требуемой Linux.
После того, как схема установлена должным образом, необходимо предоставить идентификаторы Linux для всех пользователей (и групп, членами которых они являются), которые могут зайти на компьютер Linux. Это значит, что необходимо определить значения для атрибутов uidNumber и gidNumber для пользователей и групп, которые могут зайти на компьютер Linux. Но следует помнить о некоторых требованиях к этим атрибутам:
- Linux требует идентификатор UID для каждого пользователя, удостоверяющего свою подлинность. Поскольку нам необходимо управлять информацией о пользователях в Active Directory, то каждая учетная запись пользователя, который будет входить в систему на компьютере Linux, должна иметь уникальный атрибут uidNumber. Конкретное значение, используемое для uidNumber, несущественно, но оно должно быть уникальным для всех пользователей, которые могут заходить на компьютер Linux.
- Каждый пользователь Linux должен также иметь идентификатор группы по умолчанию, так что каждый пользователь Active Directory, входящий на компьютер Linux, требует значения также для атрибута gidNumber. Это значение не обязано быть уникальным среди пользователей, но оно должно уникально определять группу.
- Каждая группа в Active Directory должна иметь уникальное значение для своего атрибута gidNumber. Строго говоря, для групп вполне нормально не иметь значения для атрибута gidNumber, но при проверке подлинности пользователя Winbind ожидает, что каждая группа, к которой тот принадлежит, будет иметь уникальное значение gidNumber. Вероятно, гораздо проще просто убедиться в наличии у каждой группы уникального значения gidNumber.
- Winbind ожидает, что каждый пользователь, находимый им в Active Directory, будет членом группы пользователей домена, так что он также ожидает, что группа пользователей домена имеет значения для своего атрибута gidNumber.
А если это не заработает?
Установка компьютера Linux на проверку подлинности с помощью Active Directory и через Winbind - нетривиальный проект. Существует масса элементов, которые нужно настроить, и масса вещей, которые можно сделать неправильно. Тот факт, что каждая версия Linux или Samba несколько различаются по своим возможностям, не облегчает этой задачи. Но существует ряд источников, содержащих информацию о происходящем.
Во-первых, это файл журнала системы Linux, ведущийся в /var/log/messages. Samba будет помещать в этот файл сообщения о значительных событиях, таких как пропажа файлов или плохая настройка. В дополнение к файлу журнала системы, свои файлы журнала есть у Samba и Winbind. Их можно найти в /var/log/samba, и они предоставят пользователю некоторую дополнительную информацию.
Подробность (и объем) сообщений журналов, выдаваемых Winbind, можно увеличить, изменив его сценарий запуска для установки уровня отладки. Отредактируйте сценарий интерпретатора команд /etc/init.d/winbind и добавьте "-d 5" к команде winbind. Это увеличит уровень отладки до 5 (допустимые значения от 1 до 10), что заставит winbind создавать более детальные сообщения об ошибках.
Если Winbind доходит до связи с контроллером домена, можно провести запись сетевых пакетов с помощью служебной программы вроде Netmon 3.1. Это позволяет проанализировать, что именно Winbind пытается сделать. Можно также изучить журнал безопасности Windows на контроллере домена, в который будут занесены попытки проверки подлинности.
Теперь, когда это заработало, что у нас имеется?
Если все слаженно работает, то теперь имеется возможность входить в системы Linux, используя учетные данные, поддерживаемые в Active Directory. Это огромное улучшение по сравнению с локальным управлением идентификацией на компьютере Linux или использованием небезопасной системы вроде NIS. Это позволяет централизовать управление пользователями в одном хранилище удостоверений: Active Directory.
Но здесь не хватает некоторых вещей, которые могли бы сделать это решение действительно полезным. Во-первых, получение технической поддержки здесь - дело удачи. Многие организации Linux не очень-то разбираются в Active Directory, а поддержка, которую можно получить от сообщества Linux, целиком зависит от того, кто прочитал ваше сообщение и его настроения на сегодняшний день.
Кроме того, пакет Samba не снабжен средствами переноса или развертывания. В случае наличия существующих учетных записей Linux, с которыми связаны идентификаторы пользователей и полномочия, необходимо вручную убедиться, что они сохраняют свои идентификаторы UID при переносе их в Active Directory.
Наконец, одно из наиболее важных приложений Active Directory, групповая политика, не доступно с Samba, хотя над этим идет работа. Хотя систему Linux можно присоединить к Active Directory с помощью Samba, ей нельзя управлять, используя групповую политику.
Решения от сторонних производителей
Проверка подлинности для компьютеров Linux с помощью Active Directory - очевидно, хорошее дело, но создание собственного решения с помощью Samba Winbind утомительно, если не просто кошмарно. Читатели могут подумать, что кто-то из изобретательных поставщиков ПО должен выступить с более простым в использовании решением, и они будут правы.
Четыре поставщика коммерческого ПО разработали простые в установке и использовании версии того, что я продемонстрировал в этой статье. Они предоставляют код и средства переноса для почти всех популярных версий Linux, UNIX и Apple Macintosh, а также поддержку управления компьютерами Linux с помощью групповой политики.
Четыре компании это: Centrify , Likewise Software , Quest Software и Symark . Все четыре поставщика предоставляют похожие функции, включая управление групповой политикой в широком спектре выпусков Linux. Likewise Software недавно открыла код своей реализации, именуемой Likewise Open, хотя ее компонент групповой политики остается коммерческим продуктом. Likewise Open будет доступен для нескольких крупных выпусков Linux. (Раскрою секрет: пока я писал эту статью, моя компания, NetPro, была приобретена Quest Software.)
Имеет ли смысл строить собственную систему проверки подлинности, используя Samba и Winbind, когда доступны коммерческие варианты? Если бюджет не предусматривает денег на программы интеграции, то использование Samba с его открытым кодом имеет преимущество бесплатности. При этом также получаешь весь исходный код, что может быть заманчивым достоинством. Но перенос существующих компьютеров Linux и их существующих идентификаторов UID - весьма тернистая проблема.
С другой стороны, если требуется сэкономить время на реализацию и установку, либо имеются существующие компьютеры Linux, которые нужно перенести, либо предпочтителен ответ специалиста на возникший вопрос, то знакомство с коммерческими решениями имеет смысл. В случае же необходимости управления групповой политикой им нет альтернативы.
Но любое решение по интеграции проверки подлинности системами Linux с Active Directory сокращает усилия, уходящие на управление несколькими учетными записями пользователей, улучшает безопасность системы и предоставляет единое хранилище удостоверений для управления и аудита. И это достаточно основательные причины, чтобы попытаться применить его.
Джил Киркпатрик- Вперёд >
Linux - это многопользовательская среда и чтобы пользователь мог начать работу в системе ему нужно пройти процедуру аутентификации. PAM (Pluggable Authentication Modules ) - это система (механизм), которая берет на себя работу по реализации процедур аутентификации. До появления PAM , разработчикам программ, которые были так или иначе связаны с аутентификацией, приходилось подстраивать свою программу под существующие механизмы аутентификации. Соответственно если менялись механизмы аутентификации, значит нужно было менять и программы которые использовали их. Поэтому была разработана система PAM , которая является “прослойкой” между программами и механизмами аутентификации. То есть теперь программы аутентификации (например, программа login ) должны всего лишь уметь работать с системой PAM . Программа передает PAM параметры (например логин и пароль) и ее (программу) уже не “интересует” какой способ аутентификации реализован в системе - аутентификация по паролу или смарт-карте или другой способ. Дальше работает PAM и возвращает программе или успех или отказ.
Посмотрим на систему PAM подробнее. Основные функции, или действия, или задачи которые выполняет система PAM - разбиты на четыре группы которые имеют определенные названия:
группа auth - это действия связанные непосредственно с аутентификацией. То есть действия или функции которые позволяют определить, что вы это вы. Это может быть аутентификация по паролю, по смарт-карте, биометрическая аутентификация (отпечаток пальца и т.д.) и другие.
группа account - это действия связанные с управлением учетными записями. Например, даже если вы аутентифицировались в системе, то вашей учетной записи можно поставить запрет на работу в определенное время суток. Или разрешить заходить в консольном режиме, но запретить заходить в графическом режиме. И т.д.
группа session - действия этой группы осуществляют выделение пользователю необходимых для работы ресурсов. Самый простой пример - это разрешение на монтирование каталогов.
группа password - действия, которые реализуют изменение аутентификационных данных пользователя. Чаще всего это действия по управлению паролями пользователя.
Все эти действия или процедуры (функции) реализованы в виде отдельных модулей, которые расположены в каталоге /lib/security/ . То есть можно сказать, есть модули группы auth , модули группы account и т.д. Соответственно система PAM является модульной и если вам необходимо реализовать биометрическую аутентификацию, то необходимо просто установить модуль, которых может это процедуру выполнить.
Основной конфигурационный файл системы PAM - это файл /etc/pam.conf . Кроме файла /etc/pam.conf , настройки PAM хранятся в файлах каталога /etc/pam.d/ . Внутри каталога находятся текстовые файлы которые содержат в себе последовательность действий (некий алгоритм) для программ которые используют PAM . Например, файл /etc/pam.d/login содержит алгоритм работы системы PAM для программы login , а файл /etc/pam.d/passwd для программы passwd .
Рассмотрим сначала формат файла /etc/pam.conf . Файл состоит из строк. Файл может состоять из одной строки, а может из нескольких строк складываясь в цепочку последовательных действий. Каждая строка описывает одно правило или один шаг такой цепочки (алгоритма). Строка состоит из четырех полей. Первое поле это имя программы к которой относится данный шаг. Второе поле, это тип действия (auth , account , session , password ). Третье поле это поле в котором задается поведение системы PAM после завершения этого шага на этом шаге алгоритма (чуть ниже остановимся подробнее на этом вопросе). Четвертое поле - это имя файла модуля. Также в строке могут присутствовать некоторые параметры передаваемые модулю.
Структура файлов находящихся в каталоге /etc/pam.d/ , такая же. Отличие только в отсутствии первого поля - имени. Так как имя программы берется из имени самого файла. Посмотрим на пример такого файла. Назовем его testpam .
auth sufficient pam_rootok.so |
Рассмотрим первую строку. Поле auth говорит, что первым шагом будет аутентификация. Третье поле - это модуль, который будет выполнять аутентификацию и возвращать результат выполнения. В данном примере модуль pam_rootok.so проверяет является ли учетная запись рутом (root ). Если, да то будет возвращен успех (true), если нет, то будет возвращена ошибка или отказ (false). Второе поле - это реакция или влияние полученного результата на цепочку в целом.
Реакция может быть четырех типов: required , requisite , optional , sufficient . На примере строки auth sufficient pam_rootok.so рассмотрим, что означают эти значения.
Если во втором поле установлено значение requisite , то это означает, что если модуль pam_rootok.so завершился с ошибкой, то дальнейшее выполнение файла testpam прерывается и система PAM возвращает приложению ошибку. Если модуль вернул положительные результат, то выполнение цепочки продолжается.
required похож на requisite . Если модуль pam_rootok.so завершился с ошибкой, то PAM также вернет, ошибку, но после того как будут выполнены остальные модули, то есть цепочка не прерывается. Если модуль вернул положительные результат, то выполнение цепочки продолжается.
sufficient - если модуль pam_rootok.so вернул успех, то система PAM возвращает приложению успех, и дальнейшее выполнение цепочки прерывается. Если неудача, то продолжается выполнение цепочки.
optional - этот параметр никак не влияет на ход цепочки. Указывается для тех модулей которые не выполняют никаких проверочных действий. Если в файле будут только строки с параметром optional , то PAM вернет приложению успех.
Более подробно о системе PAM и назначении той или иной библиотеки можно прочитать на сайте http://kernel.org/pub/linux/libs/pam/Linux-PAM-html/Linux-PAM_SAG.html . Сейчас выполним небольшое практическое упражнение которое позволить лучше понять как работает система PAM и как составлять конфигурационные файлы.
Перейдите в каталог /etc/pam.d/ . Скопируйте файл su в домашнюю директорию (чтобы можно было восстановить его) и удалите файл в su из директории /etc/pam.d/ . Попробуйте теперь выполнить команду su в терминале чтобы перейти в режим суперпользователя. После ввода пароля система выдаст ошибку аутентификации, так как отсутствует конфигурационный файл для программы su .
Создаем файл /etc/pam.d/su и пишем в нем такую строку:
Модуль pam_deny.so
всегда возвращает ошибку. Какой будет результат? Проверьте. А если заменить requisite
на required
?
Теперь напишем в файле следующее правило:
Модуль pam_wheel.so возвращает успех если учетная запись пользователя принадлежит группе wheel . Если попробовать сейчас выполнить команду su , то она тут же завершиться с ошибкой. То есть сейчас команду su смогут выполнить только пользователи, который входят в группу wheel и знают пароль учетной записи root . Если создать группу wheel и добавить туда свою учетную запись, то команда su сработает.
Вот еще пример:
auth requisite pam_wheel.so |
Попробуйте ответить кто сможет успешно выполнить команду su
и, что для этого нужно будет сделать?
На этом завершим практическое упражнение (не забудьте вернуть на место оригинальный файл su).
Хочу еще раз подчеркнуть, что конфигурационные файлы в каталоге /etc/pam.d/ можно создавать только для файлов которые используют систему PAM . Например, если создать файл /etc/pam.d/ls со строкой auth requisite pam_deny.so , то команда ls все равно будет выполнятся так как она не использует систему PAM . Чтобы проверить использует ли команда систему PAM можно использовать команду ldd , которой в качестве параметра передается полный путь к файлу команды. Например:
Ключевое слово compat как раз и “говорит” о том что в качестве системы аутентификации, будет использована система PAM .
И еще. Будьте осторожны в экспериментах с PAM . По незнанию или неосторожности можно запросто заблокировать свою систему. Поэтому перед тем как что-то менять обязательно сохраните исходные конфигурационные файлы, чтобы в случае проблем можно было их быстро восстановить.