Wie praktisch ist es, einen Linux-Server gegen AD zu authentifizieren?

Wir verwenden sowohl Windows- als auch Linux-Server in unserer Softwareentwicklungsfirma.

Einer der Reibungspunkte bei diesem Setup ist, dass wir keine Single-Sign-On-Lösung haben. Da wir eher ein Microsoft-Shop als ein Linux-Shop sind, möchten wir uns gegen AD authentifizieren.

Ich habe ein paar Artikel online gelesen und verstehe, dass dies möglich ist.

Derzeit verwenden wir die folgenden Dienste unter Linux, für die eine Authentifizierung erforderlich ist:
- Git-Server (über SSH)
- Sendmail
- Apache-Webserver, der derzeit .htaccess-Dateien verwendet.
- SAMBA-Dateifreigaben

Ich möchte wissen, wie praktisch diese Art der Einrichtung ist. Funktioniert es wirklich oder ist es fehleranfällig?

Es ist nicht schwer und es ist perfekt praktisch.

Wir haben einige hundert Dual-Boot-Desktop-Computer, die AD-Authentifizierung verwenden, sowie eine Reihe von Servern, die AD-Authentifizierung verwenden, damit Windows-Clients ihre Samba-Freigaben ohne ausdrückliche Authentifizierung durch die Benutzer verwenden können.

Es gab einen weiteren Artikel über SF über das, was Sie tun müssen.

Grundsätzlich müssen Sie Kerberos, WinBind, NSS und Pam konfigurieren.

Dann machst du ein kinitund ein net ads joinund dein Auf.

Sie können pam so konfigurieren, dass mehrere Methoden für die Authentifizierung verwendet werden, wenn also eine nicht funktioniert, wird auf die nächste zurückgegriffen.

Wir verwenden normalerweise Dateien, winbindd und ldap für Server, die Dateifreigaben für Windows-Server bereitstellen.

Wenn möglich würde ich LDAP für Kontoinformationen und Windbind ausschließlich für die Authentifizierung verwenden, aber ich glaube, Sie können Attribute in /etc/ldap.conf zuordnen, wenn Sie müssen. Wenn Sie am Ende winbindd für Kontoinformationen verwenden, können Sie die RID (Hashing-Methode) verwenden, um UIDs / GIDs zu generieren. Sie können jedoch auch andere Methoden verwenden. Wir haben RIDs auf einem großen Dateiserver verwendet, und das war ein echtes Problem. Daher würde ich versuchen, wenn möglich, eine der anderen Optionen zu untersuchen. In unserem Fall werden alle AD-Benutzer und -Gruppen in LDAP von einem vorgelagerten IDM-System widergespiegelt. Daher verwenden wir LDAP für Kontoinformationen auf neueren Servern und WinBind ausschließlich für die Authentifizierung.

Die Authentifizierung ist mit Likewise Open ganz einfach. http://www.likewise.com/products/likewise_open/index.php

Nahezu meine gesamte Linux-Infrastruktur verfügt dank Likewise Open über eine zentralisierte Authentifizierung und Benutzerverwaltung. Die Installation und Implementierung ist denkbar einfach. Ich kann unmöglich genug Gutes dazu sagen.

Als Hinweis: UIDs und GIDs werden gemäß einer Hash-Funktion zugewiesen, sodass sie über die gesamte Infrastruktur hinweg identisch sind, sodass NFS-Mounts einwandfrei funktionieren.

Ich habe Windows Services für Unix installiert und in AD einen Benutzer mit dem Namen "Unix Authenticator" hinzugefügt. Anschließend habe ich die folgenden Änderungen an der Konfigurationsdatei auf den Linux-Computern vorgenommen:

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

Hoffe das hilft.

Windows-Benutzer müssen sich gegen AD anmelden, aber die meisten unserer Server (öffentliches Laufwerk usw.) sind Linux-Server und Teil der Domäne. Aus einem Windows PoV merkt keiner. Meiner Meinung nach fühlt es sich bei meinem Windows-Benutzernamen etwas fruchtig an, aber das ist ungefähr so ​​groß.

Wir benutzen nur alten Samba.

Sie müssen Samba nicht verwenden, AD unterstützt Kerberos und LDAP direkt. Für die meisten Distributionen besteht kein Grund, externe Software zu verwenden.

Für Debian / Ubuntu können Sie dies mit libnss-ldap und libpam-krb5 tun. Es gibt ein paar Tricks, um es 100% zu bekommen. Dies setzt voraus, dass Sie "unixHomeDirectory" für Linux-Benutzer eingerichtet haben, Ihre Linux-Boxen NTP verwenden, das für Ihre Windows-Systeme üblich ist (erforderlich für Kerberos), und dass Sie mit NSS-Suchen im Klartext (nicht Kennwort, sondern Gruppenmitgliedschaftsinformationen usw.) einverstanden sind - das können Sie auch Verwenden Sie TLS, dies ist jedoch komplizierter einzurichten. Sie sollten pam_ldap NICHT als Kennwort oder Authentifizierungsquelle in PAM verwenden, es sei denn, Sie sind für die Verwendung von TLS eingerichtet.

/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

Sie müssen /etc/krb5.conf nicht bearbeiten, vorausgesetzt, Ihre Linux-Boxen verwenden DNS-Server, die mit AD vertraut sind (_msdcs-Zonen mit den entsprechenden SRV-Einträgen können aufgelöst werden).

/etc/nsswitch.conf sollte "files ldap" für Benutzer, Gruppen und Schatten haben.

Für Red Hat mit 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