Logo faq-o-matic.net
Logo faq-o-matic.net

Auslesen der Domänen-Daten über ADSI

von veröffentlicht am17. April 2003, 14:43 Uhr Kurzlink und Zitatlink einblenden
Kategorie Kategorie: Active Directory, Scripting, SQL Server   Translate with Google Translate Translate EN   Die angezeigte Seite drucken

Active Directory bringt einen OLE-DB-Provider zum Zugriff mit, über den die Domänendaten als Datenbank angesprochen werden können. So ist es möglich, die Daten der Domäne bequem über eine SQL-Abfrage auszulesen. Leider ist über diese Schnittstelle kein Verändern oder Anlegen von AD-Objekten möglich.

Die folgenden Beispiele funktionieren mit SQL Server 2005, SQL Server 2000 und SQL Server 7.0. Sie skizzieren, wie einfach der SQL-Zugriff auf Active Directory ist. Die Einsatzzwecke sind vielfältig – vor allem ist es durch diese Technik nicht (mehr) notwendig, die Domänen-Objekte parallel im AD und in einer SQL-Datenbank zu halten, denn sie können über einfache Abfragen (oder Views etc.) direkt genutzt werden.

Achtung: Bei Abfrage direkt über T-SQL können von einem OLE-DB-Provider keine Multivalue-Felder entgegengenommen werden. Dies betrifft die "offensichtlichen" Multivalue-Felder wie "memberOf", "member" oder "objectClass", aber auch andere: Obwohl "description" als Single-Value-Feld angezeigt wird, scheint es intern als Multivalue gehandhabt zu werden. Das führt zu dem Fehler.

Das Problem ist anscheinend nur lösbar, indem man keine SQL-Abfrage macht, sondern mit ADO direkt gegen AD arbeitet.

Siehe auch diesen Thread:

http://groups.google.de/group/microsoft.public.adsi.general/browse_thread/thread/4e77834a1936dd77/f35a6345f9c7354e?hl=de


Einrichten eines Verbindungsservers

Der Zugriff wird vereinfacht, wenn ein Verbindungsserver ("Linked Server") zu Active Directory eingerichtet wird. Die folgende Prozedur erledigt dies:

EXEC sp_addlinkedserver 'ADSI', '', 'ADSDSOObject'

Hierbei ist "ADSDSOObject" der interne Name für den OLE-DB-Provider, "ADSI" ist der Name, unter dem der Verbindungsserver nun angesprochen werden kann.

Achtung: Manche Anwender berichten, dass diese Methode nicht zum Erfolg führt. In meinen Versuchen funktioniert es hingegen, wenn man den Linked Server manuell anlegt.

Für SQL Server 2000:
  1. Im Enterprise Manager öffnen: Sicherheit – Verbindungsserver.
  2. Rechter Mausklick, "Neuer Verbindungsserver"
  3. Unter Name z.B. "ADSI" eintragen (dann funktionieren die Beispiele von dieser Seite). Unter "Servertyp" den Providernamen "OLE DB Provider für Microsoft Directory Services" auswählen.
  4. Mit OK bestätigen.
In SQL Server 2005 geht es so:
  1. Im SQL Server Management Studio öffnen: Serverobjekte/Verbindungsserver.
  2. Rechter Mausklick, "Neuer Verbindungsserver"
  3. Unter "Verbindungsserver" den gewünschten Namen angeben, z.B. "ADSI"
  4. Unter "Servertyp" die Auswahl "Andere Datenquelle" und dort "OLE DB Provider für Microsoft Directory Services"
  5. Unter "Produktname" eintragen: "ADSDSOObject"
  6. Bestätigen.

Auslesen von Benutzerdaten

Das folgende Beispiel ist leicht variiert aus der Online-Hilfe übernommen. Es fragt einige Benutzerdaten aus dem AD ab. Um den zukünftigen Zugriff zu vereinfachen, legt es dabei einfach eine View an, die die etwas komplexere Abfrage durchführt. Diese View kann später einfach wie eine Tabelle angesprochen werden.

CREATE VIEW vwADusers
AS
SELECT [Name], SN [Last Name], ST State
FROM OPENQUERY( ADSI,
   'SELECT Name, SN, ST
   FROM ''LDAP://server13/ cn=users,DC=sqlsem,DC=local''
   WHERE objectCategory = ''Person'' AND
      objectClass = ''user''')
GO
SELECT * FROM vwADusers

Der entscheidende Kniff liegt hier in der Nutzung von "OPENQUERY": Das AD wird als separate Datenbank angesehen, und der Domänencontroller ist der Datenbank-Server (hier "server13" in der Domäne "sqlsem.local"). "OPENQUERY" lässt nun den entfernten Server die Abfrage ausführen und fordert die Daten von ihm an. Auf diese Weise muss ADSI von SQL aus immer angesprochen werden. Man beachte dabei, dass die ganze "innere" Abfrage in einfachen Anführungsstrichen (') steht und dass die Ansprache des LDAP-Servers (das ist der Domänencontroller) daher in doppelten einfachen Anführungsstrichen steht ('', nicht zu verwechseln mit den normalen Anführungsstrichen ").


Auslesen bestimmter Daten

Kennt man die LDAP-Feldnamen, in denen Active Directory seine Daten ablegt, kann man fast alles aus dem AD auslesen. Zur Referenz sei die Dokumentation im ADSI-Toolkit empfohlen, das sich bei Microsoft kostenlos herunterladen lässt.

Hier ein Beispiel, das drei Namensfelder sowie (falls vorhanden) den Pfad zum Benutzerprofil aller Benutzer ausgibt.

SELECT    [Name] as [Name]
        , userPrincipalName as UPN
        , distinguishedname as Verzeichnisname
        , profilePath as Profil
FROM OPENQUERY( ADSI,
   'SELECT distinguishedName, name, userPrincipalName, profilePath
   FROM ''LDAP://server13/ DC=sqlsem,DC=local''
   WHERE
        objectClass = ''user''
   AND
        objectCategory = ''person''
   ')

Daten über Computer

Auch Daten über die Computer der Domäne stehen im AD. Hier eine Abfrage, die einige dieser Daten zurückgibt.

SELECT    dnshostname as [DNS-Name]
        , [name] as [NetBIOS-Name]
        , operatingsystem as OS
        , operatingsystemversion as Version
        , distinguishedname as Verzeichnisname
FROM OPENQUERY( ADSI,
   'SELECT distinguishedname, Name, dnshostname, operatingsystem, operatingsystemversion
   FROM ''LDAP://server13/ DC=sqlsem,DC=local''
   WHERE
        objectClass = ''computer''
   ')

© 2005-2019 bei faq-o-matic.net. Alle Rechte an den Texten liegen bei deren Autorinnen und Autoren.

Jede Wiederveröffentlichung der Texte oder von Auszügen daraus - egal ob kommerziell oder nicht - bedarf der ausdrücklichen Genehmigung durch die jeweiligen Urheberinnen oder Urheber.

Das Impressum findet sich unter: http://www.faq-o-matic.net/impressum/

Danke, dass du faq-o-matic.net nutzt. Du hast ein einfaches Blog sehr glücklich gemacht!