Details zur Active Directory Verbindung

Einführung

Connector-Version

Diese Dokumentation basiert auf Version 21.0.8657 des Connectors.

Erste Schritte

Active Directory Versionsunterstützung

Der Connector bietet SQL-basierten Zugriff auf Active Directory über das LDAP -Protokoll. Der Connector ist ein Standard-LDAP -Client, der LDAP v2 und v3 unterstützt.

Herstellen einer Verbindung

Authentifizieren gegenüber Active Directory

Um Anfragen zu authentifizieren, setzen Sie User Und Password Eigenschaften auf gültige Active Directory Anmeldeinformationen (z. B. festlegen User zu „Domain\BobF“ oder „cn=Bob F,ou=Employees,dc=Domain“).

Der Connector verwendet standardmäßig Klartextauthentifizierung, da der Connector versucht, TLS/SSL mit dem Server auszuhandeln. Sie können mit eine andere Authentifizierungsmethode angeben AuthMechanism.

Siehe SSL-Konfiguration für weitere Informationen zur TLS/SSL-Konfiguration.

Herstellen einer Verbindung mit Active Directory

Satz Server Und Port für grundlegende Konnektivität. Zusätzlich können Sie die Verbindung wie folgt optimieren:

• FollowReferrals: Wenn festgelegt, zeigt der Connector Daten nur als Ansichten von Verweisservern an. Um Daten auf einem Verweisserver zu ändern, müssen Sie diesen Server mit angeben Server Und Port.
• LDAPVersion: Stellen Sie hier die Version des Protokolls ein, das Ihr Server implementiert. Standardmäßig verwendet der Connector Version 2.

Optimieren des Datenzugriffs

Die folgenden Eigenschaften steuern den Umfang der zurückgegebenen Daten:

• BaseDN begrenzt den Umfang von LDAP -Suchen auf die Höhe des angegebenen Distinguished Name. Hinweis: Die Angabe eines engen BaseDN kann die Leistung erheblich steigern; beispielsweise gibt ein Wert von „cn=users,dc=domain“ nur Ergebnisse zurück, die innerhalb von „cn=users“ und seinen untergeordneten Elementen enthalten sind.
• Scope: Diese Eigenschaft ermöglicht eine genauere Kontrolle über die von einem Unterbaum zurückzugebenden Daten.

Tabellen anpassen

Der Connector zeigt die am häufigsten benötigten Spalten aus Active Directory Entitäten an. Wenn Sie jedoch mit anderen Daten arbeiten müssen, können die Tabellen leicht geändert werden. Tabellen werden in Schema definiert, die ein einfaches Format haben.

Siehe Arbeiten mit Active Directory Tabellen für eine Anleitung zum Erweitern der Standardschemata oder zum Schreiben eigener Schemata. Um benutzerdefinierte Schemata zu verwenden, setzen Sie die Location-Eigenschaft für den Ordner, der die Schema enthält.

Arbeiten mit Active Directory Tabellen

Der Connector enthält Tabellenschemata für viele standardmäßige Active Directory Objekte. Sie können die enthaltenen Tabellenschemata problemlos erweitern, um das Spaltenverhalten zu bearbeiten, oder Sie können Ihr eigenes Schema von Grund auf neu schreiben.

Tabellenschemata werden in .rsd-Dateien definiert, bei denen es sich um einfache Konfigurationsdateien handelt. In diesem Abschnitt werden die verschiedenen Teile des Schema erläutert. Als Beispiel werden der Tabelle „Person“ mehrere Spalten hinzugefügt.

Sie finden die Datei Person.rsd im Unterordner db im Installationsordner des Active Directory Connectors.

Mit benutzerdefinierten Tabellen verbinden

Um benutzerdefinierte Schemata zu verwenden, setzen Sie das Location-Eigenschaft für den Ordner, der die Schema enthält.

Definieren einer neuen Tabelle

Es ist wichtig, eine neue Tabelle mit demselben Namen wie die Objektklasse zu definieren, die die Tabelle darstellen soll. Dadurch kann der Connector bei Abfragen an den Active Directory-Server nur nach der gewünschten Objektklasse suchen. Der Dateiname definiert den Tabellennamen.

Tabellenspalten und Eingaben definieren

Spalten werden definiert in rsb:info Block, wie unten gezeigt. Der attr Tags im Schema stellen die Spalten der Tabelle dar. Diese sollten mit den Attributen übereinstimmen, aus denen die gewünschte Objektklasse besteht.

Es gibt einige Spalten, die jede Tabelle enthalten sollte, unabhängig von der Objektklasse:

<rsb:script xmlns:rsb="http://www.rssbus.com/ns/rsbscript/2">
<rsb:info title="Person" description="Create, update, delete, and query person entries in Active Directory.">
<!-- Required Columns -->
<attr name="Id"          xs:type="string" readonly="true"  key="true"        />
<attr name="DN"          xs:type="string" readonly="true"  required="false" other:ldaptype="OID" />
<attr name="RDN"         xs:type="string" readonly="true"  required="false" other:ldaptype="Directory String" />
<attr name="BaseDN"      xs:type="string" readonly="true"  required="false" other:ldaptype="OID" />

Hinweis: Die title Attribut des rsb:info Block muss mit dem Namen der .rsd-Datei übereinstimmen.

Anpassen des Spaltenverhaltens

Jede Spalte erfordert mindestens name Und xs:type Attribute. Zusätzlich müssen Sie angeben dataFormat um zu entscheiden, wie Daten aus der Tabelle zurückgegeben werden. Beispiel:

<!-- Person Required Attributes -->
<attr name="ObjectClass"                 other:dataFormat="splitDataByRow" xs:type="string" readonly="false" required="false" other:ldaptype="OID" />
<attr name="SN"                          other:dataFormat="delimitedData"  xs:type="string" readonly="false" required="false" other:ldaptype="Directory String" />
<attr name="CN"                          other:dataFormat="delimitedData"  xs:type="string" readonly="false" required="false" other:ldaptype="Directory String" />

<!-- Person Optional Attributes -->
<attr name="UserPassword"                other:dataFormat="delimitedData"  xs:type="string" readonly="false" required="false" other:ldaptype="Binary" />
<attr name="TelephoneNumber"             other:dataFormat="delimitedData"  xs:type="string" readonly="false" required="false" other:ldaptype="Directory String" />
<attr name="SeeAlso"                     other:dataFormat="delimitedData"  xs:type="string" readonly="false" required="false" other:ldaptype="DN" />
<attr name="Description_1"               other:dataFormat="splitDataByCol" xs:type="string" readonly="false" required="false" other:ldaptype="Directory String" />
<attr name="Description_2"               other:dataFormat="splitDataByCol" xs:type="string" readonly="false" required="false" other:ldaptype="Directory String" />
<attr name="Description_3"               other:dataFormat="splitDataByCol" xs:type="string" readonly="false" required="false" other:ldaptype="Directory String" />

Die other:dataFormat Attribut hat drei Optionen:

• delimitedData: Gibt mehrere Active Directory Attributwerte als durch Trennzeichen getrennte Zeichenfolgen zurück, getrennt durch delimiter Zeichen, das im Abschnitt „Tabelleneinstellungen“ der .rsd-Datei definiert ist (weiter unten ausführlich beschrieben).

  Dies ist das Standardformat zum Abrufen von Daten. Das Trennzeichen ist standardmäßig ein Semikolon.

• splitDataByRow: Mehrere Active Directory Attributwerte für denselben DN als separate Zeilen übertragen. Alle anderen Spalten werden konsistent übertragen und der Index in der ID wird erhöht. Hinweis: Durch das Übertragen mehrerer Spalten auf diese Weise wird der Ergebnissatz exponentiell vergrößert, was möglicherweise zu Leistungsproblemen führt.

• splitDataByCol: Pushen Sie mehrere Active Directory Attributwerte für denselben DN mit einem an den Spaltennamen angehängten Index. Sie müssen mehrere Spalten definieren und am Ende ein „_n“ anhängen; zum Beispiel ObjectClass_1, ObjectClass_2 und ObjectClass_3. Wenn in diesem Beispiel mehr als 3 Werte vorhanden sind, sind die verbleibenden Werte in der Tabelle nicht sichtbar, es sei denn, es werden weitere Spalten hinzugefügt.

Beispiel: Aufteilen des ObjectClass-Attributs

Der folgende Code kann verwendet werden, um die verschiedenen Werte des ObjectClass Attribute in eigene Zeilen und Description Attribute in eigene Spalten. Beachten Sie, dass die Spaltendefinition nun mehrere Spalten für die Description Attribut. Beachten Sie auch die other:dataFormat Attribut für die attr.

...
<attr name="ObjectClass"     other:dataFormat="delimitedData" xs:type="string"  readonly="false" required="false" other:ldaptype="OID" />
<attr name="SN"              other:dataFormat="delimitedData" xs:type="string"  readonly="false" required="false" other:ldaptype="Directory String" />
<attr name="CN"              other:dataFormat="delimitedData" xs:type="string"  readonly="false" required="false" other:ldaptype="Directory String" />
<attr name="UserPassword"    other:dataFormat="delimitedData" xs:type="string"  readonly="false" required="false" other:ldaptype="Binary" />
<attr name="TelephoneNumber" other:dataFormat="delimitedData" xs:type="string"  readonly="false" required="false" other:ldaptype="Directory String" />
<attr name="SeeAlso"         other:dataFormat="delimitedData" xs:type="string"  readonly="false" required="false" other:ldaptype="DN" />
<attr name="Description_1"   other:dataFormat="delimitedData" xs:type="string"  readonly="false" required="false" other:ldaptype="Directory String" />
<attr name="Description_2"   other:dataFormat="delimitedData" xs:type="string"  readonly="false" required="false" other:ldaptype="Directory String" />
<attr name="Description_3"   other:dataFormat="delimitedData" xs:type="string"  readonly="false" required="false" other:ldaptype="Directory String" />

</rsb:info>

<!-- Table Settings -->
<rsb:set attr="delimiter" value=";"/>
...

Ein Beispielergebnis sieht so aus:

Spaltenkodierung festlegen

Zusätzlich zum Datenformat bei Eingaben kann auch die Kodierung angegeben werden. Derzeit wird die Rückgabe von Daten mit UTF8-Kodierung oder BASE64-Kodierung unterstützt. Um Daten mit einer angegebenen Kodierung abzurufen, other:encoding Feld muss angegeben werden, damit das gewünschte Attribut kodiert werden kann. Wenn keine Kodierung angegeben ist, ist UTF8 die Standardeinstellung.

Ein Beispiel für die Angabe der Kodierung für ein Attribut:

...
<attr name="ObjectClass"     other:dataFormat="delimitedData" other:encoding="UTF8"   xs:type="string"  readonly="false" required="false" other:ldaptype="OID" desc="The object class of the entry."/>
<attr name="SN"              other:dataFormat="delimitedData" other:encoding="BASE64" xs:type="string"  readonly="false" required="false" other:ldaptype="Directory String" desc="The surname of the person."/>
...

Filterverhalten ändern

Optional gibt es zwei Attribute, mit denen gesteuert werden kann, wie die Filterung bei Verwendung des Treiber mit gehandhabt wird SupportEnhancedSQL. Der other:ldaptype Attribut kann verwendet werden, um die LDAP -Syntax eines Felds festzulegen. Dies wird verwendet, um die Vergleichsoperatoren zu bestimmen, die serverseitig auf Feldbasis unterstützt werden. Wenn beispielsweise ein Feld als Typ „DN“ markiert ist und eine Abfrage nach einer Teilzeichenfolge (d. h. CONTAINS) filtert, die serverseitig nicht unterstützt wird, verarbeitet der Treiber diesen Teil des Filters stattdessen vollständig clientseitig. Die unterstützten Typnamen finden Sie in Abschnitt 4.3.2 von RFC 2252. Wenn Sie sich über den Typ nicht sicher sind oder die serverseitige Filterung für eine bestimmte Spalte einfach vollständig deaktivieren möchten, können Sie die other:filterable Attribut ist ebenfalls verfügbar. Wenn Sie dies für das Feld auf false setzen, wird verhindert, dass dies jemals in einem Filter an den Server gesendet wird. Dies überschreibt das other:ldaptype Attribut vollständig.

Tabelleneinstellungen konfigurieren

Zusätzlich zu den Attributen und Eingaben müssen Sie Folgendes angeben: delimiter.

Der delimiter gibt das Zeichen an, das für abgegrenzte Daten verwendet wird. Abgegrenzte Daten werden für jedes Attribut zurückgegeben, das für ein einzelnes Objekt mehrfach vorkommt (sofern nicht anders angegeben in other:dataFormat).

Der folgende Code verknüpft beispielsweise mehrere Werte eines Attributs mit dem Zeichen ';'.

...
</rsb:info>

<!-- Table Settings -->
<rsb:set attr="delimiter" value=";"/>
...

Definieren unterstützter Vorgänge

Die Operationsdefinitionen bleiben für alle neu erstellten Tabellen genau gleich: Kopieren Sie diese bei Bedarf einfach aus einer vorhandenen Tabelle und fügen Sie sie ein.

<!-- Operation definitions -->
<rsb:script method="GET">
<rsb:set attr="action" value="Get" />
<rsb:call op="ldapadoLDAP" >
<rsb:push />
</rsb:call>
</rsb:script>

<rsb:script method="POST">
<rsb:set attr="action" value="Post" />
<rsb:call op="ldapadoLDAP" >
<rsb:push item="toout"/>
</rsb:call>
</rsb:script>

<rsb:script method="MERGE">
<rsb:set attr="action" value="Merge" />
<rsb:call op="ldapadoLDAP" >
<rsb:push />
</rsb:call>
</rsb:script>

<rsb:script method="DELETE">
<rsb:set attr="action" value="Delete" />
<rsb:call op="ldapadoLDAP" >
<rsb:push />
</rsb:call>
</rsb:script>

Wichtige Hinweise

Gespeicherte Prozeduren

• Die in dieser Dokumentation beschriebenen Funktionen für gespeicherte Prozeduren werden derzeit nicht unterstützt.
• Da gespeicherte Prozeduren derzeit nicht unterstützt werden, werden auch alle von gespeicherten Prozeduren abhängigen Funktionen derzeit nicht unterstützt.

Konfigurationsdateien und ihre Pfade

• Alle Verweise auf das Hinzufügen von Konfigurationsdateien und deren Pfaden beziehen sich auf Dateien und Speicherorte auf dem Jitterbit-Agenten, auf dem der Connector installiert ist. Diese Pfade sind je nach Agent und Operationssystem entsprechend anzupassen. Wenn mehrere Agenten in einer Agentengruppe verwendet werden, werden auf jedem Agenten identische Dateien benötigt.

Erweiterte Funktionen

In diesem Abschnitt wird eine Auswahl erweiterter Funktionen des Active Directory Connectors beschrieben.

Benutzerdefinierte Ansichten

Der Connector ermöglicht Ihnen die Definition virtueller Tabellen, sogenannter benutzerdefinierter Ansichten, deren Inhalt durch eine vorkonfigurierte Abfrage bestimmt wird. Diese Ansichten sind nützlich, wenn Sie die an die Treiber gesendeten Abfragen nicht direkt steuern können. Siehe Benutzerdefinierte Ansichten für einen Überblick über das Erstellen und Konfigurieren benutzerdefinierter Ansichten.

SSL-Konfiguration

Verwenden Sie SSL-Konfiguration, um anzupassen, wie der Connector TLS/SSL-Zertifikatsverhandlungen handhabt. Sie können aus verschiedenen Zertifikatsformaten wählen; siehe SSLServerCert-Eigenschaft unter „Verbindungszeichenfolgenoptionen“ für weitere Informationen.

Benutzerdefinierte Ansichten

Mit dem Active Directory Connector können Sie eine virtuelle Tabelle definieren, deren Inhalt durch eine vorkonfigurierte Abfrage bestimmt wird. Diese werden als benutzerdefinierte Ansichten bezeichnet und sind in Situationen nützlich, in denen Sie die an den Treiber gesendete Abfrage nicht direkt steuern können, z. B. wenn Sie den Treiber von Jitterbit verwenden. Die benutzerdefinierten Ansichten können verwendet werden, um Prädikate zu definieren, die immer angewendet werden. Wenn Sie in der Abfrage an die Ansicht zusätzliche Prädikate angeben, werden diese mit der bereits als Teil der Ansicht definierten Abfrage kombiniert.

Es gibt zwei Möglichkeiten, benutzerdefinierte Ansichten zu erstellen:

• Erstellen Sie eine Konfigurationsdatei im JSON-Format, die die gewünschten Ansichten definiert.
• DDL-Anweisungen.

Definieren von Ansichten mithilfe einer Konfigurationsdatei

Benutzerdefinierte Ansichten werden in einer JSON-formatierten Konfigurationsdatei namens UserDefinedViews.json. Der Connector erkennt die in dieser Datei angegebenen Ansichten automatisch.

Sie können auch mehrere Ansichtsdefinitionen haben und diese mit steuern UserDefinedViews Verbindungseigenschaft. Wenn Sie diese Eigenschaft verwenden, werden vom Connector nur die angegebenen Ansichten angezeigt.

Diese Konfigurationsdatei für benutzerdefinierte Ansichten ist wie folgt formatiert:

• Jedes Stammelement definiert den Namen einer Ansicht.
• Jedes Stammelement enthält ein untergeordnetes Element namens query, das die benutzerdefinierte SQL- Abfrage für die Ansicht enthält.

Zum Beispiel:

{
    "MyView": {
        "query": "SELECT * FROM User WHERE MyColumn = 'value'"
    },
    "MyView2": {
        "query": "SELECT * FROM MyTable WHERE Id IN (1,2,3)"
    }
}

Verwenden Sie UserDefinedViews Verbindungseigenschaft zur Angabe des Speicherorts Ihrer JSON-Konfigurationsdatei. Beispiel:

"UserDefinedViews", "C:\Users\yourusername\Desktop\tmp\UserDefinedViews.json"

Schema für benutzerdefinierte Ansichten

Benutzerdefinierte Ansichten werden im angezeigt UserViews Schema standardmäßig. Dies geschieht, um zu vermeiden, dass der Name der Ansicht mit einer tatsächlichen Entität im Datenmodell kollidiert. Sie können den Namen des für UserViews verwendeten Schema ändern, indem Sie UserViewsSchemaName Eigentum.

Arbeiten mit benutzerdefinierten Ansichten

Beispielsweise eine SQL-Anweisung mit einer benutzerdefinierten Ansicht namens UserViews.RCustomers listet nur Kunden in Raleigh auf:

SELECT * FROM Customers WHERE City = 'Raleigh';

Ein Beispiel für eine Abfrage an den Treiber:

SELECT * FROM UserViews.RCustomers WHERE Status = 'Active';

Daraus ergibt sich die effektive Abfrage an die Quelle:

SELECT * FROM Customers WHERE City = 'Raleigh' AND Status = 'Active';

Dies ist ein sehr einfaches Beispiel für eine Abfrage an eine benutzerdefinierte Ansicht, die tatsächlich eine Kombination aus der Abfrage und der Ansichtsdefinition ist. Es ist möglich, diese Abfragen in viel komplexeren Mustern zusammenzustellen. Alle SQL-Operationen sind in beiden Abfragen zulässig und werden bei Bedarf kombiniert.

SSL-Konfiguration

Anpassen der SSL-Konfiguration

Standardmäßig versucht der Connector, SSL/TLS auszuhandeln, indem er das Zertifikat des Servers mit dem vertrauenswürdigen Zertifikatspeicher des Systems vergleicht.

Um ein anderes Zertifikat anzugeben, siehe SSLServerCert Eigenschaft für die verfügbaren Formate, um dies zu tun.

Datenmodell

Der Active Directory Konnektor modelliert Active Directory Entitäten in relationalen Tabellen und gespeicherten Prozeduren.

Tabellen

Die enthaltenen Tabellen decken viele standardmäßige Active Directory Objektklassen ab. Sie können die Schemata problemlos erweitern, um eine genauere Zuordnung zu Ihren Active Directory Klassen zu ermöglichen. Die Schemata werden in einfachen Konfigurationsdateien definiert.

Um benutzerdefinierte Tabellen und Schemata zu verwenden, setzen Sie die Location-Eigenschaft für den Ordner mit den Schema. Die mit dem Connector gelieferten Schemas befinden sich im Unterordner db des Installationsverzeichnisses.

Siehe Arbeiten mit Active Directory Tabellen für eine Anleitung zum Anpassen von Tabellenschemata.

Gespeicherte Prozeduren

Gespeicherte Prozeduren sind funktionsähnliche Schnittstellen zur Datenquelle. Sie können verwendet werden, um auf Active Directory Funktionen zuzugreifen, die nicht als SELECT, INSERT, UPDATE oder DELETE dargestellt werden.

Kollaborative Abfrageverarbeitung

API Einschränkungen und-Anforderungen werden in diesem Abschnitt dokumentiert. Der Connector verlagert die Verarbeitung der SELECT-Anweisung so weit wie möglich auf Active Directory und verarbeitet den Rest der Abfrage dann im Speicher.

Sehen SupportEnhancedSQL für weitere Informationen dazu, wie der Connector API Einschränkungen durch die clientseitige In-Memory-Verarbeitung umgeht.

Tabellen

Der Connector modelliert die Daten im Active Directory in einer Liste von Tabellen, die mit Standard-SQL-Anweisungen abgefragt werden können.

Im Allgemeinen ist das Abfragen von Active Directory Tabellen dasselbe wie das Abfragen einer Tabelle in einer relationalen Datenbank. Manchmal gibt es Sonderfälle, beispielsweise kann das Einfügen einer bestimmten Spalte in die WHERE-Klausel erforderlich sein, um Daten für bestimmte Spalten in der Tabelle abzurufen. Dies ist normalerweise in Situationen erforderlich, in denen für jede Zeile eine separate Abfrage erfolgen muss, um bestimmte Spalten abzurufen. Diese Arten von Situationen sind oben auf der unten verlinkten Tabellenseite klar dokumentiert.

Active Directory Connector-Tabellen

Konto

Die Objektklasse „Konto“ wird verwendet, um Einträge zu definieren, die Computerkonten darstellen.

Spalten

Pseudo-Spalten

Pseudospaltenfelder werden in der WHERE-Klausel von SELECT-Anweisungen verwendet und bieten eine genauere Kontrolle über die Tupel, die von der Datenquelle zurückgegeben werden.

Anwendungsentität

X.500-Basisklasse für Anwendungen: Der Verzeichnisdienst verwendet nur die Unterklasse MSFT-DSA.

Spalten

Pseudo-Spalten

Pseudospaltenfelder werden in der WHERE-Klausel von SELECT-Anweisungen verwendet und bieten eine genauere Kontrolle über die Tupel, die von der Datenquelle zurückgegeben werden.

Bewerbungsprozess

X.500-Basisklasse für Anwendungen: Exchange verwendet nur die Unterklasse DSA-Application.

Spalten

Pseudo-Spalten

Pseudospaltenfelder werden in der WHERE-Klausel von SELECT-Anweisungen verwendet und bieten eine genauere Kontrolle über die Tupel, die von der Datenquelle zurückgegeben werden.

Anwendungseinstellungen

Basisklasse für serverspezifische Anwendungseinstellungen.

Spalten

Pseudo-Spalten

Pseudospaltenfelder werden in der WHERE-Klausel von SELECT-Anweisungen verwendet und bieten eine genauere Kontrolle über die Tupel, die von der Datenquelle zurückgegeben werden.

Anwendungssiteeinstellungen

Enthält alle standortspezifischen Einstellungen.

Spalten

Pseudo-Spalten

Pseudospaltenfelder werden in der WHERE-Klausel von SELECT-Anweisungen verwendet und bieten eine genauere Kontrolle über die Tupel, die von der Datenquelle zurückgegeben werden.

Anwendungsversion

Kann von Anwendungsentwicklern verwendet werden, um Versionsinformationen über ihre Anwendung oder ihr Schema zu speichern.

Spalten

Pseudo-Spalten

Pseudospaltenfelder werden in der WHERE-Klausel von SELECT-Anweisungen verwendet und bieten eine genauere Kontrolle über die Tupel, die von der Datenquelle zurückgegeben werden.

Integrierte Domäne

Der Container, der die Standardgruppen für eine Domäne enthält.

Spalten

Pseudo-Spalten

Pseudospaltenfelder werden in der WHERE-Klausel von SELECT-Anweisungen verwendet und bieten eine genauere Kontrolle über die Tupel, die von der Datenquelle zurückgegeben werden.

Zertifizierungsstelle

Stellt einen Prozess dar, der öffentliche Schlüsselzertifikate ausstellt, beispielsweise einen Zertifikatsserver.

Spalten

Pseudo-Spalten

Pseudospaltenfelder werden in der WHERE-Klausel von SELECT-Anweisungen verwendet und bieten eine genauere Kontrolle über die Tupel, die von der Datenquelle zurückgegeben werden.

Computer

Diese Klasse stellt ein Computerkonto in der Domäne dar.

Spalten