Active Directory v2-Verbindungsdetails

Einführung

Connector-Version

Diese Dokumentation basiert auf Version 23.0.9004 des Connectors.

Erste Schritte

Versionsunterstützung für Microsoft Active Directory

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

Herstellen einer Verbindung

Herstellen einer Verbindung mit Microsoft 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.

Authentifizieren bei Microsoft Active Directory

Um Anfragen zu authentifizieren, setzen Sie User Und Password Eigenschaften auf gültige Microsoft Active Directory Anmeldeinformationen (z. B. setzen Sie 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.

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 ein Wert von cn=users,dc=domain gibt nur Ergebnisse zurück, die innerhalb von cn=users und seine Kinder.
• 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 Microsoft 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 Standardobjekte des Microsoft Active Directory. 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 Jitterbit Connectors für Microsoft Active Directory.

Mit benutzerdefinierten Tabellen verbinden

Um benutzerdefinierte Schemas zu verwenden, müssen Sie die entsprechenden RSD-Dateien (Record Service Definition) abrufen, sie auf privaten Agenten installieren und dann ihren Speicherort in der Konfiguration einer Active Directory v2-Verbindung referenzieren. Die folgenden Schritte beschreiben, wie Sie dies tun:

1. Laden Sie eine ZIP-Datei der RSD-Dateien für das benutzerdefinierte Active Directory v2 Schema herunter.

2. Extrahieren Sie die RSD-Dateien aus der ZIP-Datei.

3. Kopieren Sie die heruntergeladenen Dateien standardmäßig in das Installationsverzeichnis des Agenten C:\Program Files\Jitterbit Agent\ unter Microsoft Windows, /opt/jitterbit/ auf Docker und Linux.

4. Bei der Konfiguration einer Active Directory v2 Verbindung, legen Sie in Erweiterten Konfigurationen die Eigenschaft Speicherort auf den Ordnerpfad fest, 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 Microsoft 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 Microsoft 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 Microsoft Active Directory Attributwerte für denselben DN mit einem angehängten Index für den Spaltennamen. 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

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 Jitterbit Connector für Microsoft Active Directory 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 die UserDefinedViews Verbindungseigenschaft zur Angabe des Speicherorts Ihrer JSON-Konfigurationsdatei. Beispiel:

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

Definieren von Ansichten mit DDL-Anweisungen

Der Connector kann das Schema auch über DDL-Anweisungen wie CREATE LOCAL VIEW, ALTER LOCAL VIEW und DROP LOCAL VIEW erstellen und ändern.

Erstellen einer Ansicht

Um eine neue Ansicht mit DDL-Anweisungen zu erstellen, geben Sie den Ansichtsnamen und die Abfrage wie folgt an:

CREATE LOCAL VIEW`[MeinAnsichtsname] `AS SELECT * FROM Customers LIMIT 20;

Wenn keine JSON-Datei vorhanden ist, erstellt der obige Code eine. Die Ansicht wird dann in der JSON-Konfigurationsdatei erstellt und ist nun erkennbar. Der Speicherort der JSON-Datei wird durch angegeben UserDefinedViews Verbindungseigenschaft.

Ändern einer Ansicht

Um eine vorhandene Ansicht zu ändern, geben Sie den Namen der vorhandenen Ansicht zusammen mit der neuen Abfrage an, die Sie stattdessen verwenden möchten:

ALTER LOCAL VIEW`[MeinAnsichtsname] `AS SELECT * FROM Customers WHERE TimeModified > '3/1/2020';

Die Ansicht wird dann in der JSON-Konfigurationsdatei aktualisiert.

Löschen einer Ansicht

Um eine vorhandene Ansicht zu löschen, geben Sie den Namen eines vorhandenen Schema neben der neuen Abfrage an, die Sie stattdessen verwenden möchten.

DROP LOCAL VIEW [MyViewName]

Dadurch wird die Ansicht aus der JSON-Konfigurationsdatei entfernt. Sie kann nicht mehr abgefragt werden.

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 festlegen 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 Jitterbit Connector für Microsoft Active Directory modelliert Microsoft 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 Microsoft Active Directory Funktionen zuzugreifen, die nicht als SELECT, INSERT, UPDATE oder DELETE dargestellt werden.

Tabellen

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

Jitterbit-Connector für Microsoft Active Directory 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