UNIXとマイクロソフトWindows NTの間の統一ログインは長い間 異質のコンピュータ環境での”聖杯”と考えられていた。 winbindはSamba環境の中のコンポーネントとして統一ログオンの解決策として 用意された。 WinbindはマイクロソフトRPCコール、プラグ可能な認証モジュール(PAM)，ネームサービススイッチ（NSS） をUNIX上の実装し、Windows NTドメインユーザーをUNIXマシン上でUNIXユーザーとして参加できるようにした。
UNIXとマイクロソフトWindows NTでは、ユーザーとグループ情報の表現手法と、 実装技術に違いがあることが良く知られている。この事が、２つのシステムを満足 できるような方法で統合することを難しくしていた。
今日用いられている一般的な方法の一つは、UNIXとWindowsで同一の 名前をもったアカウントを作成し、Sambaがファイルの提供とプリントサービスを 行うために、利用することだ。ただ、この解決方法は完全な方法とは言いがたい。 なぜなら、両方のマシンで行うユーザーの追加、削除は煩雑だし、UNIXとWindowsシステム ２組のパスワードが必要で、常にそのファイルが同期していなければいけないという問題 があり、ユーザーを混乱させるからだ。
UNIXマシンでの統一的なログオンに関する問題を、次の３つの問題点に分割する：
Windows NTのユーザーとグループ情報を取得する
Windows NTユーザーの認証
Windows NTユーザーのパスワード変更
理想的には、統一ログオン問題の将来的な解決方法は前述の問題解決にあたって、 UNIXマシン上の情報を複製したり、システム管理者がユーザーやグループのメンテナンスを 行う際にいずれのマシン上でも新たな作業をしなくてもよいことが求められている。winbind システムは、簡単でエレガントな解決方法を提供する。
UNIXとWindows NTの統合アカウントマネージャーのWinBindは、UNIXボックスを NTドメインのフルメンバーになることを許可します。いったんそうなれば、UNIXボックスは NTドメインをUNIXだけの環境で使われているNIS＋と同じようなものとみなし、NTドメインユーザーと グループをネーティブなUNIXユーザーとグループとして見る事ができる。
UNIXマシン上のプログラムが、OSに対してユーザーやグループ名の検索を依頼するたびに、 NTドメインコントローラーに対して、指定されたドメインを検索するように依頼し、回答をえます。 WinBindがOSのローレベル（Cライブラリ内のNSSを経由して）にフックすることで、 NTドメインコントローラーに対するリダイレクトは完全に透過的に行われる。
これでUNIXマシンのユーザーはＮＴのユーザーとグループ名をUNIXネーティブの ユーサー情報とみなすことができる。ＮＴドメインのユーザーはファイルを所有したり、 UNIXマシンにログインしてUNIX X-Windowのセッションをドメインユーザーとして起動する ことさえもできる。
WinbindはDOMAIN\usersとDOMAIN\groupの２つのファイルからユーザーとグループ名 を引き出している。このことが、Winbindは問い合わせをどのドメインコントローラーにするか、 どの信頼関係にあるドメインを参照するかを支配します。
加えて、WinbindはPAM（プラグ可能な認証モジュール）をフックすることで、PAMを使用した アプリケーションがNTドメイン経由で認証を受けることができるようにする。この機能により、 すべてのパスワードが一つの場所（ドメインコントローラー上）に保存されることになり、 複数のシステムの間でパスワードを同期させる必要があるという問題を解決する。
WinbindはNTベースのドメインインフラをすでに持っていて、UNIXベースの ワークステーションやサーバーの追加を希望する組織をターゲットとしている。 WinbindはUNIXワークステーションを配置する際に、新たなアカウント体系を メンテナンスする必要が無いようにする。この単純さが、NTベースの組織にUNIX ワークステーションを配置する際の管理上の煩雑さを解消することになる。
WinbindがUNIXベース設備の中核として利用されるようになると期待している。 マイクロソフトベースのネットワークに対して、ファイルや、プリントサービスを提供する設備 はWinbindを使うことで、シームレスにドメインに統合することができる。
winbindシステムは、クライアント／サーバーアーキテクチャーを背景に デザインされている。winbinddデーモンは動きつづけ、UNIX ドメインソケットにリクエストがくるのを待ちつづける。リクエストは、NSSやPAMクライアント により作られ、順番に処理される。
winbindを実装するための技術は以下に詳細に解説されている。
過去２年にわたる多くのSamba Teamのメンバーたちの苦労で、 マイクロソフトリモートプロセスコール(MSRPC)システムが解析された。 このシステムは、Windows NTマシン間で行われるネットワークに関連する多くの処理、 リモートメンテナンス、ユーザー認証、プリントスプール、で使用されている。 この初期の解析作業はSambaのプライマリードメインコントローラー(PDC)を実装する際の 助けになったが、他の目的のために使われるコードも生み出した。
Winbindは多くのMSRPCコールをドメインユーザーやグループを列挙したり、 個々のユーザーやグループの詳細情報を取得するために使用している。それ以外のMSRPCコールも NTドメインユーザーの認証やユーザーのパスワードを変更するために使用している。直接 WindowsのPDC（プライマリードメイン）にユーザーやグループの情報を問い合わせするために、 windindはNTのアカウント情報をUNIXのユーザーとグループ名にマップしている。
ネームサービススイッチ（NSS）は多くのUNIXで提供されている機能である。ホスト名、 メールエイリアス、ユーザー情報は異なるソースを参照して解決している。たとえば、 スタンドアロンのUNIXワークステーションはシステム情報をローカルのファイルシステムに保存した 複数の単純なファイルを使って解決している。ネットワーク上のワークステーションでは、 まず最初にローカルのファイルからシステム情報が取得できるかどうか試みる。その次に、 NISデータベースにユーザー情報を問い合わせ、DNSサーバーにホスト名の情報を問い合わせる。
winbindによるNSSアプリケーションプログラムI／Fはそれ自身がUNIXのユーザー名やグループ を解消する際の提供元となる。Winbindはこのインターフェースと、Windows NTサーバーから MSRPCを使用して取得した情報で、新たにアカウント表を提供する。 UNIXの標準ライブラリーコールを使用することで、Winbindが動作しているUNIXマシンのユーザーや グループを列挙することができ、NTドメインと、信頼するドメイン上のユーザーとグループを あたかもローカルのユーザーとグループのように見ることができる。
NSSのプライマリーコントロールは/etc/nsswitch.conf。 UNIXアプリケーションが検索の要求をすると、Cライブラリは/etc/nsswitch.conf を調べ、要求されたサービスタイプと一致する行を探し出す。たとえば、"passwd"サービスタイプは ユーザーやグループ名を検索するのに用いられる。このconfig行はどのサービスを使用すべきか、 そしてどの順番で呼ぶかを特定するために使用する。もしpasswd行であれば：
passwd: files example
Cライブラリーは、まず/lib/libnss_example.soと /lib/libnss_files.soモジュールをロードする。 Cライブラリはこれらのモジュールをダイナミックロードした後で、要求された問いを解消するために、 これらモジュールのリゾルバ関数を呼び出す。要求が解決されると、Cライブラリは 結果を元のアプリケーションに返却する。
このNSSインターフェースはOS内部をフックすることで、非常に簡単に提供されている。 必要なことは、/lib/にlibnss_winbind.soを置き、 "winbind"を/etc/nsswitch.confの適切な場所に加えるだけだ。 すると、Cライブラリはユーザーとグループ名を解決するために、Winbindを呼ぶようになる。
PAMとして知られているプラグ可能な認証モジュールは、認証を抽象化した認証技術のことである。 PAMモジュールを使うことで再コンパイルすことなく、システムアプリケーションのために異なる認証方法を 選ぶことができる。PAMは独自の認証ポリシーを実装する際に有用となる。例をあげると、システム管理者が ローカルのパスワードファイルに乗っているユーザーにのみコンソールログインを許可するが、 NISデータベースで認証されたユーザーにはネットワーク経由でログインさせたい時が考えられる。
WinbindはWindows NTのユーザーをUNIXシステムに統一するために、認証の管理とパスワードの 管理でPAMインターフェースを使う。Windows NTユーザーはUNIXマシンにログインし、プライマリー ドメインコントロラーに認証される。ユーザーはバスワードを変更することができ、その変更は直接 プライマリードメインコントローラーに反映される
PAMは/etc/pam.d/ディレクトリのコントロールファイルで 認証が必要なサービスごとに設定されている。アプリケーションが認証を要求すると、 Cライブラリの中のPAMコードがこのコントロールファイルを検索し、どのモジュールを 認証のためにロードする必要があるか、そしてその順番で読み込めばよいかを決定する。 このインターフェースは新しい認証サービスをwindindに加えることを容易にしている。必要なことは 単に/lib/security/にpam_winbind.soモジュールをコピーし、 関連するサービスのPAMコントロールファイルをWinbind経由で認証するようにアップデートするだけだ。詳細は PAMのドキュメントを参照のこと。
ユーザーやグループがWindows NT上で作成さると、RIDが割り当てられる。これはUNIXとわずかに 違う。UNIXではある並びの数字がユーザーを識別するために使われ、同様の数字がグループを 識別するために使用される。WinbindがRIDからUNIXのID番号に変換する作業を行う。Winbindが 設定されると、UNIXのユーザーIDのある空間と、グループIDの空間の一部を与えられる。Windows NT ユーザーがはじめて認証の問い合わせをすると、UNIXのIDを先ほどの範囲の中から割り当てる。 同様なことがグループに関しても行われる。こうしてwinbindはWindows NTのすべてのユーザーと グループをUNIXのユーザーIDとグループIDにマップすることになる。
このマッピングの結果は、永続的にtdbデータベースの中にIDマッピングとして保存される。 こうしてRIDはUNIXのIDへ矛盾無くマップされる。
頻繁に利用されているシステムは多くのユーザーやグループ名の問い合わせを行う。 ネットワーク負荷を下げるために、winbindはNTドメインコントローラが使用している SAMシーケンス番号を元に、キャッシュを用いる。PDCから返却されたユーザーやグループ情報は PDCから返却されたシーケンス番号にしたがってwinbindによりキャッシュされる。このシーケンス 番号はユーザーやグループ情報が変更されるたびにWindows NTが＋１する。 もしキャッシュされた内容が期限切れになると、PDCからシーケンス番号を要求される。 ２つのシーケンス番号を比較し、違っていた場合は、キャッシュされた内容が破棄され、 アプリケーションからの問い合わせを直接PDCに送る。
winbindをインストールする最も簡単な方法は、近くのSambaミラーサーバーから pub/samba/appliance/にあるパッケージを使用することになる。 このパッケージには、Sambaのソースコードのスナップショットと、全機能が動くように 設定されたwinbindが入っている。winbindがSAMBA_TNGと呼ばれる開発用のコードブランチに 依存するコードを必要としているため、セットアップは若干複雑になっている。
パッケージをインストールしたら、winbindd(8)を読むこと。 そこに設定に関する情報と若干の設定例のファイルが用意されている。 Sambaの主要デーモン(smbd, nmbd)をより新しい開発バージョン、たとえばSamba 2.2 alpha、 にアップデートすることも可能です。
Winbind は現状ではいくつかの制約事項を持っている。将来のリリースで 解消されることを望んでいる。
Winbindfは現状ではLinux環境でのみ供給されている。とはいえ、 他のOSに移植することも間違いなく可能である。移植するためには、対象となるOSの CライブラリでNSSとPAMがサポートされている必要がある。NSSとPAMは多くのUNIXベンダーで サポートされるようになっている
Windows NTのRIDからUNIXのIDへのマップは演算的に作られたものではなく、winbindが 未登録とみなしたユーザーやグループから割り当てる。したがって、 マップ情報を保持しているファイルが改竄されたり、破壊されるとRIDからUNIXのIDへのマップを 復旧することは難しい。
現状のwinbindのPAMモジュールはアカウントが 有効なワークステーションを入れること、？Windows NTユーザーにセットされたログオン時間の 限定機能を実現していない
winbindをソースからビルドするのは非常に退屈である。ビルドには２つのSambaの ブランチからソースを取得する必要がある。ソースの取得は、Sambaのメインコードブランチから 行う必要がある。
winbindシステムはネームサービススイッチ（NSS）、プラグ可能な認証（PAM）、 適当なマイクロソフトRPCを通してUNIXユーザーとマイクロソフトWindows NTドメインユーザーをシームレスに 統合することができるようになった。その結果、UNIXとNTネットワークの混在環境での管理コストが大幅に 削減できる。