Назад | Перейти на главную страницу

Централизованный метод аутентификации

В моей сети более 1000 серверов Linux / Unix (Solaris), и я хочу реализовать какой-то централизованный сервер входа в систему. Так что я создаю пользователей на одном сервере, и он может войти в систему на любом сервере в моей сети. Но было бы какое-то исключение, которое я хочу реализовать, например, каждый, я не хочу предоставлять каждому пользователю доступ к каждому серверу. Например, парень из команды разработчиков не должен иметь доступа к серверам команды Fault Management и наоборот.

Я не хочу использовать LDAP. Я слышал о Kerberos и RADIUS или Radius + SSH + LDAP. Пожалуйста, подскажите, какой из них будет лучше. Мне просто нужно централизованное управление пользователями и доступом к серверу.

Спасибо и С уважением, Рамеш Кумар

На самом деле есть только одно решение: LDAP, если вы не идете по действительно устаревшему маршруту: NIS, NIS +.

LDAP может очень хорошо работать с сетевыми группами для настройки того, какие люди имеют доступ к каким серверам, есть Вики проекта Fedora по этому поводу. Вы также можете оставить sudo конфигурация в LDAP, и для дополнительного преимущества для нее уже существуют решения для веб-управления, GOsa² быть одним из лучших, более ориентированных на Linux.

Может быть, просто скажите нам, почему вам не нужен LDAP, таким образом мы сможем решить ваши проблемы с ним ...

Есть три способа обойти проблему сбоя сети или сервера:

  • используйте реплицированную настройку с несколькими серверами LDAP (и nss_ldap, и pam_ldap будут использовать резервный сервер, когда основной не работает), Документация OpenLDAP довольно обширен в этой теме
  • использовать кеширование на клиенте, pam_ccreds или Fedora SSSD
  • пойти по самому сложному пути: использовать дополнительный сервер LDAP на наиболее важных серверах

У вас должно быть центральное хранилище пользователей, что означает какую-то службу каталогов. В наши дни это означает Active Directory, eDirectory, OpenLDAP или какой-либо другой сервер в стиле LDAP. Затем этот центральный сервер может использовать различные протоколы аутентификации, понимая, что рано или поздно служба аутентификации обратится к службе каталогов и что служба каталогов, вероятно, будет использовать LDAP. Это так, даже если у службы каталогов есть свой собственный API, потому что все использует LDAP, поэтому в настоящее время приложения обычно используют его.

Active Directory, конечно же, является самым простым выбором в наши дни, поскольку Microsoft довольно сильно настаивала на его повсеместном распространении и удовлетворении большинства потребностей.

Я предпочитаю eDirectory, потому что он обладает очень высокой стабильностью и масштабируемостью, более удобен для Unix, чем AD (как для клиентов, так и для серверов), и имеет непревзойденную модель репликации.

Openldap (и его производные, включая Open Directory от Apple) намного дешевле и модифицируемо, чем другие, поскольку он является входом с открытым исходным кодом, но у меня сложилось впечатление, что он немного более хрупок в крупных развертываниях, а управление более беспорядочным.

Существуют и другие серверы LDAP (например, Oracle Directory Server, который может хорошо вписаться в ваши устройства Sun), но я менее знаком с ними и поэтому не могу дать точных подробностей. Учитывая, что вы, кажется, хотите избежать LDAP, вы можете проверить, какие методы аутентификации каждая служба каталогов поддерживает для серверов Unix, и основывать свое решение на этом.

Если ваш Linux является производным от Red Hat, взгляните на Freeipa. Тогда вы легко получите разумно управляемую установку ldap + kerberos. У них также есть клиент solaris, надеюсь, кто-нибудь из Canonical проснется и освободит ресурсы, необходимые для работы клиентов Ubuntu в таком домене.