Windowsとの認証統合

ようやく目標その2に到達。LDAPを使ってWindowsと認証を統合するといっても、結局実際にWindowsと連携するのはSambaである。ユーザデータをLDAPサーバ上のデータベースで一元管理出来ることが違いだと思うが、Windows2000/2003サーバ上のActiveDirectoryにNIS情報を持たせることと本質的に変わらない気もする。

まずはシステムの動作を理解したいので一旦slapdのTLSオンリーは解除。TLSを使っても出来ると思うが、それはシステムが動いてから改めていじることに。

使うパッケージはsamba,samba-common,smbldap-tools,samba-doc(LDAP用のsamba.schemaはここに入っている)。基本的に設定は参考サイトに書いてある通りに進めればよい。smbldap-toolsでは各種ツールが/usr/sbinに拡張子.plが取られた状態で配置され、参考サイトに書いてある修正はほとんどすでになされていることに注意。またドメイン参加の際コンピュータアカウントもサーバマシン上でログインアカウントとして認識されている状態にすることが必須である。わざわざ強調したのはこのせいで一日以上作業が進まなかったから(苦笑)。これを怠ると、ドメインに参加させる権限のあるユーザの認証が終わった後で「ユーザが見つかりません」と言われて終わってしまう。ログ出力のレベルが低いとサーバ側にエラーログが一切残らないので解決に手間取った。

ログ出力のレベルを最大にして情報の波からエラーと思しきメッセージを探し出し、その原因にあたりをつけて一つずつ解決法を試していく…今回はそんなことばっかりだった気が…(本職の方々には当たり前すぎる話だろうけど)

広告
カテゴリー: Linux, OpenLDAP, Samba. Windowsとの認証統合 はコメントを受け付けていません。

LDAPによるネットワーク認証

認証情報の共有をNISで行っていると、md5で暗号化されているとはいえパスワードが見えてしまっていてよくない…ということで、認証をLDAPで行ってみることにした。Windowsとの認証の共有化もスマートにできそうだし(注:この辺の認識は間違いあり。モチベーションではあったのでこのまま書いているが)。

よく調べずに「LDAPを使うとセキュアである」という言葉だけを先行させていたのだが、よくよく調べてみるNISとLDAPの違いはこんな感じらしい。

  • ログインに際してサーバからクライアントに渡される情報自体はNISとまったく同じ(当たり前といえば当たり前だが)
  • 違うのは通信プロトコルやデータ型。これらが違うからNISではできない細かいアクセス制御や、暗号化通信ができる
  • SASLを用いれば認証それ自体をサーバに任せることもできる(NISだと受け取った情報を元に実際に認証を行うのはクライアント)
カテゴリー: Linux, OpenLDAP. LDAPによるネットワーク認証 はコメントを受け付けていません。

slapd

認証とか抜きにして、LDAPサーバを構築してデータを登録していくだけであれば、パッケージのインストールとしてはslapd,ldap-utils,libldap2を入れればよい。設定法などは以下の参考記事を元に適当にカスタマイズするだけ。

カテゴリー: Linux, OpenLDAP. slapd はコメントを受け付けていません。

データの登録

データの登録はldap-utilsに含まれるldapaddを使う。詳しい説明はやはり参考記事にゆだねるが、大体のイメージとしては

  • 個々のエントリはプログラムで言うところの変数を定義することに近い
  • 変数を定義するときは型が必要になるが(とりあえずJavaを想像してください)、その型は多重継承可能なクラスみたいなもの(Java使うのならimplementだといってしまったほうがよいかも知れない…)
  • 継承したクラスそれぞれの持つフィールドを定義してやる

こんな感じだと思う。手続きとしては入れ物(dc,ou)を作って、個々のエントリ(cn)を入れていく。ActiveDirectoryだと最初からビルトインでいろいろ用意されていたものを自分で一つずつ積み上げているだけのこと。

カテゴリー: OpenLDAP. データの登録 はコメントを受け付けていません。

データの複製

参考記事に書いてある複製のメカニズムが分かれば、それにしたがって何をすればよいかがおのずと分かる…はず。

  • スレーブはマスターのデータの複製を保持するわけだが、スレーブ自体はデータの変更を行わない -> スレーブを参照しているマシンで、ディレクトリのデータ変更を必要とする場合(例:パスワード変更)、変更をするマスターサーバのアドレスを指定しなければならない -> スレーブ側updaterefの設定
  • マスターのデータが変更されると、マスターはその変更をスレーブに適用する。-> マスターはスレーブの更新権限を持っていないといけない -> スレーブ側updatednの設定(≒データ更新のためのユーザとそのパスワードの組)
  • マスターのデータが変更されると、マスターはその変更をスレーブに適用する。-> マスターはスレーブのアドレスを知っていないといけない -> マスター側replicaの設定(スレーブのupdatednで設定したユーザ名などを知らせる必要)

ここ関連でコケたのはupdatednとupdaterefディレクティブの設定が間違っているのにかかわらず、slapdがそれを無視して起動してしまうので何が悪いのかしばらく分からなかったこと。-d 16383してようやく設定が間違っていることが分かった。これは動作としていいのだろうか?

カテゴリー: OpenLDAP. データの複製 はコメントを受け付けていません。

暗号化通信への切り替え

暗号化なしで一通り出来るようになったので、以上の手続きをすべて暗号化するように設定を書き直す。暗号化の手続きは参考記事の通り、そこに載っていない各種設定ファイルはhostの変わりにuri ldaps://(LDAPサーバのFQDN)を使うこと、slapdを暗号化のみ起動するには引数に-h ldaps:///を使えばよくそのためにはdebianの場合/etc/init.d/slapdの適当に書き換える必要がある。

さらにクライアント側は、cacertを適当な場所にコピーして/etc/ldap/ldap.confにここに書いてある通りcacertの場所を指定してやる必要がある。

カテゴリー: OpenLDAP. 暗号化通信への切り替え はコメントを受け付けていません。

LDAPを用いた認証(クライアント側)

以上の運用でデータを見られることを確認した上で認証を実装する。認証に使うパッケージはlibnss-ldap,libpam-ldapだけのはずなのだが、後述の参考サイトのやり方を真似るとその他もろもろのpamがらみのパッケージを要してしまう。具体的にはlibpam-opie,libpam-cracklibとそれに依存するパッケージである。この他、passwdでパスワード変更しようとすると新しいパスワードをUNIXパスワードとLDAPのパスワードのそれぞれで入力させられる(前者は捨てられる?)問題もあるので、pam.dがらみの問題はもう少し慎重に対策したほうがよさそうだ。この辺はRedHat系だとauthconfigを使うことで一発解決なはずだが…

設定ファイルに関しては

  • LDAPユーザのエントリに関する設定は/etc/libnss-ldap.conf
  • LDAPユーザの認証に関する設定は/etc/pam_ldap.conf

をそれぞれいじる必要があるのだが、実は両者のファイルはほとんど同じものなので共通化出来たりする。ldapにはlibldap2パッケージの中にさらに/etc/ldap/ldap.confというファイルがあって、これもやはり同種の設定をつかさどっていたりする。三つをシンボリックリンクで結びつけて運用することも出来なくない。今回のようなケースでわざわざ三者を分けて使用する必要はあるだろうか…

(追記) SSL絡みで使おうとしたら、三者統一だとうまくいかない…。

(長いけど追記その2) 参考サイトLDAPv3 HOWTO on Debianの方法(pam.dまるごとコピー)だとパスワード変更の際に二度聞かれたり何かと使い勝手が悪かったり、今までと違ったりするので方法の再考。調べたらUUの記事でも使われていたlibpam-unix2がdebianにもあるので、それをインストール。/etc/pam.d/common-*にsufficientでpam_unix2.soを利用するようにすればよいだけだった。

(追記その3) 上の方法だとLDAPユーザの場合、パスワード認証の初回が必ず失敗する。pam_unix.soの変わりにpam_unix2.soを使うだけでよい。これでもpasswdコマンドでパスワード変えようとするとまだ少し具合が悪い。具体的にはLDAPユーザがpasswdで最初のパスワード認証で空のパスワードを入れると、通常アカウントのパスワードの認証に入ってしまう(もちろん通常アカウントにはエントリがないので認証は必ずこけるわけだが)。この辺は再度改良の余地あり。pam.dについても理解が無駄に深まっていく…(実際、無駄ということはないが)

カテゴリー: Linux, OpenLDAP. LDAPを用いた認証(クライアント側) はコメントを受け付けていません。