Integration eines Centos5.x-Servers in ein Active-Directory

ad1

Sinn und Hintergrund

Es ist wünschenswert, Kosten in der IT zu senken und die Effizienz zu erhöhen. OS von MicroSoft sind kostspielig und fallen oft durch eine unangenehme Häufung von Sicheheitslücken auf. Ein reiner Fileserver kann auch mit LINUX betrieben werden, es entsteht aber zusätzlicher Aufwand durch die Inhomogenisierung der IT-Landschaft. Hier hilft die Integration des LINUX-Servers in das Active Directory, so dass z.B.

  • AD-Benutzer ohne Anmeldedialog auf die Resourcen des LINUX-Servers zugreifen können.
  • IT-Verantwortliche nicht mehrere User/Password-Datenbanken (AD, LINUX, Samba) pflegen müssen.

In diesem Dokument wird beschrieben, wie ein LINUX-Server mit dem Dienst "Samba" in ein bestehendes AD integriert wird und die Authentifizierung, die eigentlich über passwd/smbpasswd geschieht, komplett an das AD übergeben wird.

Voraussetzungen

  • bestehendes AD. DCs sind DNS-Server, alle SRV-Einträge sind richtig und funktionieren (wichtig für winbindd, siehe dort).
  • AD-Benutzer können sich fehlerfrei gegenüber dem AD authentifizieren.
  • LINUX-Server mit Samba >= 3.0.20, Kerberos, ntp
  • Die Netzwerkzeit zwischen LINUX und AD muss übereinstimmen. ntp hilft auf LINUX-Seite, diese korrekt einzustellen. Falls die Zeit des LINUX-Servers zu sehr von der des AD abweicht, kommt es zu seltsamen Phänomenen bis hin zur Unmöglichkeit der AD-Benutzer, die Samba-Freigaben des LINUX-Server nutzen zu können.
  • Kerberos auf LINUX-Seite muss exakt eingerichtet sein. Kerberos v5 ist das von MicroSoft in AD2003 verwendete Authentifizierungsprotokoll. Es ist zwar noch möglich, NTLM(2) zu verwenden wie unter NT4, dies sollte aber aus Sicherheitsgründen abgestellt sein. Der LINUX-Server verwendet Kerberos v5, um sich mit seinem AD-Konto in der Domäne zu authentifizieren.
  • Samba muss konfiguriert sein, um einen Domain Member Server zu simulieren und Benutzerauthentifizierungen an das AD weiterzuleiten.
  • Der LINUX-Server muss erfolgreich dem AD beigetreten sein (ein Konto besitzen) und sich dort einloggen können.
  • Folgende Dienste müssen auf dem LINUX-Server aktiviert sein: smb, nmb, winbind

getestet mit

  • CentOS5.1 32bit
  • AD 2003R2

Schritt-für-Schritt

  • Konfiguration des DNS-Clients auf dem LINUX-Server:
    Die Datei /etc/hosts muss angepasst werden: 127.0.0.1 centos5.italia.local centos5
    127.0.0.1 localhost     Die Datei /etc/sysconfig/network muss angepasst werden: NETWORKING=yes
    NETWORKING_IPV6=no
    HOSTNAME=centos5     Die Datei /etc/resolv.conf muss angepasst werden: domain italia.local
    search italia
    nameserver 192.168.1.242
    nameserver 192.168.1.2     Der erste Nameservereintrag muss auf einen Server verweisen, der alle gültigen SRV-Records der Domain auflösen kann, am Besten eben der DNS-Server der AD-Domain.
    Eine fehlerhafte DNS-Client-Konfiguration führt zu unvorhersehbaren Ereignissen, teilweise funktionieren dann bestimmte Aufrufe an das AD, andere wieder nicht. Falls die DNS-Konfiguration im Verdacht steht, Fehler zu erzeugen, hilft mitsniffern.
  • Einrichten des Samba-Dienstes auf dem LINUX-Server
    Die Datei /etc/samba/smb.conf muss im Abschnit [Global] folgende Einträge haben: [global] load printers = yes
    cups options = raw
    idmap gid = 1000-2000
    server string = Centos51
    idmap uid = 1000-2000
    workgroup = Italia
    os level = 20
    security = ads
    realm = ITALIA.LOCAL
    passdb backend = tdbsam
    encrypt passwords = yes
    log level = 3
    log file = /var/log/samba/%m
    max log size = 50
    printcap name = cups
    printing = cups
    winbind enum users = Yes
    winbind enum groups = Yes
    winbind use default domain = Yes
    winbind nested groups = Yes
    winbind tparmeparator = +     Bitte mit # testparm auf korrekte Syntax prüfen.
  • Konfiguration von Kerberos v5
    Kerberos v5 ist das Authentifizierungsprotokoll von Windows AD. Dabei versucht ein (Windows)Client, sich gegenüber dem AD-DomainController zu authentifizieren. Dies funktioniert mit dem sog. Ticket-Verfahren. Dazu muss Kerberos auf dem LINUX-Server exakt konfiguriert werden. (Anm. Kerberos ist keine Erfindung von Microssoft, sondern schon älter als das AD-Modell. Wers genau wissen will: http://de.wikipedia.org/wiki/Kerberos_(Informatik)
    Die Datei /etc/krb5.conf muss konfiguriert werden. Sie steuert die Authentifizierung des LINUX-Servers gegenüber der AD-Domain: [logging]
    default = FILE:/var/log/krb5libs.log
    kdc = FILE:/var/log/krb5kdc.log
    admin_server = FILE:/var/log/kadmind.log

    [libdefaults]
    default_realm = ITALIA.LOCAL

    [realms]
    ITALIA.LOCAL = {
    default_domain = italia.local
    kdc = italia-dc01.italia.local:88
    admin_server = italia-dc01.italia.local:749
    }

    [domain_realm]
    italia.local = ITALIA.LOCAL

    [appdefaults]
    pam = {
    debug = true
    ticket_lifetime = 36000
    renew_lifetime = 36000
    forwardable = true
    krb4_convert = false
    }     Sobald diese Datei gespeichert ist, sollte eigentlich schon eine Anmeldung vom LINUX-Server gegenüber der AD-Domain möglich sein. Dazu folgendes eingeben: # kinit Administrator@ITALIA.LOCAL Achtung! Groß/Kleinschreibung beachten. Nach der korrekten Abfrage der Passwortes sollte eine positive Anmeldebestätigung kommen. Wers genau wissen will, sniffert mit. Hochinteressant! Nun mit # net ads join -U Admnistrator der Domain beitreten. In "AD Users and Computers" sollte der LINUX-Server jetzt als Computerobjekt auftreten. # wbinfo -u listet jetzt alle User der Domain auf, # wbinfo -g alle Gruppen. # wbinfo -a username%password testet eine erfolgreiche Anmeldung eines AD-Benutzers. Dieser muss dem LINUX-Server NICHT bekannt sein. Mit der Anmeldung hat der LINUX-Server nichts mehr zu tun.
  • Jetzt muss dem LINUX-Server klar gemacht werden, dass für ihn unbekannte Benutzer von der AD-Domain beglaubigt werden. Dazu wird die Datei /etc/nsswitch.conf geändert: #
    # /etc/nsswitch.conf
    #
    # An example Name Service Switch config file. This file should be
    # sorted with the most-used services at the beginning.
    #
    # The entry '[NOTFOUND=return]' means that the search for an
    # entry should stop if the search in the previous entry turned
    # up nothing. Note that if the search failed due to some other reason
    # (like no NIS server responding) then the search continues with the
    # next entry.
    #
    # Legal entries are:
    #
    # nisplus or nis+ Use NIS+ (NIS version 3)
    # nis or yp Use NIS (NIS version 2), also called YP
    # dns Use DNS (Domain Name Service)
    # files Use the local files
    # db Use the local database (.db) files
    # compat Use NIS on compat mode
    # hesiod Use Hesiod for user lookups
    # [NOTFOUND=return] Stop searching if not found so far
    #

    # To use db, put the "db" in front of "files" for entries you want to be
    # looked up first in the databases
    #
    # Example:
    #passwd: db files nisplus nis
    #shadow: db files nisplus nis
    #group: db files nisplus nis

    passwd: files winbind
    shadow: files winbind
    group: files winbind

    #hosts: db files nisplus nis dns
    hosts: files dns wins

    # Example - obey only what nisplus tells us
    #services: nisplus [NOTFOUND=return] files
    #networks: nisplus [NOTFOUND=return] files
    #protocols: nisplus [NOTFOUND=return] files
    #rpc: nisplus [NOTFOUND=return] files
    #ethers: nisplus [NOTFOUND=return] files
    #netmasks: nisplus [NOTFOUND=return] files

    bootparams: nisplus [NOTFOUND=return] files

    ethers: db files
    netmasks: files
    networks: files
    protocols: db files
    rpc: files
    services: files

    netgroup: files

    publickey: nisplus

    automount: files
    aliases: files nisplus
    Die Konfig sagt aus, dass zuerst lokale Accounts geprüft werden. Sollte dort kein Passwort hinterlegt sein oder der Account unbekannt sein, wird dem Dienst winbind die Authentifizierung übergeben. Dieser leitet sie dann über Kerberos v5 an die Domain weiter.
    Weiter müssen im Verzeichnis /lib noch zwei symbolische Links angelegt werden: libnss_winbind.so
    libnss_winbind.so.2 -> libnss_winbind.so
    libnss_wins.so
    libnss_wins.so.2 -> libnss_wins.so
  • PAM-Authentifizierung.
    Ein Wort zu PAM (Plugable Authentication Module). Früher gab es nur eine Möglichkeit, bei UNIX ein Passwort zu überprüfen. Die Datei /etc/passwd. Inzwischen bietet jedes vernünftige Betriebssystem (NetWare, LINUX, UNIX) mehrere Möglichkeiten an, Passwörter zu überprüfen. Die Überprüfung wird von einem Dienst übernommen, der als PAM-Dienst dem System bekannt sein muss. So kann LINUX z.B. die Datei /etc/passwd überprüfen, oder NIS oder NIS+ oder eben auch über Kerberos die Authentifizierung einer AD-Domain übergeben. Zuständig für die Konfiguration der möglichen Dienste ist die Datei /etc/pam.d/system-auth-ac # This file is auto-generated.
    # User changes will be destroyed the next time authconfig is run.
    auth required /lib/security/pam_env.so
    auth sufficient /lib/security/pam_unix.so likeauth nullok
    auth sufficient /lib/security/pam_winbind.so use_first_pass
    auth required /lib/security/pam_deny.so

    account required /lib/security/pam_unix.so
    account sufficient /lib/security/pam_succeed_if.so uid < 100 quiet
    account sufficient /lib/security/pam_winbind.so use_first_pass
    account required /lib/security/pam_permit.so

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

    session required /lib/security/pam_limits.so
    session required /lib/security/pam_unix.so
    session required /lib/security/pam_winbind.so use_first_pass
    session required /lib/security/pam_mkhomedir.so
  • Jetzt kommt der große Moment. Melden Sie sich an einem PC der Domain mit einem gültigen Domainbenutzer an und suchen Sie in der Netzwerkumgebung nach dem Samba-Server. Doppelklicken Sie ihn. Es erscheint, ohne dass Sie den User auf dem LINUX-Server oder dem Samba-Dienst bekannt geben müssen, das Homeverzeichnis dieses Benutzers in der Freigabeliste des Samba-Servers. Wenn Sie sich mit diesem Benutzer oder mit root-Rechten an dem LINUX-Server anmelden, werden Sie diese Homeverzeichnis unter /home/DOMAIN/ finden.