システム奮闘記：その92

Samba + OpenLDAPの設定入門



Tweet
(2011年4月27日に掲載) 
はじめに

　LinuxやWindowsのID管理を一元化できないかと考え
たどり着いたのがOpenLDAPの活用だった。
LinuxとwindowsのIDの一元管理に
Samba + OpenLDAPは有効
WindowsとLinuxのIDの統合管理
上図のようなシステムを構築すれば、LinuxとWindowsのIDを
一元管理する事ができる。しかもオープンソースの組み合わせなので
ActiveDirectoryのように、CALの費用の発生は起こらない。 

　だが、いきなり、Samba + OpenLDAPのシステムを構築しようとしても

　ホップ、ステップ、肉離れ (--;;

　になってしまうのは、目に見えている。

　そこで、第一段階として、LinuxやUNIX系のID管理の一元化するための
OpenLDAPの設定の実践演習を行なう事にした。
OpenLDAPサーバーでLinuxユーザーアカウントを一元管理
OpenLDAPサーバーでLinuxのユーザーアカウントを一元管理
複数のLinuxマシンのユーザーアカウントを個々の端末で管理するより
OpenLDAPサーバーで一元管理した方が便利になるし、整合性も取りやすい。 

　OpenLDAPについて詳しい事は「システム奮闘記:その90」の
(OepnLDAPの設定入門)をご覧ください。


　だが、WindowsのID管理を行なう場合、そうは簡単に問屋は卸さない。

　WindowsのID管理を直接、OpenLDAPで行なう事はできない。
　そこで仲介役としてSambaを使う必要が出てくる。
Windowsのユーザーアカウントを
OpenLDAPサーバーで一元管理するためには
LDAPサーバーでWindowsのユーザーアカウントを一元管理する方法
OepnLDAPを使ってWindowsのユーザーアカウントの一元管理を行なうには
途中で、Sambaサーバーを中継する必要があります。
Sambaを使い、NTドメインとPDCの構築が必要になる。

他にも有償ソフトを使えば、LDAPでWindowsのユーザーアカウントの
一元管理ができるらしいが、私は知らないので何とも言えない・・・。


　この時点でも、Samba + OpenLDAPの設定を行なおうとすると

　ホップ、ステップ、肉離れ (--;;

　になるのは、目に見えているので、第二段階として、
Sambaを使ってPDCの設定を行なってみる事にした。
SambaでPDCを構築して
Windowsのユーザーアカウントを一元管理
SambaでPDCを構築してWindowsのユーザーアカウントを一元管理
Samba + OpenLDAPの一歩手前の段階として
SambaでPDCを構築して、Windowsのユーザーアカウントの
一元管理できる事を目指す事にした。 

　SambaでPDC構築について詳しい事は「システム奮闘記:その91」の
(SambaでPDC構築)をご覧ください。

　着実に設定項目などを理解しながら、前に進めてきたのだ。



Samba + OpenLDAPの設定 


　いよいよSamba + OpenLDAPでPDCの設定を行なう事になった。

　設定本などでは、SambaとOpenLDAPのマシンは同じマシン上での設定で
記述しているのが多いが、私の場合は、マシンは別々に行なった。
SambaとOpenLDAPのマシンは別々にした
OpenLDAPサーバーでLinuxのユーザーアカウントを一元管理
マシンをわける事で、トラブルの切り分けがしやすくなる。
サーバーの仮想化を行なっているので、仮想マシンを2つ作るぐらい
問題ないのだ。 

　Sambaは既存のSambaマシンで、OpenLDAPは新たに
別のマシンで立ち上げたからだ。


OpenLDAP側の設定


　まずはOpenLDAPのインストールと設定から行なう。


　Sambaと連携させるためには、Samba独自のスキーマを
取り込む必要がある。

　なので、Sambaのソースファイル(samba-3.5.6.tar.gz)を
展開させて、独自スキーマを取り出す必要がある。
独自スキーマを取り出す
[root@LDAP]# pwd
/usr/local/src/samba-3.5.6/examples/LDAP
[root@LDAP]# ls
README               ol-schema-migrate.pl   samba-schema-netscapeds4.x  samba.schema
convertSambaAccount  samba-nds.schema       samba-schema-netscapeds5.x  samba.schema.at.IBM-DS
get_next_oid         samba-schema-FDS.ldif  samba-schema.IBMSecureWay   samba.schema.oc.IBM-DS
[root@LDAP]# 
[root@LDAP]# cp samba.schema /etc/openldap/schema/
[root@LDAP]#
Samba独自のスキーマをOpenLDAPのスキーマを格納する
ディレクトリにコピーする。 

　そしてOpenLDAPの設定ファイルに、Samba独自のスキーマを
取り込む設定を行なう。
sladp.confファイル (一部抜粋)
変更前
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include		/etc/openldap/schema/core.schema
include		/etc/openldap/schema/cosine.schema
include		/etc/openldap/schema/inetorgperson.schema
include		/etc/openldap/schema/nis.schema
変更後
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include		/etc/openldap/schema/core.schema
include		/etc/openldap/schema/cosine.schema
include		/etc/openldap/schema/inetorgperson.schema
include		/etc/openldap/schema/nis.schema
include		/etc/openldap/schema/samba.schema
Samba独自のスキーマを取り込む設定を行なった。 


　次に、OpenLDAPの管理者パスワードを設定する。
パスワードの暗号化
[root@LDAP]# slappasswd
New password: 
Re-enter new password: 
{SSHA}Aos7er9J2cGg/3LU2yIg6fnil++MQVHr
[root@LDAP]#
slappasswdコマンドでパスワードを暗号化した。
opensslコマンドだと暗号化の強度が弱い。
暗号化されたパスワードは赤い部分になる。 

　まずはslapd.confのデータベースの定義についての設定部分を変更する。
sladp.confファイル (一部抜粋)
変更前
#######################################################################
# ldbm and/or bdb database definitions
#######################################################################
 

database    bdb
suffix        "dc=my-domain,dc=com"
rootdn        "cn=Manager,dc=my-domain,dc=com"
# Cleartext passwords, especially for the rootdn, should
# be avoided.  See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
# rootpw        secret
# rootpw        {crypt}ijFYNcSNctBYg
変更後
#######################################################################
# ldbm and/or bdb database definitions
#######################################################################


database    bdb
suffix        "dc=company,dc=jp"
rootdn        "cn=Manager,dc=company,dc=jp"
# Cleartext passwords, especially for the rootdn, should
# be avoided.  See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
# rootpw        secret
# rootpw        {crypt}ijFYNcSNctBYg
rootpw            {SSHA}Aos7er9J2cGg/3LU2yIg6fnil++MQVHr

色をつけたのが変更した箇所だ。
設定については「システム奮闘記:その90」の
OpenLDAP入門をご覧ください。


　次に、OpenLDAPに接続する際の接続制限の設定を行なう。
sladp.confファイル (一部抜粋)
変更前
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
# access to *
#	by self write
#	by users read
#	by anonymous auth
変更後
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
# access to *
#	by self write
#	by users read
#	by anonymous auth

access to attrs=userPassword,shadowLastChange
        by  anonymous auth
        by  dn="cn=Manager,dc=company,dc=jp" write
        by  self write
        by  * none

access to attrs=sambaLMPassword,sambaNTPassword
        by  dn="cn=Manager,dc=company,dc=jp" write
        by  * none


access to *
        by  dn="cn=Manager,dc=company,dc=jp" write
        by  * read

接続制限を設けるというのだ。

一番上の赤い部分は、Linuxのユーザーパスワードへの接続で
LDAPの管理者か、自分自身(LDAPサーバー)のみ、書き換え可能だ。
他者は、閲覧すら不可にしている。

青い部分は、Windowsのパスワードへの接続だ。
LDAPの管理者のみ接続可能だ。
LANMAN(Win9x系)と、NTLM(WinNT系)が用意されている。
他者は閲覧すら不可になっている。

桃色の部分は他のデータベースで、LDAPの管理者のみ書き換え可能で
他者は読み込みのみ可能という意味だ。


　わかったような書き方をしているのだが、実は・・・

　この時点では本の丸写し!

　なのだ。
　あとになって、意味がわかったのだ。
　見栄を張っても、バレるだけなので、正直に書く私なのだ (^^)


　これで設定完了だ。


　そしてOpenLDAPのデーモンを稼働させる。
slapdデーモンを稼働させる (CentOS5系)
[root@LDAP]# /etc/rc.d/init.d/ldap start
slapd の設定ファイルをチェック中:  config file testing succeeded
                                                           [  OK  ]
slapd を起動中:                                            [  OK  ]
[root@LDAP]# 

CentOSの場合、デーモンを起動させたり停止させるのは簡単にできる。
でも、使い勝手が良い環境になれると、どこのLinuxでも使える
普遍性の高い設定の紹介ができなくなるなぁ・・・。



　そして初期スキーマを用意する。
　本の丸写しなのだ。なので何も考えずに作成した (^^)
init.ldifファイル
dn: dc=company,dc=jp
objectClass: top
objectClass: dcObject
objectClass: organization
o: myorganization
dc: company


dn: ou=users,dc=company,dc=jp
objectClass: top
objectClass: organizationalUnit
ou: users

dn: ou=groups,dc=company,dc=jp
objectClass: top
objectClass: organizationalUnit
ou: groups


dn: ou=idmap,dc=company,dc=jp
objectClass: top
objectClass: organizationalUnit
ou: idmap


dn: ou=computers,dc=company,dc=jp
objectClass: top
objectClass: organizationalUnit
ou: computers

ユーザー名、グループ名、コンピューター名が格納されるための
エントリーだというのは、わかる。
でも、なぜユーザ名は「users」で、グループ名は「groups」なのか
全く考えずに、本の丸写しを行なった。

Linux認証のデータベースにも使う際は、注意が必要だ。
本の丸写しだと、あとで四苦八苦する。四苦八苦の話は後述しています。


　初期スキーマを設定する。
初期スキーマを設定
[root@LDAP]# ldapadd -x -D "cn=Manager,dc=company,dc=jp" -W -f ./init.ldif
Enter LDAP Password: 
adding new entry "dc=company,dc=jp"

adding new entry "ou=users,dc=company,dc=jp"

adding new entry "ou=groups,dc=company,dc=jp"

adding new entry "ou=idmap,dc=company,dc=jp"

adding new entry "ou=computers,dc=company,dc=jp"

[root@LDAP]# 


　これで、OpenLDAP側の設定はこれで完了だ。




Samba側の設定


　次にSamba側の設定を行なう。
　まずはSambaのインストールだが、RPMを使うと楽なのだが
CentOS5.4だとWindows7に対応していないバージョンのため
RPMは使えない。

　そこでソースコンパイルで、最新バージョンを入れる必要がある。
　Samba-3.5.8が出ている。
configureを行なう
[root@samba]# ./configure --with-libiconv=/usr --with-ldap --with-pam  --with-winbind --with-acl-support --enable-nss-wrapper
SAMBA VERSION: 3.5.8
-
-
#    define SAMBA_VERSION_STRING SAMBA_VERSION_OFFICIAL_STRING
LIBREPLACE_LOCATION_CHECKS: START
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu


(途中、省略)


config.status: creating include/config.h
config.status: executing rm-stdint.h commands
config.status: executing rm-stdbool.h commands
[root@samba]# 


　次にmakeコマンドでコンパイルを行なう。
makeでコンパイル
[root@samba]# make
Using CFLAGS     = -O -I. -I/usr/local/src/samba-3.5.8/source3 -I/usr/local/src/samba-3.5.8/source3/iniparser/src -Iinclude -I./include  -I. -I. -I./../lib/replace -I./../lib/tevent -I./libaddns -I./librpc -I./.. -I./../lib/talloc -I../lib/tdb/include -DHAVE_CONFIG_H  -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -Iinclude -I./include -I. -I. -I./../lib/replace -I./../lib/tevent -I./libaddns -I./librpc -I./.. -I./../lib/popt -DLDAP_DEPRECATED  -I/usr/local/src/samba-3.5.8/source3/lib -I.. -I../source4 -D_SAMBA_BUILD_=3 -D_SAMBA_BUILD_=3
      PICFLAG    = -fPIC
      LIBS       = -lcap -lresolv -lresolv -lnsl -ldl
      LDFLAGS    = -pie -Wl,-z,relro -L./bin
      DYNEXP     = -Wl,--export-dynamic
      LDSHFLAGS  = -fPIC -shared -Wl,-Bsymbolic -Wl,-z,relro -L./bin -lc -Wl,-z,defs


(途中、省略)


Compiling ../nsswitch/pam_winbind.c
Linking shared library bin/pam_winbind.so
Compiling ../client/cifs.upcall.c
Linking bin/cifs.upcall
Compiling ../nsswitch/winbind_krb5_locator.c
Linking bin/winbind_krb5_locator.so
[root@samba]# 


　そしてインストールを行なう。
make install　でインストールする
[root@samba]# make install
Using CFLAGS     = -O -I. -I/usr/local/src/samba-3.5.8/source3 -I/usr/local/src/samba-3.5.8/source3/iniparser/src -Iinclude -I./include  -I. -I. -I./../lib/replace -I./../lib/tevent -I./libaddns -I./librpc -I./.. -I./../lib/talloc -I../lib/tdb/include -DHAVE_CONFIG_H  -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -Iinclude -I./include -I. -I. -I./../lib/replace -I./../lib/tevent -I./libaddns -I./librpc -I./.. -I./../lib/popt -DLDAP_DEPRECATED  -I/usr/local/src/samba-3.5.8/source3/lib -I.. -I../source4 -D_SAMBA_BUILD_=3 -D_SAMBA_BUILD_=3
      PICFLAG    = -fPIC
      LIBS       = -lcap -lresolv -lresolv -lnsl -ldl
      LDFLAGS    = -pie -Wl,-z,relro -L./bin
      DYNEXP     = -Wl,--export-dynamic


(途中、省略)


==============================================================
MO files for pam_winbind are installed.
==============================================================
==============================================================
All MO files for Samba are installed. You can use "make uninstall"
or "make uninstallmo" to remove them.
==============================================================
[root@samba]#
無事、インストールが終わった。 

　さて、設定ファイルの smb.confを触る必要がある。
　ソースコンパイルを行なったので、特に設定ファイルを保管する
ディレクトリ指定をしなければ、 /usr/local/samba/lib　に保管される。

　設定ファイルなのだが・・・

　お得意(?)の本の丸写しなのらー (^^)

　というわけで以下の本の丸写しを行なう事にした。
　『サーバ構築の実例がわかる　Samba「実践」入門』(高橋基信:技術評論社)
smb.confの設定
   dos charset = CP932
   unix charset = UTF-8

   netbios name = <Sambaのコンピューター名>
   workgroup = <ドメイン名>

   security = user
   passdb backend = ldapsam

   os level = 33

   domain master = yes 

   local master = yes
   preferred master = yes

   domain logons = yes



ldap admin dn = cn=Manager,dc=compnay,dc=jp
ldap suffix = dc=compnay,dc=jp
ldap group suffix = ou=groups
ldap machine suffix = ou=computers
ldap user suffix = ou=users
ldap idmap suffix = ou=idmap

idmap backend = ldap:ldap://192.168.X.Y
idmap uid = 10000-19999
idmap gid = 10000-19999

ldap delete dn = yes
ldap password sync = yes

ldap ssl = no



ldapsam:editposix = yes
ldapsam:trusted =yes



(以下、細かい設定は省略)

青い枠で囲んだ部分は、定番の設定で、かつ、
マスターブラウザを自分自身にするための設定だ。

赤い枠で囲んだ部分はLDAPとの連動のための設定だ。
まさに本の丸写しの部分になる。

緑の枠は対になった設定なのだ。


　ところで上の設定で、緑で囲んだ部分がある。
　その中で「ldapsam:trusted = yes」に設定すると
以下のような事ができる。
ldapsam:trusted = no の場合(初期設定)
ldapsam:trustedオプションを行わない場合
ldapsam:trusted = yes の場合
ldapsam:trustedオプションを行なった場合
「ldapsam:trusted = no」の場合、ユーザー検索、グループ検索を行なう際
Samba上のLinuxユーザー、グループユーザーが対応しているかどうかの
確認作業を行なう。そのため、検索速度が遅くなる問題がある。

だが「ldapsam:trusted = yes」の場合、Samba上のユーザー情報、
グループ情報はLDAP上にあるという設定のため、Samba上では素通りで
LDAPへの確認を行なう。そのため、高速化ができるというわけだ。


　「ldapsam:trusted = yes」にすれば、高速化ができて
良いと思ったので

　詳しく調べず、その設定を行なった

　そして「ldapsam:editposix = yes」は対になっているようなので

　何も考えずに、その設定を行なった

　この2つに関しては、後に書いていますwinbindの話の所で
少し踏み込んで書いています。



　ところでOpenLDAPとの連動だが、OpenLDAP側の管理者パスワードを
どこかに記録しておかないと、LDAPの中のデータが検索できない。

 Sambaではsmbpasswdコマンドを使って、LDAPの管理者パスワードを
Sambaに登録している。
LDAPの管理者パスワードの登録
[root@samba]# smbpasswd -w ***********
Setting stored password for "cn=Manager,dc=company,dc=jp" in secrets.tdb
[root@samba]#
赤い部分はパスワード。中身は内緒 (^^) 

　そしてwinbinddデーモンを動かす。
winbinddデーモンを動かす
[root@samba]# pwd
/usr/local/samba/sbin
[root@samba]# ./winbindd -D
なぜ、winbinddデーモンを起動させるかについては
この時は、全く理解していませんでしたので、本の丸写しをしました。
Winbindの話を後述していますので、その部分で触れています。 


　そして「net sam provison」コマンドを使う。
　もちろん、そのコマンドの意味は知らなかったのだが
本の丸写しを行なう事にした (^^)
「net sam provison」コマンドを使う
[root@samba]# net sam provision
Checking for Domain Users group.
Adding the Domain Users group.
Unable to allocate a new gid to create Domain Users group!
Checking for Domain Admins group.
Adding the Domain Admins group.
Unable to allocate a new gid to create Domain Admins group!
Check for Administrator account.
Adding the Administrator user.
Can't create Administrator user, Domain Admins group not available!
[root@samba]#
エラーが出てしまった。 

　なんでエラーが出るねん (--;;

　原因はどこにあるのだろうか?

　PAMではないか!!

　そこでSambaをコンパイルした際にできたPAM関連のライブラリを
CentOS5.4の所定の場所に置く事にした。
PAM関連のライブラリを所定のディレクトリにコピー
[root@samba]# pwd
/usr/local/samba/lib/security
[root@samba]# ls -l
合計 2108
-rwxr-xr-x 1 root root 2059250  3月 24 15:08 pam_smbpass.so
-rwxr-xr-x 1 root root   88858  3月 24 15:08 pam_winbind.so
[root@samba]# cp pam_winbind.so /lib/security/
[root@samba]#
コンパイルで生成したPAM関連のライブラリを
所定のディレクトリにコピーしてみた。 

　それでもアカンかった (TT)

　その日は断念した。
　翌日、何気なく「Samba実践入門」のP157を開いてみた。

　そうか!　わかった!!

　Winbinddデーモンを動かす際に使っているライブラリが
所定のディレクトリにないために、正常に稼働しないようなのだ。

　なので、コンパイルして生成されたライブラリを
所定のディレクトリにコピーする事にした。
ライブラリを所定のディレクトリにコピー
[root@samba]# cd /usr/local/src/samba-3.5.8/nsswitch
[root@samba]# ls
config.m4          wb_common.c             winbind_nss_irix.c
config.mk          wb_common.o             winbind_nss_irix.h
libnss_winbind.so  wbinfo.c                winbind_nss_linux.c
libnss_wins.so     wbinfo.o                winbind_nss_linux.h
libwbclient        winbind_client.h        winbind_nss_linux.o
nsstest.c          winbind_krb5_locator.c  winbind_nss_netbsd.c
nsstest.h          winbind_krb5_locator.o  winbind_nss_netbsd.h
nsstest.m4         winbind_nss.h           winbind_nss_solaris.c
pam_winbind.c      winbind_nss_aix.c       winbind_nss_solaris.h
pam_winbind.h      winbind_nss_config.h    winbind_struct_protocol.h
pam_winbind.o      winbind_nss_freebsd.c   wins.c
tests              winbind_nss_hpux.h      wins.o
[root@samba]# cp libnss_winbind.so /lib
[root@samba]#
本の丸写しなのだが、ライブラリが保管されるディレクトリは
CentOSの場合 /lib なので、丸写しで良いのだ。 

　そして気を取りなおして、smbd、nmbdを停止させて
winbinddを起動させながら「net sam provison」を打ってみた。

　見事、成功!

　なのだ (^^)
再々度「net sam provison」を打ってみた
[root@samba]# /usr/local/samba/sbin/winbindd -D
[root@samba]# /usr/local/samba/net sam provision
Checking for Domain Users group.
Adding the Domain Users group.
Checking for Domain Admins group.
Adding the Domain Admins group.
Check for Administrator account.
Adding the Administrator user.
Checking for Guest user.
Adding the Guest user.
Checking Guest's group.
Adding the Domain Guests group.
[root@samba]#
winbindを起動させて、「net sam provision」コマンドを使った。
これによって初期ユーザーや初期グループが登録されるというのだ。 

　これで作成されるユーザーは管理者の「Administrator」と
「nobody」なのだ。

　管理者パスワードを設定する。
管理者のパスワードの設定
[root@samba]# smbpasswd administrator
New SMB password:
Retype new SMB password:
[root@samba]#
smbpasswdコマンドで管理者ユーザーの「Administrator」の
パスワードを設定する。パスワードは内緒 (^^) 

　これでドメイン参加の準備ができた。
登録されたユーザー情報を見てみる。
[root@ldap]# ldapsearch -x -LLL -D "cn=Manager,dc=company,dc=jp" -W -b "dc=company,dc=jp"
Enter LDAP Password:


(途中、省略)


dn: sambaDomainName=EBISU,dc=company,dc=jp
sambaDomainName: EBISU
sambaSID: S-1-5-21-1484220470-359798937-1990557657
sambaAlgorithmicRidBase: 1000
objectClass: sambaDomain
sambaNextUserRid: 1000
sambaMinPwdLength: 5
sambaPwdHistoryLength: 0
sambaLogonToChgPwd: 0
sambaMaxPwdAge: -1
sambaMinPwdAge: 0
sambaLockoutDuration: 30
sambaLockoutObservationWindow: 30
sambaLockoutThreshold: 0
sambaForceLogoff: -1
sambaRefuseMachinePwdChange: 0
sambaNextRid: 1004



dn: cn=domusers,ou=groups,dc=company,dc=jp
objectClass: posixGroup
objectClass: sambaGroupMapping
cn: domusers
displayName: Domain Users
gidNumber: 10000
sambaSID: S-1-5-21-1484220470-359798937-1990557657-513
sambaGroupType: 2



dn: cn=domadmins,ou=groups,dc=company,dc=jp
objectClass: posixGroup
objectClass: sambaGroupMapping
cn: domadmins
displayName: Domain Admins
gidNumber: 10001
sambaSID: S-1-5-21-1484220470-359798937-1990557657-512
sambaGroupType: 2



dn: uid=Administrator,ou=users,dc=company,dc=jp
objectClass: account
objectClass: posixAccount
objectClass: sambaSamAccount
uid: Administrator
cn: Administrator
displayName: Administrator
uidNumber: 10000
gidNumber: 10001
homeDirectory: /home/EBISU/Administrator
loginShell: /bin/bash
sambaSID: S-1-5-21-1484220470-359798937-1990557657-500
sambaNTPassword: EEEF2F586364E8152495295A4036FF47
sambaPasswordHistory: 00000000000000000000000000000000000000000000000000000000
 00000000
sambaAcctFlags: [U          ]
sambaPwdLastSet: 1301366741
userPassword:: e1NTSEF9a3JZMkJpcXRLR0cxdjZVZGVROHR6SHlOd1NMRmJCZWQ=



dn: uid=nobody,ou=users,dc=company,dc=jp
objectClass: account
objectClass: posixAccount
objectClass: sambaSamAccount
uid: nobody
cn: nobody
displayName: nobody
uidNumber: 99
gidNumber: 99
homeDirectory: /
loginShell: /sbin/nologin
sambaSID: S-1-5-21-1484220470-359798937-1990557657-501
sambaAcctFlags: [DU         ]



dn: cn=domguests,ou=groups,dc=company,dc=jp
objectClass: posixGroup
objectClass: sambaGroupMapping
cn: domguests
displayName: Domain Guests
gidNumber: 99
sambaSID: S-1-5-21-1484220470-359798937-1990557657-514
sambaGroupType: 2
青い枠が各グループのエントリで、赤い部分は各ユーザーのエントリだ。
「net sam provision」コマンドで登録した
初期ユーザー、初期グループがある。 

　これで準備が整った。




ユーザー登録


　普段なら「小野真弓」を使うのだが、今回は、別の愛する
「宮地真理子」の名前を使ってみる (^^)


　ユーザー登録を行なう場合、Windowsのツールを使えば便利だ。
　「システム奮闘記:その91」(SambaでPDC構築)に書いている事の復習を書きます。

  ツールは、Windows2000/XPで動く。
　だが、私が触った時は、Windows2000でしか使えないと勘違いしたため
わざわざWindows2000をインストールしてツールを使ったため
それを使っている。
Windows2000の画面
Windows2000の場面

　管理ツールは以下の所からダウンロードする。
　Windows NT Workstation 4.0 用の Windows NT サーバー ツール

　(2011/4/12の時点では、ダウンロード可能)


　早速、ダウンロードしたツールをインストールしてみた。
ツールをインストールした後の画面
ツールをインストールした後の画面
ユーザー管理のアイコン(茶色で囲んだ部分)と
サーバー管理のアイコンがある。 

　そしてユーザー登録だ。
ユーザー登録
ユーザー登録
「miyachi」で登録する様子。 

　ユーザー登録が終了する。
ユーザー登録終了後
無事「miyachi」が登録されている。 

　さて、愛する宮地真理子の「miyachi」が登録できたので
実際に、「miyachi」でログオンしてみる。
「miyachi」でログオン(WindowsXP)
「miyachi」でログイン(WindowsXP)

　すると・・・

　ログオン成功 (^^)

　なのだ。
ログオンした画面
WindowsXPでログインした画面



　ところで、OpenLDAPサーバーでは、ユーザー情報が
どのように保管されているのか、見てみる事にした。
ユーザー情報を見てみる
[root@LDAP]# ldapsearch -x -LLL -D "cn=Manager,dc=company,dc=jp" -W -b "dc=company,dc=jp"
Enter LDAP Password:

(途中、省略)


dn: uid=miyachi,ou=users,dc=company,dc=jp
uid: miyachi
sambaSID: S-1-5-21-1484220470-359798937-1990557657-1003
objectClass: sambaSamAccount
objectClass: account
objectClass: posixAccount
cn: miyachi
uidNumber: 10003
gidNumber: 10000
homeDirectory: /home/EBISU/miyachi
sambaKickoffTime: 0
sambaPasswordHistory: 00000000000000000000000000000000000000000000000000000000
 00000000
sambaAcctFlags: [U          ]
loginShell: /bin/bash
sambaNTPassword: FA2CED9BF16DD899BFE31E9ED67B5774
sambaPwdLastSet: 1301385455
userPassword:: e1NTSEF9dWRFVVpybWVFTCtJb0JYR1dLNnlyZzhVNEFERDBRRVI=

赤い部分はWindowsの暗号化パスワード。
青い部分はLinuxの暗号化パスワード。

他にもLinuxにログインした時のディレクトリの指定、
シェルの種類の設定などがある。
WindowsとLinuxが共存できる形になっている。




コンピューターの登録とデータの中身


　WindowsXP/Vista/7が、Sambaドメインに参加する場合
管理者ID、パスワードだけでなく、コンピューター名の登録も必要だ。

　だが、特にコンピューター名を登録する必要はないのだ。
　ドメインに参加する際に、自動的に登録される仕組みになっているからだ。

　ところで、OpenLDAPサーバーには、どんな形でコンピューター名が
登録されているのか、見てみる事にした。
コンピューター名の登録の情報
[root@LDAP]# ldapsearch -x -LLL -D "cn=Manager,dc=company,dc=jp" -W -b "dc=company,dc=jp"
Enter LDAP Password:

(途中、省略)


dn: uid=suga-pc$,ou=computers,dc=company,dc=jp
uid: suga-pc$
sambaSID: S-1-5-21-1484220470-359798937-1990557657-1001
sambaAcctFlags: [W          ]
objectClass: sambaSamAccount
objectClass: account
objectClass: posixAccount
cn: suga-pc$
uidNumber: 10001
gidNumber: 10000
homeDirectory: /home/EBISU/SMB_workstations_home
loginShell: /bin/false
sambaNTPassword: 7549F757938307E01891E9DA5F307F97
sambaPwdLastSet: 1301367567


(以下、省略)
コンピューター名は「suga-pc」なのだ。
Sambaで登録される際は、コンピューター名の後ろに「$」が付く。 
　

　全てのユーザー情報とコンピューター情報がOpenLDAPの
データベースの中に格納されるのだ。



Linuxの認証 (OpenLDAPのクライアントの設定)


　Samba + OpenLDAPの組み合わせを使うと、WindowsのID管理だけでなく
LinuxのIDも、一緒に管理できる利点がある。

　今度は、Linuxのユーザー認証がOpenLDAPで行なえるように
クライアントの設定する
OpenLDAPを使ったLinuxのユーザー認証部分
OpenLDAPを使ったLinuxのユーザー認証

　既に、システム奮闘記:その90」(OpenLDAP入門)でクライアントの
設定を行なっただけに、簡単にできると思った。


　だが、思わぬ落とし穴があったのだ。
　それは私が・・・

　OpenLDAPのクライアントの設定を詳しく知らない!!

　だった。
　そのため七転八倒する羽目になった。


　さて、あるLinuxマシンをOpenLDAPのクライアントにするため
以下の設定を行なった。クライアントはCentOS5.4なのだ。

　設定は以下の本の丸写しを行なった。
　「CentOS5で作るネットワークサーバー構築ガイド」
　(サーバー構築研究会:秀和システム)

　なので変更したのは以下の2つのファイルのみだった。

　まずは/etc/nsswitch.confファイルを触る。
/etc/nsswitch.confファイルを触る
変更前

passwd:     files
shadow:     files
group:      files
変更後

passwd:     files ldap
shadow:     files
group:      files ldap



　そして、/etc/ldap.confを触る必要がある。
/etc/ldap.confを触る
# Your LDAP server. Must be resolvable without using LDAP.
# Multiple hosts may be specified, each separated by a 
# space. How long nss_ldap takes to failover depends on
# whether your LDAP client library supports configurable
# network or connect timeouts (see bind_timelimit).
host 192.168.X.Y

# The distinguished name of the search base.
base dc=company,dc=jp
赤い部分はLDAPサーバーのIPアドレスを記述する。
青い部分はベースDNを記述する。 

　これで完了と思った。

　だが・・・

　認証してくれへん (TT)

　だった。
ログイン(認証)失敗
[suga@linux]$ telnet 192.168.X.Y
Trying 192.168.1.229...
Connected to 192.168.X.Y (192.168.X.Y).
Escape character is '^]'.
CentOS release 5.4 (Final)
Kernel 2.6.18-164.el5 on an i686
login: miyachi
Password: 
Login incorrect

login:
ログインしてくれない状態・・・ (--;;
もちろん、この状態だと ftpも使えない。 

　原因がさっぱりわからない。

　何せ「システム奮闘記:その90」(OpenLDAPの設定入門)にも書いてあるのだが
OpenLDAPのクライアントの設定を行なう際も本の丸写しだった。

　そのため設定ファイルを眺めたりしても・・・

　何がどう悪いのか見当もつかへん (--;;

　だった。


　ふと思った。
　OpenLDAPのサーバー設定時に設けた接続制限が原因かも。
　そこで接続制限を外す事にした。
OpenLDAPのサーバー設定ファイル(sladp.conf)
接続制限の設定している状態
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
# access to *
#	by self write
#	by users read
#	by anonymous auth

access to attrs=userPassword,shadowLastChange
        by  anonymous auth
        by  dn="cn=Manager,dc=company,dc=jp" write
        by  self write
        by  * none

access to attrs=sambaLMPassword,sambaNTPassword
        by  dn="cn=Manager,dc=company,dc=jp" write
        by  * none


access to *
        by  dn="cn=Manager,dc=company,dc=jp" write
        by  * read
変更後
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
# access to *
#	by self write
#	by users read
#	by anonymous auth
接続制限を外したので、これでいけるかなぁと思った。 

　だが・・・

　これでも認証できへん (TT)

　だった。
ログイン(認証)失敗
[suga@linux]$ telnet 192.168.X.Y
Trying 192.168.1.229...
Connected to 192.168.X.Y (192.168.X.Y).
Escape character is '^]'.
CentOS release 5.4 (Final)
Kernel 2.6.18-164.el5 on an i686
login: miyachi
Password: 
Login incorrect

login:
まだログインさせてもらえない状態・・・ (--;; 

　色々考えた末に、次の事を思いついた。
　サーバー側に設定した

　LDIFの初期設定ファイルに問題があるのでは?
今回、Samba + LDAPのために作ったinit.ldifファイル
(「Samba実践入門」の丸写しとも言う)
dn: dc=company,dc=jp
objectClass: top
objectClass: dcObject
objectClass: organization
o: myorganization
dc: company


dn: ou=users,dc=company,dc=jp
objectClass: top
objectClass: organizationalUnit
ou: users



dn: ou=groups,dc=company,dc=jp
objectClass: top
objectClass: organizationalUnit
ou: groups


dn: ou=idmap,dc=company,dc=jp
objectClass: top
objectClass: organizationalUnit
ou: idmap


dn: ou=computers,dc=company,dc=jp
objectClass: top
objectClass: organizationalUnit
ou: computers
OpenLDAPの設定のために作ったinit.ldifファイル
(「CentOS5で作るネットワークサーバー構築ガイド」の丸写しとも言う)
詳しくは「システム奮闘記:その90」をご覧ください。 
dn: dc=company,dc=jp
objectClass: dcObject
objectClass: organization
o: myorganization
dc: company
 
dn: cn=Manager,dc=company,dc=jp
objectClass: organizationalRole
cn: Manager
 

dn: ou=People,dc=company,dc=jp
objectClass: organizationalUnit
ou: People



dn: ou=Group,dc=company,dc=jp
objectClass: organizationalUnit
ou: Group


青い枠はユーザー情報を登録するエントリ部分で
赤い枠はグループ情報を登録するエントリ部分だ。

属性の「ou」の部分を見てみる。
ユーザー名の「ou」が「users」と「People」との違いがあり
グループ名の「ou」では「groups」と「Group」の違いがある。


　ふと思った。

　「ou」を同じにすればエエかも!

　そこで今回のSamba +OpenLDAPの設定で使うユーザー登録などの
LDIFファイルを以下のように書き換えて使う事にした。
OpenLDAPサーバーで使うinit.ldifファイルを
以下のように属性「ou」を書き換えて使ってみる
dn: dc=company,dc=jp
objectClass: top
objectClass: dcObject
objectClass: organization
o: myorganization
dc: company


dn: ou=People,dc=company,dc=jp
objectClass: top
objectClass: organizationalUnit
ou: People



dn: ou=Group,dc=company,dc=jp
objectClass: top
objectClass: organizationalUnit
ou: Group


dn: ou=idmap,dc=company,dc=jp
objectClass: top
objectClass: organizationalUnit
ou: idmap


dn: ou=computers,dc=company,dc=jp
objectClass: top
objectClass: organizationalUnit
ou: computers
ユーザー情報のエントリ部分の青い枠のouを「People」に
グループ情報のエントリ部分の赤い枠のouを「Group」に書き換えた。 

　そしてSambaサーバーのsmb.confの設定も以下のように書き換えた。
smb.confの設定(一部抜粋)
書き換え前
ldap admin dn = cn=Manager,dc=company,dc=jp
ldap suffix = dc=company,dc=jp
ldap group suffix = ou=groups
ldap machine suffix = ou=computers
ldap user suffix = ou=users
ldap ssl = no
書き換え後
ldap admin dn = cn=Manager,dc=compnay,dc=jp
ldap suffix = dc=company,dc=jp
ldap group suffix = ou=Group
ldap machine suffix = ou=computers
ldap user suffix = ou=People
ldap ssl = no


　そして認証を行なってみたのだが

　それでもアカン (TT)
ログイン(認証)失敗
[suga@linux]$ telnet 192.168.X.Y
Trying 192.168.1.229...
Connected to 192.168.X.Y (192.168.X.Y).
Escape character is '^]'.
CentOS release 5.4 (Final)
Kernel 2.6.18-164.el5 on an i686
login: miyachi
Password: 
Login incorrect

login:
まだまだログインさせてもらえない状態・・・ (--;; 

　全くわからない。途方に暮れる私。
　でも、ネットで調べていくと、ある事に気づく。

　PAMの設定してへんやん!


　そこでPAMの設定を行なうのだが・・・

　PAMの設定方法を忘れてもうた (--;;

　「システム奮闘記:その47」(PAMの設定入門)を書いたのだが、2006年の話だ。
　それから5年経つと、PAMの話は忘却の彼方なのだ。

　なので自分が書いた物を読みながら復習する事にした。
　自慢ではないが、おそらくPAMの日本語の説明で、
これよりも詳しい内容の記述はないと思う (^^)V
PAMを使った認証の仕組み
PAMを使った認証の仕組み
telnetやftpなどで接続する場合、PAMを介する。
そして各種認証のためのライブラリを経由して
認証データベースへ参照する仕組みなのだ。


　OpenLDAPのクライアントとして動かそうとしたLinuxマシンには
OpenLDAPでの認証を行なう設定はしていないから
認証を行なおうとしても、認証ができないのは当然なのだ。

　そこで、PAMの部分でsystem-authファイルの書き換えを行なう。
/etc/pam.d/system-auth の記述変更
書き換え前
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        required      pam_deny.so

account     required      pam_unix.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
書き換え後
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_ldap.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        required      pam_deny.so

account     required      pam_unix.so
account     sufficient    pam_ldap.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3
password    sufficient    pam_ldap.so
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so



　これで再度、認証を行なってみる。すると・・・

　無事、成功 (^^)V

　だった。
ログイン(認証)成功
[suga@linux]$ telnet 192.168.X.Y
Trying 192.168.1.229...
Connected to 192.168.X.Y (192.168.X.Y).
Escape character is '^]'.
CentOS release 5.4 (Final)
Kernel 2.6.18-164.el5 on an i686
login: miyachi
Password: 
Last login: Wed Mar 30 14:23:26 from machine
-bash-3.2$
ようやくログインできた (^^) 

　ここで思った。

　原因はPAMの設定だけだろうか?

　そこで、本の丸写しの設定に戻していこうと思った。

　まずは接続制限の設定から。
sladp.confファイル (一部抜粋)
接続制限をかけていない場合
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
# access to *
#	by self write
#	by users read
#	by anonymous auth
本の丸写し通り接続制限をかけた
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
# access to *
#	by self write
#	by users read
#	by anonymous auth

access to attrs=userPassword,shadowLastChange
        by  anonymous auth
        by  dn="cn=Manager,dc=company,dc=jp" write
        by  self write
        by  * none

access to attrs=sambaLMPassword,sambaNTPassword
        by  dn="cn=Manager,dc=company,dc=jp" write
        by  * none


access to *
        by  dn="cn=Manager,dc=company,dc=jp" write
        by  * read


　OpenLDAPのクライアントのLinuxマシンにログインしてみると・・・

　問題なくログインできた!

　接続制限が問題ではなかった。

　それも、そのはず。
　クライアント側の設定で、閲覧なら可能だからだ。


　次に、初期スキーマのLDIFの設定を本の丸写しに戻してみた。
今回、Samba + LDAPのために作ったinit.ldifファイル
(「Samba実践入門」の丸写しとも言う)
dn: dc=company,dc=jp
objectClass: top
objectClass: dcObject
objectClass: organization
o: myorganization
dc: company


dn: ou=users,dc=company,dc=jp
objectClass: top
objectClass: organizationalUnit
ou: users



dn: ou=groups,dc=company,dc=jp
objectClass: top
objectClass: organizationalUnit
ou: groups


dn: ou=idmap,dc=company,dc=jp
objectClass: top
objectClass: organizationalUnit
ou: idmap


dn: ou=computers,dc=company,dc=jp
objectClass: top
objectClass: organizationalUnit
ou: computers


　すると・・・

　ログインできへん!!

　だった。

 LDIFファイルの設定で、安易に属性「ou」の値を設定すると認証ができなくと思った。
　なので、この時は、ユーザーDNの場合は「ou=People」であり
グループDNの場合は「ou=Group」にする必要があると思った (注意)
実際は「ou=XXX」は関係ない
ここまでの流れにおいて、ユーザーエントリのLDIFファイルで
本の丸写しで「ou=People」を「ou=users」にしたため
LDAPのクライアントのLinuxにおいて認証できなかったと思った。

実際には「ou=XXX」(XXXは名称)は、何でも良いのだ。


　さて、「ou=XXX」の値を安易に設定できないと思った私。
　だが、人間、思い込むと、そのまま、まっすぐ進んでしまう。


　ユーザーエントリのLDIFファイル作成の時、属性「ou」の値は
「ou=People」だという証拠探しに走る事になった。

　さて、OpenLDAPのクライアントの設定ファイル(/etc/ldap.conf)を
何気なく見ていた時だった。
　それを眺めてみると、ある事に気づいた。
/etc/ldap.conf の初期状態の一部抜粋
(CentOS5系)
# RFC2307bis naming contexts
# Syntax:
# nss_base_XXX		base?scope?filter
# where scope is {base,one,sub}
# and filter is a filter to be &'d with the
# default filter.
# You can omit the suffix eg:
# nss_base_passwd	ou=People,
# to append the default base DN but this
# may incur a small performance impact.
#nss_base_passwd　　　　ou=People,dc=example,dc=com?one
#nss_base_shadow	ou=People,dc=example,dc=com?one
#nss_base_group		ou=Group,dc=example,dc=com?one
#nss_base_hosts		ou=Hosts,dc=example,dc=com?one
#nss_base_services	ou=Services,dc=example,dc=com?one
#nss_base_networks	ou=Networks,dc=example,dc=com?one
#nss_base_protocols	ou=Protocols,dc=example,dc=com?one
#nss_base_rpc		ou=Rpc,dc=example,dc=com?one
#nss_base_ethers	ou=Ethers,dc=example,dc=com?one
#nss_base_netmasks	ou=Networks,dc=example,dc=com?ne
#nss_base_bootparams	ou=Ethers,dc=example,dc=com?one
#nss_base_aliases	ou=Aliases,dc=example,dc=com?one
#nss_base_netgroup	ou=Netgroup,dc=example,dc=com?one
なんだかLDIFファイルを記述する時の定義のような部分だ。
RFC2307bisって一体何だろうか?

赤い部分がユーザーエントリのDNに関する部分と思い
青い部分がグループエントリのDNに関する部分だと思った。 

　これを見て思った。
　ユーザーDNやグループDNにおいて、属性「ou」の値は・・・

　ここで定義しているのか!


　このファイルを触れば、ユーザーエントリのDNで「ou=users」を
グループエントリのDNで「ou=groups」でも認識できると思った。

　そこで、まずはLDAPのクライアント側の/etc/ldap.confファイルを
以下のように書き換えた。
/etc/ldap.conf の初期状態の一部抜粋
(CentOS5系)
# RFC2307bis naming contexts
# Syntax:
# nss_base_XXX		base?scope?filter
# where scope is {base,one,sub}
# and filter is a filter to be &'d with the
# default filter.
# You can omit the suffix eg:
# nss_base_passwd	ou=People,
# to append the default base DN but this
# may incur a small performance impact.
nss_base_passwd　　　 　ou=users,dc=company,dc=jp
#nss_base_shadow	ou=People,dc=example,dc=com?one
nss_base_group		ou=groups,dc=company,dc=jp
#nss_base_hosts		ou=Hosts,dc=example,dc=com?one
#nss_base_services	ou=Services,dc=example,dc=com?one
#nss_base_networks	ou=Networks,dc=example,dc=com?one
#nss_base_protocols	ou=Protocols,dc=example,dc=com?one
#nss_base_rpc		ou=Rpc,dc=example,dc=com?one
#nss_base_ethers	ou=Ethers,dc=example,dc=com?one
#nss_base_netmasks	ou=Networks,dc=example,dc=com?ne
#nss_base_bootparams	ou=Ethers,dc=example,dc=com?one
#nss_base_aliases	ou=Aliases,dc=example,dc=com?one
#nss_base_netgroup	ou=Netgroup,dc=example,dc=com?one
赤い部分は「ou=users」でも認識できるようにと思い行なった設定
青い部分は「ou=groups」でも認識できるようにと思い行なった設定 

　なので、OpenLDAPのサーバー側で以下のinit.ldifファイルを用意し
登録を行なってみる。
init.ldifファイル
dn: dc=company,dc=jp
objectClass: top
objectClass: dcObject
objectClass: organization
o: myorganization
dc: company

dn: ou=users,dc=company,dc=jp
objectClass: top
objectClass: organizationalUnit
ou: users

dn: ou=groups,dc=company,dc=jp
objectClass: top
objectClass: organizationalUnit
ou: groups


　ユーザー登録を行なってみた。


　そして、早速、認証を行なってみるが・・・
ログインの様子
[suga@client]$ telnet 192.168.X.Y
Trying 192.168.X.Y...
Connected to 192.168.X.Y (192.168.X.Y).
Escape character is '^]'.
CentOS release 5.4 (Final)
Kernel 2.6.18-164.el5 on an i686
login: suga
Password: 
Login incorrect

login: 


　全然、アカンやん・・・ (--;;
この時、ダメだった本当の原因は
実は、別のLinuxマシンで実験していたため大事な事を忘れていた。
この時、認証ができなかった本当の原因はPAMの設定を
忘れていたためだった。それに気づかなかった。
でも、この後に書いていますように、知らなかった事が出てきた。 

　PAMの設定し忘れなんぞ、知る由もなしだった私。
　そこで検索サイトを駆使して調べてみる事にした。
　すると以下のサイトを発見。

　nbkf205の日記:[OpenLDAP]CentOS5にOpenLDAPをインストール


　思わず・・・

　こんなファイルを触るのか！

　だった。

　CentOS5系の場合、/usr/share/openldap/migration/migrate_common.ph
なのだ。

　そのファイルを見てみる事にした。
/usr/share/openldap/migration/migrate_common.ph
(一部抜粋: CentOS5系の場合)
$NETINFOBRIDGE = (-x "/usr/sbin/mkslapdconf");

if ($NETINFOBRIDGE) {
        $NAMINGCONTEXT{'aliases'}           = "cn=aliases";
        $NAMINGCONTEXT{'fstab'}             = "cn=mounts";
        $NAMINGCONTEXT{'passwd'}            = "cn=users";
        $NAMINGCONTEXT{'netgroup_byuser'}   = "cn=netgroup.byuser";
        $NAMINGCONTEXT{'netgroup_byhost'}   = "cn=netgroup.byhost";
        $NAMINGCONTEXT{'group'}             = "cn=groups";
        $NAMINGCONTEXT{'netgroup'}          = "cn=netgroup";
        $NAMINGCONTEXT{'hosts'}             = "cn=machines";
        $NAMINGCONTEXT{'networks'}          = "cn=networks";
        $NAMINGCONTEXT{'protocols'}         = "cn=protocols";
        $NAMINGCONTEXT{'rpc'}               = "cn=rpcs";
        $NAMINGCONTEXT{'services'}          = "cn=services";
} else {
        $NAMINGCONTEXT{'aliases'}           = "ou=Aliases";
        $NAMINGCONTEXT{'fstab'}             = "ou=Mounts";
        $NAMINGCONTEXT{'passwd'}            = "ou=People";
        $NAMINGCONTEXT{'netgroup_byuser'}   = "nisMapName=netgroup.byuser";
        $NAMINGCONTEXT{'netgroup_byhost'}   = "nisMapName=netgroup.byhost";
        $NAMINGCONTEXT{'group'}             = "ou=Group";
        $NAMINGCONTEXT{'netgroup'}          = "ou=Netgroup";
        $NAMINGCONTEXT{'hosts'}             = "ou=Hosts";
        $NAMINGCONTEXT{'networks'}          = "ou=Networks";
        $NAMINGCONTEXT{'protocols'}         = "ou=Protocols";
        $NAMINGCONTEXT{'rpc'}               = "ou=Rpc";
        $NAMINGCONTEXT{'services'}          = "ou=Services";
}

何かの条件でユーザー登録の部分のエントリで
「ou=users」になるのか「ou=People」になるのかが決まる。

同様にグループエントリの部分でも「ou=groups」なのか
「ou=Group」になるのかも決まる。


　深追いしたくなるのだが・・・

　とても深追いする気力があらへん・・・

　なのだ (--;;

　直感的なのだが、何か、とんでもない物が出てきそうな気がした。
　そして、調べ出したらパンドラの箱を開けるような予感がした。

　そのため、保留にする事にした。
　いずれは、この辺りを掘り下げた内容を取り上げたいと思います。



　さてさて、立往生した私。
　だが、ふと思った。

　PAMの設定をしてへんわ (^^;;

　そこでPAMの設定を行なった所、認証が問題なくできた。
ログインの様子
[suga@client]$ telnet 192.168.X.Y
Trying 192.168.X.Y...
Connected to 192.168.X.Y (192.168.X.Y).
Escape character is '^]'.
CentOS release 5.4 (Final)
Kernel 2.6.18-164.el5 on an i686
login: suga
Password: 
Last login: Tue Apr 19 21:54:38 from 192.168.X.Z
[suga@ldap]$ 


　問題なくログインができた。

　はたしてOpenLDAPのクライアント側の/etc/ldap.confを
書き換えたお蔭だろうか？
　そこで、クライアント側の/etc/ldap.confの記述を
元に戻してみる事にした。
/etc/ldap.conf の初期状態の一部抜粋
(CentOS5系)
# RFC2307bis naming contexts
# Syntax:
# nss_base_XXX		base?scope?filter
# where scope is {base,one,sub}
# and filter is a filter to be &'d with the
# default filter.
# You can omit the suffix eg:
# nss_base_passwd	ou=People,
# to append the default base DN but this
# may incur a small performance impact.
#nss_base_passwd　　　　ou=People,dc=example,dc=com?one
#nss_base_shadow	ou=People,dc=example,dc=com?one
#nss_base_group		ou=Group,dc=example,dc=com?one
#nss_base_hosts		ou=Hosts,dc=example,dc=com?one
#nss_base_services	ou=Services,dc=example,dc=com?one
#nss_base_networks	ou=Networks,dc=example,dc=com?one
#nss_base_protocols	ou=Protocols,dc=example,dc=com?one
#nss_base_rpc		ou=Rpc,dc=example,dc=com?one
#nss_base_ethers	ou=Ethers,dc=example,dc=com?one
#nss_base_netmasks	ou=Networks,dc=example,dc=com?ne
#nss_base_bootparams	ou=Ethers,dc=example,dc=com?one
#nss_base_aliases	ou=Aliases,dc=example,dc=com?one
#nss_base_netgroup	ou=Netgroup,dc=example,dc=com?one
これで、LDAPのクライアントが認証できなくなったら
このファイルの、この部分が原因だと思う。 

　だが・・・

　問題なく認証できる！

　だった。

　色々、試してみた。

　ユーザーエントリのDNで属性「ou」を「ou=People」にする
必要もなければ、グループエントリのDNも「ou=Group」にする必要もない。

　任意で決められる名称なのだ。


　なので、本に書いてあった、ユーザーエントリのDNで
「ou=users」でも、グループエントリのDNを「ou=groups」にしても
全く問題ないのだ。

　そのため、エラーが出た原因がわからない。
　記述する際の綴り間違いなどといった単純な間違いであって欲しい。
　でないと・・・

　ドツボにハマっていくのらー!! (TT)

　結局、原因がわからないままになった。
　だが、これ以上、調べていくには、相当な知識が要求されるので
今回は、ここで断念する事にした。




Winbindについて


　Samba + OpenDALを実現させる上で、Winbindを使うのが便利になる。
　なぜ、Winbindを使うのか。そこでwinbindの話を簡単に触れたいと思います。


　Winbindは、Sambaの機能の一部で、Sambaサーバーが
NTドメイン(Sambaドメイン)やADドメインに参加した場合、
ドメインコントローラーに登録されたユーザー情報に基づいて
Linux(UNIX)のユーザー情報を自動生成するのだ。

　図式化すると以下のようになる。
Winbindとは何か?
winbindとは
Sambaマシンを、ADドメイン(もしくは、NT/Sambaドメイン)に参加させた場合
ドメインコントローラーにあるユーザー、グループ情報に基づいて
SambaマシンのLinux(UNIX)ユーザー情報を自動生成するための物だ。


　この機能を使う事によって、どんな利点があるのか。
　まずは、復習として、Samba単体の時の認証を見てみる事にする。
Sambaのユーザー認証の概略
Sambaのユーザー認証の概略
Linuxのユーザーとは独立した形で、Samba独自でユーザー管理をしている。
Sambaの独自データベースに、Windowsの方法で暗号化したパスワードを
保管しているのだ。

WindowsがSambaサーバーへ接続認証する際、/etc/passwdファイルを使って
該当のユーザーの有無の確認だけ行なわれる。
登録されているユーザーであれば、Sambaユーザーのデータベースを見に行き
暗号化パスワードの突き合わせを行なうのだ。


　LinuxユーザーとSambaユーザーの2つを登録する必要がある。

　ところで、SambaマシンをADドメイン(もしくはNT/Sambaドメイン)に登録した上で
Winbindを使うと、以下のような、すっきりした事ができるのだ。
Winbindを導入すると
winbindを使うと、認証の仕組みが変わる
Sambaユーザー認証は、ドメインコントローラー内のデータベース(SAM)を
参照して行なわれる。

そして、Sambaマシン上のLinuxユーザーとの対応づけなのだが
なんとドメインコントローラーのデータベース(SAM)のユーザー情報を活用し
Sambaマシン上のWinbindがLinuxユーザー情報を自動生成するのだ。
それにより、Linuxユーザーとの対応づけが可能になるだけでなく
SambaマシンへLinuxユーザーとしてもログイン可能になるのだ。

ADドメイン(NT/Sambaドメイン)に参加する事で、Sambaマシン上では
Linuxユーザーの登録が不要になる。ドメインコントローラー上ので
ユーザー情報の一元管理ができるというわけなのだ。


　実際に、SambaドメインにSambaマシンを参加させた実験を
行なってみたのだが、結構、話が長くなるので、割愛します m(--)m
　割愛する理由なのだが・・・

　システム奮闘記を書くのも大変なのらー!

　小野真弓や宮地真理子に「がんばってね♥」と励まされ
腕組んでデートのご褒美があれば、目の色変えて頑張るのだが
そうでないため。息切れを起こしてしまうのらー!! (--;;

　というわけで、別の機会に書くことにします。
Samba4が正式に出た後が
Winbindの話を書く機会かも
現在、開発が進められているSamba4がある。
ActiveDirectoryのドメインコントローラーになれるのが注目すべき所なのだ。

ところで、OSC2011/Tokyo Springの「Samba最新動向&座談会」で
今の所、Samba4は、Sambaなのにファイルサーバーをサポートしていない
という衝撃的な事を聞いた。

もし、Samba4の正式版が公開された時に、ファイルサーバー機能が使えない場合
ファイルサーバー機能は、Samba3のマシンで補う事になる。
そのSamba3マシンを、ADドメインに参加させた時に、Winbindを使う事になる。

嫌でも、Winbindの話から逃げられないだけに、この時に、触れたいと思います。



　だが、これだけ知っても次の疑問は残ったままだ。

　なんでSamba + OpenLDAPにwinbindが必要やねん?

　この時点では、Samba + OpenLDAPと、ADドメイン(NT/Sambaドメイン)の
ドメインコントローラーのデータベース(SAM)のユーザー情報から
Linuxユーザーの自動生成とが、まだ結び付かない。

　なので、この疑問を解く事にした。


　調べていくと、なんとなく見えてきた。
　どうやら・・・

　ユーザー登録時にOpenLDAPにLinuxユーザーを登録するために

　uidとgidを自動生成するため

　にwinbindが活用されているようだ。


　ところで、Samba単独で動かす場合、ユーザー登録する場合、
Sambaユーザーを登録と同時に、Linux(UNIX)ユーザーの登録も必要だった。
　Linuxユーザーの登録の手間を省くため、Sambaの設定ファイル(smb.conf)に
以下の設定を行なう必要があった。
Sambaを単独で動かす場合
Linuxユーザーを自動生成するための設定(smb.conf)
#pdbeditコマンドの際、Linux(UNIX)ユーザーの
#登録・削除を同時に行なうための設定


   add user script = /usr/sbin/useradd %u
   add group script = /usr/sbin/groupadd %g
   add user to group script = /usr/bin/gpasswd -a %u %g
   add machine script = /usr/sbin/useradd -d /dev/null -s /bin/false %u

   delete user script = /usr/sbin/userdel %u
   delete user from group script = /usr/bin/gpasswd -d %u %g
   delete group script = /usr/sbin/groupdel %g


#ユーザー登録・削除とパスワードの同期

   unix password sync = yes
   pam password change = yes
Samba単独で動かす場合、Sambaユーザー登録と同時に
Linuxユーザーの登録もできるようするため
上の設定を行なう必要があった。 

　だが、今回、Samba + OpenLDAPの設定で本の丸写しをしたが、
上の設定は行なわなかった。
　Sambaマシン上でもLinuxユーザーの登録も行なわなかった。

　なのに、Sambaへの認証は問題なくできている。


　そこで、踏み込んで調べていく事にした。

　さて、Samba + OpenLDAPの組み合わせで運用する際に
以下の設定を行なう場合、winbindの起動が欠かせなくなる。

　ところで・・・

　editposix ldapsamって何?

　色々、検索して調べてみたが、どうも釈然としない。

　「日本男児たる者、英語なんか読むもんか！」と思いながらも
仕方がないので、嫌いな英語を読む事にした。

　Ldapsam Editposix

　smb.confの解説の英語版

　読む気が起こらへん (--;;

　でも、なんとか日本語の情報を見つけたので、そっちを読む事にした。

　smb.confの解説の日本語版(Samba3.5)

　ようやく意味がわかった。
ldapsam:editposixのオプションの役目
LDAPでユーザーやグループ管理を行なうためのオプションで
これを使う事で、特別なスクリプトなどを組む必要がなくなる。

ユーザーとグループの作成時に、uid、gid(ユーザー番号と、グループ番号)を
割り当てるため、winbindを動かす必要がある。


要するに、Samba上でユーザーやグループの登録・変更した場合
Linux(UNIX)のユーザー情報、グループ情報をLDAP上に
登録・変更するためのオプションなのだ。


　このオプションができる前は、外部ツールの「smbldap-toos」を
使っていたと言う。
　だが、Samba-3.0.23からは「ldapsam:editposix」オプションが
使えるようになったため、過去の物になった。


　ここでSamba + OpenLDAPの際に、Winbindを使う理由がわかったのだ。

　ユーザー登録時に、OpenLDAP上に、Linuxユーザーとグループ登録するため

　uidとgidを自動生成している

　のだ。

　uidとgidの値の範囲は、以下のように設定するのだ。
uidとgidを自動生成する際の値の範囲(smb.conf)
idmap uid = 10000-19999
idmap gid = 10000-19999
uidを割り当てる際の値の範囲は「10000〜19999」なのだ。
そしてgidを割り当てる際の値の範囲は「10000〜19999」なのだ。 

　そして「ldapsam:editposix = yes」と対になって使うオプションが
「ldapsam:trusted = yes」なのだ。

　なぜ、この2つが対になるのか。

　Sambaに認証を行なう際、Sambaユーザーで認証を行なうと同時に
Linuxユーザーの対応付けも行なっている。

　もう1度、「ldapsam:trusted」の役目を見てみる。

　もし、「ldapsam:trusted = no」の場合、Samba上にある
Linuxユーザーとの対応づけを確認する必要がある。
ldapsam:trusted = no の場合(初期設定)
ldapsam:trustedオプションを行わない場合
この場合、Sambaユーザーの認証はLDAPのデータを使って行なうのだが
Linuxユーザーとの対応付けは、Sambaマシンに登録している
Linuxユーザーのデータ(/etc/passwd)を見にいく。

折角、「ldapsam:editposix」で、Linuxユーザー情報を自動生成して
LDAP側にLinuxユーザー情報を保管しているにも関わらず
Sambaマシン上のLinuxユーザー情報を見にいく事になる。
処理的に無駄が発生するのだ。


　だが、「ldapsam:trusted = yes」にすると、以下のように変わる。
ldapsam:trusted = yes の場合
ldapsam:trustedオプションを行なった場合
この場合、Sambaユーザーの認証と、Linuxユーザーの対応づけは
LDAPに登録されているユーザー情報を使って行なわれるのだ。

「ldapsam:editposix = yes」にして、Linuxユーザー情報を自動生成し
LDAPに保管しているデータを活用する事ができる。

単に、SambaマシンのLinuxユーザー情報(/etc/passwd)を見にいく
処理を減らすだけでなく、LDAP内のデータの活用ができるのだ。

ユーザー情報の一元管理という役目も果たしているのだ。


　Winbind、Samba + OpenLDAP、「ldapsam:trusted = yes」
そして「ldapsam:editposix = yes」の4つ。

　これで全てがつながった。すっきりした気分だ。
　まさに

　ツモ役満!! 一気通貫! でや！

　なのだ (^^)

　一度は、やってみたい役なのだ。
　過去に、大三元、国士無双はあるのだが、一気通貫はない。


　麻雀を知らない人には、この表現が伝わらないので、
別の表現に置き換えると、ドミノ倒しで、綺麗に倒れていった爽快感なのだ (^^)


　ところで、「ldapsam:trusted = yes」にする利点は他にある。
　Sambaマシンが故障した場合を考えてみる。
ldapsam:trusted = no の場合
Sambaマシンが故障した場合、Linuxユーザー情報が見れなくなる
もし、Sambaマシンが故障して、Linuxユーザーのファイルまで破損した場合
Sambaマシンの取り替えだけでなく、Linuxユーザーとの対応関係を行なうため
再度、Linuxユーザーやグループ登録が必要になる。
復旧の際、手間が増える事があるのだ。


　だが、「ldapsam:trusted = yes」にすると以下のようになる。
ldapsam:trusted = yes の場合
Sambaマシンが故障した場合でも、Linuxユーザー情報は問題なし
Sambaマシンが故障しても、ユーザー情報はLDAP側にあるため
Sambaマシンだけ交換すれば良いのだ。ユーザー情報が保全される。

ただし、ファイルサーバーとして運用していた場合
大事なファイルがオシャカになる場合があり
できる限り、故障は避けたい所だが・・・


　要するに、ユーザー情報を1ヶ所に保管しているため
単にPDCとしてSambaを使っている場合なら、Sambaマシンが故障しても
Linuxユーザーやグループの登録を考える必要はなく
単にマシンを取り替えるだけで済むという事なのだ。


Samba + OpenLDAPの注意点


　ところで、Samba + OpenLDAPでLDAP側が停止した場合は
どうなるのか？

　答えは・・・

　Sambaが機能しなくなる!

　なのだ。

　実は、この原稿を書いている最中、うちの会社で停電があり
停電時間が長かったため、UPSのバッテリーが持たなかった。

　Sambaは、PDCだけでなく、ファイルサーバーとしても使っていた。
　Sambaマシンを立ち上げたが、OpenLDAPのマシンを立ち上げ忘れた。
　それに気づかず、Samba復旧を宣言した。

　だが、同僚から

　Sambaがつながらへんで!
　
　と言われた。

　Sambaのデーモンは問題なく動いている。
　一体、原因は、どこなのか?　全く見当がつかないだけに
だんだん混乱してきた。

　だが、ふと気づいた。

　OpenLDAPのマシンが起動してへん!

　そこで、OpenLDAPのマシンを起動させると、Sambaが使えるようになった。

　ここで思った。
　多分、以下のようになっていたのだ。
Samba + OpenLDAPでLDAPが停止していると
Samba + OpenLDAPでLDAPが停止していると、Sambaも正常に動かなくなる
Sambaでドメインを組むと、Sambaを利用する場合、ユーザー認証が必要になる。
しかし、LDAPが停止していると、ユーザー情報への問い合わせができず
認証ができないため、Sambaが使えなくなるのだ。


　幸いSambaのファイルシステムに問題がなかったので助かった。

　災い転じて福となす!

　という所だろうか。
　ファイルシステムが無事だったので、そんな事を言えるのだが
ファイルシステムが破損していたら、血相を変えていたと思う (--;;



設定ファイル smb.conf　の記述について


　Sambaの設定ファイル(smb.conf)の記述で、LDAPとの連動に関する部分で
まだ説明していない箇所を書きたいと思います。
smb.confの記述
ldap delete dn = yes
ldap password sync = yes

赤い部分は、LDAPに登録しているSambaユーザー削除の際
DN全体(そのユーザー情報全体)を消去する設定。

青い部分はSambaユーザーのパスワード変更の際
LDAPに登録されているLinux(UNIX)ユーザーのパスワードも変更する設定。


　Samba + OpenLDAPの際、SambaユーザーとLinuxユーザーの
登録・変更・削除を連動させるための設定なのだ。

　Samba独自で動かす場合と違い、たった2行でできるので
すっきりした感じになる (^^)


　LDAPとの連携で大事なのは、サフィックス(suffix)の設定だ。

　ところで・・・

　suffixって何やねん!

　知ったかぶりして前に進もうとしても、必ずコケる私なので
最初からメッキをはがして前に進む (^^)
サフィックス(suffix)の意味
元々、suffixとは「接尾辞」という意味なのだ。
つまり、文末につける言葉だ。

LDAPの場合、LDAPのデータ識別子の意味で、DNと同じ意味になる。


　さて、設定ファイルを見ていく事にする。
smb.confを一部抜粋
ldap admin dn = cn=Manager,dc=compnay,dc=jp
ldap suffix = dc=compnay,dc=jp
ldap group suffix = ou=groups
ldap machine suffix = ou=computers
ldap user suffix = ou=users
ldap idmap suffix = ou=idmap
上から見ていく。
管理者のDN、LDAPのベースDN、グループDN
マシンDN、ユーザーDN、idmapのDNなのだ。

LDAP内のデータの検索を行なうための設定箇所なのだ。 

　Samba + OpenLDAPの設定は、結構、すっきりした感じだ。
　そして、意外と記述する内容が少ないのだ (^^)

　もちろん、踏み込んだ設定はしていないため
単純に見えるだけかもしれないのだが。




OpenLDAPと内部統制


　Samba + OpenLDAPでユーザー情報の統合管理が行なえる。
　一元管理する事で、データの整合性を高める事ができるのだ。

　ある日の事、こんなサイトの記事を見た。

　OpenLDAPで内部統制の強化!

　これを見た瞬間、なるほどと思った。


　セキュリティーの3大分類がある。
セキュリティーの3大分類
(1) 機密性 データの盗難・漏洩から守る。
(2) 可用性 常に事業が継続できる状態にする事。
災害時にもバックアップ機能を使って業務続行したり
例え、止まっても、すぐに復旧できる体制にする事
(3) 完全性 データの正確性を保つ事。
入力間違いや、不正入力など防止する事。
これを内部統制という。 

　「内部統制」という文字を見ると、威圧的な感じがするが
単にデータや情報の正確性を保つ事なのだ。

　LDAPを使ってユーザー情報の統合管理を行なう事で
以下のように、ユーザー情報の一元的な管理ができる。
LDAPを活用したユーザー情報の一元管理
LDAPによるユーザー情報の一元管理の様子
OpenLDAPのデータベースに、全てのユーザー情報を格納する。
それによって、Windowsの認証も、Linuxの認証も
各種アプリケーションの認証やユーザー情報の利用ができる。 


　もし、バラバラで管理していたら、変更がある度に
全て変更を行なう必要があり、手間がかかるだけでなく
変更漏れが発生する事もありえる。

　変更漏れ、即ち、完全性が保てない

　という事だ。

　各情報やデータの整合性を保つためにLDAPの活用は有効だという。

　内部統制を高めるという理由は、そこにあるのだ。

　フフフ、格好良く決まったぜ！ (^^)V

　難しい言葉を使えば、賢くなったと勘違いする典型です (^^)



最後に


　Samba + OpenLDAPを使ってPDCを構築しようという事で
まずはOpenLDAPでLDAPサーバーの構築(システム奮闘記:その90)を行ない
そして、SambaでPDC構築(システム奮闘記:その91)を行ない
最終段階として、今回の話になりました。


　2002年、LILOの西宮のセミナーで、当時、Sambaユーザー会の
副代表だった小田切さんの講演がありました。
　「Samba + OpenLDAPでWindowsによるドメインコントローラー構築」
　当時の私の知識では、チンプンカンプンでしたが、小田切さんの名刺を頂いて
喜んだりしました。ミーハーな私です  (^^)V

　2004年、SambaでPDCに手を出してみましたが、簡単に触れただけで終わり
7年の時を経て、ようやくたどり着きました。長かったです (^^)


　さて、今後、Samba + OpenLDAPの形態はどうなるのか？
　Samba4が正式に世に送り出され、ADドメインが組めるようになった時
Sambaドメインの役目は終わるだろうと思われる。

　それだけに、Samba + OpenLDAPでSambaドメインを組むのは
微妙な時期だと思うが、無駄にはならないと思う。
　段階を踏みながら進まないと、一足飛びでは絶対にコケるからだ。


　ところで、うちの会社の場合、WindowsXPのHome版が多いため
これらの撲滅に時間がかかると思う。
　撲滅していく過程で、Samba4の登場を、じっくり待ちながら、
ActiveDirectoryの導入を進めていきたいと思います。
次章:「勤務先でのOpenOffice導入事例」を読む
前章:「SambaでPDC構築入門」を読む
目次:システム奮闘記に戻る

Tweet