Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- invis_server_wiki:upgrade:rescuead [2018/04/05 19:41]
flacco [Daten in neues AD importieren]
+++ 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 es Maschinen-Kontos niemals abläuft. Einen Unterschied macht das leider nicht:
+Ö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:
 ----
@@ Zeile 284: / Zeile 307: @@
 Daraus lässt sich recht schnell ein Script stricken, welches dieses Komanndo für alle vorhandenen Benutzer ausführt. Das überlasse ich Ihrer Fantasie.
-==== NextRid ====
+==== 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.
-Beim Hochzählen wird nicht unterschieden, ob es sich bei einem neuen Objekt um eine Gruppe, einen Benutzer oder ein Maschinenkonto handelt. Sie müssen also nach dem höchsten bisher vergebenen Wert in Ihrem alten AD suchen:
+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.... ;-)