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

Насколько практично аутентифицировать сервер Linux с помощью AD?

В нашей компании по разработке программного обеспечения мы используем серверы Windows и Linux.

Одна из проблем с этой настройкой заключается в том, что у нас нет единого решения для входа в систему. Поскольку мы больше похожи на магазин Microsoft, чем на Linux, мы хотим пройти аутентификацию в AD.

Я прочитал пару статей в Интернете и понимаю, что это возможно.

В настоящее время мы используем следующие службы в Linux, требующие аутентификации:
- git server (через SSH)
- Отправить почту
- Веб-сервер Apache, в настоящее время использующий файлы .htaccess.
- Файловые ресурсы SAMBA

Я хочу знать, насколько практична такая установка? Это действительно работает или подвержено ошибкам?

Это не сложно и совершенно практично.

У нас есть несколько сотен настольных компьютеров с двойной загрузкой, которые используют аутентификацию AD, а также ряд серверов, которые используют аутентификацию AD, чтобы клиенты Windows могли использовать свои общие ресурсы samba без явной аутентификации со стороны пользователей.

О том, что вам нужно делать, была еще одна статья в SF.

В основном вам нужно настроить kerberos, winbind, nss и pam.

Затем вы делаете kinit и net ads join и ты.

Вы можете настроить pam для использования нескольких методов аутентификации, если хотите, поэтому, если один из них не работает, он вернется к следующему.

Обычно мы используем файлы, winbindd и ldap для серверов, обслуживающих общие файлы для серверов Windows.

Если возможно, я бы использовал LDAP для информации об учетной записи и windbind строго для аутентификации, но я считаю, что вы можете сопоставить атрибуты в /etc/ldap.conf, если вам нужно. Если вы в конечном итоге используете winbindd для информации об учетной записи, можно использовать RID (метод хеширования) для генерации uids / gids, но также можно использовать другие методы. Мы использовали RID на одном большом файловом сервере, и это было настоящей головной болью, поэтому я бы попробовал изучить один из других вариантов, если это возможно. В нашем случае все пользователи и группы AD отражаются в LDAP вышестоящей системой IDM, поэтому мы используем LDAP для информации об учетных записях на новых серверах и используем winbind исключительно для аутентификации.

Аутентификация с помощью Likewise Open абсолютно проста. http://www.likewise.com/products/likewise_open/index.php

Почти вся моя инфраструктура Linux имеет централизованную аутентификацию и управление пользователями благодаря Likewise Open. Его потрясающе просто установить и реализовать. Я не могу сказать достаточно хорошо об этом.

Обратите внимание, что UID и GID назначаются в соответствии с хеш-функцией, поэтому они идентичны для всей инфраструктуры, поэтому монтирование NFS работает идеально.

Я установил службы Windows для Unix и добавил в AD пользователя с именем «Unix Authenticator», а затем внес следующие изменения в файл конфигурации на машинах с Linux:

/etc/ldap.conf: 
host ldap.<foo>.com
base cn=Users,dc=<foo>,dc=com
binddn cn=Unix Authenticator,cn=Users,dc=<foo>,dc=com
bindpw <password>
nss_base_passwd cn=Users,dc=<foo>,dc=com?sub
nss_base_shadow cn=Users,dc=<foo>,dc=com?sub
nss_base_group cn=Users,dc=<foo>,dc=com?sub
nss_map_objectclass posixAccount User
nss_map_objectclass shadowAccount User
nss_map_objectclass posixGroup Group
nss_map_attribute cn msSFUName
nss_map_attribute uid msSFUName
nss_map_attribute gid gidNumber
nss_map_attribute gecos sAMAccountName
nss_map_attribute homeDirectory msSFUHomeDirectory
nss_map_attribute uniqueMember Member
pam_login_attribute msSFUName
pam_filter objectclass=user
pam_password ad
/etc/ldap.secret: 
<password>
/etc/nsswitch.conf: 
passwd: compat ldap
shadow: compat ldap
group: compat ldap
/etc/nsswitch.ldap: 
host files dns
/etc/pam.d/system-auth: 
auth required /lib/security/pam_env.so
auth sufficient /lib/security/pam_unix.so likeauth nullok
auth sufficient /lib/security/pam_ldap.so use_first_pass
auth required /lib/security/pam_deny.so

account sufficient /lib/security/pam_ldap.so
account required /lib/security/pam_unix.so

password required /lib/security/pam_cracklib.so retry=3
password sufficient /lib/security/pam_unix.so nullok md5 shadow use_authtok
password sufficient /lib/security/pam_ldap.so use_first_pass use_authtok
password required /lib/security/pam_deny.so

session required /lib/security/pam_limits.so
session required /lib/security/pam_unix.so

Надеюсь это поможет.

Пользователи Windows авторизуются против AD, но большинство наших серверов (публичные диски и т. Д.) - это Linux, и они являются частью домена. Из окна PoV никто не замечает. С моей стороны, мне кажется, что ssh'ing немного фруктовый с моим именем пользователя Windows, но это примерно размер.

Просто используйте старую добрую самбу.

Вам не нужно использовать Samba, AD поддерживает Kerberos и LDAP напрямую. У вас нет причин использовать какое-либо внешнее программное обеспечение в большинстве дистрибутивов.

Для Debian / Ubuntu это можно сделать с помощью libnss-ldap и libpam-krb5. Есть несколько уловок, чтобы получить его на 100%. Это предполагает, что у вас есть "unixHomeDirectory", заполненный для пользователей Linux, ваши Linux-устройства используют NTP, общий с вашими системами Windows (требуется Kerberos), и что вы в порядке с поиском NSS в виде простого текста (не пароль, а информация о членстве в группе и т. Д. - вы также можете используйте TLS, но это сложнее настроить). Вам НЕ следует использовать pam_ldap в качестве пароля или источника аутентификации в PAM, если вы не настроены на использование TLS.

/etc/ldap.conf

# LDAP Configuration for libnss-ldap and libpam-ldap.
# Permit host to continue boot process with out contacting LDAP server
bind_policy soft
# Define LDAP servers to use for queries, these must be Global Catalog servers
uri ldap://ldap.site.company.local
# Define root search location for queries
base dc=company,dc=local
#debug 1
# LDAP version, almost always going to be v3, it is quite mature
ldap_version 3
# Username used to proxy authentication. You can have this in a separate file owned by root for security OR use TLS/SSL (see man page)
# Do NOT use LDAP for authentication if you are using plain text binds, use Kerberos instead (and LDAP for authorization only). See libpam-krb5.
binddn cn=ldap-auth-svc,ou=ldap,ou=services,dc=site,dc=company,dc=local
# Password for proxy acct
bindpw SooperSekeretPazzwerd
#  TCP port to perform queries on, 3268 is a Global Catalog port which will reply for all users in *.company.local
port 3268
# Search range scope (sub = all)
scope sub
# Tell the client to close TCP connctions after 30 seconds, Windows will do this on the server side anyways, this will prevent errors from showing up in the logs.
 idle_timelimit 30
# Expect queries for group membership to return DN for group members instead of usernames (lets you use MSAD group membership seamlessly)
nss_schema rfc2307bis
# Filters - User accounts must have a UID >= 2000 to be recognized in this configuration and must have a unixHomeDirectory defined.
nss_base_group dc=company,dc=local?sub?&(objectClass=group)(gidNumber=*)
nss_base_user dc=company,dc=local?sub?&(objectClass=user)(!(objectClass=localputer))(uidNumber>=2000)(unixHomeDirectory=*)
nss_base_shadow dc=company,dc=local?sub?&(objectClass=user)(!(objectClass=localputer))(uidNumber>=2000)(unixHomeDirectory=*)
# Object Class mappings.  You may want to have the posixAccount to map to "mail" and have users login with their email addresses, i.e.  "nss_map_objectclass posixAccount mail".
nss_map_objectclass posixAccount user
nss_map_objectclass shadowAccount user
nss_map_objectclass posixGroup group
# Attribute mappings.
nss_map_attribute uniqueMember member
nss_map_attribute uid sAMAccountName
nss_map_attribute homeDirectory unixHomeDirectory
nss_map_attribute shadowLastChange pwdLastSet
# Attribute in LDAP to query to match the username used by PAM for authentication
pam_login_attribute sAMAccountName
# Filter for objects which are allowed to login via PAM
pam_filter objectclass=User

Вам не нужно редактировать /etc/krb5.conf, предполагая, что ваши Linux-серверы используют DNS-серверы, которые знают об AD (зоны _msdcs с соответствующими записями SRV разрешимы)

В /etc/nsswitch.conf должны быть "файлы ldap" для пользователей, групп, теней.

Для Red Hat, использующего SSSD:

/etc/sssd/sssd.conf

[domain/AD]
id_provider = ldap
auth_provider = krb5
chpass_provider = krb5
access_provider = ldap

ldap_uri = ldap://ldap.company.local:3268/
ldap_search_base = dc=company,dc=com
ldap_default_bind_dn = cn=ldap-auth-svc,ou=ldap,ou=services,dc=site,dc=company,dc=local
ldap_default_authtok = SooperSekeretPazzwerd
ldap_schema = rfc2307bis
ldap_user_object_class = user
ldap_group_object_class = group
ldap_user_name = sAMAccountName
ldap_user_home_directory = unixHomeDirectory
enumerate = true
ldap_tls_reqcert = never
ldap_tls_cacertdir = /etc/openldap/cacerts

ldap_id_use_start_tls = False
cache_credentials = True
krb5_realm = SITE.COMPANY.COM
case_sensitive = false
[sssd]
services = nss, pam
config_file_version = 2

domains = AD
[nss]
filter_users = root,named,avahi,nscd