Fügt der neuen Windows-Installation automatisch eine Domänengruppe hinzu


0

Beim Versuch, den lokalen Administratoren automatisch eine Domänengruppe hinzuzufügen, habe ich in meinem Workstation-Installationsskript den folgenden catch22 festgestellt.
Der Haken, den ich erlebe, ist der folgende:

  • Wenn ich den lokalen Administrator verwende, habe ich das Recht, Benutzer zu einer lokalen Gruppe hinzuzufügen, muss jedoch Domänenanmeldeinformationen angeben, um eine Verbindung mit der Domäne herzustellen
  • Wenn ich einen Domänenbenutzer verwende, kann ich eine Verbindung zum AD herstellen, der Benutzer ist jedoch noch kein lokaler Administrator, sodass ich lokale Gruppen noch nicht ändern kann.

Ich bin in einer GMP-Umgebung, also sind Regeln und Vorschriften wirklich! streng, was andere mögliche Pfade einschränkt.

  • Die Rollen sind aufgeteilt, sodass ich keinen Zugriff auf den Domain-Administrator habe.
  • Es sind keine Änderungen an Organisationseinheiten zulässig, durch die die Gruppe von den Gruppenrichtlinien verdrängt werden könnte
  • Die Verwendung von PowerShell mit Remoteskripts ist nicht zulässig

Dies ist ziemlich einfach, wenn Sie compmgmt.msc verwenden und die erforderlichen Anmeldeinformationen angeben, wenn Sie dazu aufgefordert werden. Ich möchte jedoch vermeiden, manuelle Schritte hinzuzufügen, und die gesamte Installation so weit wie möglich automatisieren.

Einige Details:

  • Das Betriebssystem der Workstation ist Windows 10
  • Das Skript, das ich verwende, ist PowerShell
  • Das Skript wird mit einem lokalen Administratorkonto mit erhöhten Rechten ausgeführt
  • Die Arbeitsstation ist bereits der Domäne beigetreten
  • Das Konto, mit dem die Arbeitsstation der Domäne hinzugefügt wird, ist kein Domänenadministrator
  • Um Administratorrechte für mein Domain-Konto zu haben, muss ich die Gruppe unserer Abteilung zur lokalen Administratorgruppe hinzufügen

Der Code, mit dem ich der lokalen Administratorgruppe eine Gruppe hinzufüge, lautet $de = [ADSI]"WinNT://$Env:ComputerName/Administrators,group" $de.psbase.Invoke("Add",([ADSI]"WinNT://MyCompanyDomain/MyDepartmentGroup").path)
Dieser Code funktioniert wie ein Zauber, wenn er mit einem Domänenkonto ausgeführt wird und ist ein lokaler Administrator.

Da dies für die Installation einer brandneuen Workstation verwendet wird, kann ich dies entweder als Domänenkonto ausführen oder lokaler Administrator
Mit dem ersteren die $de.psbase.Invoke("Add", Teil scheitert
Mit letzterem die ([ADSI]"WinNT://MyCompanyDomain/MyDepartmentGroup").path scheitert

Ich habe versucht mit start-process Cmdlet mit –verb runas Optionen, um einen anderen Sicherheitskontext zu erhalten, aber ich bin auf dasselbe Problem wie oben gestoßen.

Gibt es eine Möglichkeit, die ich kann?

  • nur lösen ([ADSI]"WinNT://MyCompanyDomain/MyDepartmentGroup").path im Sicherheitskontext eines Domänenbenutzers und übergebe das an den Rest meines Skripts, das im Sicherheitskontext des lokalen Administrators ausgeführt wird.

oder

  • Erstellen Sie das [ADSI] -Objekt aus fest codierten Daten, ohne eine Verbindung zur Domäne herstellen zu müssen

oder

  • an etwas anderes, blendend offensichtliches habe ich nicht gedacht

Sie können dies mit unattend.xml tun, ohne dass ein Skript erforderlich ist. Ist das in Ihrer Umgebung machbar?
Patrick Seymour

Antworten:


2

Sie können einer lokalen Gruppe eine Domänengruppe über die Schaltfläche hinzufügen unattend.xml Datei, wodurch keine Skripte mehr erforderlich sind.

Bearbeiten von Unattend.xml über System Image Manager (SIM)

Nach dem Öffnen Ihres unattend.xml Suchen Sie auf der SIM-Karte in der linken unteren Ecke des Fensters den Knoten für Microsoft-Windows-Shell-Setup. ( Hinweis: Sie sollten den Knoten verwenden, der der Architektur Ihres Images entspricht, d. H. Amd64 für 64-Bit-Plattformen.) Erweitern Sie dann den Shell-Setup-Knoten UserAccounts, DomainAccounts, und DomainAccountList. Klicken Sie mit der rechten Maustaste auf DomainAccount Knoten, und fügen Sie die Einstellung hinzu, um 7 (oobeSystem) zu übergeben. adding DomainAccount node to unattend

In der Mitte des SIM-Fensters müssen Sie die neu hinzugefügten Knoten konfigurieren. In dem DomainAccountList Geben Sie den Namen Ihrer Domain in das Feld ein Domain Wert.

In dem DomainAccount Knoten, der Group In diesem Fall sollte der Wert auf den Namen der lokalen Gruppe festgelegt werden, die Sie ändern möchten Administratoren . Das Name Der Wert sollte auf den Namen der Domänengruppe festgelegt werden, die Sie der lokalen Gruppe hinzufügen möchten.

Manuelles Bearbeiten von Unattend.xml ( nicht empfohlen )

Sie können auch die bearbeiten unattend.xml Datei manuell in Ihrem bevorzugten Texteditor. Suchen Sie die <settings> Knoten für die oobeSystem bestehen. Sie können das kopieren DomainAccounts Knoten unten, und platzieren Sie es in Ihrem unattend.xml nach dem AdministratorPassword Knoten. Ändern Sie unbedingt die Group und Name Knoten in der DomainAccount Knoten zusammen mit dem in der angegebenen Domainnamen Domain Knoten.

  <settings pass="oobeSystem">
    <component name="Microsoft-Windows-Shell-Setup" ... >
      <UserAccounts>
        <AdministratorPassword>
          <Value>mylocaladminpassword</Value>
          <PlainText>true</PlainText>
        </AdministratorPassword>
        <DomainAccounts>
          <DomainAccountList wcm:action="add">
            <DomainAccount wcm:action="add">
              <Group>Administrators</Group>
              <Name>Name-Of-Domain-Group-To-Add</Name>
            </DomainAccount>
            <Domain>DOMAIN_NAME_HERE</Domain>
          </DomainAccountList>
        </DomainAccounts>

Dies würde in der Tat unter der Bedingung funktionieren, dass ich der Domain in der unattend.xml beitreten darf ... was ich leider nicht bin. Der Grund dafür ist, dass (a) das Passwort für den automatischen Domain-Beitritt nicht in der Datei unattend.xml verschlüsselt werden kann, (b) unsere Passwörter alle 6 Monate geändert werden müssen, was bedeuten würde, dass ich einen neuen qualifizierten Build erstellen müsste (sprich: Lose) Papierkram) alle 6 Monate und (c) wir dürfen keine allgemeinen Dienstkonten verwenden, alles muss benannt werden. Ansonsten ist dies eine hervorragende Antwort, an die ich (um ehrlich zu sein) nicht gedacht habe.
GapWim

Sie sollten in der Lage sein, die obigen Einstellungen unabhängig davon zu verwenden, ob Sie der Domain über die unbeaufsichtigte Installation beitreten. Auch unser Domain-Beitrittsprozess ist nicht unbeaufsichtigt, und diese Methode funktioniert bei uns.
Patrick Seymour

In diesem Fall werde ich es versuchen und später darauf zurückkommen (kann einige Tage dauern). Wenn Sie sehen, dass Ihre Antwort als Antwort markiert wurde, wissen Sie, was das Ergebnis war;). bearbeitet, um hinzuzufügen: Ich muss das Äquivalent in ICD finden, nicht SIM. Aber wenn die Erinnerung stimmt, erinnere ich mich an etwas Ähnliches.
GapWim

Ich bin nicht sicher, was Sie teilen können, aber ich arbeite in einer ziemlich offenen Umgebung und bin gespannt auf Prozesse, die Sie durchlaufen müssen, wenn Sie etwas teilen können.
Patrick Seymour

Kein großes Geheimnis, nur ein stark reguliertes Umfeld. Ich mache derzeit ein Projekt in einem "Big Pharma" -Unternehmen. Die staatlichen Vorschriften verpflichten sie zur Verwendung von GMP, das für „Good Manufacturing Procedures“ (Gute Herstellungsverfahren) steht und nicht ohne Grund den Spitznamen „Great Mountains of Paper“ trägt. Extrem vereinfacht bedeutet dies, dass alle Aktionen, die die Produktion in geringster Weise beeinträchtigen könnten, dokumentiert, mit einem Zeitstempel versehen und unterschrieben werden müssen. Daher muss eine Änderung an einem benutzerdefinierten Build dokumentiert und protokolliert werden, wer einen PC mit dem AD verbunden hat. Daraus ergibt sich die Praxis: "Wenn es funktioniert, berühren wir es NIEMALS !!!"
GapWim
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.