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:

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
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:

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:

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 ..

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

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

Keywords:Migration Koexistenz ADMT Samba