2007年11月29日

auto_master と auto.master の違い

auto.master / auto_master など、アンダーライン’_’とドット’.’だけ異なるautomount のマップ名が表記される ことがある。

Linux の autofs では、ドットの名前にこだわったり、Solaris とかのドキュメントを読むとアンダーラインの名前だったり、どんな違いがあるのだろうか?

又聞きの話だと、NISからNIS+の移行時に、NIS+ではドット文字が特殊な意味を持つので、auto.masterからauto_masterに変更になったらしい。(例,1,2)

Linux ではNIS+サーバが実装されなかったのもあり、’.’->’_’の変更が行われずにそのままになったらしい。

Linux の automount の情報は他とは微妙に違うので、別々にできるのも、そのままになっている理由かもしれない。


[全文を読む]

2007年11月28日

OpenDirectory で FreeBSD/NetBSDを認証

なんかシリーズ化して申し訳ないが、とりあえず設定してみた。

  1. FreeBSD 6.2-Release + ports (portsnap使って最新?)
  2. NetBSD 3.1 + pkgsrc-2007Q3

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
...

Kerberos5 設定

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 の設定

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

NSSの設定

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 上のユーザ情報が見えれば良し。

PAM の設定

ユーザのパスワードのタイプが「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を使ったエントリを加えると、何故かパスワードを変えろとかプロンプトが出るんだが、なんか設定が足らんかも。。。

amd の設定

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 ディレクトリが無ければ作成。

追記

Open Directory の設定のまとめ 2008Q1


[全文を読む]

2007年11月26日

FreeBSD でコケる。でも立ち上がる。

向学のために 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"
...

設定を変更して、再起動。。。ちゃんと動く。。。ばかぁ


[全文を読む]

Ubuntuサーバー版って

Ubuntuサーバー版って Web 系とかの個々のノードサーバ用なんだ。。。


[全文を読む]

OpenDirectory で Debian系を認証

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

Kerberos 5 設定

/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)

うまく行かない場合、ネットワーク設定や時間同期を見直す。

LDAP 設定

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

NSSの設定

/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の設定

pam の設定は管理者の数だけ書き方があるのだが、2点を留意して設定する。

  1. Linux-PAM の独自の制御フィールド構文を使わない。
  2. Debian 系の独自パッチにあまり依存しない。(特に、@include文ってなに?)

管理の簡便性のため、/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タスクエントリの最後になるように調節する必要がある。

autofs の設定

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"
...

追記

Open Directory の設定のまとめ 2008Q1


[全文を読む]

2007年11月23日

nscd がちょっと詰まる

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
...

を付け加えると、症状が収まる。

なんだかなぁ

追記

Open Directory の設定のまとめ 2008Q1


[全文を読む]

2007年11月21日

Leopard の ssh の Kerberos認証の不具合?

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認定を受けた恩恵か!?


[全文を読む]

LinuxのNFSv4とNFSv3でエクスポートポイントを共通化

全てサーバが隈無く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の両方で同じエクスポートポイントで共有する場合

NFSv4の疑似ファイルシステムを作成

/etc/fstab

...
# for nfs4
/export/home    /srv/nfs4/export/home   none    bind
...

シェルで

# mkdir -p /srv/nfs4/export/home
# mount /srv/nfs4/export/home
exports を書く

/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 めぇ!

追記

Open Directory の設定のまとめ 2008Q1


[全文を読む]

2007年11月20日

Linux の NFS ver 3 で、Kerberos化は?

GSSAPI は下層モジュールの Sun RPC の認証方法のお話なので、 Linux の NFS ver 3 でも sec=mode の指定が可能な気がする。

で、ちょっとだけ試してみた。

NFSサーバとして2種類

  1. Solaris 10 の NFS ver3 + sec=krb5
  2. Debian/Linux etch の NFS ver3 + sec=krb5 (??)

NFSクライアントとして3種類

  1. Solaris 9
  2. CentOS 5
  3. MacOSX Server 10.5

用意した。

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 では問題なくできるのだがぁ。

今のところ、Kerberos化したNFSサーバはLinuxではNFS4のみ。クライアントでは、NFSv3でもNFSv4でも可能らしい。

/etc/exports 設定を見直したら、LinuxでもNFSv3サーバ/NFSv4サーバのKerberos化が可能だった。


[全文を読む]

2007年11月18日

Linux の autofs とLDAPの関係はどうなってる

Linux の autofs の LDAPインタフェースは何度か変遷があるようなので調べてみた。

基本は、Network Service Switch の設定ファイル /etc/nsswitch.conf で、検索方法に LDAP を追加すれば良い。。。

...
automount: files ldap
...

それだけで済めばいいなぁ〜。

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
  1. RFC2307 で定義されている。
  2. Netscape Directory Server 4.11 Solaris Extensions NIS Extension Guide に記載がある。古くから使われていた奴っぽい。
  3. RFC2307bis に記載がある。最後に落とされた項目らしい。でもオフィシャルで定義されてるところは知らない。。。

マップ名の書式

autofs のマップ名の書式は異常なほど癖がある。古いバージョンでは 1. しか使えなかった。

  1. ldap:[servername:]basedn
  2. ldap:[//servername/]basedn
  3. ldap:mapname
  4. mapname

4. のマップ名書式は nsswitch.conf に記載してある検索順序で読み出すのだが、マスターマップ名でしか(マスターマップ内ではない、、)機能しなかった期間が結構あった。。。 (prefixに/etc/をつけた)ファイルマップの中に +mapname があれば、files の次の検索順序にある方法で読み出すのが正解かなぁ。

autofs の変遷

RedHat7.2/7.3/8/9/Fedora1
  1. autofs ver 3.x
  2. LDAP v2 での匿名バインド??。OpenLDAPがサーバの場合では、bind_v2 bind_anon_dn の許可が必要。
  3. サーバ、検索ベースは、/etc/openldap/ldap.conf を参照
  4. マスターマップ名は auto.master で固定
  5. LDAP schema は、1. => 2. の順で検索
  6. マップ名書式は、1. のみ
Fedora2/Fedora3
  1. autofs ver 4.x
  2. LDAP v3 での匿名バインド。
  3. サーバ、検索ベースは、/etc/openldap/ldap.conf を参照
  4. マスターマップ名は auto.master で固定
  5. LDAP schema は、1. => 2. の順で検索
  6. マップ名書式は、1. と 2.
Fedora4/Fedora5
  1. autofs ver 4.x
  2. LDAP v3 での匿名バインド。
  3. サーバ、検索ベースは、/etc/openldap/ldap.conf を参照
  4. マスターマップ名は任意で指定可能 (デフォルトは auto.master )
  5. LDAP schema は、1. => 2. => 3. の順で検索
  6. マップ名書式は、1. と 2.
CentOS4
  1. autofs ver 4.x
  2. LDAP v3 での匿名バインド。
  3. サーバ、検索ベースは、/etc/openldap/ldap.conf を参照
  4. マスターマップ名は任意で指定可能 (デフォルトは auto.master )
  5. LDAP schema は、1. => 2. => 3. の順で検索可能だったものに固定。
  6. マップ名書式は、1. と 2. と 3. と 4.
Fedora6/Fedora7/Fedora8/CentOS5
  1. autofs ver 5.x
  2. LDAP v3 での匿名バインド。
  3. サーバ、検索ベースは、/etc/openldap/ldap.conf を参照
  4. マスターマップ名は任意で指定可能 (デフォルトは auto.master )
  5. LDAP schema は、1. or 2. or 3. を指定可能 (デフォルトは1. )
  6. マップ名書式は、1. と 2. と 3. と 4.

まとめ

autofs ver 5.x でまともな実装になったなぁ〜。でも、pam_ldap/nss_ldap とLDAP繋がりで共通の設定ファイルとかあったらいいのにぃ〜。

追記

Open Directory の設定のまとめ 2008Q1


[全文を読む]

2007年11月16日

NFSv4とKerberosを組み合わせる

どうもNFSはパケットだだ漏れ、認証もへったくれもない、スピード狂のネットワークファイルシステムのイメージは拭えない。ただ、Linux のNFSv3では AUTH_SYSぐらいしか使えなかった(使わなかった?)のも大きいかも。

NFSv3 から NFSv4 への移行に合わせて、まともなKerberos認証を組み合わせてみた。 丁度、OpenDirectory にはもれなく、即運用可能なKerberosサーバ群がついてくるので、、、。

前提として

  • NFS サーバ/クライアントは、Fedora2以上/CentOS4以上である。
  • NFS サーバ/クライアントになるマシンのKerberos のクライアント設定(/etc/krb5.conf)が完了してる。
  • NFS サーバ/クライアントにはユーザアカウント情報がある。
    • /etc/passwd ファイル内であれ、LDAPサーバ上であれ、あればいい。

参考

NFSv4 のドメイン設定

NFSサーバ/クライアントの両方で、下記ファイルを編集してrpcidmapdを再起動

/etc/idmapd.conf

...
Domain = example.com
...

nfs用のサービスプリンシパルの登録

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 にコピーする

rpc.gssd を有効化

/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 をロードしておく必要がある。。。どうでもいいけど。

NFSv4 のサーバの設定

/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

クライアントでNFSv4のマウント

これで最後で 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 めぇ!

追記

Open Directory の設定のまとめ 2008Q1


[全文を読む]

2007年11月10日

netatalk で Kerberos 認証

だいぶ前に設定できたのだが備忘として書いておこう。

Debian/etch 環境の netatalk は DHX認証のプラグインが含まれていないので、GSSAPI 経由で Kerberos v5 を使う。

前提として、

  • netatalkサーバはクリアテキスト認証でのファイル共有が可能
  • Kerberos のクライアント設定(/etc/krb5.conf)が完了してる。
    • ユーザは既に特定のレルムからKerberos のチケットが入手できる。
    • netatalk サーバが動いてるマシンのデフォルトのレルムが上と同じ。でもサービスプリンシパルの登録はしていない。

使っている 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認証が提供されるのだろうかねぇ。

追記

Open Directory の設定のまとめ 2008Q1


[全文を読む]

Leopard はサーバが無くとも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 ? 、、、そのうち情報が出てくるのかなぁ。

追記 (2007/11/30)

専門家では、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を見る限り)が、、、、どうも取り方がわからん。

追記 (2008/08/28)

LKDC の レルム名は、次のように特殊な名前のTXTレコードの問い合わせを使うらしい。

# dns-sd -Q _kerberos.hostname.local txt

avahiではこの形の問い合わせや通知が出来ないので、もうひねり加えないと使えない模様である。


[全文を読む]

2007年11月7日

Leopard が netatalk サーバを自動的に見つられる設定

Leopard は、いい意味でも悪い意味でも、過去の遺産をばっさり切り捨てたツンなOSである。

SLP によるサービス検索機能がなくなってしまったらしく、 netatalk は AFPサーバ機能を SLP 通知しているので見つけられなくなってしまったらしい。

そんな人は、avahi を使えとか言われるが、設定方法があまり載っていない。。。

Debian/etch だと avahi-daemon は設定が何もなく?困るし。。。

avahi でサービスを通知する方法

ドキュメントを読めばよく、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 の設定のまとめ 2008Q1


[全文を読む]

OpenDirectory で Feodra/CentOSを 認証

Open Directory を立ち上げるのは非常に簡単である。 例えば、インストールするとき標準構成とかを選べば、勝手に OpenDirectory のマスターが出来上がるし、それ以外の構成でもGUIのツールを使い、LDAPの基本DNやKerberosのrealm名を指定して数クリックで完了する。

これだけで、LDAPサーバとKerberosサーバ群が直に使える状態になるのは、なんというか、、、楽だ。

CentOS5/Fedora7 の認証

authconfig を使えば、簡単にできる。同様なGUIの管理ツールauthconfig-gtk があるのでこっちを使ってよいかも。

  • ユーザ情報には、LDAPサポートを有効にして、LDAPの設定情報に OpenDirectory の検索ベースとIPアドレスを指定する。
  • 認証には、Kerberosサポートを有効にして、Realm /KDC/管理サーバに、OpenDirectoryのKerberos領域とIPアドレスとポート番号(KDCは88/管理サーバ749)を指定する。

上記に設定で書き換わるのは、次のファイル群なので面倒な問題が起きた場合これらのファイルを眺めればいい。

  • /etc/nsswitch.conf
  • /etc/krb5.conf
  • /etc/pam.d/system-auth
  • /etc/ldap.conf

大体、RedHat7くらいから同様な設定で行けたみたいだ。。。知らんかった。。。(RedHat6.2とかだともう一捻りが必要だ、、、多分知らんでもいいと思う。)

2つ問題点

Open Directory から提供されるうち基本的な部類の情報に プラットホーム依存なものがある。

  • ログインシェル
  • ホームディレクトリ

どのプラットホームに共通してあるシェルは、/bin/sh と /bin/csh くらいだが、bash がなければ別途パッケージをいれ、/bin/bash にシンボリックリンクを張れば、/bin/bash を指定できるので、大した問題では無い。

残るのは、ホームディレクトリをどうするねん。。。 ネットワークファイルシステムはどれにするとか、 オートマウントを使うか使わないかとか、、、それはプラットホーム依存ばりばりなんだなぁ。。。

で、Leopard で実装された autofs がLDAPからマップ情報をとれるので、これは面白いことになってきたって話。。。。(続く)

追記

Open Directory の設定のまとめ 2008Q1


[全文を読む]

祝 Leopard Server げっと、、、10日後

10日くらい前に予約注文したでゲットした MacOSX Server 10.5 (Leopard Server)をいじくり倒してちょっと寝不足気味である。 それで、今3度目にクリーンインストールの真最中。

まぁ、前バージョンに比べて、RADIUS サーバ / autofs / NFS4 の機能が追加や、管理ツールが一層に磨きがかかっているに違いないと、わくわくしながら触っていたのだが。

ちょっと寝不足気味。

autofs

最初は 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

NFS4 はまだ実験的実装でまだ安定的にサポートできていないみたい。ちょっと読み違いだなぁ。

、、、で嫌なことを思い出した

MacOSX 全般でファイル名を UTF8 NFD のエンコードで扱えるように、UTF8 NFD <-> UTF8 NFC の変換をよろしくやっている。NFS だけ例外で素で通して何もしてくれない。。。

Linux や他のUnixとの相互運用時に引っかかるところ、普通は NFS をあきらめ samba/netatalk で逃げる、、、つまりautofs/NFS がどんなに賢くなっても意味ないじゃん

まぁ、他のUnixは捨てって言えればいいのだがぁ。

ちょっと思い出して疲れた。

RADIUS サーバ

まだ、触れていません。。。

追記

Open Directory の設定のまとめ 2008Q1


[全文を読む]