Mit ADO auf Active Directory zugreifen

[Heinz Schneider]

Hallo allerseits
ich übe wieder mal mit etwas Neuem für mich rum. Ich möchte aus dem Active Directory erst mal vor allem die Computer auslesen und Daten wie Standort Computername, Beschreibung, Letzte an- und Abmeldung anzeigen.
Hierfür habe ich einfach mal ein Testprojekt ohne eine einzige Zeile Code erstellt. Ich habe eine TADOConnection-Komponente, eine TADODataSet-Komponente, eine TDataSource-Komponente und eine TDBGrid-Komponente aufs Formular gezogen. Der Connect funktioniert, die DataSource hat das ADODataSet als DataSet und das ADODatSet die ADOConnection als Connection. Und eigentlich funktioniert auch (fast) alles. Wenn ich das ADODataSet mit folgendem CommandText auf Active := True setze, wird mir der Inhalt des AD bereits im Grid angezeigt:

Code:

SELECT sAMAccountName, location  FROM 'LDAP://dc=SchneiderInformatikGmbH,dc=local' WHERE objectClass = 'user' and objectCategory = 'computer'

Wenn ich aber beim SELECT einen Begriff wie lastLogon oder description anfüge, bekomme ich beim Aktivieren eine Fehlermeldung vom Typ 'Variante des Typs (Dispatch) konnte nicht in Typ (String) konvertiert werden.
Und nun stehe ich wie der Esel am Berg. Wie kann ich diesen Fehler eliminieren wenn der bereits auf Design-Ebene, also ohne das Programm zu starten, auftritt?

[Loïs Bégué]

Lastlogon ... description:
Meinst Du, in Deiner Tabellen gibt es Spalten mit diesen Namen?
Wenn ja:
1) probiere mal die Spaltennamen im SQL Query in (doppelten) Hochkomma zu setzen
Select "Description" from ...
oder
2) qualifiziere die Namen mit der Tabellenbezeichnung:
Select MeineTabelle.Description from MeineTabelle
bzw.
Select A.Description from MeineTabelle A
oder
3) statt den Namen zu benutzen, probiere es mit der Spaltennummer.
Select [3] from MeineTabelle (wenn Description die 3. Spalte ist.

Anmerkung I:
je nach Datenbank unterscheidet sich u.U. die Konvention für das Ansprechen der Spalten.
Im Bsp oben: in 1) die doppelten Hochkomma und in 3)  die "[...]" sind nicht universell.
Aber Entsprechendes findet sich in der Regel immer.

Anmerkung II:
jede Datenbank hat eine Reihe von reservierte Schlüsselworte bzw. Bezeichner bzw. Funktionsnamen die man bei der Gestaltung seiner DB vermeiden sollte...

[Heinz Schneider]

Hallo Loïs

danke für Deine Antwort. Zur ersten Frage: In der Tabelle gibt es die Spalten. Es ist ja das MS-Active Directory (MS-Server 2003). Ich habe nun Deine Lösungsvorschläge durchgespielt.
Zu 1: Mit doppeltem oder einfachen Hochkomma bekomme ich denselben Fehler wie ohne. Mit Anführungszeichen gibts eine SQL-Fehlermeldung.
Zu 2: Obwohl die Qualifizierung ziemlich mühsam ist (Du hast ja mein CommandText gesehen, habe ich auch das versucht. Der Fehler bleibt derselbe.
Zu 3: Kann ich leider nicht versuchen. Ich habe bisher noch nirgends eine Beschreibung des Active Directorys gefunden, aus der die Spaltennnummern der Felder ersichtlich wären.

Die Fehlermeldung, die ich bekomme, tönt mir irgendwie nach einer Art von TypeCast-Error.  An sich sind in der AD-Tabelle bei der Objekt-Kategorie 'Computer' gar nicht so viele Spalten vorhanden: 
sAMAccountName
description
memberOf
location
managedBy
operatingSystem
operatingSystemVersion
lastLogon
lastLogoff
Seltsamerweise funktioniert mein CommandText für sAMAccountName und location perfekt, der Fehler kommt bei description, lastLogon oder lastLofoff.

Wenn Du (oder sonst jemand) noch eine andere Idee hat ....

[grenzgaenger]

hallo heinz,

mit ADO bin ich zwar nicht fit, aber was du als letztes gepostet hast, scheint mir ein allgemeines SQL problem zu sein. daher möchte ich dir eines von den beiden punkten raten

• P2: nimm strings mit quotedstr(xxx) in deinen sql abfrage string mit rein
• P1: versuche die variablen bestandteile mit parameter den SQL string zu übergeben, damit sollte auch UNI-Code funktionieren

<HTH> GG

PS:
P1: Priorität 1
P2: Priorität 2

[Loïs Bégué]

Was Du probieren auch solltest: Umbenennen der Tabellenspalten.
Um sicher zu gehen, dass keine Konflikte mehr bestehen können...

Ansonsten:
Kann es sein, dass Dein ADS nicht "alles" preisgibt?
"Active Directory" ist nicht gleich "Active Directory" ;)

[Heinz Schneider]

Bitte entschuldigt, dass ich diesen alten Thread ausgrabe, habe aber wirklich mit Unterbrüchen bis jetzt nach einer Lösung dieses Problems gesucht und möchte deshalb Lösung posten. Vielleicht hilft's ja jemandem, nicht ebenfalls so lange suchen zu müssen.

Das Problem ist zweiteilig. LDAP/ADO liefert zum Teil Felder als Variant Arrays zurück (z.B. Description bei Computers). Solche Felder können mit folgener Funktion in Strings umgewandelt werden:

Code:

{Variant-Rückgabe in String umsetzen}
function TFADAbgl.VariToStr(Vari : Variant) : string;
var j : integer;
var s : string;
var t : Variant;
begin
 if (VarIsArray(Vari)) and not (VarIsNull(Vari)) then
    begin
    s := '';
    t := Vari;
    for j := VarArrayLowBound(t, 1) to VarArrayHighBound(t, 1) do
        begin
        if (s <> '') then
           s := s + ', ';
        s := s + t[j];
        end;
    end
 else
    if (not (VarIsNull(Vari))) then
       s := VarToStr(Vari);
 Result := s;
end;

Der 2 Knackpunkt sind gewisse Datumfelder wie LastLogon oder LastLogoff bei Computer welche als sogenannte Dispatch-Felder geliefert werden.
Damit diese Felder umgesetzt werden können ist folgendes nötigt:
- ActiveDS_TLB bei uses einfügen
- folgende Felder definieren
  var ft     : TFileTime;
  var lt     : TFileTime;
  var st     : TSystemTime;
  var dt     : TDateTime;
  var lis    : IADsLargeInteger;
  var myVar  : Variant;

Code:

              myVar := ADODataSet2.FieldbyName('lastLogon').AsVariant;
              lis := IDispatch(myVar) as IADsLargeInteger;
              ft.dwLowDateTime  := Lis.LowPart;
              ft.dwHighDateTime := lis.HighPart;
              FileTimeToLocalFileTime(ft, lt);
               FileTimeToSystemTime(lt, st);
              dt := SystemTimeToDateTime(st);

Dieser Code setzt so ein Datumdeld um