• 11Okt

    Es gibt schon HOWTOs wie Sand am Meer zu diesem Thema. Damit ich nicht immer wieder suchen muss, schreibe hier nochmal alles in Kurzform auf 🙂

    Sinn und Zweck der Aktion ist es, mit einem Samba-Server einer Windows-Domain beizutreten. Die Benutzer können dann ohne erneute Anmeldung für sie freigegebene Verzeichnisse nutzen und sich auch per SSH anmelden.

    Umgebung: Ubuntu Hardy und eine Windows Server 2003-Domain namens „NAME.LOCAL“ mit einem Domain Controller „server.name.local“ an der Adresse 192.168.0.1.

    1. Benötigte Pakete
      • samba
      • winbind
      • krb5-user
      • libpam-krb5
      • krb5-config
      • libkadm55
    2. Wichtige Einstellungen der /etc/samba/smb.conf
      workgroup = NAME
      realm = NAME.LOCAL
      wins server = 192.168.0.1
      password server = 192.168.0.1
      client use spnego = yes
      client ntlmv2 auth = yes
      security = ADS
      encrypt passwords = true
      idmap backend = rid:NAME.LOCAL=70000-1000000
      idmap uid = 70000-1000000
      idmap gid = 70000-1000000
      template shell = /bin/bash
      template homedir = /home/%D/%U
      winbind use default domain = yes
      winbind enum groups = yes
      winbind enum users = yes
    3. Eine Beispiel-Freigabe mit Berechtigung für eine Windows-Gruppe
      [webroot]
      comment = Verzeichnis des Webservers
      path = /var/www
      browseable = yes
      read only = no
      create mask = 0664
      directory mask = 0775
      valid users = @NAME\Webentwickler
    4. /etc/nsswitch.conf
      passwd:   compat winbind
      group:    compat winbind
    5. /etc/pam.d/common-password
      password   requisite  pam_unix.so nullok obscure md5
      password   optional   pam_smbpass.so nullok use_authtok
                            use_first_pass missingok
    6. /etc/pam.d/common-account
      account sufficient      pam_winbind.so
      account required        pam_unix.so
    7. /etc/pam.d/common-session
      session required pam_unix.so
      session required pam_mkhomedir.so umask=0022 skel=/etc/skel
      session optional pam_foreground.so
    8. /etc/pam.d/common-auth
      auth required   pam_group.so use_first_pass
      auth sufficient pam_winbind.so
      auth sufficient pam_unix.so nullok_secure use_first_pass
      auth required   pam_deny.so
    9. /etc/pam.d/sudo
      #%PAM-1.0
      auth sufficient pam_winbind.so
      auth sufficient pam_unix.so use_first_pass
      auth required   pam_deny.so
      @include common-account
    10. /etc/krb5.conf
      [libdefaults]
        default_realm = NAME.LOCAL
        NAME.LOCAL = {
          kdc = server.name.local
          admin_server = server.name.local
        }
      
      [domain_realm]
        .name.local = NAME.LOCAL

    Ob die Kerberos-Verbindung zum Windows-Server klappt, kann dann mit dem Kommando „kinit Administrator@NAME.LOCAL“ und einem nachfolgenden „klist“ überprüft werden.

    Nach dem Neustart der Samba- und Winbind-Dienste muss der Server dann noch in die Domain eingefügt werden. Das geht über das Kommando „net rpc join -S server -U Administrator“. Ob die Windows-Benutzerdatenbank richtig angezapft wird, lässt sich mit „wbinfo -u“ und „wbinfo -g“ überprüfen.

    Nachtrag:

    • Das Dateisystem, das die Freigaben beinhaltet, muss mit acl- und user_xattr-Unterstützung eingebunden sein, damit NT-Dateiberechtigungen auch richtig abgebildet werden können. Also in der /etc/fstab „defaults,acl,user_xattr“ in die vor-vorletzte Spalte
    • Eine Freigabendefinition sieht mit ACL-Unterstützung so aus, ob das optimal ist muss sich noch zeigen:
      [share]
      path = /srv/share
      browseable = yes
      read only = no
      valid users = @NAME\domänen-benutzer
      admin users = @NAME\domänen-admins
      nt acl support = yes
      acl group control = yes
      inherit permissions = yes
      map acl inherit = yes

    Permalink

    Tags: , , , ,

  • 18Nov

    Heute stand mal wieder die Einrichtung einer Exchange-Umgebung an. Ich weiß schon, warum ich das letzte Mal in dieser Situation lieber den exzellenten Kerio MailServer eingesetzt habe…

    Die betreute Firma benutzt 4 bis 5 verschiedene Domains mit immer gleichen Mailkonten, und sowohl beim Senden als auch beim Empfangen soll ersichtlich sein, welche Domain nun gerade benutzt wird. Eigentlich kein Ding, oder? Tja, wer das denkt, kennt Exchange nicht. Oder kenne ich es nicht gut genug?

    Empfangen: OK, das mit dem schrottigen POP3-Connector im SBS 2003 muss ich keinem erzählen. Also mal wieder Cygwin mit cron und fetchmail eingerichtet. Die schöne Lösung mit Mailsammlung beim Provider und zentraler Abholung per UUCP ist leider nicht drin, weil der Provider nicht auf den schönen Namen Tigernet hört 😉

    Erste Idee: Ein Konto pro Benutzer mit allen dazugehörigen Mailadressen, gesammelte Zustellung durch fetchmail an diesen Account, und Server-Regeln zum Einsortieren der Mails in Domain-Unterordner. Das scheitert aber daran, dass Exchange die Information über die ursprüngliche Empfängeradresse nicht durchreicht – jedenfalls nicht so, dass man sie per Regel auswerten könnte. Eine eingehende Mail an xy@domain1.com ist also nicht von einer an xy@domain2.com zu unterscheiden.

    Also läuft es nun so: Mehrere Windows-Konten pro Benutzer, jeweils nach Maildomains aufgeteilt. Als Anhängsel zum Nachnamen gibt es „[Domain1]“ oder „[Domain2]“. fetchmail stellt an die jeweiligen Windows-Konten zu, und dort ist in den Zustelloptionen das eigentliche Hauptkonto als Ziel angegeben. So fließt die Domain in Form des Nachnamen-Anhängsels ein und ist für den Anwender sichtbar. Die Zusatzkonten werden in den Exchange-Adresslisten unsichtbar gemacht und stören so nicht weiter. Nicht schön, aber geht. Das hatten wir doch neulich erst!

    Senden: Auch nicht viel schöner. Man könnte ja denken, dass ein Benutzer alle seine zugewiesenen Mailadressen in einer Auswahlliste in Outlook zu sehen bekommt und dann auswählen kann, mit welcher Identität er gerade verschicken will. Das geht ja schließlich auch, wenn man mehrere POP3-Konten eingerichtet hat. Aber nein, das wäre ja viel zu einfach. Das geht nur mit Zusatztools von IvaSoft: SmartReply für Outlook (50$ pro Client) und ChooseFrom für Exchange (200$). Funktioniert gut, ist dem Kunden aber nicht zu vermitteln. Diese beiden Tools hätte Microsoft mal statt des POP3-Connectors kaufen und integrieren sollen!

    Was also tun, außer sich das Thunderbird-Feature mit mehreren Identitäten pro Konto zu wünschen? Mal wieder der alte Hack mit den Dummy-POP3-Konten, die nur zum Senden benutzt werden. *schüttel*

    So, genug Schauergeschichten für heute. Halloween ist schließlich schon lange vorbei!

    Permalink

    Tags: , , ,

  • 24Okt

    Mal wieder ein Fall von „Typisch Microsoft“: Ein Windows Server 2003 (in diesem Fall eine Small Business Edition) deaktiviert bei jedem Neustart den Schreibcache seiner Systemfestplatte, wenn er keine Batteriepufferung o.ä. erkennt. Grund: Absicherung gegen Stromausfälle. Auswirkung: Performance wie eine Schildkröte.

    Ob man betroffen ist, lässt sich einfach feststellen: Geräte-Manager -> Laufwerke -> entsprechendes Laufwerk auswählen. In den Eigenschaften unter „Richtlinien“ kann man die Haken für „Schreibcache auf dem Datenträger aktivieren“ und „Erhöhte Leistung aktivieren“ setzen. Die Einstellung wirkt sich sofort aus. Wenn die Haken nach einem Neustart des Servers wieder verschwunden sind: Willkommen im Club!

    Das Setzen eines Schreibschutzes für die entsprechenden Registry-Schlüssel, die hinter diesen Haken stecken, bringt nichts. Abhilfe schafft das Programm dskcache.exe, das es seit Windows 2000 gibt. Trotzdem gehört es nicht zum Lieferumfang und lasst sich nur als „Hotfix auf Anfrage“ unter http://support.microsoft.com/kb/811392 herunterladen. Alternativ könnte man bei Google nach Windows2000_KB811392_x86_ENU.EXE suchen 😉 .

    Ein Aufruf von dskcache ohne Parameter zeigt den Cache-Status an. Man aktiviert den Cache über dskcache +p +w. Das kann man nun nach jedem Neustart per Hand oder Batchdatei oder Batchdatei im Autostart machen. Besser ist es aber, einen „Geplanten Task“ anzulegen, damit der Aufruf beim Hochfahren automatisch ausgeführt wird, auch wenn sich (wie an einem Server üblich) niemand anmeldet.

    Ich sehe ja ein, dass ein Server – und gerade seine Systempartition – gegen Dateisystemfehler abgesichert sein muss. Trotzdem sollte Microsoft dem Admin die Möglichkeit geben, dieses automatische Abschalten des Caches zu unterbinden, ohne Klimmzüge zu unternehmen.

    Was wohl die Elitetruppe auf Experts Exchange zu dem Thema herausgefunden hat…?

    Permalink

    Tags: , ,