ldap_sasl_bind_s (GSSAPI) - Was soll in den Anmeldeinformationen Berval Struktur zur Verfügung gestellt werden

StackOverflow https://stackoverflow.com/questions/3144910

  •  01-10-2019
  •  | 
  •  
War es hilfreich?

Lösung

ich es geschafft, einen LDAP-SASL binden über GSSAPI durchzuführen, ldap_sasl_bind_s verwenden. Für Interessenten, hier sind einige Hinweise.

Für eine abstrakte Beschreibung der Aktionen ein Client und Server müssen während einer GSSAPI SASL Authentifizierung, "Das Kerberos V5 (" GSSAPI ") Simple Authentication and Security Layer (SASL) Mechanismus" RFC ausführen gelesen werden soll; Insbesondere Abschnitt der ‚Client-Seite von Authentication Protocol Exchange-‘ von Interesse ist, weil es einen Hinweis auf die Abfolge von Aktionen gibt müssen wir erfolgreich binden an einen LDAP-Server über Kerberos.

auszuführen

Die Anmeldeinformationen ldap_sasl_bind_s erwartet - ihre Form und ihre Bedeutung -. Hängt von dem tatsächlichen Authentifizierungsmechanismus verwendet werden, das in unserem Fall ist Kerberos

In der Microsoft SDK ist Kerberos über SSPI zur Verfügung - was in etwa die Microsoft-Implementierung von GSSAPI ist; die Methoden, die für unseren speziellen Fall relevant sind: AcquireCredentialsHandle, InitializeSecurityContext, DecryptMessage, EncryptMessage

Ein LDAP-SASL binden über Kerberos hat drei Phasen.

Phase 1

Anruf AcquireCredentialsHandle und InitializeSecurityContext.
Wichtige Hinweise hier:

  • passieren einen Zeiger auf eine Struktur zu AcquireCredentialsHandle SEC_WINNT_AUTH_IDENTITY die eigentlichen Anmeldeinformationen enthält (Realm, Benutzername, Passwort) oder NULL wenn die Anmeldeinformationen des aktuellen Threads verwendet werden
  • sollte der Zielname ein SPN sein auf das Konto zugeordnet, unter dem der LDAP-Server läuft
  • wenn InitializeSecurityContext aufrufen, müssen die gegenseitige Authentifizierung angefordert werden.

Wenn alle wichtigen Argumente korrekt sind - ein gültiger Berechtigungsnachweis, gültige SPN, NULL Eingabe-Token - der InitializeSecurityContext Anruf SEC_I_CONTINUE_NEEDED zurückkehren sollte und richtig die Ausgabe-Token füllen. Der Inhalt dieser Ausgabe-Token in der BERVAL Struktur ldap_sasl_bind_s erwartet als Client-Anmeldeinformationen gehen sollte.

Anruf ldap_sasl_bind_s mit der Ausgabe von InitializeSecurityContext als Client-Anmeldeinformationen Token. Wenn alle Argumente korrekt sind - leer DN, GSSAPI als Mechanismus Name - der eigentliche Anruf sollte LDAP_SUCCESS und die aktuellste LDAP-Fehler für die LDAP-Sitzung zurückkehren sollte LDAP_SASL_BIND_IN_PROGRESS sein.

Als Randbemerkung, die jüngsten LDAP-Fehler für eine LDAP-Sitzung können durch den Aufruf ldap_get_option auf der Sitzung entdeckt werden, mit LDAP_OPT_ERROR_NUMBER als Option.

Phase 2

Nach dem erfolgreichen Aufruf ldap_sasl_bind_s, sein letztes Argument verweist auf eine BERVAL Struktur, die die Server-Anmeldeinformationen enthält. Der Inhalt dieser BERVAL Struktur soll jetzt als für den zweiten Anruf zu InitializeSecurityContext Token-Eingang verwendet werden.

Dieser zweite Aufruf an InitializeSecurityContext sollte SEC_OK und eine leere Ausgabe-Token zurück.

Dieser leere Ausgabe-Token sollte für einen anderen Aufruf an ldap_sasl_bind_s als die Client-Anmeldeinformationen verwendet werden. Dieser zweite Aufruf an ldap_sasl_bind_s sollte LDAP_SUCCESS, mit den letzten LDAP-Fehlern für die LDAP-Sitzung seines LDAP_SASL_BIND_IN_PROGRESS zurück.

Phase 3

Nach dem zweiten erfolgreichen Aufruf ldap_sasl_bind_s, sein letztes Argument verweist auf eine BERVAL Struktur mit Serverdaten. Dieser Server Daten sollten als Eingabe für DecryptMessage gegeben werden. Wie in dem zuvor erwähnten RFC angegeben, muss die entschlüsselten Daten lang 4 Byte sein.

Der Kunde sollte seine Antwort baut nach den Angaben in der gleichen RFC.
Hinweis : In meinem Fall weggelassen ich die Berechtigungs-ID in der RFC erwähnt. Zu meinem Verständnis, eine leere Berechtigungs-ID führt zu der Authentifizierungs-ID für die Autorisierung wird ebenfalls verwendet.

Die Antwort der Client gebaut sollte dann als Eingabe für EncryptMessage weitergegeben werden. Der Ausgang des EncryptMessage Aufruf sollte dannwie die Client-Anmeldeinformationen für den dritten und letzten Aufruf an ldap_sasl_bind_s weitergegeben werden.

Hinweis : Die Dokumentation MSDN für EncryptMessage unter Kerberos scheint unvollständig zu sein. Google Code Search sollte mit einem Arbeitsbeispiel unterstützen. Auch für ein Arbeitsbeispiel der Strömung oben beschrieben, Sambas Quellcode kann zu Rate gezogen werden.

Andere Tipps

Ich fand das Problem.

Nach diesem Thread ( https://groups.google.com/group/microsoft.public.active.directory.interfaces/browse_thread/thread/9c13fe85e520f0b4/820a136e032946e9?pli=1 ) gibt es einen Fehler mit ldap_sasl_bind_s Rückkehr leeren Server Anmeldeinformationen in Windows XP. Ich habe meine Anwendung unter Windows 2008 Server getestet und die Anmeldeinformationen korrekt zurückgegeben.

Artikel von Sun und MSDN . Wahrscheinlich, wenn Sie versuchen können, ein Beispielprogramm Erstellung können Sie die Antworten bekommen

Another One

Pseudo-Code 

struct berval   cred;
char mechanism[BUFSIZ];
getline( mechanism, sizeof(mechanism), stdin, "mechanism? " );
getline( passwd, sizeof(passwd), stdin,"credentials? " );
cred.bv_val = passwd;
cred.bv_len = strlen( passwd );
rc = ldap_sasl_bind_s( ld, dn, mechanism, &cred, NULL, NULL, NULL );
Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top