Active Directory und Trusted Domain

[TigerLilly]

Ich könnte Hilfe gebrauchen. Danke!

Ich habe zwei Domänen DOM-A und DOM-B, die via Trusted Donain verbunden sind.
Ich kann aus der Domäne DOM-A für den User X aus dem AD die Gruppen auslesen:
select memberof from 'LDAP://DOM-A' where objectClass='person' and sAMAccountName='X'

Damit ich aus der DOM-B die gruppen des Users auslesen kann, muss ich aus DOM-A den SID ermitteln und damit in DOM-B suchen:
select objectSID from 'LDAP://DOM-A' where objectClass='person' and sAMAccountName='X'

Liefert siwas: S-1-5-21-144191708-1486429690-1194094237-999999
Mit dem SID suche ich nun in DOM-B:
select memberof from 'LDAP://DOM-B' where objectClass='foreignSecurityPrincipal' and Name='S-1-5-21-144191708-1486429690-1194094237-999999'

Das Problem ist nun, dass das zwar eine Zeile zurückliefert, aber ich auf die Felder der Query nicht zugreifen kann. Etwas, das im Schritt ganz oben ohne Probleme funktioniert. Siehe Code unten.

Code:

   if (sSID <> '') then begin
      sSQL := 'select memberof from ''LDAP://' + sDomain +
        ''' where objectClass=''foreignSecurityPrincipal'' and Name=' + QuotedStr(sSID);
    end else begin
      sSql := 'select memberof from ''LDAP://' + sDomain + ''' where objectClass=''person'' and sAMAccountName=' +
        QuotedStr(sUSername);
    end;
    qQuery.SQL.Text := sSql;
    qQuery.Open;
    s := '';
    while not qQuery.EOF do begin
      i := qQuery.FieldCount; <---- es gibt 1 Feld
      for i := 0 to qQuery.FieldCount - 1 do begin
        try
          v    := qQuery.Fields[i].Value; < --- v ist Variant
          nDim := VarArrayDimCount(v);  <-- das hat Wert 0 bei Abfrage über SID
          nUpper := VarArrayHighBound(v, 1); < --- hier gibt es einen fehler, weil das Dimension 0 hat + wohl ein anderer Datentyp?
          nLower := VarArrayLowBound(v, 1);
          for n := nLower to nUpper do begin
            try
              s := s + ', ' + v[n];
            except
              on e: Exception do begin
                o_Log.Log(e.message, llDebug);
              end;
            end;
          end;
        except
          on e: Exception do begin
            o_Log.Log(e.message, llDebug);
          end;
        end;
      end;

Ich vermute, dass der Variant v da einen anderen Datentyp hat, aber welchen? Oder übersehe ich da was ganz anderes?

[Kas Ob.]

I am sorry for being understanding the question if full.

But i don't think LDAP and SQL works like that, please refer and research this filtering mechanism https://learn.microsoft.com/en-us/wi...-filter-syntax
Might be better to use something like the following for specific SID

Code:

1.2.840.113556.1.4.1941:=(

As for the empty but not so empty result, it might be the Null SID https://learn.microsoft.com/en-us/wi...ell-known-sids

I might be wrong though, and sorry for that.

[Delphi.Narium]

Mit VarIsType müsste sich ermitteln lassen, von welchem Typ v ist.
Mit VarIsArray ließe sich prüfen, ob v überhaupt ein Array ist.
VarIsEmpty prüft, ob überhaupt was in v drinne ist.

Vermutlich wirst Du Dich da durch die Routinen aus der Doku System.Variants.VarIsEmpty durchquälen müssen, um an den passenden Datentyp zu kommen.

LDAP ist bei mir lange her, aber es war nie wirklich witzig, sich damit zu befassen

Eventuell kannst Du mit sowas in der Art weiterkommen:

ShowMessage(VarTypeAsText(VarType(v)));

Statt ShowMessage ggfls. einfach im Debugger "nachfragen"

[TigerLilly]

Zitat von Kas Ob.:

But i don't think LDAP and SQL works like that, please refer and research this filtering mechanism https://learn.microsoft.com/en-us/wi...-filter-syntax

LDAP and SQL works quite ok. Additionally I speak SQL but no ADSI :- )

[TigerLilly]

Zitat von Delphi.Narium:

Mit VarIsType müsste sich ermitteln lassen, von welchem Typ v ist.
Mit VarIsArray ließe sich prüfen, ob v überhaupt ein Array ist.
VarIsEmpty prüft, ob überhaupt was in v drinne ist.

Statt ShowMessage ggfls. einfach im Debugger "nachfragen"

Danke dafür. Ja, da hantle ich mich mal durch.
Ich hab hier zum Testen natürlich nicht so eine AD-Struktur. Das ist beim Kunden. Natürlich. :- /

[Delphi.Narium]

Beim Kunden ist immer alles anders, egal welche Fehler, Besonderheiten, ... Du "abklapperst". Es gibt (leider) immer einen Kunden, bei dem es dann doch noch 'ne weitere Alternative gibt Murphys Gesetz halt

Ergänze doch Deine Fehlerbehandlung jeweils um

Delphi-Quellcode:

   o_Log.Log(e.message, llDebug);
   o_Log.Log(VarTypeAsText(VarType(v)), llDebug);

Dann bekommst Du bei den Sonderlocken der Kundensysteme direkt etwas weitergehende Infos.

Könnte eventuell Data.DB.VarTypeToDataType eine brauchbare Alternative sein?

[TigerLilly]

Zitat:

sSQL := 'select memberof from ''LDAP://' + sDomain +
''' where objectClass=''foreignSecurityPrincipal'' and Name=' + QuotedStr(sSID);

Das detaillierte Ausgeben von Typ etc hat zumindest aufgezeigt, dass "memberof" da gar nicht als Attribut vorkommt. Aber LDAP liefert da keine fehler, sondern Null. Gut, zumindest das ist jetzt klar.
Jetzt muss ich nur mehr die Gruppen in der Trusted Domain finden.

[Kas Ob.]

Zitat von TigerLilly:

Zitat:

sSQL := 'select memberof from ''LDAP://' + sDomain +
''' where objectClass=''foreignSecurityPrincipal'' and Name=' + QuotedStr(sSID);

Das detaillierte Ausgeben von Typ etc hat zumindest aufgezeigt, dass "memberof" da gar nicht als Attribut vorkommt. Aber LDAP liefert da keine fehler, sondern Null. Gut, zumindest das ist jetzt klar.
Jetzt muss ich nur mehr die Gruppen in der Trusted Domain finden.

Of course "MemeberOf" is not an attribute, it is full blown Object Class with attributes, just like the User and its SID.
I think you need to refine the query and go after "Ldap-Display-Name" from https://learn.microsoft.com/en-us/wi...ectedfrom=MSDN

I am sorry if i still missing something, though i don't want to waste your time, but it doesn't make sense to me to make the SQL query answer and parse the security objects, it logical to parse the SQL outside the AD controller, and make it use the standard query with filters to talk with the controller, also the controller should NOT be parsing any SQL, while the LDAP SQL parser should NOT be able to parse the details of the Objects, thus minimizing the attack surface, here why the filters should work and in my opinion it is the only way, again this is my take in designing such critical system, in other words the SQL here is merely an interpreter for AD query.

[TigerLilly]

MemberOf as well as Member is an enumeration and contains a list of all Users rsp Groups. SQL works quite ok, so this is not the problem. In contrary to the docs, LIKE is not suported, but " = '*vvv'" instead of "LIKE '%vvv'". Additionally wrong spelled or non exiting attributes do not generate an error, but return Null. So you my receive one row, but with no data.

Finally I came up with a solution, that
- searches for the groups for a user
- identifies the SID of the user
- creates a list of the groups of the trusted domain
- checks if the SID is in the list of members of the group

If anybody is interested in the SQL statements or the code, that makes the SID readable and comparable, I´d be happy to post this here.

[Kas Ob.]

Zitat von TigerLilly:

If anybody is interested in the SQL statements or the code, that makes the SID readable and comparable, I´d be happy to post this here.

Yes please share it, and thank you in advance !