auto.master / auto_master など、アンダーライン’_’とドット’.’だけ異なるautomount のマップ名が表記される ことがある。
Linux の autofs では、ドットの名前にこだわったり、Solaris とかのドキュメントを読むとアンダーラインの名前だったり、どんな違いがあるのだろうか?
auto.master / auto_master など、アンダーライン’_’とドット’.’だけ異なるautomount のマップ名が表記される ことがある。
Linux の autofs では、ドットの名前にこだわったり、Solaris とかのドキュメントを読むとアンダーラインの名前だったり、どんな違いがあるのだろうか?
なんかシリーズ化して申し訳ないが、とりあえず設定してみた。
OpenBSD はPAMでは無くBSD_AUTH とかいう仕組みを使っており、かつ NSS に当たるものが見当たらないので、ちょっと諦めた。
ただ、3つともにはKerberos 5 認証は組み込まれている。。。不思議だ。
FreeBSD 6.2-Release
# cd /usr/ports/net/nss_ldap
# make install clean
...
# cd /usr/ports/security/pam_ldap
# make install clean
...
NetBSD 3.1
# cd /usr/pkgsrc/databases/nss_ldap
# make install clean
...
# cd /usr/pkgsrc/security/pam-ldap
# make install clean
...
FreeBSD/NetBSDともに KTH Heimdal Kerberos 5 が使われているのが、設定ファイルに関してはほぼ流用できる。
/etc/krb5.conf
...
[libdefaults]
default_realm = EXAMPLE.COM
...
[realms]
HOME.MOIMOITEI.JP = {
kdc = leopardserver.example.com:88
}
...
[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
Open Directoryに使われているのは MIT Kerberos なので FreeBSD/NetBSD 上の kadmin は使えない。適当なマシンで keytab を作成してコピーする。
# kinit -p diradmin
Authenticating as principal diradmin with password.
Password for diradmin@EXAMPLE.COM:
kadmin: addprinc -randkey host/freebsd.example.com@EXAMPLE.COM
kadmin: addprinc -randkey host/netbsd.example.com@EXAMPLE.COM
kadmin: ktadd -k /tmp/freebsd.keytab host/freebsd.example.com@EXAMPLE.COM
kadmin: ktadd -k /tmp/netbsd.keytab host/netbsd.example.com@EXAMPLE.COM
...
/tmp/freebsd.keytab, /tmp/netbsd.keytab をそれぞれのマシンの/etc/krb5.keytabにコピー
...
freebsd# chmod 600 /etc/krb5.keytab
freebsd# ktutil list
FILE:/etc/krb5.keytab:
Vno Type Principal
3 des3-cbc-sha1 host/freebsd.example.com@EXAMPLE.COM
3 arcfour-hmac-md5 host/freebsd.example.com@EXAMPLE.COM
3 des-cbc-crc host/freebsd.example.com@EXAMPLE.COM
時間の同期がとれてるかは要確認。
LDAP用のPAM/NSS モジュールは、Linux でよく使われている PADL Software Pty Ltd のものなので、完全に同じ設定ファイルが使える。(参照OpenDirectory で Debian系を認証の/etc/ldap.conf)
FreeBSD 6.2-Release
# scp ubutnu71s:/etc/ldap.conf /tmp/ldap.conf
# cp /tmp/ldap.conf /usr/local/etc/ldap.conf
# cp /tmp/ldap.conf /usr/local/etc/nss_ldap.conf
NetBSD 3.1
# scp ubutnu71s:/etc/ldap.conf /tmp/ldap.conf
# cp /tmp/ldap.conf /usr/pkg/etc/pam_ldap.conf
# cp /tmp/ldap.conf /usr/pkg/etc/nss_ldap.conf
FreeBSD 6.2-Release
/etc/nsswitch.conf
group: files ldap
hosts: files dns
networks: files
passwd: files ldap
shells: files
NetBSD 3.1
/etc/nsswitch.conf
group: files ldap
hosts: files dns
netgroup: files
networks: files
passwd: files ldap
shells: files
これで Open Directory 上のユーザ情報が見えれば良し。
ユーザのパスワードのタイプが「Open Directory」でのみの運用であれば、/etc/pam.d/system の pam_krb5 をコメントアウトを外してやれば良い。
「暗号化パスワード」も使う場合は pam_ldap を追加する。
FreeBSD 6.2-Release
/etc/pam.d/system
# auth
auth sufficient pam_opie.so no_warn no_fake_prompts
auth requisite pam_opieaccess.so no_warn allow_local
auth sufficient pam_krb5.so no_warn try_first_pass
auth sufficient /usr/local/lib/pam_ldap.so no_warn try_first_pass
#auth sufficient pam_ssh.so no_warn try_first_pass
auth required pam_unix.so no_warn try_first_pass nullok
# account
account required pam_krb5.so
account required pam_login_access.so
account required pam_unix.so
# session
#session optional pam_ssh.so
session required pam_lastlog.so no_fail
# password
password sufficient pam_krb5.so no_warn try_first_pass
password sufficient /usr/local/lib/pam_ldap.so no_warn try_first_pass
password required pam_unix.so no_warn try_first_pass
NetBSD 3.1
/etc/pam.d/system
# auth
auth sufficient pam_krb5.so no_warn try_first_pass
auth sufficient /usr/pkg/lib/security/pam_ldap.so no_warn try_first_pass
auth required pam_unix.so no_warn try_first_pass nullok
# account
account required pam_krb5.so
account required pam_unix.so
# session
session required pam_lastlog.so no_fail no_nested
# password
password sufficient pam_krb5.so no_warn try_first_pass
password sufficient /usr/pkg/lib/security/pam_ldap.so no_warn try_first_pass
password required pam_unix.so no_warn try_first_pass
ただし、両方のOSともに /etc/pam.d/sshd は上記に設定をincludeしていないので、同様な変更が必要。
try_first_pass よりも use_first_pass を混ぜる方が好みだが、、、BSD 系はこうなんだろうなぁ。
accountタスクにpam_ldapを使ったエントリを加えると、何故かパスワードを変えろとかプロンプトが出るんだが、なんか設定が足らんかも。。。
FreeBSD/NetBSD ともに amd は標準の配布に含まれているが、ldap マップタイプが使えるようには構築されていない。また、amd の ldap 実装で使われる ldap schema は Open Directory には含まれていない。 なので、素直にファイルベースのものを使う。。。
そのうちAutoFS on FreeBSD 6が入ってくるのかなぁ。。。
FreeBSD 6.2-Release
/etc/rc.conf
...
rpcbind_enable="YES"
amd_enable="YES"
amd_flags="-F /etc/amd.conf"
...
NetBSD 3.1
/etc/rc.conf
...
rpcbind=YES
amd=YES
...
FreeBSD 6.2-Release/NetBSD3.1 両方
/etc/amd.conf
[ global ]
browsable_dirs = no
restart_mounts = yes
unmount_on_exit = yes
log_file = syslog
#log_options = all
auto_dir = /amd
map_type = file
mount_type = nfs
search_path = /etc
dismount_interval = 60
[ /home ]
map_name = amd.home
/etc/amd.home
/defaults opts:=rw
fileserver type:=nfs;rhost:=${key};rfs:=/export/home
/amd ディレクトリが無ければ作成。
向学のために VMware 上に FreeBSDをインストールしてみていたが、amd の設定で不明なエラーが出て詰まっていた。
# /etc/rc.d/amd start
# amq
amq: localhost: RPC: Port mapper failure - RPC: Unable to send
# dmesg
...
nfs send error 49 for server pid473@freebsd:/home
nfs server pid473@freebsd:/home: not responding
...
Google先生に聞くと、そんな例が出てくるが、結局うやむやに解消されている、、、。
ふと気付いた。
ホスト名を指定すると、amqがマトモな返事を返してくれる!
# amq -h freebsd
/ root "root" freebsd:(pid473)
/home toplvl /etc/amd.home /home
熟考の結果、ループバックインタフェースにIPv4のアドレス127.0.0.1が付いていなかった。。。
# ifconfig lo0
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
inet6 ::1 prefixlen 128
原因はインストール直後のネットワーク設定をテキトウに書いたため。
/etc/rc.conf
...
network_interfaces="lo0 lnc0"
...
設定を変更して、再起動。。。ちゃんと動く。。。ばかぁ
Debian系は認証設定のツール群が充実していない。結局は設定ファイルを直に編集するのが近道になる。Debian Policy Manualを見る限り、ローカルユーザとNISなりLDAPなり外部由来ユーザの区別が無い。。。何だが X っぽい。
Ubuntu 7.10 リリース記念なので、こいつの Server 版を、Leopard Server にぶら下げてみた。
参考 OpenDirectory で Feodra/CentOSを 認証
# apt-get install libnss-ldap libpam-ldap
# apt-get install libpam-krb5 krb5-user
# apt-get install libpam-cracklib
# apt-get install portmap nfs-common autofs-ldap
/etc/krb5.conf
...
[libdefaults]
default_realm = EXAMPLE.COM
...
[realms]
HOME.MOIMOITEI.JP = {
kdc = leopardserver.example.com:88
admin_server = leopardserver.example.com:749
}
...
[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
...
これでKerberos5関連のコマンドが有効に機能するので確認するついでに、host/nfsプリンシパルを作成しとく。
# kinit -p diradmin
Authenticating as principal diradmin with password.
Password for diradmin@EXAMPLE.COM:
kadmin: addprinc -randkey host/ubuntu71s.example.com@EXAMPLE.COM
kadmin: addprinc -randkey nfs/ubuntu71s.example.com@EXAMPLE.COM
kadmin: ktadd host/ubuntu71s.example.com@EXAMPLE.COM
kadmin: ktadd -e des-cbc-crc:normal nfs/ubuntu71s.example.com@EXAMPLE.COM
# klist -k -e
keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
3 host/ubuntu71s.example.com@EXAMPLE.COM (Triple DES cbc mode with HMAC/sha1)
3 host/ubuntu71s.example.com@EXAMPLE.COM (ArcFour with HMAC/md5)
3 host/ubuntu71s.example.com@EXAMPLE.COM (DES cbc mode with CRC-32)
3 nfs/ubuntu71s.example.com@EXAMPLE.COM (DES cbc mode with CRC-32)
うまく行かない場合、ネットワーク設定や時間同期を見直す。
Debian/etch の libnss-ldap/libpam-ldapの設定ファイルは、別々になっているが、特に分ける必要がないので、シンボリックリンクを張っとく。
# ln -sf /etc/ldap.conf /etc/libnss-ldap.conf
# ln -sf /etc/ldap.conf /etc/pam_ldap.conf
ldap の設定では、ホスト名ではなくIPアドレスを直に設定する。 (XX.XX.XX.XXがleopardserverのアドレス)
/etc/ldap.conf
host XX.XX.XX.XX
uri ldap://XX.XX.XX.XX/
base dc=example,dc=com
ldap_version 3
port 389
#bind_policy [hard|soft]
bind_policy soft
#binddn cn=proxyuser,??,dc=example,dc=com
#bindpw secret
#rootbinddn ???
ssl no
#ssl [no|on|start_tls]
#tls_cacertfile /etc/openldap/cacert
#tls_cacertdir /etc/openldap/cacerts
#tls_checkpeer yes
#tls_ciphers [SSLv2|SSLv3|TLSv1]
#tls_cert mycert
#tls_key mykey
timelimit 60
bind_timelimit 60
idle_timelimit 300
####
scope one
nss_schema rfc2307
nss_base_passwd cn=users,?one
nss_base_shadow cn=users,?one
nss_base_group cn=groups,?one
nss_base_hosts cn=machines,?one
pam_password exop
#pam_filter objectclass=account
pam_login_attribute uid
pam_check_host_attr no
pam_check_service_attr no
/etc/nsswitch.conf
passwd: files ldap
group: files ldap
shadow: files ldap
hosts: files dns
networks: files
protocols: files
services: files
ethers: files
rpc: files
netgroup: ldap
automount: files ldap
これで Open Directory 上のユーザ情報が見えれば良し。
pam の設定は管理者の数だけ書き方があるのだが、2点を留意して設定する。
管理の簡便性のため、/etc/pam.d/common-* の設定ファイルは /etc/pam.d/system に纏めておく。
# echo "auth include system" > /etc/pam.d/common-auth
# echo "account include system" > /etc/pam.d/common-account
# echo "password include system" > /etc/pam.d/common-password
# echo "session include system" > /etc/pam.d/common-session
/etc/pam.d/system
#
# /etc/pam.d/system - authentication settings common to all services
#
# account
account sufficient pam_unix.so
account sufficient pam_krb5.so
account sufficient pam_ldap.so
account required pam_deny.so
# auth
auth sufficient pam_unix.so nullok_secure
auth sufficient pam_krb5.so use_first_pass
auth sufficient pam_ldap.so use_first_pass
auth required pam_deny.so
# password
password required pam_cracklib.so retry=3 minlen=6 difok=3
password sufficient pam_unix.so use_authtok nullok md5
password sufficient pam_krb5.so use_authtok
password sufficient pam_ldap.so use_authtok
password required pam_deny.so
# session
session required pam_unix.so
session optional pam_krb5.so
session optional pam_ldap.so
ただし、他のサービスでのcommon-auth/common-account/common-password の取り込み位置がそれぞれのauth/account/passwordタスクエントリの最後になるように調節する必要がある。
Debian etch / Ubuntu 7.10 は、まだautofs ver 4.x 系なので、rfc2307bisで定義されている automountMap/automountオブジェクトクラスは使えない。従って、nisMap/nisObject オブジェクトクラスのレコードを Open Directory 上に登録しておく必要がある。
/etc/default/autofs
...
LDAPURI=ldap://XX.XX.XX.XX
...
LDAPBASE="dc=example,dc=com"
...
LDAPサーバをLeopard Server のOpen Directory を使い、新しめのCentOS/Fedora をクライアントにした場合、ls コマンドとかが不定期に固まる症状が出た。それ以外にも、automount+NFS4を組み合わせるとログインがちょっと固まった。
ログにはたくさん LDAPサーバを再接続してるよん〜って出ている。
Nov 10 05:54:25 centos5 nscd: nss_ldap: reconnected to LDAP server ldap://xx/ after 1 attempt
Nov 10 06:02:12 centos5 rpc.idmapd[1589]: nss_ldap: reconnected to LDAP server ldap://xx/ after 1 attempt
はて?
再接続してるならば、良いじゃない。
でも、時々固まる??
何故に?
調べてみると、LDAP サーバ/クライアントの idle_timelimit の値がサーバの方が小さいためのようである。
クライアントがサーバから強制切断されると、何故に固まるようである、、、バグ?
ちなみに、Leopard Server のOpen Directory の idle_timelimit が 300 秒がデフォルトになっており、新しめのCentOS/Fedoraのauthconfig が勝手に 3600秒に設定してくれる。
なので、
/etc/ldap.conf
...
timelimit 60
idle_timelimit 300
...
を付け加えると、症状が収まる。
なんだかなぁ
ssh の公開鍵認証はいい。
ただ、ホームディレクトリを automount で Kerberos化した NFS をマウントする場合は利用できない。 そんなあなたのために ssh+GSSAPI+Kerberos を使うといい。
sshd_config と.ssh/config に下記設定をする。
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
あら不思議、チケットを持っていたら、認可され、チケットが転送されて、証明書キャッシュに保存され、Kerberos化されたNFSサービスがよろしくアクセスできる。
サーバ側がLeopard だと、認可され、チケットが転送され、何故か証明書キャッシュには保存されない。なので、Kerberos化されたNFSサービスは使えない。。。
で、再度チケットを取得するとKerberos化されたNFSが使えるようになる。
なんか設定が足らんのか、そのうち直るかなぁ。。。
これが振る舞いが無ければ automountMap を Solarisと共存できるのに、、、。
でも、MacOSXで sec=krb5/krb5i/krb5p が使えるようになったのって凄いっすね。UNIX認定を受けた恩恵か!?
全てサーバが隈無くNFSv4で統一できたら悩むことはないのだが、NFSv3までしかサポートしないサーバとかがまだ多くある。
Linux NFSv4 で1つ混乱する振る舞いがある。過渡的な状況かもしれないが、どうなるだろかなぁ。
Linux NFSv4では、クライアントから見えるNFSv4の疑似ファイルシステムが fsid=0 を指定した特定のエクスポートポイントをルートとしたディレクトリのツリーになっている。結果、サーバ側の/etc/exports で記述されるディレクトリと実際にクライアントが見るディレクトリが異なることになる。
かつ、fsid=0が指定されたディレクトリのツリー内のエクスポートポイントはNFSv4でのみ、それ以外はNFSv3でのみで利用が可能になっているらしい。。。へたれ実装と言われかねないなぁ。
実際、Solaris 10では、疑似ファイルシステムのルートは実際のルートだし、NFSv3/NFSv4は共有設定ファイルでは区別は無いし、、、そうあるべくある感じだし。。。まぁいいかぁ。
automount を使う場合、NFSv3とNFSv4が同じエクスポートポイントに見えるようにしなければ混乱の元になる。 Linuxには seamless という単語が無いのかぁ、、、。
/export/home をNFSv3/NFSv4の両方で同じエクスポートポイントで共有する場合
/etc/fstab
...
# for nfs4
/export/home /srv/nfs4/export/home none bind
...
シェルで
# mkdir -p /srv/nfs4/export/home
# mount /srv/nfs4/export/home
/etc/exports
# for NFS3 Clients
/export/home \
*(rw,sync,insecure,no_subtree_check) \
gss/krb5(rw,sync,insecure,no_subtree_check) \
gss/krb5i(rw,sync,insecure,no_subtree_check) \
gss/krb5p(rw,sync,insecure,no_subtree_check) \
# for NFS4 Clients
/srv/nfs4 \
gss/krb5(rw,sync,fsid=0,crossmnt,insecure,no_subtree_check) \
gss/krb5i(rw,sync,fsid=0,crossmnt,insecure,no_subtree_check) \
gss/krb5p(rw,sync,fsid=0,crossmnt,insecure,no_subtree_check)
/srv/nfs4/export/home \
gss/krb5(rw,sync,fsid=1,insecure,no_subtree_check) \
gss/krb5i(rw,sync,fsid=1,insecure,no_subtree_check) \
gss/krb5p(rw,sync,fsid=1,insecure,no_subtree_check)
で、nfsサービス群を再起動。Kerberozied NFS の設定もしとく。
# mount -t nfs -osec=krb5i server:/export/home /mnt
# mount -t nfs4 -osec=krb5i server:/export/home /mnt2
# mount
server:/export/home on /mnt type nfs (rw,sec=krb5i,addr=XX.XX.XX.XX)
server:/export/home on /mnt2 type nfs4 (rw,sec=krb5i,addr=XX.XX.XX.XX)
めでたく、同じエクスポートポイントが見えました。。。Linux NFSv4 めぇ!
GSSAPI は下層モジュールの Sun RPC の認証方法のお話なので、 Linux の NFS ver 3 でも sec=mode の指定が可能な気がする。
で、ちょっとだけ試してみた。
NFSサーバとして2種類
NFSクライアントとして3種類
用意した。
NFSサーバの1. は問題なく個々のクライアントでマウント接続が出来るが、NFSサーバの 2. は、どうもマウント接続を受け付けない。。。
Linux 側の設定は、fsid=0とは無関係な所で
/etc/exports
...
# for NFS3 Clients
/srv/nfs/home *(rw,sync,insecure,no_subtree_check)
/srv/nfs/home gss/krb5(rw,sync,insecure,no_subtree_check)
/srv/nfs/home gss/krb5i(rw,sync,insecure,no_subtree_check)
/srv/nfs/home gss/krb5p(rw,sync,insecure,no_subtree_check)
...
パッケージは
# dpkg --list | grep nfs
ii libnfsidmap2 0.18-0 An nfs idmapping library
ii nfs-common 1.0.10-6+etch.1 NFS support files common to client and serve
ii nfs-kernel-server 1.0.10-6+etch.1 Kernel NFS server support
どうだろう。 NFS ver 4 では問題なくできるのだがぁ。
/etc/exports 設定を見直したら、LinuxでもNFSv3サーバ/NFSv4サーバのKerberos化が可能だった。
Linux の autofs の LDAPインタフェースは何度か変遷があるようなので調べてみた。
基本は、Network Service Switch の設定ファイル /etc/nsswitch.conf で、検索方法に LDAP を追加すれば良い。。。
...
automount: files ldap
...
それだけで済めばいいなぁ〜。
automount として使われる schema は3種類ある。
1 | 2 | 3 | |
Map Object | nisMap | automountMap | automountMap |
Map Attribute | nisMapName | ou | automountMapName |
Entry Object | nisObject | automount | autmount |
Entry Attribute | cn | cn | automountKey |
Value Attribute | nisMapEntry | automountInformation | automountInformation |
autofs のマップ名の書式は異常なほど癖がある。古いバージョンでは 1. しか使えなかった。
4. のマップ名書式は nsswitch.conf に記載してある検索順序で読み出すのだが、マスターマップ名でしか(マスターマップ内ではない、、)機能しなかった期間が結構あった。。。
(prefixに/etc/をつけた)ファイルマップの中に +mapname があれば、files の次の検索順序にある方法で読み出すのが正解かなぁ。
autofs ver 5.x でまともな実装になったなぁ〜。でも、pam_ldap/nss_ldap とLDAP繋がりで共通の設定ファイルとかあったらいいのにぃ〜。
どうもNFSはパケットだだ漏れ、認証もへったくれもない、スピード狂のネットワークファイルシステムのイメージは拭えない。ただ、Linux のNFSv3では AUTH_SYSぐらいしか使えなかった(使わなかった?)のも大きいかも。
NFSv3 から NFSv4 への移行に合わせて、まともなKerberos認証を組み合わせてみた。 丁度、OpenDirectory にはもれなく、即運用可能なKerberosサーバ群がついてくるので、、、。
前提として
参考
NFSサーバ/クライアントの両方で、下記ファイルを編集してrpcidmapdを再起動
/etc/idmapd.conf
...
Domain = example.com
...
KDCにNFSサーバ/クライアントのサービスプリンシパルの登録し、それぞれをkeytabに保存。暗号化/ソルトをdes-cbc-crc:normal に限定するのがミソらしい。
# kadmin -p diradmin
Authenticating as principal diradmin with password.
Password for diradmin@EXAMPLE.COM:
kadmin: add_principal -randkey nfs/server1.example.com@EXAMPLE.COM
...
kadmin: add_principal -randkey nfs/client1.example.com@EXAMPLE.COM
...
kadmin: ktadd -k /tmp/server1.keytab -e des-cbc-crc:normal nfs/server1.example.com@EXAMPLE.COM
...
kadmin: ktadd -k /tmp/client1.keytab -e des-cbc-crc:normal nfs/client1.example.com@EXAMPLE.COM
できた keytab をそれぞれのマシンの /etc/krb5.keytab にコピーする
/etc/sysconfig/nfs
...
SECURE_NFS=yes
...
で起動。
# /etc/init.d/rpcgssd start
...
# ps `pidof rpc.gssd`
PID TTY STAT TIME COMMAND
2644 ? Ss 0:16 rpc.gssd
# lsmod | grep rpc
rpcsec_gss_krb5 12873 7
auth_rpcgss 42465 4 rpcsec_gss_krb5
sunrpc 142973 10 nfs,lockd,nfs_acl,rpcsec_gss_krb5,auth_rpcgss
ただし、Fedora2だけは事前に rpcsec_gss_krb5 をロードしておく必要がある。。。どうでもいいけど。
/etc/exports
/srv/nfs4 gss/krb5(rw,sync,fsid=0,crossmnt,insecure,no_subtree_check)
/srv/nfs4 gss/krb5i(rw,sync,fsid=0,crossmnt,insecure,no_subtree_check)
/srv/nfs4 gss/krb5p(rw,sync,fsid=0,crossmnt,insecure,no_subtree_check)
/srv/nfs4/home gss/krb5(rw,sync,insecure,no_subtree_check)
/srv/nfs4/home gss/krb5i(rw,sync,insecure,no_subtree_check)
/srv/nfs4/home gss/krb5p(rw,sync,insecure,no_subtree_check)
適当にディレクトリを作成して、nfsを起動
# mkdir -p /srv/nfs4/home
# mount --bind /path/to/home /srv/nfs4/home
# /etc/init.d/nfs restart
...
# exportfs
/srv/nfs4/home gss/krb5
/srv/nfs4/home gss/krb5i
/srv/nfs4/home gss/krb5p
/srv/nfs4 gss/krb5
/srv/nfs4 gss/krb5i
/srv/nfs4 gss/krb5p
これで最後で root 権限で
# mount -t nfs4 -o sec=krb5 server1:/home /mnt
# mount | grep home
server1:/home on /mnt type nfs4 (rw,sec=krb5,addr=XX.XX.XX.XX)
一般ユーザでKerberosレルムに認証されている状態であれば、NFS上のファイルが触れる。。。
# su - user1
% klist -5
klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_5002)
% ls /mnt
ls: cannot access /mnt: Permission denied
% kinit
Password for user1@EXAMPLE.COM:
% klist -5
Ticket cache: FILE:/tmp/krb5cc_5002
Default principal: user1@EXAMPLE.COM
Valid starting Expires Service principal
11/16/07 03:34:16 11/16/07 13:34:16 krbtgt/EXAMPLE.COM@EXAMPLE.COM
renew until 11/17/07 03:34:17
11/16/07 03:34:20 11/16/07 13:34:16 nfs/server1.example.com@EXAMPLE.COM
renew until 11/17/07 03:34:17
% ls /mnt
lost+found user1 user2 user3
% touch /mnt/user1/a
% ls -l /mnt/user1/a
-rw-r--r-- 1 user1 users 0 Nov 16 03:34 /mnt/user1/a
以上。
あぁ忘れていた。
とりあえずSELinux が有効になってる場合、いろんなアクセスが阻止されるので、Disabled か Permissive にした方がよい。。。SELinux めぇ!
だいぶ前に設定できたのだが備忘として書いておこう。
Debian/etch 環境の netatalk は DHX認証のプラグインが含まれていないので、GSSAPI 経由で Kerberos v5 を使う。
前提として、
使っている Open Directory だと MIT Kerberos なので、kadminはそれようなのを使うべし。
kadmin で管理者でログインして、サービスプリンシパルを登録して、そのサービスプリンシパルが入った keytab を作成する。
# kadmin -p diradmin
Authenticating as principal diradmin with password.
Password for diradmin@EXAMPLE.COM:
kadmin: addprinc -randkey afpserver/machine.example.com@EXAMPLE.COM
...
kadmin: ktadd -k /tmp/krb5.keytab afpserver/machine.example.com@EXAMPLE.COM
できた keytab をマシンの /etc/krb5.keytab にコピーする。別のサービスプリンシパルがあれば、ktuil とかで追加すると吉。
認証方法の指定を /etc/default/netatalk では行わず、afpd.conf から行うようにする。
/etc/default/netatalk
...
AFPD_UAMLIST=""
...
/etc/netatalk/afpd.conf
...
- -tcp -uamlist uams_gss.so -k5service afpserver -k5keytab /etc/krb5.keytab -k5realm EXAMPLE.COM -fqdn machine.example.com:548
...
Linux でもローカルKDC?とでのKerberos認証が提供されるのだろうかねぇ。
ふと、sudo klist -k とかすると、サーバでも無いのにサービス鍵が登録されている。
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
3 afpserver/LKDC:SHA1.####@LKDC:SHA1.#### (Triple DES cbc mode with HMAC/sha1)
3 afpserver/LKDC:SHA1.####@LKDC:SHA1.#### (ArcFour with HMAC/md5)
3 afpserver/LKDC:SHA1.####@LKDC:SHA1.#### (DES cbc mode with CRC-32)
3 cifs/LKDC:SHA1.####@LKDC:SHA1.#### (Triple DES cbc mode with HMAC/sha1)
3 cifs/LKDC:SHA1.####@LKDC:SHA1.#### (ArcFour with HMAC/md5)
3 cifs/LKDC:SHA1.####@LKDC:SHA1.#### (DES cbc mode with CRC-32)
3 vnc/LKDC:SHA1.####@LKDC:SHA1.#### (Triple DES cbc mode with HMAC/sha1)
3 vnc/LKDC:SHA1.####@LKDC:SHA1.#### (ArcFour with HMAC/md5)
3 vnc/LKDC:SHA1.####@LKDC:SHA1.#### (DES cbc mode with CRC-32)
ファイル共有や画面共有とかのスタンドアーロンな認証でも、Kerberos 認証に移行するらしい。AFP/SAMBA/VNCとかは、パスワード認証不可なのか??
まぁ、セキュリティ的には安全性の高い方向への舵取りなんだろうな。
Kerberosのセキュリティ情報とかは、Leopard では結構重要な悪い知らせになるのだろうなぁ。
ローカルのKDCのレルム名はどう算出するのだろう? Bonjour ? 、、、そのうち情報が出てくるのかなぁ。
専門家では、peer-to-peer Kerberos とか呼ばれているらしい。本当か!?
ローカルKDCのレルム名は、システムキーチェーン /Library/Keychains の中にあるカスタム証明書「com.apple.kerberos.kdc」の Fingerprint のSHA1の値を使っているらしい。
LKDC:SHA1.<証明書com.apple.kerberos.kdcのfingerprintのsha1値>
秘密鍵とか公開鍵とかがなんか使ってるのかなぁ。
Leopard では、KDCデーモン krb5kdc を生成する kdcmond がレルム名やサーバ名等々をBonjour に登録するらしい(manを見る限り)が、、、、どうも取り方がわからん。
LKDC の レルム名は、次のように特殊な名前のTXTレコードの問い合わせを使うらしい。
# dns-sd -Q _kerberos.hostname.local txt
avahiではこの形の問い合わせや通知が出来ないので、もうひねり加えないと使えない模様である。
Leopard は、いい意味でも悪い意味でも、過去の遺産をばっさり切り捨てたツンなOSである。
SLP によるサービス検索機能がなくなってしまったらしく、 netatalk は AFPサーバ機能を SLP 通知しているので見つけられなくなってしまったらしい。
そんな人は、avahi を使えとか言われるが、設定方法があまり載っていない。。。
Debian/etch だと avahi-daemon は設定が何もなく?困るし。。。
ドキュメントを読めばよく、sshサービスのサンプルもついてくる。
/etc/avahi/services/ssh.services
<?xml version="1.0" standalone='no'?>
<service-group>
<name replace-wildcards="yes">Remote Terminal on %h</name>
<service>
<type>_ssh._tcp</type>
<port>22</port>
</service>
</service-group>
avahi-daemon を再起動させると、Leopard の「ターミナル」の「新規リモート接続」のリストに自動的に追加される。
netatalk を通知するには、AFPのサービスタイプ(http://www.dns-sd.org/ServiceTypes.html を参考)を指定して、
/etc/avahi/services/afp.services
<?xml version="1.0" standalone='no'?>
<service-group>
<name replace-wildcards="yes">%h</name>
<service>
<type>_afpovertcp._tcp</type>
<port>548</port>
</service>
</service-group>
ついでに Samba と区別ができなくなるので、
/etc/avahi/services/smb.services
<?xml version="1.0" standalone='no'?>
<service-group>
<name replace-wildcards="yes">Samba on %h</name>
<service>
<type>_smb._tcp</type>
<port>139</port>
</service>
</service-group>
Finder のサイドバーの共有のリストに、samba/netatalk のエントリが追加され、ちょっといい感じになります。
Open Directory を立ち上げるのは非常に簡単である。 例えば、インストールするとき標準構成とかを選べば、勝手に OpenDirectory のマスターが出来上がるし、それ以外の構成でもGUIのツールを使い、LDAPの基本DNやKerberosのrealm名を指定して数クリックで完了する。
これだけで、LDAPサーバとKerberosサーバ群が直に使える状態になるのは、なんというか、、、楽だ。
authconfig を使えば、簡単にできる。同様なGUIの管理ツールauthconfig-gtk があるのでこっちを使ってよいかも。
上記に設定で書き換わるのは、次のファイル群なので面倒な問題が起きた場合これらのファイルを眺めればいい。
大体、RedHat7くらいから同様な設定で行けたみたいだ。。。知らんかった。。。(RedHat6.2とかだともう一捻りが必要だ、、、多分知らんでもいいと思う。)
Open Directory から提供されるうち基本的な部類の情報に プラットホーム依存なものがある。
どのプラットホームに共通してあるシェルは、/bin/sh と /bin/csh くらいだが、bash がなければ別途パッケージをいれ、/bin/bash にシンボリックリンクを張れば、/bin/bash を指定できるので、大した問題では無い。
残るのは、ホームディレクトリをどうするねん。。。 ネットワークファイルシステムはどれにするとか、 オートマウントを使うか使わないかとか、、、それはプラットホーム依存ばりばりなんだなぁ。。。
で、Leopard で実装された autofs がLDAPからマップ情報をとれるので、これは面白いことになってきたって話。。。。(続く)
10日くらい前に予約注文したでゲットした MacOSX Server 10.5 (Leopard Server)をいじくり倒してちょっと寝不足気味である。 それで、今3度目にクリーンインストールの真最中。
まぁ、前バージョンに比べて、RADIUS サーバ / autofs / NFS4 の機能が追加や、管理ツールが一層に磨きがかかっているに違いないと、わくわくしながら触っていたのだが。
ちょっと寝不足気味。
最初は autofs を中心に触ってみた、いい感じだ。 Open Directory サーバ上のマップ情報を読んでくれる。
追加用のGUIが無さそうなので、適当な LDAP 管理ツール (Apache Directory Studio )とかで、cn=automountMap,dc=example,dc=com 以下に次のレコードを追加する必要がある。
dn: automountMapName=auto_home,cn=automountMap,dc=example,dc=com
objectClass: automountMap
objectClass: top
automountMapName: auto_home
dn: automountKey=fileserver,automountMapName=auto_home,cn=automountMap,dc=example,dc=com
objectClass: automount
objectClass: top
automountInformation: fileserver:/srv/nfs/home
automountKey: fileserver
ワークグループマネージャで、/home/fileserver/username をホームに指定すれば、いい感じである。
MacOSX が忘れ去られしまった /home の地位がちょっとだけ向上できてうれしい。
NFS4 はまだ実験的実装でまだ安定的にサポートできていないみたい。ちょっと読み違いだなぁ。
、、、で嫌なことを思い出した。
MacOSX 全般でファイル名を UTF8 NFD のエンコードで扱えるように、UTF8 NFD <-> UTF8 NFC の変換をよろしくやっている。NFS だけ例外で素で通して何もしてくれない。。。
Linux や他のUnixとの相互運用時に引っかかるところ、普通は NFS をあきらめ samba/netatalk で逃げる、、、つまりautofs/NFS がどんなに賢くなっても意味ないじゃん
まぁ、他のUnixは捨てって言えればいいのだがぁ。
ちょっと思い出して疲れた。
まだ、触れていません。。。
かなり期間が空いてしまったが、ブログを再開してみようと思う。 2013年3月が直前の投稿だったが、頻繁に更新していた時期が 2011年11月までなので、8年間ぶりとなる。 8年間なにをしていたのかと言えば、2回転職して未だにIT技術者の職を得ている。 その...