Samba Migration

Vermutlich erwarten Sie auf der MSXFAQ nicht gerade eine Beschreibung einer SAMBA-Migration. Aber da ich in letzter Zeit einige Migrationen von SAMBA nach Exchange 200x durchführen bzw. Unterstützen durfte, scheint es dafür einen Tätigkeitsbereich zu geben.

Unterstützung durch Net at Work:
Wir helfen ihnen gerne bei der Migration ihrer SAMBA-Umgebung. Sprechen Sie uns einfach an. Die Beschreibung auf der Seite kann nicht alle Eventualitäten und Sonderfälle behandeln.

Werkzeug ADMT
Ein wichtiges Werkzeug ist ADMT Lesen und verstehen Sie daher zuerst die Funktionsweise von ADMT.

Samba und Exchange

Zuerst stellt sich die Frage wie Samba und Exchange zusammen hängen. SAMBA kann ja kein "Active Directory" nachbilden und selbst beim Einsatz von LDAP haben sich die SAMBA-Entwickler für einen eigenen LDAP-Dienst entschieden, statt OpenLDAP zu nutzen. Keiner dieser Dienste ist aber leistungsfähig genug, um Exchange 2000 oder höher darauf abbilden zu können. Zudem können Sie natürlich auch nicht Exchange auf Unix installieren (wenn man mal von der Installation in einer virtuellen Umgebung absieht). Aber SAMBA kann schon länger einen NT4 Domänencontroller simulieren und damit den Betrieb von Exchange 4.0, 5.0 und 5.5 auf einem NT4 Memberserver in einer NT4-ählichen Domäne erlauben.

Und genau diese Konstellation scheint es noch relativ oft zu geben:

  • Domänencontroller auf SAMBA
  • Exchange 5.5 auf einem Memberserver (NT4 oder Windows 2000)
  • Windows Workstations in der Domäne mit Outlook

Damit ist es einfach möglich, die Anmeldung über SAMBA zu erledigen, die Workstations ebenfalls an der Domäne zu betreiben und sogar ein "Single Sign On" mit Exchange 5.5 und Outlook zu erhalten. Exchange 5.5 kann in solch einer Umgebung problemlos als "Primäres Konto" einen Benutzer der SAMBA-Domäne referenzieren. Alle anderen Exchange Eigenschaften stehen ja weiterhin in der DIR.EDB von Exchange 5.5.

Lizenzen sparen
Ich frage mich natürlich schon, warum jemand eine SAMBA-Domäne mit Exchange 5.5 betreibt. Vielleicht in der irrigen Annahme, man müsste dann keine Windows CALs habe, da man ja kein Windows Domain Controller hat. Das ist aber falsch. Sobald ein Windows Server vorhanden ist und Anwender Exchange-Dienste auf diesem Server nutzen, muss für den Client sowohl eine Exchange CAL als auch eine Windows CAL vorliegen. Der Das einzige Einsparungspotential liegt dann darin, dass der Server mit SAMBA kein Windows Server sein muss. Man spart also maximal die Server Lizenz für jeden Server der SAMBA statt Windows betreibt. Mir schein die Einsparung dieser Server Lizenzen in keinem gesunden Verhältnis zu Komplexitätssteigerung zu stehen.

Warum migrieren und wohin ?

Auch wenn solch eine Umgebung viele Jahre problemlos gelaufen ist, so ist das Ende abzusehen. Exchange 5.5 und Windows NT 4.0 wird schon lange nicht mehr unterstützt und die Funktionen sind doch recht beschränkt (SMTP-Standards, Spamschutz). Auch gibt es immer weniger SystemhäUser und Dritthersteller (Speziell Virenschutz und Datensicherung), die sich noch mit Exchange 5.5 auskennen. Nur wie lässt sich diese Umgebung nun aktualisieren ?.

Natürlich können Sie versuchen, die Inhalte per IMAP4 auszulesen und in andere Produkte zu überführen. Aber wenn Sie heute schon Outlook und Windows Clients einsetzen, dann ist es nicht nur eine Frage von "Mail", sondern die gesamte Umgebung ist zu betrachten. Windows NT4 und die NT4 Policies sind im Vergleich zu Gruppenrichtlinien des Active Directory doch eher beschränkt. Auch könnte die Einführung von NIS, z.B.: gekoppelt oder basierend auf dem Active Directory Kosten einsparen.

So liegt aus meiner Sicht die Migration in ein Active Directory und nach Exchange 2003 oder sogar 2007 nahe.

Die klassischen Migrationswege von Exchange 5.5 nach Exchange 2000/2003 habe ich schon auf Updategrundlagen beschrieben. Aber in diesem Fall handelt es sich ja um eine SAMBA-Domäne, die natürlich nicht so einfach in ein Active Directory überführt werden kann.

Windows Domänen

Ein Inplace-Update eines Samba DCs auf Windows 200x ist ebenso wenig möglich wie die Installation eines NT4 BDCs in die Domäne um diese dann hochzurüsten. Also können wir ausschließen, dass wir die SAMBA-Domäne einfach in ein Active Directory überführen können. Wir müssen also das Active Directory erst einmal "frisch" und leer installieren.

Es ist nicht möglich, eine SID aus einem „nicht Windows System“ in einen Windows DC als „SID-History“ anzuhängen. Technisch wäre es sicher möglich aber das entsprechende LDAP-Feld ist „protected“ und die einzige API, die Microsoft bereitstellt (und bei SIDHIST.VBS selbst öffentlich nutzt) erlaubt nur die Übertragung von Windows nach Windows.
Allerdings kann ADMT zumindest mit einer Textdatei die SIDs auf Shares, Dateien, Registry-Keys etc. Umstellen.

Das bedeutet natürlich auch, dass alle Benutzer, Gruppen und Computerkonten nicht so einfach in das neue Active übernommen werden können. Microsoft bietet zwar mit ADMT ein sehr mächtiges Werkzeug, um eben diese Daten von einer Domäne in eine andere Domäne zu verschieben, aber ADMT funktioniert mit einer SAMBA-Domäne nur unter Einschränkungen.

  • SID-History
    ADMT kann leider nicht die SID einer SAMBA-Quelldomäne als SID-History in das Zielobjekt übernehmen. Der entsprechende RPC-Aufruf gegen einen Sambaserver ist nicht möglich.
  • Kennwort
    Weiterhin kann der Passwortserver natürlich nicht installiert werden. Eine Übernahme der Kennworte ist daher auch nicht möglich.

SID History
Das Feld "sidhistory" im Active Directory kann per LDAP zwar gelöscht aber nicht beschrieben werden. Anscheinend geht dies nur durch einen RPC-Aufruf gegen LSASS, der aber nicht offen gelegt ist. Das passende COM-Objekt, welches von ADMT aber auch sidhist.vbs und Clonepr.vbs genutzt wird, erlaubt nur die Übertragung einer SID von einer Quelle auf ein Ziel, aber kein "Import" einer SID aus anderen Quelle.
Ich bin sehr daran interessiert, wenn jemand hier eine Lösung oder weitere Details hat.

ADMT kann aber doch genutzt werden, um die Benutzer und Gruppen zu übernehmen und die Computer zu migrieren. Dies sollten Sie auch unbedingt nutzen. Diese Migration erlaubt ihnen nämlich dann die Information in der ADMT-Datenbank zu nutzen, um nachträglich noch Berechtigungen zu konvertieren. Dazu braucht ADMT aber eine Zuordnung der alten SID zum neuen Benutzernamen. Hierzu müssen Sie wissen, dass ADMT eben diese Information auch aus einer CSV-Datei gewinnen kann, die sie aber erst generieren müssen.

Unterstützung durch Net at Work:
Wir nutzen dazu ein kleines VBScript (DUMPSID), welches aus SAMBA die SID-Informationen ausliest und in einem ADMT3-kompatiblen Format ablegt.

So gelangen die Benutzer und Gruppen alle in das Active Directory und auch die Computerkonten lassen sich mit ADMT problemlos migrieren.

Es gibt Produkte von Drittherstellern, die die Kennwort aus SAMBA sogar auslesen und im Active Directory setzen, so dass die migrierten Benutzer mit ihrem bisherigen Kennwort weiter arbeiten können. Die gehashten LM und NT-Passwörter stehen im Klartext in der jeweiligen samba-Datenbank (smbpasswd/tdb/ldap)

Leider ist es aber anscheinend nicht möglich, die SID der SAMBA-Domäne als SID-History in das Active Directory zu kopieren. Die entsprechenden Tools von Microsoft erwarten immer, dass die SID aus einer Quelldomäne kopiert wird. Der Import aus einer Textdatei wird nicht unterstützt.

Allerdings müssen natürlich ein paar Randbedingungen stimmen (Namensauflösung, Trusts, Berechtigungen etc.), die ich hier aber nicht alle im Detail aufzählen kann. Ein Trust ist aber zumindest ein der Richtung "AD vertraut Samba" erforderlich, dass die folgenden Schritte möglich sind.

Exchange Server und Dienstkonto

Bei der Umstellung von Exchange gibt es zwei Dinge zu beachten:

  • Exchange Dienstkonto
    Mit diesem Konto arbeitet Exchange 5.5 selbst. Es ist problemlos möglich, einen Memberserver von einer SAMBA-Domäne in eine Active Directory Domäne zu verschieben und dort weiter zu betreiben. Um jedoch die alte Domäne irgendwann abschalten zu können, muss man auch das Dienstkonto von Exchange 5.5 auf einen Benutzer in der neuen Domäne ändern. Zum Glück gibt es hier entsprechende Anleitungen von Microsoft, um eben dies durchzuführen.
    So ist es mit einer kurzen Downtime möglich, den Exchange 5.5 Server schon einmal in das Active Directory zu bringen
  • Primäres Benutzerkonto
    Kniffliger wird es dann aber mit den Exchange 5.5 Postfächern, an denen ebenfalls die SID zum Anmeldekonto des Benutzers enthalten ist. Bei einer normalen Migration mit ADMT und SID-History ist es recht einfach, dass der Benutzer sowohl mit dem alten Konto als auch mit dem neuen Konto arbeitet. Ohne SID-History hingegen muss man sich dann einmal einen Zeitpunkt suchen, zu dem ein Benutzer sich nur noch mit den neuen Anmeldedaten am Active Directory anmeldet und in Exchange 5.5 eben das primäre Konto durch das neue Anmeldekonto ersetzen. Das können Sie Postfach für Postfach einzelne machen oder per ADMT oder CSV-Datei massenhaft ändern lassen.

Letztlich haben Sie es aber dann geschafft, dass der Exchange Member Server und das Exchange Dienstkonto schon im neuen Active Directory sind und die Anwender sich mit ihrem Active Directory Konto anmelden und auf das Postfach zugreifen können.

Beachten Sie bei dieser Umstellung aber etwaige Drittkomponenten wie Backup, Virenschutz und andere Skripte, die vielleicht noch den alten Domänennamen nutzen.

Workstations und Profile

Nicht vergessen werden darf natürlich auch die Workstation. Was wäre ein Server mit Postfächern, wenn die Mitarbeiter keinen Zugriff mehr darauf hätten. Damit der Zugriff auf das Postfach möglich ist, sind folgende Punkte zu beachten:

  • Domänenzugehörigkeit des PCs
    Der PC muss einer Domäne angehören, die zum einen der Domäne mit dem Anmeldekonto des Benutzers vertraut, so dass dieser sich anmelden kann und zum anderen muss die Domäne mit dem Exchange Konto ebenfalls per Trust angebunden sein. Wenn Sie nur eine Domäne betreiben, dann bedeutet diese Forderung, dass das Anmeldekonto und der Computer am besten schon in das Active Directory migriert worden sind.
  • Anmeldung des Mitarbeiters
    Dann muss natürlich sichergestellt werden, dass sich der Mitarbeiter am PC mit dem "richtigen" Benutzer anmeldet. War der PC gestern noch in der Samba Domäne dann ist die "Default Domain" immer noch die Samba-Domäne und der Mitarbeiter versucht sich weiter dort anzumelden. Mit diesen Benutzer kommt er natürlich nicht mehr an sein Postfach. Eine Gruppenrichtlinie hilft, um die Default Domain der PCs auf die neue Domäne zu setzen.
  • MAPI Profil
    Der Wechsel des Anwenders von "Samba\Username" auf "ADDomain\Username" hat natürlich ein einen Wechsel der SID mit sich gebracht und damit ist der Benutzer für den PC natürlich ein komplett anderer neue Benutzer mit einem neuen Profil. Ohne weiterer Vorkehrungen fehlen dem Benutzer also nicht nur sein geliebtes Hintergrundbild sondern auch das MAPI-Profil und eventuell vorhandene PST-Dateien und andere Dokumente. Auch hier kann ADMT helfen, dass die Anwender auch mit dem neuen Anmeldenamen von der Arbeitsstation wiedererkannt werden und ihr bestehendes Profil weiter verwenden können. Auch hier müssen Sie ohne die SID-History auskommen, so dass diese Umstellung sorgfältig geplant werden muss.
  • Andere Server
    Etwas "Rücksicht" sollten Sie noch auf andere Server in der alten SAMBA-Domäne nehmen. Auch hier haben die Benutzer der SAMBA-Domäne natürlich Berechtigungen, die mit der Umstellung erst einmal nicht konvertiert werden. Damit die Anwender also auch mit ihrem neuen Konto auf andere Services zugreifen können, müssen Sie auch dort die Rechte kontrollieren, konvertieren (ADMT hilft) oder gleich über Gruppen regeln. Wenn Sie die Berechtigungen auf Freigaben etc. über Gruppen steuern, dann ist es sehr viel einfacher ein Konto in eine Gruppe aufzunehmen anstatt auf allen Server, alle Freigaben und Dateien anzupassen.

Aber auch diese "Probleme" sind zu bewältigen, so dass die Mitarbeiter nach der Migration des Exchange Servers, des Computers und des Benutzerkontos an ihrem PCs mit ihrem neuen Anmeldekonto ungestört weiter arbeiten können.

Warnung

Unterschätzen Sie allgemein nicht die Einführung von Active Directory und Gruppenrichtlinien. Sie haben mit der Migration quasi die einmalige Gelegenheit ein Active Directory ganz frisch aufzubauen. Das ist eine gute Chance aber auch eine umfangreiche Aufgabe. Ich denke da nur an ..

  • Zeitabgleich
  • Namensauflösung (DNS/WINS)
  • Gruppenrichtlinien
  • OU-Konzepte und Administrative Berechtigungen
  • Kennwortrichtlinien
  • Benutzerprofile

Alles Dinge, die in einer SAMBA-Domäne oder NT4-Domäne nicht verfügbar bzw. nicht erforderlich waren.

Unterstützung durch Net at Work:
Nutzen sie unser fundiertes Wissen um das Active Directory, Exchange und unsere Erfahrung bei der Migration anderer Systeme.

SID und SIDHistory und DUMPSID

An vielen Stellen haben Sie nun auch den Begriff "SID" gehört und auch ein Benutzer in einer SAMBA-Domain hat eine SID. Windows 2000 und höher unterstützen eine Funktion namens "SIDHistory", bei der ein Prozess eine alte SID einfach dem neuen Benutzer als "zusätzliche SID" mitgeben kann. Der smarte Effekt dabei ist, dass der neue Anwender damit einfach auf die Ressourcen weiter zugreifen kann, auf die der alte Anwender native Zugriff hatte. Der Server kann gar nicht unterscheiden, dass dies nicht die "primäre" sondern eine weitere SID ist. Genauso wenig wie dies bei Gruppen möglich ist.

Da kommt natürlich der Wunsch auf, auch die SID von SAMBA einfach an das neue Konto zu addieren. Per ADMT und per SIDHIST.VBS ist das ja problemlos möglich, wenn die Quelle eine Windows Domäne ist. Leider ist mir dies mit SAMBA als Quelle noch nicht gelungen. Übertragen werden wohl

  • Kennworte
    Diese werden von ADMT aber wohl nicht in "Klartext" ausgelesen, was schon Prinzip bedingt nur gehen würde, wenn in der Quelle die Kennworte tatsächlich im Klartext oder reversibel gespeichert wären. Es dürften also nur die Hashwerte ausgelesen werden und die sind nicht interoperabel
  • SIDHistory
    Meines Wissen kann diese Funktion nur mit ADMT, SIDHIST, ClonePR und ein paar anderen Skripten erreicht werden, die aber alle die gleiche Microsoft-API verwenden. Über diese Schnittstelle wird aber der komplette Kopierprozess von der Quelle zum Ziel gesteuert und diese API unterstützt eben nur bestimmte Quellen. Ich kenne keinen Weg eine bekannte SID auf einem Zielkonto einfach zu "setzen". Und das ist genau genommen ja auch gut, denn die SID selbst ist nicht besonders "geschützt". Man kann sie auf jeder Ressource auslesen, an der sie genutzt wird. Diese Nummer dann einem beliebigen anderen Konto zu geben würde ein Sicherheitsloch ungeahnten Ausmaßes aufreißen.
    Die API ist zwar nach oben hin offen gelegt aber nicht die Schnittstelle zu den Servern. Die per NETMON verwendeten API-Aufrufe sind dokumentiert und scheinen gut gesichert zu sein. Mir ist nämlich noch kein Tool für diese "Umgehung" bekannt.

Trotzdem gibt es einen Bedarf für Skripte wie eben DumpSid, welche die SID holen und als CSV-Datei speichern. ADMT kann nämlich für die Funktion "Suchen und Ersetzen" von ACLS nicht nur auf seine interne Datenbank zugreifen, sondern eben auch auf eine CSV-Datei. So ist es zumindest möglich auf Windows-Systemen mit ADMT alle Ressourcen abzuklappern und alle Vorkommen der alten SID durch die neue zu ergänzen, zu ersetzen oder nach getaner Migration die alte SID zu entfernen.

Weitere Links