LDAP_SASL_BIND_S (GSSAPI) - Que doit être fourni dans la structure BERVAL DE CIDENS

article de Sun et MSDN . Probablement si vous pouvez essayer de créer un exemple de programme, vous pouvez obtenir les réponses

un autre

pseudocode xxx

J'ai réussi à effectuer une liaison LDAP SASL sur GSSAPI, en utilisant ldap_sasl_bind_s . Pour les personnes intéressées, voici quelques pointeurs.

Pour une description abstraite des actions Un client et un serveur doivent effectuer lors d'une authentification GSSAPI SASL, "The Kerberos V5 (" GSSAPI ") Mécanisme d'authentification et de sécurité SASL) (SASL)" RFC devrait être lu; Plus précisément, le «côté client de la section de l'échange de protocoles d'authentification» est d'intérêt, car il donne une indication de la séquence d'actions que nous devons effectuer pour lier avec succès à un serveur LDAP sur Kerberos.

Les informations d'identification ldap_sasl_bind_s attendent - leur forme et leur signification - dépendent du mécanisme d'authentification réel utilisé, ce qui est dans notre cas Kerberos.

Dans le SDK Microsoft, Kerberos est disponible via SSPI - qui est à peu près l'implémentation Microsoft de GSSAPI; Les méthodes qui sont pertinentes pour notre cas particulier sont les suivantes: AcquireCredentialShandle , InitialiseSecurityContext , DecryptMessage , EncryptMessage

Un LDAP SASL BIND sur Kerberos a 3 phases.

Phase 1

appel AcquireCreDentialShandle et InitialiseSecurityContext .
Notes importantes ici:

• passe à AcquireCreDentialShandle un pointeur sur un SEC_WINNT_AUTH_IENTITITY structure contenant les informations d'identification réelles (royaume, nom d'utilisateur, mot de passe) ou null si les informations d'identification du fil actuel doit être utilisé
• Le nom de la cible doit être un SPN mappé sur le compte sous lequel le serveur LDAP fonctionne
• Lorsque vous appelez initialisiseSecurityContext , l'authentification mutuelle doit être demandée.

  Si tous les arguments importants sont corrects - des informations d'identification valides, valides SPN, null jeton d'entrée - The InitialiseSeCurityContext L'appel doit renvoyer sec_i_continue_needed (code> et bien remplir le jeton de sortie. Le contenu de ce jeton de sortie devrait aller dans le Berval structure ldap_sasl_bind_s s'attend en tant que références clientes.

  appel ldap_sasl_bind_s avec le jeton de sortie à partir de initialisationSecurityContext comme des informations d'identification du client. Si tous les arguments sont corrects - vides DN, GSSAPI en tant que nom de mécanisme - l'appel actuel doit renvoyer ldap_success ldap_sasl_bind_in_progress . < / p>

  En tant que note latérale, l'erreur LDAP la plus récente pour une session LDAP peut être découverte en appelant ldap_get_option sur la session, avec ldap_opt_error_number comme option.

  Phase 2

  Après l'appel réussi à ldap_sasl_bind_s , son dernier argument pointe vers un BERVAL structure contenant les informations d'identification du serveur. Le contenu de cette structure BERVAL doit maintenant être utilisé comme jeton d'entrée pour le deuxième appel à InitialiseSecurityContext . .

  Ce second appel à InitialiseSecurityContext doit renvoyer sec_ok et un jeton de sortie vide.

  Ce jeton de sortie vide doit être utilisé comme des informations d'identification du client pour un autre appel à ldap_sasl_bind_s . Ce second appel à ldap_sasl_bind_s doit renvoyer ldap_success , avec l'erreur LDAP la plus récente de la session LDAP étant ldap_sasl_bind_in_progress . .

  Phase 3

  Après le deuxième appel réussi à ldap_sasl_bind_s , son dernier argument pointe vers un BERVAL structure contenant des données du serveur. Ces données de serveur doivent être données comme entrée sur déchiffsmessage . Comme spécifié dans le RFC mentionné précédemment, les données déchiffrées doivent être de 4 octets longs.

  Le client doit construire sa réponse en fonction des informations du même RFC.
note : dans mon cas, j'ai omis l'ID d'autorisation mentionné dans la RFC. À ma compréhension, un ID d'autorisation vide conduit à l'ID d'authentification utilisé pour l'autorisation.

  La réponse Le client construit doit ensuite être passé en entrée sur chiffrementMessage . La sortie de l'appel cryptMessage doit ensuite être transmise en tant que lettres d'identification du client pour le troisième et dernier appel à ldap_sasl_bind_s . .

  note : la documentation MSDN pour l'utilisation de chiffrermessage sous Kerberos semble être incomplète. La recherche de code de Google doit aider avec un exemple de travail. De plus, pour un exemple de travail du flux décrit ci-dessus, le code source de Samba peut être consulté.