Jak praktyczne jest uwierzytelnianie serwera Linux przeciwko AD?

Używamy serwera Windows i Linux w naszej firmie zajmującej się tworzeniem oprogramowania.

Jednym z punktów tarcia w tej konfiguracji jest to, że nie mamy rozwiązania jednokrotnego logowania. Będąc bardziej sklepem Microsoft niż Linuxem, chcemy uwierzytelnić się w stosunku do AD.

Przeczytałem kilka artykułów online i rozumiem, że jest to możliwe.

Obecnie korzystamy z następujących usług w Linuksie, które wymagają uwierzytelnienia:
- serwer git (przez SSH)
- Sendmail
- serwer WWW Apache obecnie używa plików .htaccess.
- Udziały plików SAMBA

Chcę wiedzieć, jak praktyczna jest taka konfiguracja? Czy to naprawdę działa, czy jest podatne na błędy?

To nie jest trudne i jest całkowicie praktyczne.

Mamy kilkaset komputerów stacjonarnych z podwójnym uruchomieniem, które korzystają z uwierzytelniania AD, a także wiele serwerów, które korzystają z uwierzytelniania AD, aby umożliwić klientom Windows korzystanie z udziałów samby bez wyraźnego uwierzytelnienia przez użytkowników.

Był jeszcze jeden artykuł na temat SF o tym, co musisz zrobić.

Zasadniczo musisz skonfigurować kerberos, winbind, nss i pam.

Potem robisz A kiniti A net ads joini twoja gra .

Jeśli chcesz, możesz skonfigurować pam tak, aby korzystały z wielu metod uwierzytelniania, więc jeśli jedna nie działa, wróci do następnej.

Zwykle używamy plików, winbindd i ldap dla serwerów obsługujących pliki na serwerach Windows.

Jeśli to możliwe, używałbym LDAP dla informacji o koncie i windbind ściśle dla auth, ale myślę, że możesz mapować atrybuty w / Myślę, że /etc/ldap.conf, jeśli potrzebujesz. Jeśli w końcu użyjesz winbindd do informacji o koncie, możesz użyć RID (metoda mieszania) do wygenerowania identyfikatorów / identyfikatorów, ale możesz też użyć innych metod. Użyliśmy identyfikatorów RID na jednym dużym serwerze plików i to był prawdziwy ból, więc spróbuję zbadać jedną z innych opcji, jeśli to możliwe. W naszym przypadku wszyscy użytkownicy AD i grupy są odzwierciedleni w LDAP przez nadrzędny system IDM, więc używamy LDAP do informacji o koncie na nowszych serwerach i używamy winbind wyłącznie do autoryzacji.

Uwierzytelnianie jest absolutnie proste przy użyciu Likeewise Open. http://www.likewise.com/products/likewise_open/index.php

Prawie cała moja infrastruktura Linuksa ma scentralizowane uwierzytelnianie i zarządzanie użytkownikami dzięki Likewise Open. Jest niezwykle prosty w instalacji i implementacji. Nie mogę powiedzieć wystarczająco dużo na ten temat.

Uwaga: identyfikatory UID i GID są przypisywane zgodnie z funkcją haszującą, więc są identyczne w całej infrastrukturze, więc podłączenia NFS działają idealnie.

Zainstalowałem usługi systemu Windows dla systemu Unix i dodałem użytkownika w usłudze AD o nazwie „Unix Authenticator”, a następnie wprowadziłem następujące zmiany pliku konfiguracyjnego na komputerach z systemem Linux:

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

<password>

passwd: compat ldap
shadow: compat ldap
group: compat ldap

host files dns

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

Mam nadzieję że to pomoże.

Użytkownicy Windowsa uwierzytelniają się w stosunku do AD, ale większość naszych serwerów (dysk publiczny itp.) Jest linux i należą do domeny. Z okna PoV nikt nie zauważa. Z mojej strony to trochę owocowe ssh'ing z moją nazwą użytkownika Windows, ale to mniej więcej o jej wielkości.

Używaj zwykłej starej samby.

Nie musisz używać Samby, AD obsługuje Kerberos i LDAP bezpośrednio. Nie ma powodu, abyś używał zewnętrznego oprogramowania w większości dystrybucji.

W przypadku Debiana / Ubuntu możesz to zrobić za pomocą libnss-ldap i libpam-krb5. Jest kilka sztuczek, aby uzyskać 100%. Zakłada się, że masz „unixHomeDirectory” wypełniony dla użytkowników Linuksa, twoje Linux-y używają NTP wspólnego z twoimi systemami Windows (wymaganymi przez Kerberos) i że jesteś w porządku z wyszukiwaniem zwykłego tekstu NSS (nie hasłem, ale informacjami o członkostwie w grupie itp. - możesz również użyj TLS, ale jest to bardziej skomplikowane w konfiguracji). NIE powinieneś mieć pam_ldap jako hasła lub źródła autoryzacji w PAM, chyba że masz skonfigurowane używanie 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

Nie powinieneś edytować pliku /etc/krb5.conf, zakładając, że Twoje Linux-y korzystają z serwerów DNS, które znają AD (można rozwiązać strefy _msdcs z odpowiednimi rekordami SRV)

/etc/nsswitch.conf powinien mieć „pliki ldap” dla użytkowników, grup, cienia.

W przypadku Red Hat za pomocą 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