Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- invis_server_wiki:upgrade:rescuead [2018/04/05 19:03]
flacco [Maschinen-Konten extrahieren]
+++ invis_server_wiki:upgrade:rescuead [2018/04/05 20:45] (aktuell)
flacco [Maschinen-Konten extrahieren]
@@ Zeile 1: / Zeile 1: @@
 ====== AD Rettung ======
-Die Übernahme eines bestehenden ActiveDiretories beispielsweise beim Upgrade von Sernet-Samba Paketen hin zu unseren eigenen, kann durchaus auch schief gehen. Uns ist das inzwischen mehrfach passiert. Beschädigt war in aller Regel das ID-Mapping zwischen den Windows-SIDs und den UNIX UID/GIDs. Eine Möglichkeit dies zu reparieren haben wir noch nicht gefunden, dafür aber einen anderen sehr eleganten Ausweg.
+Die Übernahme eines bestehenden ActiveDiretories beispielsweise beim Upgrade von Sernet-Samba Paketen hin zu unseren eigenen, kann durchaus auch schief gehen. Uns ist das inzwischen mehrfach passiert. Beschädigt war in aller Regel das ID-Mapping zwischen den Windows-SIDs und den UNIX UID/GIDs. Im Samba-Log haben sich dann immer nachfolgende Einträge zu Hauf gezeigt:
-Solange die Datei **''sam.ldb''** im Verzeichnis <file>/var/lib/samba/private</file> nicht beschädigt ist, können alle darin enthaltenen Informationen wie Benutzerkonten, Maschinenkonten usw. in ein neues AD übernommen werden. Sichern Sie sich diese Datei evtl. auf dem neuen System in ein Arbeitsverzeichnis.
+<code>
+[2017/09/11 12:45:36.109347,  0]
+../source4/auth/unix_token.c:107(security_token _to_unix_token)
+   Unable to convert SID (S-1-1-0) at index 3 in user token to a GID.
+Conversion was returned as type 0, full token:
+[2017/09/11 12:45:36.109486,  0]
+../libcli/security/security_token.c:63(security_token_debug)
+   Security token SIDs (8):
+     SID[  0]: S-1-5-21-477667662-2079173432-720341635-1110
+     SID[  1]: S-1-5-21-477667662-2079173432-720341635-513
+     SID[  2]: S-1-5-21-477667662-2079173432-720341635-1108
+     SID[  3]: S-1-1-0
+     SID[  4]: S-1-5-2
+     SID[  5]: S-1-5-11
+     SID[  6]: S-1-5-32-545
+     SID[  7]: S-1-5-32-554
+    Privileges (0x          800000):
+     Privilege[  0]: SeChangeNotifyPrivilege
+    Rights (0x             400):
+     Right[  0]: SeRemoteInteractiveLogonRight
+</code>
+Zugriffe auf Freigaben beispielsweise waren dann nicht mehr möglich. Eine Möglichkeit dies zu reparieren haben wir noch nicht gefunden, dafür aber einen anderen durchaus gangbaren Ausweg.
+Solange die Datei **''sam.ldb''** im Verzeichnis <file>/var/lib/samba/private</file> nicht beschädigt ist, können alle darin enthaltenen Informationen wie Benutzerkonten, Maschinenkonten usw. in ein neues AD übernommen werden. Sichern Sie sich diese Datei evtl. auf dem neuen System in ein Arbeitsverzeichnis.
 Voraussetzung für die Übernahme der Informationen ist, dass das neue AD den gleichen **Domain Secure Identifier** (Domain SID) trägt wie das zu rettende.
@@ Zeile 118: / Zeile 141: @@
 <code>
-invis:~/arbeitsverzeichnis # ldbsearch -H sam.ldb -b "CN=DHCP Config,CN=DHCP-Server,CN=invis-Server,DC=doc-net,DC=loc" objectClass=iscDhcpHost > hosts.ldif
+invis:~/arbeitsverzeichnis # ldbsearch -H sam.ldb -b "CN=DHCP Config,CN=DHCP-Server,CN=invis-Server,DC=invis-net,DC=loc" objectClass=iscDhcpHost > hosts.ldif
 </code>
@@ Zeile 159: / Zeile 182: @@
 ==== Maschinen-Konten extrahieren ====
-Das extrahieren der Maschinenkonten ist ebenfalls ein bisschen komplizierter als die Informationen rund um die Mailkonten der Benutzer.
+Das extrahieren der Maschinenkonten ist ebenfalls ein bisschen komplizierter als die Informationen rund um die Mailkonten der Benutzer. Ob der Schritt überhaupt sinnvoll ist, kann ich nicht abschließend sagen, da die Domänenbeitritte aller Arbeitsstationen in jedem Falle wiederholt werden müssen. Trotzdem beschreibe ich es mal hier, kann ja nicht schaden sich ein bisschen mit seinem AD auseinanderzusetzen.
 Neben der **objectGUID** müssen mit den Attributen **isCriticalSystemObject** und **primaryGroup** weitere Attribute entfernt und mit **pwdLastSet** ein Attribut manuell geändert werden.
@@ Zeile 169: / Zeile 192: @@
 </code>
-Öffnen Sie jetzt die soeben erzeugte Datei in einem Editor und setzen Sie für alle enthaltenen Objekte den Wert des Attributes "pwdLastSet" auf **''-1''** oder **''0''**. Die vorhandenen realen Werte sind für den Import nicht zulässig. Dabei bedeutet der Wert **''0''**, dass das Passwort des Clients abgelaufen ist und der Wert **''-1''** bedeutet, dass das Passwort des Maschinen-Kontos niemals abläuft.
+Öffnen Sie jetzt die soeben erzeugte Datei in einem Editor und setzen Sie für alle enthaltenen Objekte den Wert des Attributes "pwdLastSet" auf **''-1''** oder **''0''**. Die vorhandenen realen Werte sind für den Import nicht zulässig. Dabei bedeutet der Wert **''0''**, dass das Passwort des Clients abgelaufen ist und der Wert **''-1''** bedeutet, dass es niemals abläuft. Einen Unterschied macht das leider nicht:
-Hintergrund dessen "dürfte" sein, dass beim Extrahieren der Konto-Informationen das Passwort-Attribut nicht Teil des Ergebnisses ist. Es fehlt schlicht. Somit nutzt es auch nichts einen realen Zeitstempel für die letzte Passwort-Änderung anzugeben. Gespeichert werden die Passwörter (das gilt auch für Benutzerpasswörter) Bas64-Codiert im Attribut **''unicodePwd''**. Dieses lässt sich zwar gesondert auslesen:
+----
+**Hintergrundwissen**
+Beim Extrahieren der Konto-Informationen ist das Passwort-Attribut nicht Teil des Ergebnisses. Es fehlt schlicht. Somit nutzt es auch nichts einen realen Zeitstempel für die letzte Passwort-Änderung anzugeben.
+Gespeichert werden die Passwörter (das gilt auch für Benutzerpasswörter) Bas64-Codiert im Attribut **''unicodePwd''**. Dieses lässt sich zwar gesondert auslesen:
 <code>
@@ Zeile 182: / Zeile 210: @@
 </code>
-... fügt man diesen einfach in die Ergebnis-LDIF-Datei ein und versucht einen Import endet dies mit folgender Fehlermeldung:
+...aber fügt man dieses Attribut einfach in die Ergebnis-LDIF-Datei ein und versucht einen Import, endet dies mit folgender Fehlermeldung:
 <code>
@@ Zeile 191: / Zeile 219: @@
 Wem hier eine bessere Lösung einfällt, der darf sich gerne bei uns melden!
+----
 Evtl. enthalten die einzelnen Maschinenkonten auch Unterknoten mit Informationen zu Druckerwarteschlangen freigegebener Drucker. Diese können gesondert extrahiert werden:
@@ Zeile 218: / Zeile 246: @@
 Gehen sie die Ergebnisdatei in einem Editor manuell durch. Entfernen Sie alle Konten, die Sie nicht im neuen AD brauchen. Setzen Sie bei allen verbleibenden Konten das Attribut "pwdLastSet" wie zuvor bei den Maschinenkonten auf den Wert **''-1''** oder **''0''**.
-Im Falle der **''0''** müssen alle Benutzerpasswörter nach dem Neuaufbau des ADs neu gesetzt werden.
+Da hier prinzipiell das gleiche gilt wie oben unter "Hintergrundwissen" im Abschnitt "Extraktion der Maschinenkonten" beschrieben, spielt es auch hier keine Rolle, für welchen Wert Sie sich entscheiden. Sie müssen die Passwörter in jedem Falle neu setzen. Im Falle der Benutzer ist das allerdings kein ganz so großes Problem. Sie können mit einem einfachen Script einfach ein Standard-Passwort setzen und dies den Usern, mit der Bitte es unmittelbar neu zu setzen, mitteilen. Im Moment in dem Sie ein Passwort setzen, ändert sich auch unmittelbar der Wert des Attributs **''pwdLastSet''**. Ändern Sie ihn nachträglich für alle User wieder auf **''0''** werden sie bei der Erstanmeldung gezwungen ihr Passwort neu zu setzen.
 Damit sind auch die Benutzerkonten erfolgreich exportiert.
@@ Zeile 265: / Zeile 293: @@
 </code>
-Kontrollieren Sie das AD nach jedem Schritt. Über die Administrationsseite des invis-Portals können Sie über den Link "Verzeichnisdienst" die Appklikation **phpldapadmin" nutzen um sich Ihr AD anzuschauen.
+Kontrollieren Sie das AD nach jedem Schritt. Über die Administrationsseite des invis-Portals können Sie über den Link "Verzeichnisdienst" die Appklikation **phpldapadmin** nutzen um sich Ihr AD anzuschauen.
 Damit sind alle erforderlichen Informationen ins neue AD übernommen.
 ===== Letzte Handgriffe =====
-...to be continued
+==== Benutzerpasswörter ====
+Zur Nacharbeit zählt natürlich das Setzen neuer Passwörter für die Benutzer. Es empfiehlt sich (sollten Sie als Admin nicht //zufällig// im Besitz aller Passwörter sein ;-)) ein Standard-Passwort zu setzen:
+<code>
+invis:~ # sudo samba-tool user setpassword TestUser2 --newpassword=passw0rd --must-change-at-next-login
+</code>
+Daraus lässt sich recht schnell ein Script stricken, welches dieses Komanndo für alle vorhandenen Benutzer ausführt. Das überlasse ich Ihrer Fantasie.
+==== rIDNextRID ====
+Der zweite **sehr wichtige** Punkt ist, dass Sie Ihrem AD den letzten vergebene RID (relative Identifier) mitteilen. Der RID ist Bestandteil des SID (Security Identifier). Der SID eines Benutzers, einer Gruppe oder eines Maschinenkontos identifiziert dieses Objekt innerhalb der Domäne eindeutig. Er besteht aus einem statischen (dem Domain SID) und einem dynamischen Teil (RID). Dabei ist der RID einfach ein Wert bei für jedes neu angelegte Objekt jeweils um den Wert **''1''** hoch gezählt wird.
+Suchen Sie in der alten **''sam.ldb''** einfach nach dem dort vergebenen Wert:
+<code>
+invis:~/arbeitsverzeichnis # ldbsearch -H sam.ldb -b "CN=RID Set,CN=IhrDC,OU=Domain Controllers,DC=invis-NET,DC=loc" rIDNextRID
+# record 1
+dn: CN=RID Set,CN=MARS,OU=Domain Controllers,DC=invis-net,DC=loc
+rIDNextRID: 1141
+# returned 1 records
+# 1 entries
+# 0 referrals
+</code>
+//**Hinweis:** Ersetzen Sie "IhrDC" durch den Hostnamen Ihres AD Domain Controllers.//
+Im hier gezeigten Beispiel ergab die Suche den Wert **''1141''**. Diesen müssen Sie an gleicher Stelle in Ihrem neuen AD einsetzen. Das können Sie entweder über **phpldapadmin** oder mittels //**ldbedit**// erledigen.
+Dabei ist letzteres ein wirklich praktisches Tool. Es öffnet eine LDB-Datei an einer Stelle Ihrer Wahl im Editor Ihrer Wahl. Sie können damit LDB-Dateien bearbeiten, als wären es einfache ASCII-Dateien. Es versteht sich von selbst, dass Samba dabei besser nicht aktiv ist und Sie Ihr AD zuvor mit //**adbackup**// sichern sollten.
+Geben Sie beim Kommandoaufruf keinen Editor an, wird (was wohl auch sonst) der //**vi**// verwendet.
+//**Achtung:** Sie bearbeiten jetzt nicht die gesicherte **''sam.ldb''** des alten ADs, sondern die des neuen aktiven AD!//
+<code>
+invis:~ # ldbedit -H /var/lib/samba/private/sam.ldb -b "CN=RID Set,CN=IhrDC,OU=Domain Controllers,DC=doc-NET,DC=loc"
+</code>
+Sollten Sie ein Problem mit //**vi**// haben, können Sie mit folgender Zeile Ihren Lieblingseditor bestimmen:
+<code>
+invis:~ # ldbedit -e lieblingseditor -H /var/lib/samba/private/sam.ldb -b "CN=RID Set,CN=IhrDC,OU=Domain Controllers,DC=doc-NET,DC=loc"
+</code>
+Damit haben Sie Ihr AD gerettet. Viel Spaß bei den anstehenden Domänenbeitritten.... ;-)