LDAP_SASL_BIND_S(GSSAPI) - 資格情報で提供されるべきものBerval構造
質問
私は使用しようとしています ldap_sasl_bind_s
Microsoft LDAP C SDKからの方法 gssapi 認証メカニズムとして。 ldap_sasl_bind_s
資格情報はaとして期待されます BERVAL
構造、これは不透明です。
ユーザー名(またはDN)とパスワードが与えられた場合、 どうすれば到達できますか BERVAL
構造 私が渡すことになっていること ldap_sasl_bind_s
?
私がこれまでに見つけた例
- 他のldap c sdksからのもの - マイクロソフトからのものではありません
- 使用する
ldap_sasl_bind_s
単純な認証が必要な場合 - しかし、GSSAPIを使用する必要があります - 使用する
ldap_sasl_interactive_bind_s
他のSASL認証メカニズムが必要な場合。しかし、noはありませんldap_sasl_interactive_bind_s
Microsoft SDKで。
サイドノートとして、目標はSASLをさまざまなLDAPサーバーにバインドできることです。とりあえず:ActiveDirectoryとOpenLdap。
どんなポインターも大歓迎です。
解決
GSSAPIを使用してLDAP SASLバインドを実行することができました ldap_sasl_bind_s
. 。興味のある方のために、ここにいくつかのポインターがあります。
アクションの抽象的な説明のために、クライアントとサーバーがGSSAPI SASL認証中に実行する必要があります、 「Kerberos V5(「GSSAPI」)シンプルな認証とセキュリティレイヤー(SASL)メカニズム」 RFCを読む必要があります。具体的には、「認証プロトコル交換のクライアント側」セクションは興味深いものです。これは、Kerberosを介してLDAPサーバーにうまくバインドするために実行する必要がある一連のアクションを示しているためです。
資格情報 ldap_sasl_bind_s
予想 - それらの形とその意味 - は、使用されている実際の認証メカニズムに依存しています。私たちの場合はKerberosです。
Microsoft SDKでは、KerberosはSSPIを通じて利用可能です。これは、GSSAPIのMicrosoft実装です。特定のケースに関連する方法は次のとおりです。 AcquireCredentialsHandle
, InitializeSecurityContext
, DecryptMessage
, EncryptMessage
Kerberosの上にLDAP SASLバインドには3つのフェーズがあります。
フェーズ1
電話 AcquireCredentialsHandle
と InitializeSecurityContext
.
ここで重要なメモ:
- に渡します
AcquireCredentialsHandle
aへのポインターSEC_WINNT_AUTH_IDENTITY
実際の資格情報(レル、ユーザー名、パスワード)、またはNULL
現在のスレッドの資格情報を使用する場合 - ターゲット名は、LDAPサーバーが実行されているアカウントにマッピングされたSPNである必要があります
- 電話するとき
InitializeSecurityContext
, 、相互認証を要求する必要があります。
すべての重要な引数が正しい場合 - 有効な資格情報、有効なSPN、 NULL
入力トークン - InitializeSecurityContext
電話が返されるはずです SEC_I_CONTINUE_NEEDED
出力トークンを適切に埋めます。この出力トークンの内容は、 BERVAL
構造 ldap_sasl_bind_s
クライアントの資格情報として期待しています。
電話 ldap_sasl_bind_s
出力トークンから InitializeSecurityContext
クライアント資格として。すべての引数が正しい場合 - メカニズム名としての空のDN、gssapi-実際の呼び出しは返されるはずです LDAP_SUCCESS
そして、LDAPセッションの最新のLDAPエラーは LDAP_SASL_BIND_IN_PROGRESS
.
サイドノートとして、LDAPセッションの最新のLDAPエラーは、呼び出すことで発見できます ldap_get_option
セッションで、 LDAP_OPT_ERROR_NUMBER
オプションとして。
フェーズ2
通話が成功した後 ldap_sasl_bind_s
, 、その最後の議論はaを指します BERVAL
サーバー資格情報を含む構造。これの内容 BERVAL
次の2回目の呼び出しのための入力トークンとして構造を使用する必要があります InitializeSecurityContext
.
この2回目の呼び出し InitializeSecurityContext
返す必要があります SEC_OK
そして空の出力トークン。
この空の出力トークンは、別の呼び出しのクライアント資格情報として使用する必要があります ldap_sasl_bind_s
. 。この2回目の呼び出し ldap_sasl_bind_s
返す必要があります LDAP_SUCCESS
, 、LDAPセッションの最新のLDAPエラーがあります LDAP_SASL_BIND_IN_PROGRESS
.
フェーズ3
2回目の成功した呼び出しの後 ldap_sasl_bind_s
, 、その最後の議論はaを指します BERVAL
サーバーデータを含む構造。このサーバーデータは、入力として指定する必要があります DecryptMessage
. 。前述のRFCで指定されているように、復号化されたデータの長さは4バイトでなければなりません。
クライアントは、同じRFCの情報に従って返信を作成する必要があります。
ノート: :私の場合、RFCで言及されている承認IDを省略しました。私の理解のために、空の承認IDは、認証IDが許可にも使用されることにつながります。
クライアントが構築した返信は、入力として渡す必要があります EncryptMessage
. 。の出力 EncryptMessage
次に、3回目と最終呼び出しのクライアント資格情報として通話を渡す必要があります ldap_sasl_bind_s
.
ノート: :使用するMSDNドキュメント EncryptMessage
Kerberosの下では不完全なようです。 Googleのコード検索は、実用的な例を支援する必要があります。また、上記のフローの作業例については、Sambaのソースコードを参照できます。
他のヒント
問題を見つけました。
このスレッドによると( https://groups.google.com/group/microsoft.public.active.directory.interfaces/browse_thread/thread/9c13fe85e520f0b4/820a136e032946e9?pli = 1)LDAP_SASL_BIND_SがWindows XPで空のサーバー資格情報を返すバグがあります。 Windows 2008サーバーでアプリケーションをテストし、資格情報が適切に返されます。
からの記事 太陽 と MSDN. 。おそらく、サンプルプログラムを作成してみることができれば、答えが得られるかもしれません
擬似コード
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 );