Freitag, 15. Oktober 2010
[*]

Die Linux-Server im Windowsnetz (Teil 1)

, 12:16

Als wir noch nicht Microsoft-Gold-Partner waren, und uns die Windowslizenzen noch nicht nachgeworfen wurden, wurden hier ein paar Linux-Server als Fileserver aufgebaut. Mit Linux kann man (über NIS und den Automounter) sehr einfach die Benutzerverzeichnisse und -dateien über mehrere Rechner verteilen. Die Windows-Arbeitsplatzrechner hatten zu der Zeit noch keine Anbindung an eine zentrale Benutzerverwaltung sondern lokale Benutzerkonten.

Mit der Einführung von Exchange (statt Lotus Domino) wurde später eine Active Directory-Domäne eingerichtet, so dass Benutzernamen und Passwörter jetzt auf allen Windowsrechnern einheitlich funktionieren. Die Linux-Rechner blieben bisher außen vor (weil wir aber auf dem Fileserver einige Unix-Eigenheiten nutzen, weil es dort eine sehr gute vollautomatische Backupsoftware gibt, und weil außerdem inzwischen auch einige andere Dienste auf den Maschinen laufen kommt eine Umstellung auf Windows nicht ohne weiteres in Betracht).

Diese Gesamtkonstruktion sorgt dafür, dass für jeden Benutzer (mindestens) drei Passwörter existieren (AD, Unix/NIS, Samba). Wenn ein Benutzer nur eins davon ändert, dann wird er an (für ihn) unvorhersehbaren Stellen plötzlich nach einem (welchem?) Passwort gefragt. Die Lösung dafür war bisher einfach: die Benutzer änderten ihre Passwörter nicht (gibt es eigentlich Untersuchungen darüber, ob häufiger Passwortwechsel die Sicherheit eher erhöht oder verringert?). Jetzt sind wir aber seit kurzem mittelbares Tochterunternehmen einer Bank, und die hat einen Katalog an IT-Sicherheitsrichtlinien, zu dem auch eine Mindestkomplexität (8 Zeichen, große und kleine Buchstaben, Zahlen und Sonderzeichen) und eine Höchstgültigkeitsdauer (90 Tage) für Passwörter gehören.

Zeit also für eine Anbindung zwischen Linux und Active Directory:


Teil 1 orientiert sich an diesem sehr guten Tutorial.

Wir gehen also von einem Rechner mit Debian Lenny aus, der an AD (die Domain heißt exchange.as.lan) angebunden werden soll. Dankenswerterweise setzt Microsofts Active Directory seit ein paar Versionen auf Standardprotokolle wie LDAP und Kerberos auf, zu denen es im Opensource-Umfeld passende Implementationen gibt.

Schritt 1: Pakete installieren

apt-get install krb5-user samba winbind ntpdate ntp ssh

Schritt 2: Vorbedingungen

Auf dem Linux-Server (und auch auf den Domaincontrollern) sollte ntp korrekt eingerichtet sein, weil Kerberos-Tickets Zeitstempel und Gültigkeitsdauer beinhalten. Wenn da die Uhren verschiedener Ansicht über die aktuelle Zeit sind, dann kann das interessante Ergebnisse haben.

Schritt 3: Konfiguration

In der Datei /etc/krb5.conf wird die AD-Domain als Kerberos-Realm eingerichtet

[libdefaults]
        default_realm = EXCHANGE.AS.LAN

# The following krb5.conf variables are only for MIT Kerberos.
        krb4_config = /etc/krb.conf
        krb4_realms = /etc/krb.realms
        kdc_timesync = 1
        ccache_type = 4
        forwardable = true
        proxiable = true

# The following libdefaults parameters are only for Heimdal Kerberos.
        v4_instance_resolve = false
        v4_name_convert = {
                host = {
                        rcmd = host
                        ftp = ftp
                }
                plain = {
                        something = something-else
                }
        }
        fcc-mit-ticketflags = true

[realms]
        EXCHANGE.AS.LAN = {
                kdc = dc01.exchange.as.lan
                admin_server = dc01.exchange.as.lan
                default_domain = exchange.as.lan
        }

[domain_realm]
        .kerberos.server = EXCHANGE.AS.LAN
        .exchange.as.lan = EXCHANGE.AS.LAN

[login]
        krb4_convert = true
        krb4_get_tickets = false

Aus dem Samba-Projekt stammt der praktische Winbind-Service, der für in Active Directory eingetragene  Benutzern automatisch Unix-Benutzer (mit GID) und aus den AD-Gruppen automatisch Unix-Gruppen (mit GID) erzeugt. Winbind wird zusammen mit dem Rest von Samba in der /etc/samba/smb.conf konfiguriert:


[global]
## Browsing/Identification ###
# Change this to the workgroup/NT-domain name your Samba
# server will part of
    workgroup = EXCHANGE
    realm = EXCHANGE.AS.LAN
# server string is the equivalent of the NT Description field
    server string = %h server
    netbios name = DEBIAN

[...]

# "security = user" is always a good idea. This will require a Unix account
# in this server for every user accessing the server. See
# /usr/share/doc/samba-doc/htmldocs/Samba3-HOWTO/ServerType.html
# in the samba-doc package for details.
    security = ADS
# You may wish to use password encryption.  See the section on
# 'encrypt passwords' in the smb.conf(5) manpage before enabling.
    encrypt passwords = false

[...]

# Some defaults for winbind (make sure you're not using the ranges
# for something else.)
   idmap uid = 10000-20000
   idmap gid = 10000-20000
   template shell = /bin/bash
   template homedir = /home/restricted

# The following was the default behaviour in sarge,
# but samba upstream reverted the default because it might induce
# performance issues in large organizations.
# See Debian bug #368251 for some of the consequences of *not*
# having this setting and smb.conf(5) for details.
   winbind enum groups = yes
   winbind enum users = yes
   winbind use default domain = yes

Als nächstes muss Winbind mit der C-Bibbliothek (insbesondere mit dem „Name Service Switch“) reden. Dazu bringt Debian das passende Modul libnss_winbind.so schon mit. Es muss also nur in der /etc/nsswitch.conf eingeschaltet werden:

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat winbind
group:          compat winbind
shadow:         compat winbind

hosts:          files dns mdns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

Da in AD (im Gegensatz zu z.B. NIS) die Passwörter nicht in einer Form abgelegt sind, die Unix direkt überprüfen kann (also als Crypt- oder MD5-Hash), muss der Winbind-Service auch das übernehmen. Ein passendes Pluggable Authentication Module lässt ihn Benutzernamen und Passwort dem Domaincontroller zur Überprüfung vorlegen. Das wird in der /etc/pam.d/common-auth konfiguriert:

#
# /etc/pam.d/common-auth - authentication settings common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authentication modules that define
# the central authentication scheme for use on the system
# (e.g., /etc/shadow, LDAP, Kerberos, etc.).  The default is to use the
# traditional Unix authentication mechanisms.
#
auth    sufficient      pam_winbind.so
auth    required        pam_unix.so nullok_secure use_first_pass

Schritt 4: Der Domäne beitreten

Der Rechner ist jetzt zwar auf die Verbindung vorbereitet aber nicht automatisch Domänenmitglied. Genau wie bei einem Windowsrechner muss für ihn durch einen Domänenadmin ein Computerkonto angelegt werden:

net ads join -U Administrator

(dieser Befehl legt das Computerkonto an und trägt den Rechner ins dynamische DNS ein — der zweite Teil davon schlägt in unserem Netzwerk aus mir nicht bekannten Gründen fehl…)

So, noch Dienste starten und wir haben einen Linux-Rechner in AD integriert: Man kann sich per ssh mit dem AD-Passwort anmelden und von anderen Client-Rechnern (Domänenmitglieder unter Windows) aus kann man sich durch das bei der Anmeldung erstellte Kerberos-Ticket gegenüber Samba ausweisen (und so ohne weitere Passwortabfrage auf seine Verzeichnisse zugreifen).

Leider bleibt in dieser Konfiguration ein großer Haken: der Winbind-Service erzeugt die UIDs und GIDs für Unix aus den Windows-SIDs bei Bedarf und lokal. Jeder Benutzer hat also auf jedem Unix-Rechner (möglicherweise) eine andere UID, was die gemeinsame Nutzung von Verzeichnissen über NFS beinahe unmöglich macht. Wie man das behebt, damit wird sich Teil 2 beschäftigen.

Eine Reaktion:

  1. […] in Teil 1 schon erwähnte Sicherheitsrichtlinie schreibt auch vor, dass VPN-Zugänge logisch nicht an […]

Kommentare willkommen