Kopanoのユーザー管理をDBからSamba-ad-dcに移行

SASL over TLSの設定

addc.hogeserber.hogeddns.jp側の設定

ユーザー管理は Samba ad dc で行う。この記事で phpLDAPadmin から LDAPS による接続ができる状態になっていることを確認済み。

Kopanoのスキーマを登録するために Samba ad dc サーバーの設定に追加が必要。

/etc/samba/smb.conf ※Samba ad dc サーバーで赤文字を追加

[global]
…
    # SASLでTLSを有効化
    ldap server require strong auth = allow_sasl_over_tls
…

Samba ad dc にスキーマを登録する際に ldb-tools に含まれるツールを使うが、そのツールが SASL をデフォルトで使う。この設定を追加しないと SASL なのに TLS が使われている！と怒られる。

Samba ad dc サーバーを再起動。

$ sudo systemctl restart samba-ad-dc

Kopano LDAPスキーマの登録準備

temp.hogeserver.hogeddns.jp側の設定

Samba ad dc サーバーで実施するのが普通なのかもしれないが、この先に色々発生する問題を解決する知識が得られるかも？と考えて temp サーバーで実行。
※実際は Samba ad dc サーバーで実施しても全く問題なし。

スキーマ登録ツールのダウンロード

スキーマ登録について色々探ってみて、これが使えそうと分かる。
Kopano Wiki / 1. Installation - Core → User backend で Samba を選択。
Bitbucket / kopano-ads-source/samba/kopano-samba-ads

ここからファイルをダウンロードするには、左上にある「ファイル」の下にある「…」をクリックし、表示されるポップアップメニューの「ダウンロード」をクリックする。

スキーマ登録ツールが利用するライブラリのインストール

スキーマ登録ツールは LDB Tools を使う。また、LDB Tools 実行時に Samba オプションを利用するので Samba もインストールする必要がある。なお、LDB というのは LDAP によく似た Samba の組み込みデーターベースのこと。

dos2unixはテキストファイルの改行コードを変換するツールで、スキーマ登録ツールの中にスキーマファイルを変換する動作が書かれているため併せてインストールする。

$ sudo apt install samba ldb-tools dos2unix

スキーマ登録ツール実行環境の設定

TLSの受け入れ条件を設定する。

/etc/samba/smb.conf ※以下を追記

[global]
…
    tls verify peer = ca_and_name
    tls cafile = /usr/share/ca-certificates/hogeserver.hogeddns.jp.crt
#   tls crlfile =
…

※ウチで無効化した証明書はないので、CRL(無効リスト)なし。

なお、LDB Tools に含まれるコマンドを実行する時に smb.conf を参照するだけのようなので、Samba の再起動は必要ない。

スキーマ登録ツールの改変

さて、スキーマ登録ツールの使い方を見てみる。

$ bash kopano_schema_add.sh
Error: Please select domain dn
Usage:
  kopano_schema_add.sh <domain dn> <path to kopano ldf directory> <options>
                -H <url>                     Database URL
                -U <username>%<password>     Set the network username
                -v                           verbose
                -writechanges                without this option we
                                             do not make any changes
                                             on the database
                -dontclean                   do not cleanup temporary
                                             files

Examples:
  kopano_schema_add.sh DC=SAMDOM,DC=EXAMPLE,DC=PRIVATE 
                ./ 
                -v 
                -H /usr/local/samba/private/sam.ldb
  kopano_schema_add.sh DC=samdom2,DC=example,DC=private 
                /home/kopano/myKopanoLDF_Files 
                -H ldap://mydc.samdom2.example.private 
                -U Administrator%sTR0ngPassWD 
                -writechanges

パスワードをコマンドラインに書き込むようになっているようだが、ヒストリーに残るのと、パスワードに特定の記号があるとうまく動かないことから、スクリプトをちょっと改造。以下を参考にした。
Qiita / シェルスクリプトでパスワード入力プロンプト

kopano_schema_add.sh ※216行目付近に赤文字を追記

…
for arg in "$@" ; do
    case $arg in
    "-U")
        userpass="-U `eval echo '$'$[$argno+1]`"
        read -sp "Password: " temppass
        userpass=$userpass%$temppass
        ;;
    "-H")
…

スキーマ登録ツールのテスト実行

スキーマ登録ツールをテスト実行。

$ cd samba/kopano-samba-ads
$ bash kopano_schema_add.sh DC=hogeserver,DC=hogeddns,DC=jp ./ 
 -H ldaps://addc.hogeserver.hogeddns.jp 
 -U Administrator%[Administratorのパスワード]
dos2unix: converting file kopano-ads.ldf.unix to Unix format...
dos2unix: converting file kopano-display-ads.ldf.unix to Unix format...
Error: Can not find CN=kopanoDynamicGroup-Display,CN=401,CN=DisplaySpecifiers,CN=Configuration,DC=hogeserver,DC=hogeddns,DC=jp

※2022/08/27 追記
LDAPでもSASLが有効なので、ldapsではなく、ldapでいけるかもしれない。
また、この日に実行してみたところ、パスワード指定がないとスクリプトが固まる(ldbsearchでパスワードを聞いているが、それが表示されないままに止まっている)。そのため、パスワードを引数で渡すように修正した。

実行できた。テストのため -writechanges を付けていなかったのでデータベースは変わっておらず、登録結果に KopanoDynamicGroup-Display …がない、というエラーが表示されているだけ。ここまでくればスキーマ登録はできそう。

うまく動作しないときには、これとは違う面倒なエラーがでる。

• Error: Can not find ldbmodify
  → ldb-toolsをインストールしていなかった
• Error: installed version ldbmodify is not supported
  → Sambaをインストールしていなかった
• Failed to connect to ldap URL 'ldaps://addc.hogeserver.hogeddns.jp' - LDAP client internal error: NT_STATUS_INVALID_PARAMETER_MIX
  → CA証明書をsmb.confで定義していなかった
• Failed to bind - LDAP error 49 LDAP_INVALID_CREDENTIALS - <8009030C: LdapErr: DSID-0C0904DC, comment: AcceptSecurityContext error, data 52e, v1db1> <>
  → パスワードを正しく指定できていなかった
• Failed to bind - LDAP error 53 LDAP_UNWILLING_TO_PERFORM - <SASL:[GSS-SPNEGO]: Sign or Seal are not allowed if TLS is used> <>
  → SASL認証なのにTLSを使おうとしていた
• Error: Can not find CN=user-Display,CN=401,CN=DisplaySpecifiers,CN=Configuration,DC=hogeserver,DC=hogeddns.DC=jp
  → 要素指定の誤り(カンマであるべきところにピリオド)
• Error: ldbmodify reported an error
  → デフォルトではスキーマの更新が許可されていなかった

Samba ad dc のバックアップ

addc.hogeserber.hogeddns.jp側の設定

この日のために準備した Samba ad dc のバックアップスクリプトを実行。
Ubuntu18.04 Samba-ad-dcのバックアップ

$ sudo samba_backup

これでも多分問題ないレベルに復元ができるはずだが、念のためにESXiでスナップショットをとるなど、復元のための準備をしておく。

Samba ad dc のスキーマ保護解除

addc.hogeserber.hogeddns.jp側の設定

スキーマは下手に更新されると Samba ad dc が起動しなくなってしまうのでデフォルトではガードがかかっている。このガードを外しておく。

/etc/samba/smb.conf ※Samba ad dc サーバーで赤文字を追加

[global]
…
    # スキーマ更新を有効化
    dsdb:schema update allowed = true
…

Samba ad dc サーバーを再起動。

$ sudo systemctl restart samba-ad-dc

Kopano LDAPスキーマの登録

temp.hogeserver.hogeddns.jp側で実行すると結果として、
addc.hogeserber.hogeddns.jp側にスキーマが流し込まれる。

さぁ、本番登録。

$ bash kopano_schema_add.sh DC=hogeserver,DC=hogeddns,DC=jp ./ 
 -H ldaps://addc.hogeserver.hogeddns.jp 
 -U Administrator%[Administratorのパスワード] 
 -writechanges
Password: dos2unix: converting file kopano-ads.ldf.unix to Unix format...
Modified 35 records successfully
Modified 15 records successfully
Modified 2 records successfully
Modified 2 records successfully
Modified 2 records successfully
Modified 2 records successfully
Modified 2 records successfully
dos2unix: converting file kopano-display-ads.ldf.unix to Unix format...
Modified 3 records successfully
Modified 3 records successfully
…
Modified 1 records successfully

Wrote 557 changes to -H ldaps://addc.hogeserver.hogeddns.jp

※2022/08/27 追記
LDAPでもSASLが有効なので、ldapsではなく、ldapで実行可能。
パスワードを引数で渡すように、コマンド実行行を修正。

スキーマ登録完了！

phpLDAPadminで接続してみたところ、例えば

CN=Kopano-Account,CN=Schema,CN=Configuration,DC=hogeserver,DC=hogeddns,DC=jp
CN=Kopano-Admin,CN=Schema,CN=Configuration,DC=hogeserver,DC=hogeddns,DC=jp

とかが登録されている。

Samba ad dc のスキーマ保護と再起動

addc.hogeserber.hogeddns.jp側の設定

スキーマはデフォルトで保護されていたので、元に戻しておく。

/etc/samba/smb.conf ※Samba ad dc サーバーで赤文字を追加

[global]
…
    # スキーマ更新を有効化
#   dsdb:schema update allowed = true
…

Samba ad dc サーバーを再起動する。

$ sudo systemctl restart samba-ad-dc

スキーマに問題が発生していなければ Samba ad dc は起動する。

server.cfgの設定

temp.hogeserver.hogeddns.jp側の設定

従来 db でユーザー管理をしていたが ldap によるユーザー管理に変更する。
ユーザーを検索する方法はこれから作成する /etc/kopano/ldap.cfg に書き込むので、このファイルが参照されることを確認する。

/etc/kopano/server.cfg

…
##############################################################
#  USER PLUGIN SETTINGS

# Name of the plugin that handles users
# Required, default = db
# Values: ldap, unix, db
#user_plugin        = db
user_plugin         = ldap

# configuration file of the user plugin, examples can be found in /usr/share/doc/kopano/example-config
user_plugin_config  = /etc/kopano/ldap.cfg ← 確認

…

※/etc/kopano/ldap.cfg は元々書かれていたので確認するのみ。

ldap.cfgの作成

temp.hogeserver.hogeddns.jp側の設定

ユーザーやグループの情報を参照しようとするとき、ldap.cfg で設定されている条件で検索をしに行くようになっている。

ldap.cfg は doc/kopano からコピーしてくるように書かれているが、Ubuntuのパッケージにない…ない…検索してみたところ、これらしい。
GitHub / Kopano-dev/kopano-core/installer/linux/ldap.cfg

後で調べてみたら、Ubuntu のソースパッケージにも入っていた。
ubuntu packages / kopano-server (8.5.5-0ubuntu1) [universe] → [kopanocore_8.5.5.orig.tar.xz]

なんちゃって翻訳しながら設定値を考えてみる。

/etc/kopano/ldap.cfg

##############################################################
#  LDAP DIRECTORY USER PLUGIN SETTINGS
#

# 実装の選択。
# もし /usr/share/kopano/*.cfg の設定を書き換える必要があるなら、
# この設定ファイル(/etc-resident)の最後にそうしてください。
#
#!include /usr/share/kopano/ldap.openldap.cfg
!include /usr/share/kopano/ldap.active-directory.cfg

# LDAP URI
# 接続先のLDAPサーバー詳細、例えば ldaps://servername:port
# 'ldaps'を使用するときは、/etc/ldap/ldap.confがTLS_CACERTで正しく設定されて
# いることを確認してください。スペース区切りのURIを複数指定することもできます。
ldap_uri = ldaps://addc.hogeserver.hogeddns.jp:636

# LDAPサーバーに格納されている文字列のキャラクターセットです。通常これは
# utf-8ですが、これはあなたの設定によって異なります。ここで指定される
# キャラクターセットはiconv(1)によってサポートされているものに限ります。
# すべての文字セットについてはiconv -lを参照してください。
ldap_server_charset = utf-8

# すべてのLDAP接続をTLSで保護するように要求します。
# 確立できない場合、接続は拒否されます。
# ※この設定はこのバージョンでは使えませんでした。
#ldap_starttls = no

# 通常の操作で使用するユーザーのDN(ldap_authentication_method が"bind"に
# 設定されている場合は認証には使用されません)。
# 空の場合、匿名バインディングが使用されます。
# ldap_authentication_methodオプションがpasswordに設定されている場合、
# userPassword属性はこのユーザーに対して読み取り可能でなければなりません。
ldap_bind_user = administrator@hogeserver.hogeddns.jp

# LDAP bind password
ldap_bind_passwd = adminさんのパスワード

# The timeout for network operations in seconds
#ldap_network_timeout = 30

# 一度にダウンロードされるクエリの結果数を制限します。
# デフォルトは1000です。
#ldap_page_size = 1000

##########
# Object settings

# 最上位の検索ベース、すべてのオブジェクトはこのツリーの下にあるはずです。
ldap_search_base = dc=hogeserver,dc=hogeddns,dc=jp

# カスタム定義のLDAPプロパティマッピングを使用します。
# これはほとんどの環境では必須ではありませんが、
# 特別なLDAPプロパティのカスタムMAPI属性へのカスタムマッピングを可能にします。
#!propmap /etc/kopano/ldap.propmap.cfg

# Kopanoを使えるユーザー・グループに限定して検索できるようにする
ldap_user_search_filter = (&(objectClass=user)(kopanoAccount=1))
ldap_group_search_filter = (&(objectClass=group)(kopanoAccount=1))

Kopano documentation には、デフォルトの設定値を変更するならこのファイルの最後に追加しておけ、と書かれている。例として ldap_user_search_filter と書かれている。実際に移行してみると、ビルトインユーザーやビルトイングループが検索結果として表示されてしまってややこしいので、上記の通りKopanoを利用できるユーザー・グループだけに限定してみた。

ご覧の通りAdministratorのパスワードをこのファイルの中に書き込んでいるので、以下の通りの権限設定とした。

$ sudo chmod 600 /etc/kopano/ldap.cfg
$ sudo chown kopano:kopano /etc/kopano/ldap.cfg
$ ls -l /etc/kopano/ldap.cfg
-rw------- 1 kopano kopano 2593 Jul  7 20:08 /etc/kopano/ldap.cfg

なお、この ldap.cfg が include するファイルは以下で発見。
Ubuntu パッケージ検索 Kopano-serverパッケージ
ここからファイル一覧を見ると、以下にファイルがあることが分かる。

/usr/share/kopano/ldap.active-directory.cfg
/usr/share/kopano/ldap.openldap.cfg
/usr/share/kopano/ldap.propmap.cfg

AppArmorの設定

temp.hogeserver.hogeddns.jp側の設定

ldap.cfg を読み込もうとしても AppArmor によってアクセスが無効化されてしまうため、追加設定が必要。

今回の作業で見つけられた設定

ここで書くのは多分のレベル。動作が阻害されると syslog に出力されるので、必要ならば追加で対策してください…

/etc/apparmor.d/usr.sbin.kopano-server からincludeされるlocalなファイルに設定を書き入れる。今までこの手の問題に遭遇していない場合0バイトのファイルのままになっているかもしれない。

/etc/apparmor.d/local/usr.sbin.kopano-server

capability sys_resource,

/run/kopano/search.sock rw,
/etc/ssl/openssl.cnf r,

/etc/kopano/ldap.cfg r,
/usr/share/kopano/ldap.active-directory.cfg r,
/usr/share/kopano/ldap.propmap.cfg r,
/etc/ldap/ldap.conf r,

dbus bus=system,

アクセス先のファイルや、dbusの機能呼び出しも許可している。

指定方法がいまいち分からずツールを使ってこの問題を解決しようとした関係で、思わぬファイルが書き換えられていた。これは元の状態が全く分からないので、そのまま貼り付けてみる。

/etc/apparmor.d/usr.sbin.kopano-dagent

# Last Modified: Sun Jul  7 08:42:31 2019 ← 書き換えられたらしい…
#include <tunables/global>

/usr/sbin/kopano-dagent flags=(attach_disconnected) {
  #include <abstractions/base>
  #include <abstractions/lxc/container-base>
  #include <abstractions/nameservice>
  #include <abstractions/python>
  #include <abstractions/user-tmp>
  #include <local/usr.sbin.kopano-dagent>

}

/etc/apparmor.d/local/usr.sbin.kopano-dagent

capability sys_resource,
/etc/ssl/openssl.cnf r,

設定を反映。

$ sudo systemctl reload apparmor

ツールを使った設定

AppArmor の設定はツールを使えば比較的簡単になるが、まとめてみたらついでの量を超えてしまったので、別の記事に切り出した。

もしかしたら後で役立つかもしれないし、記事が長くなるし…

Postfixの設定

temp.hogeserver.hogeddns.jp側の設定

Postfix はメールを受信するときに「こんなメアドを持っている人っている？」を確認する。今までは Kopano の DB を確認しに行っていたが、これからは、Samba ad dc が提供する LDAP を見に行ってもらう。
Kopano Wiki / Postfix

LDAPライブラリをインストール

Postfix はデフォルトでは LDAP を扱えない。扱えるようにするには、追加のモジュールをインストールする必要がある。

$ sudo apt install postfix-ldap

main.cfを変更

Wikiに沿って修正した上で試行錯誤した結果から見ると、従来の設定から temp.hogeserver.hogeddns.jp 宛ての受信設定を抜き取り、virtual_mailbox で temp.hogeserver.hogeddns.jp のメールを受け取るように設定すれば良いことが分かった。

/etc/postfix/main.cf

… virtual_mailbox を使うので重複しないように設定を変える
#mydestination = $myhostname, temp.hogeserver.hogeddns.jp, localhost.hogeserver.hogeddns.jp, , localhost
mydestination = localhost.hogeserver.hogeddns.jp, , localhost
#
… virtual_mailbox を設定する
# for Kopano
virtual_mailbox_domains = temp.hogeserver.hogeddns.jp
virtual_mailbox_maps = ldap:/etc/postfix/ldap-users.cf
#virtual_alias_maps = mysql:/etc/postfix/mysql-aliases.cf
virtual_alias_maps = ldap:/etc/postfix/ldap-aliases.cf, ldap:/etc/postfix/ldap-groups.cf
virtual_transport = lmtp:127.0.0.1:2003
mailbox_command = /usr/sbin/kopano-dagent "$USER"
mailbox_transport = kopano: kopano_destination_recipient_limit = 1

※virtual_transport で指定している LMTP(Local Mail Transfer Protocol) というプロトコルのサービスは kopano-dagent が提供している。

ユーザーは3種類のメールアドレスを持つことができる。

• ユーザー自身が持つメールアドレス(ldap:/etc/postfix/ldap-users.cfで読み取る)。
• ユーザー自身がもつ別メールアドレス(ldap:/etc/postfix/ldap-aliases.cfで読み取る)。
• 所属しているグループが持つメールアドレス(ldap:/etc/postfix/ldap-groups.cfで読み取る)。

以降でこれを読み取る設定をしていく。

ldap-*.cfの新規作成

main.cf の virtual_mailbox_maps と virtual_alias_maps はメールアドレスのリストを指す。ここに LDAP 検索テーブルを設定したので、中身をここで作成する。

上記の Kopano Wiki / Postfix ベースで作成したが LDAPS で接続するための変更等が必要なため、マニュアルも併せて参照した。
ubuntu manuals / ldap_table - Postfix LDAP client configuration

やってみて分かったのは ldap-*.cf の1つでも間違いがあると、すべてのメールが受け取れなくなること。エラーが発生したら、ldap-users.cf、ldap-aliases.cf、ldap-groups.cf の順に1つ1つ追加しながらメールの送受信を試すと良さそう。

ldap-users.cf

ユーザー自身が持つメールアドレスを取り出す ldap-users.cf を定義する。

/etc/postfix/ldap-users.cf ※新規作成

server_host = ldaps://addc.hogeserver.hogeddns.jp:636
bind = yes
version = 3
bind_dn = cn=administrator,cn=Users,dc=hogeserver,dc=hogeddns,dc=jp
bind_pw = adminさんのパスワード
search_base = cn=Users,dc=hogeserver,dc=hogeddns,dc=jp
query_filter = (&(objectClass=user)(kopanoAccount=1)(mail=%s))
scope = one
result_attribute = mail

server_host で サーバーとプロトコル(LDAPS)、ポート(636)を指定。
bind で LDAP サーバーとバインドすることを示す。
version でプロトコルバージョンが3であることを示す。

bind_dn でバインドするユーザーを示す。
bind_pw でバインドするユーザーのパスワードを示す。

search_base でユーザー情報の検索先となる場所を示す。ユーザーとグループはUsersの中にあることを phpLDAPadmin で確認した。
query_filter で宛先となるメールアドレスを持つユーザーを検索条件とする。
scope は one としてその階層だけを探すことにした。

result_attribulte で問い合わせへの回答内容を mail としている。

start_tls = yes の指定は不要。今までの設定で Samba ad dc 側で TLS している。
tls_ca_cert_file によるCA証明書の設定も同様。

query_filter や result_attribute で mail を使っている(%sには宛先のメールアドレスが入っている)。phpLDAPadminで接続するとEmailが該当する項目に思われたが、ldapsearchで探してみたところ、Email という項目はなく mail に Email と同じ内容が書かれている…これはエイリアスが設定されているからだった。

$ ldapsearch -H ldaps://addc.hogeserver.hogeddns.jp:636 
-b "cn=Users,dc=hogeserver,dc=hogeddns,dc=jp" -s sub 
-D administrator@hogeserver.hogeddns.jp -W 
"(&(objectClass=user)(mail=administrator@temp.hogeserver.hogeddns.jp))"

Enter LDAP Password:<administratorのパスワード>
…
kopanoAccount: 1
mail: Administrator@temp.hogeserver.hogeddns.jp
…

ldap-aliases.cf

ユーザー自身が持つ別メールアドレスは各ユーザーの otherMailbox に格納されているので、検索条件を作る。戻されるのはユーザーのメールアドレス。

/etc/postfix/ldap-aliases.cf ※新規作成

server_host = ldaps://addc.hogeserver.hogeddns.jp:636
bind = yes
version = 3
bind_dn = cn=administrator,cn=Users,dc=hogeserver,dc=hogeddns,dc=jp
bind_pw = adminさんのパスワード
search_base = cn=Users,dc=hogeserver,dc=hogeddns,dc=jp
query_filter = (&(objectClass=user)(kopanoAccount=1)(otherMailbox=%s))
scope = one
result_attribute = mail

ldap-groups.cf

グループが持つメールアドレスの検索条件を作る。宛先となるグループに含まれるユーザーのメールアドレスを戻す。戻り値が複数あるときは leaf_result_attribute を使うみたい。

/etc/postfix/ldap-groups.cf ※新規作成

server_host = ldaps://addc.hogeserver.hogeddns.jp:636
bind = yes
version = 3
bind_dn = cn=administrator,cn=Users,dc=hogeserver,dc=hogeddns,dc=jp
bind_pw = adminさんのパスワード
search_base = cn=Users,dc=hogeserver,dc=hogeddns,dc=jp
query_filter = (&(objectClass=group)(kopanoAccount=1)(mail=%s))
scope = one
leaf_result_attribute = mail
special_result_attribute = member

権限設定

バインドユーザーのパスワードを設定ファイルに書き込んでいるので、権限を変えておく。

$ sudo chmod 600 ldap-users.cf
$ sudo chmod 600 ldap-aliases.cf
$ sudo chmod 600 ldap-groups.cf

設定の反映

Postfixを再起動して設定を反映させる。

$ sudo systemctl restart postfix

root@temp.hogeserver.hogeddns.jpにメールが届かない

2020/01/04追記
今日、サーバー移行をした後でテストをしていたら、root宛てのメールが届かないことが分かった。このことに見事に対応しているサイトを発見、root宛のメールが届くようになった。
稲葉サーバーデザイン / Postfixによるメール送信設定

まずは、root宛のメールはローカルに展開する設定ファイルを作成。

/etc/postfix/transport ※新規作成

root@temp.hogeserver.hogeddns.jp local:
* :

ハッシュファイルを作成。

$ sudo postmap /etc/postfix/transport

作成したハッシュ情報を設定の最終行に追加。

/etc/postfix/main.cf

transport_maps = hash:/etc/postfix/transport

Postfixを再起動して設定を反映させたところ、rootにメールが届くようになった。

$ sudo systemctl restart postfix

ドメインユーザーやグループにKopano属性を付与

ドメインにいるユーザーやグループに Kopano 属性を付与して、Kopano や Postfix にユーザーとグループを認識させる。

Active Directory ユーザーとコンピューターで付与

ここでは第3のホスト Windows10 Professional を利用。

すべてをUbuntu上で実施できたらかっこいいなとは思うものの、LDAPを直接操作するにしてもどこに何を追加すれば良いのか…マニュアルで調べて実行するのは大変なので Windows10 試用版を使わせてもらって属性を設定してみる。

Kopano Active Directory Extension のインストール

ホスト名を WinTemp とした Windows10 Professional をドメインに参加させると、Samba ad dc にこんなエントリが追加される。
CN=WINTEMP,CN=Computers,DC=hogeserver,DC=hogeddns,DC=jp

このWindows10にRSATをインストールし、「Active Directory ユーザーとコンピューター」を起動、ユーザーのプロパティを見てみたが、この時点ではKopano関連のタブはない。

Kopano Knowledge Base / 1.Installation Core をたどってみると、最終バージョンの AD exstension をダウンロードしてインストールするように書かれている。ただしここには製品版しかなく Community版を利用している自分はダウンロードできない。コミュニティ版であればこちらからダウンロードできる。

この日のバージョンは KopanoADS-1.1-88-64bit.msi だった。
マニュアルに Setup Type は Typical を選択する絵が書かれてるので、これをインストールしたところ、ユーザーのプロパティに Kopano, Kopano Features のタブが現れた。

ユーザーへのKopano属性付与

AD Extension を利用して Kopano の属性を付与する。

Kopano Account にチェックを入れると、KopanoAccount 属性が追加される。

Administrator には 2つのメールアドレスを設定してみた。
　administrator@temp.hogeserver.hogeddns.jp
　root@temp.hogeserver.hogeddns.jp

honmyou には1つだけメールアドレスを設定。
　honmyou@temp.hogeserver.hogeddns.jp
　※画像は割愛

グループへのKopano属性付与

「Active Directory ユーザーとコンピューター」で Family というグループを作成。

Kopano Distribution List にチェックを入れると、KopanoAccount 属性が追加される。

グループにKopano 属性のメールアドレスを設定。
　family@temp.hogeserver.hogeddns.jp

グループのメンバーには Administrator と honmyou を加えた。このグループにメールを送ると2人にメールが届くようになる。

コマンドで付与

addc.hogeserber.hogeddns.jp側の設定

Windows 10 の RSAT は 1809 以降、FoD(Feature On Demand)で提供されるようになったようだが、ここに「Active Directory ユーザーとコンピューター」が見当たらない。設定からオプション機能の「Active Directory Domain Services およびライトウェイトディレクトリサービスツール」をインストールしてみたが Samba ad dc は未対応の機能なので使えない。

こういう動向ならば、別のツールでも操作できるようにしておかなきゃ駄目かも…ということでやり方を探してみた。

ユーザーの追加と属性付与

ユーザーを追加してみる。

$ sudo samba-tool user create rohhie -U administrator
New Password:
Retype Password:
User 'rohhie' created successfully

※本番環境に rohhie を作っていなかったのでちょうどいい、作ってみた。

ユーザーの属性を編集するコマンドで、Kopano 属性を付与する。

$ sudo samba-tool user edit rohhie -U administrator

vi が起動して属性情報が表示されるので、KopanoAccount 属性と mail 属性を付与する。

dn: CN=rohhie,CN=Users,DC=hogeserver,DC=hogeddns,DC=jp
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: rohhie
instanceType: 4
whenCreated: 20190727213015.0Z
whenChanged: 20190727213015.0Z
uSNCreated: 6787
name: rohhie
objectGUID: e3002107-55e7-4df6-b252-441d3075b6d5
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
lastLogon: 0
primaryGroupID: 513
objectSid: S-1-5-21-1946807796-1988204200-2484953960-1120
accountExpires: 9223372036854775807
logonCount: 0
sAMAccountName: rohhie
sAMAccountType: 805306368
userPrincipalName: rohhie@hogeserver.hogeddns.jp
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=hogeserver,DC=hogeddns,DC=jp
pwdLastSet: 132087366154995600
userAccountControl: 512
uSNChanged: 6789
distinguishedName: CN=rohhie,CN=Users,DC=hogeserver,DC=hogeddns,DC=jp
kopanoAccount: 1
mail: rohhie@temp.hogeserver.hogeddns.jp

変更後、 :wq で保存・終了すると、以下が表示される。

Modified User 'rohhie' successfully

これで Kopano のユーザーとして認識される。

ユーザーに付与する属性の詳細

画面入力が属性にどのように反映されるのかを確認。GUIじゃなくても属性を直接編集すれば同じ結果が得られる…ハズ。
この日使っている KopanoADS-1.1-88-64bit.msi のバージョンであり、過去とは違うかもしれないし、未来に変わるかもしれない。

まず、Kopano ユーザーであることを示す方法。種別ごとに記載。

■Active User
kopanoAccount: 1

■Administrator
kopanoAccount: 1
kopanoAdmin: 1
kopanoSharedStoreOnly: 0

■System Administrator
kopanoAccount: 1
kopanoAdmin: 2
kopanoSharedStoreOnly: 0

■Shared store only
kopanoAccount: 1
kopanoAdmin: 0
kopanoSharedStoreOnly: 1

■Room / Equipment
kopanoAccount: 1
kopanoAdmin: 0
kopanoSharedStoreOnly: 1
kopanoResourceType: room または equipment のいずれか
kopanoResourceCapacity: 0～1000 の数字

※一時的に Kopano ユーザーから外すときには KopanoAccount に 0 を指定すれば良さそうだけれど、データストアのフックが多分外れるから要注意。

メールアドレスとエイリアスは以下の通りに指定。

mail: rohhie@temp.hogeserver.hogeddns.jp
otherMailbox: rohhie2@temp.hogeserver.hogeddns.jp
otherMailbox: rohhie3@temp.hogeserver.hogeddns.jp

自分の代わりにメールを送る人(多分…)はここで指定。

kopanoSendAsPrivilege: CN=hogeuser,CN=Users,DC=hogeserver,DC=hogeddns,DC=jp
kopanoSendAsPrivilege: CN=hogewife,CN=Users,DC=hogeserver,DC=hogeddns,DC=jp

クォーターは以下で指定できる。不要な属性は指定しなければ無指定扱い。

kopanoQuotaOverride: 1
kopanoQuotaWarn: 0～10485760 でメガバイト単位
kopanoQuotaSoft: 〃
kopanoQuotaHard: 〃

アドレス帳から隠す場合には以下を指定。

kopanoHidden: 1

Home Server は以下で指定できるが、効果がちょっと分からない。

kopanoUserServer: WinTemp ← コンピューターの登録名と思われる

グループの追加と属性付与

samba-tool はユーザーの属性編集をサポートしているが、グループの属性編集はできなかったので、ldbedit コマンドで属性を付与する。

まずはグループを追加してみる。

$ sudo samba-tool group add grrohhie -U administrator
Added group grrohhie

LDBを編集するコマンドで対象となるグループを指定し、Kopano 属性を付与する。

$ ldbedit -H ldaps://addc.hogeserver.hogeddns.jp -b DC=hogeserver,DC=hogeddns,DC=jp samAccountName=grrohhie -U Administrator

※この指定方法であれば temp.hogeserver.hogeddns.jp からでも行ける。
※条件として samAccountName を使用。これは重複しないIDとして使える。

# editing 1 records
# record 1
dn: CN=grrohhie,CN=Users,DC=hogeserver,DC=hogeddns,DC=jp
objectClass: top
objectClass: group
cn: grrohhie
instanceType: 4
whenCreated: 20190727224136.0Z
whenChanged: 20190727224136.0Z
uSNCreated: 6793
uSNChanged: 6793
name: grrohhie
objectGUID: 17012a9c-3ff7-4cdb-bed0-26459f1257f3
objectSid: S-1-5-21-1946807796-1988204200-2484953960-1121
sAMAccountName: grrohhie
sAMAccountType: 268435456
groupType: -2147483646
objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=hogeserver,DC=hogeddns,DC=jp
distinguishedName: CN=grrohhie,CN=Users,DC=hogeserver,DC=hogeddns,DC=jp
kopanoAccount: 1
mail: grrohhie@temp.hogeserver.hogeddns.jp

変更後、 :wq で保存・終了すると、以下が表示される。

# 0 adds  2 modifies  0 deletes

これで Kopano のグループとして認識される。

NT_STATUS_INVALID_PARAMETER_MIX なエラーが出たときは、smb.conf の設定を修正する。

グループに付与する属性の詳細

こちらも画面入力が属性にどのように反映されるのかを確認。注意事項も同じ。

まず、Kopano が取り扱うグループであることを示すには以下を設定。

kopanoAccount: 1

メールアドレスとエイリアスは以下の通りに指定。

mail: grrohhie@temp.hogeserver.hogeddns.jp
otherMailbox: grrohhie2@temp.hogeserver.hogeddns.jp
otherMailbox: grrohhie3@temp.hogeserver.hogeddns.jp

アドレス帳から隠す場合には以下を指定。

kopanoHidden: 1

グループのメールを送る人(多分…)はここで指定。

kopanoSendAsPrivilege: CN=hogeuser,CN=Users,DC=hogeserver,DC=hogeddns,DC=jp
kopanoSendAsPrivilege: CN=hogewife,CN=Users,DC=hogeserver,DC=hogeddns,DC=jp

LDAPSによる認証の確認

Samba ad dc のユーザーでログインができるか確認してみる。

サーバーを再起動。

$ sudo systemctl restart kopano-server

ユーザーとグループの一覧を出してみる。

$ sudo kopano-admin -l
$ sudo kopano-admin -L

ドメインのユーザーが表示されることが確認できたら、ドメインのユーザーでWebAppからログインしてみる。

ドメイン内の他のユーザーへのメール送信

ドメイン内のユーザー、ユーザーの別メールアドレス、グループにメールを送ってみる。問題なく相手のメールボックスにメールが届けば設定はできている。

メール送信成功！と表示されても、設定がうまくいっていないと実際にメールが届かずに戻ってくることがある。設定中には Postfix の設定が足りずに何度もエラーメールが戻ってきていた。

• Recipient address rejected: User unknown in local recipient table. (no retry)
  → 宛先がDBのままだった
• error: unsupported dictionary type: ldap
  → PostfixのLDAPモジュールをインストールしていない
• warning: dict_ldap_connect: Unable to bind to server ldap://addc.hogeserver.hogeddns.jp:389 with dn cn=administrator,ou=Users,dc=hogeserver,dc=hogeddns,dc=jp: 8 (Strong(er) authentication required)
  → LDAPSへの接続設定ができていない
• error: dict_ldap_connect: Unable to set STARTTLS: 1: Operations error
  → 不要なTLS設定がされている
• warning: dict_ldap_set_tls_options: Unable to allocate new TLS context -1: Can't contact LDAP server
  → CA証明書を参照できない

現行システムのユーザー管理をDBからSamba ad dcに移行

現在運用している DB からきっちりまるごと LDAP に移行したいと考えた。

調べてみると、Kopano はメールやスケジュールのデーターをストアで管理しており、LDAP 管理に移行した後、LDAP のユーザーに DB のユーザーが持っていたストアをフックすればデータの復元ができる。しかし、この方法でデータを復元してみたところ、フォルダに設定してある権限(ACL)、具体的にはカレンダーに設定した権限が復元できない。

DB にあるユーザー情報を LDAP ユーザーと一致させるためには、DB を直接書き換えれば良い。

Kopanoのデータの考え方

ちょっと長くなるけれども、分かっていると発生した問題への対応力が変わりそうなのでメモ。

ユーザーとデータの所有関係

Kopano の内部では自動発番される ID でユーザーとグループを管理している(usersテーブル)。ユーザーの実態は externID。

ユーザーの詳細情報、たとえば、それはユーザーなのかグループなのか、その名前は何なのか、パスワードは何か…といった情報は ID で紐付けられた objectproperty テーブルで管理されている。

オブジェクト(多分、ストアだけじゃなく色々なデータ)は object テーブルで管理されていて、持ち主は externID で示されている。オブジェクトの先にぶら下がるデータは恐らくIDで紐付けられている。

[Table:users ] externID, <u>ID  <---> [Table:objectproperty] <u>ID, propname, value
                  |
[Table:object] externID, <o>ID  <---> [様々なデーター] <o>ID, …

※users.ID と object.ID は自動発番。リレーション先となるテーブルがユーザー関連(プロパティとかACLとか)なら users.ID の意味だし、データー関連(ストかとか)なら object.ID の意味だろうと思う。

なお、externID は LDAP の属性のどれなのかを確認したところ、それがユーザーの場合には objectGUID 属性であり、グループの場合には objectSid 属性と一致していた。
※これが分からなくて移行に手こずってしまった。

このようなデータ構成だから、users テーブルと object テーブル の externID を LDAP のユーザー・グループを指し示す ID に置き換えれば移行ができる。

データをフックし直す方法で移行しようとしたとき、ユーザーの externID は書き換えるコマンドがあるのだけれど、グループの externID を書き換えるコマンドがない。ユーザーのストアだけをフックし直してみた結果、例えばカレンダーへのアクセス権は残っている(存在しないグループでまとめられたアクセス権が残っている)のだけれども、どういう権限なのか見ることもできないし、編集もできない状態になってしまうのだった。

ユーザー管理

kopano-server は起動すると server.cfg の user_plugin に従ってユーザーの一覧を取りに行く。DB 管理の場合には、DBから取ってきて終わり。

これが LDAP になるとジャストインタイムなユーザー管理ロジックが動き出す。Kopano のユーザーは users テーブルに保管されており、LDAP に初めてのユーザーを見つけたらユーザーを作る。逆に、LDAPに登録されていないユーザーは削除する。

LDAP から DB に戻すとどうなるか…新たなユーザーが作られている。ユーザーがいる・いないを見分けるために externID が使われていると想定される。

ユーザー作成時には一緒に「ストア」を作る。ユーザー削除時には「ストア」を削除しない…何らかの事故でユーザーが削除されても「ストア」は残っているので、新たに作り直したユーザーに「フック」すれば復元ができるようになっている。

試行錯誤の過程で user_plugin をコロコロと変えていたので、変えるたびに「ユーザー」と「ストア」が作られ、いなくなったと判断された「ユーザー」が次々と削除されていった。結果として大量の「ストア」が残されていた。

ユーザーはたくさんあるストア群のなかから1つの「ストア」をフックしており、ストアに紐付けられたメールやスケジュールなどのデータを使う。

ユーザーは「ストア」を使うためのインターフェースでしかなく、「ユーザー」がフックする「ストア」はいつでも掛け替えられる。

今まで参加した開発でこのような「ユーザーのデータをフックする・フックし直す」→「ユーザーを入れ替えられる」データ構成を設計したことはなかった。マニュアルをちゃんと読めば分かるのだろうけれども英語だし、やってみて動きを見てようやくこのことが理解できたのが実態。

なるほど…ユーザーとストアを切り離せば認証機構が変わっても簡単に追従できるな、この考え方すごいな。

移行準備

Kopano で運用していたユーザーとグループを再現する。
上記の考え方から、ユーザーやグループの大事な属性だけそろえておいて、細かな属性値は後から修正するやり方で問題ないと考えられる。

気にしなければならない大事な属性は、KopanoAccount とユーザーのsAMAccountName くらい。後のものは普通に作業すれば正しい値が設定されるはず。

DBで運用しているデータの復元

temp.hogeserver.hogeddns.jp側の設定

運用中のデータベースと添付ファイルをしかるべき場所にリストアする。
(データベースはドロップしなくてもまるごと置き換わるのね…)

$ sudo systemctl stop kopano-server
$ sudo mysql -D kopanoserver < kopanoserver.dmp

※添付ファイルのリストアの説明は割愛、過去記事参照。

同じユーザーとグループを作る

DB で運用中の現行システムで以下を実行すると、登録済みのユーザーとグループの一覧を表示させられる。これをaddc.hogeserber.hogeddns.jpに再現する。

Windows10 Professional で AD Extention を使っても良いし、addc の上でsamba-tool/ldbeditコマンドを使っても良い。

$ sudo kopano-admin -l
$ sudo kopano-admin -L

DB に登録されているユーザーとグループがあれば良いので、addc だけに存在するユーザーやグループがあっても構わない。

ユーザー名rootをAdministratorに変える

temp.hogeserver.hogeddns.jp側の設定

運用中のシステムに root というユーザーがいる。これは addc においては Administratorにあたる。移行にあたり名前が違うと同一ユーザーとして扱われないため、ユーザーの名前を変える。

user plugin を一旦 DB にして起動させる。

/etc/kopano/server.cfg

user_plugin     = db
#user_plugin     = ldap

$ sudo systemctl start kopano-server

いままで root としていたユーザーを Administrator に改名。

$ sudo kopano-admin -u root -U Administrator
User information updated.
$ sudo kopano-admin -l
User list for Default(11):
        Username        Fullname                Homeserver
        ---------------------------------------------------------
        SYSTEM          SYSTEM                  Kopano
        Administrator   Administrator
…

サービスを停止する。

$ sudo systemctl stop kopano-server

user plugin を LDAP に変更。

/etc/kopano/server.cfg

#user_plugin      = db
user_plugin      = ldap

Administrator に変更したユーザーのメールアドレスは root@temp.hogeserver.hogeddns.jp と Administrator@temp.hogeserver.hogeddns.jp の2つあっていい。

Windows10 Professionalにインストールした AD Extension や samba-tool/ldbedit を利用して mail と otherMailBox にこれらのアドレスを設定しておく。どちらが mail でも構わない。

移行

ユーザーの実態である externID を置き換える。

ユーザーデータの保護

Kopano はジャストインタイムでユーザーを提供するので、何かをミスるとユーザーが置き換わってしまう。そこで、ジャストインタイムでユーザーを提供する機能を止める。

/etc/kopano/server.cfg

# Set this option to 'yes' to skip the creation and deletion of new users
# The action will be logged, so you can see if your changes to the plugin
# configuration are correct.
#user_safe_mode = no
user_safe_mode = yes

この設定ならユーザーが作られない、削除されない。

externID置き換えスクリプトを用意

externID 置き換えを行うスクリプトをダウンロードしてくる。

DB から LDAP へのマイグレーションをしようとしている人の問い合わせの中で、以下のツールが示されていた。Zarafaツールだけれども、Kopanoでも使えるらしい。
Zarafa wiki / Zarafa DB to LDAP user plugin conversion

展開すると2つのスクリプトが入っている。
1つは externID を置き換えるもの、1つはアドレス帳を書き換えるものらしい。
アドレス帳の書き換えはちょっと意味が分からなくて今回は扱わない(分かる人、是非教えてください)。

externID を置き換えるスクリプトは db-to-ldap-plugin.pl という名前。これはユーザーの externID を書き換えてくれるけれどもグループの externID は書き換えてくれないので、ちょっとだけ改造。

データベースからユーザーとグループの名前を取ってきて、LDAP からそれと同じ名前のユーザーとグループの externID を取ってくる。そして、取ってきた externID でデータベースを上書きする。という動作になる。

db-to-ldap-plugin.pl

# 関数 get_extern_id_grp を追加(groupのexternIDを取ってくる)
sub get_extern_id_grp($$$) {
    my ($lo, $ldap, $db_username) = @_;
    my $mesg = $ldap->search(filter => "($lo->{ldap_groupname_attribute}=$db_username)",
                             base   => "$lo->{ldap_search_base}",
                             attrs  => ["$lo->{ldap_groupname_attribute}", "$lo->{ldap_group_unique_attribute}"],
                             scope  => "sub");

    my @entries = $mesg->entries;
    # if $mesg->count != 1 fallback on emailaddress lookup?
    if ( $mesg->count == 0 ) {
        print "Error updating $db_username. No entry found in ldap for ($lo->{ldap_groupname_attribute} = $db_username)n";
        return ($mesg->count, "");
    }
    if ( $mesg->count > 1 ) {
        print "Error updating $db_username. Multiple entries found in ldap for ($lo->{ldap_groupname_attribute} = $db_username)n";
        return ($mesg->count, "");
    }

    return ($mesg->count, $entries[0]->get_value($lo->{ldap_group_unique_attribute}));
}

# Select文の変更(赤文字部分の追加、userだけでなくgroupも取ってくる)
$query = "SELECT u.id AS user_id, op.value AS user_name, o.id, op.propname FROM users AS u JOIN object AS o ON u.externid=o.externid JOIN objectproperty AS op ON o.id=op.objectid AND ( op.propname='loginname' OR op.propname='groupname' )"

# groupのexternIDを更新する処理を追加(赤文字部分の追加)
while (@row = $sth->fetchrow_array) {
    my $db_user_id = $row[0];
    my $db_user_name = $row[1];
    my $db_object_id = $row[2];
    my $db_userorgroup = $row[3];

    if ($db_userorgroup eq 'loginname') {
        print "Found user '$db_user_name' in database with user_id '$db_user_id'n";

        my ($retval, $extern_id) = get_extern_id(%ldapopt, $ldap, $db_user_name);
        if ($retval == 1) {
            $query = "UPDATE users SET externid=? WHERE id=?";
            $upd = $dbh->prepare($query)
                or die $DBI::errstr;
            $upd->execute($extern_id, $db_user_id);
            $query = "UPDATE object SET externid=? WHERE id=?";
            $upd = $dbh->prepare($query)
                or die $DBI::errstr;
            $upd->execute($extern_id, $db_object_id);
        }
    } else {
        print "Found group '$db_user_name' in database with user_id '$db_user_id'n";

        my ($retval, $extern_id) = get_extern_id_grp(%ldapopt, $ldap, $db_user_name);
        if ($retval == 1) {
            $query = "UPDATE users SET externid=? WHERE id=?";
            $upd = $dbh->prepare($query)
                or die $DBI::errstr;
            $upd->execute($extern_id, $db_user_id);
            $query = "UPDATE object SET externid=? WHERE id=?";
            $upd = $dbh->prepare($query)
                or die $DBI::errstr;
            $upd->execute($extern_id, $db_object_id);
        }
    }
}

※上記の狙いが満たされていることを確認の上、自己責任で利用すること。
※まぁまぁ不格好な改造だけれども動くからいいか。変更後のファイルはこれ。

externID置き換えスクリプト実行環境の設定

スクリプト開発当初の server.cfg と ldap.cfg から情報を取ってくるような作りになっているため、バージョンが変わって記載方法が変わってしまっている。ここで実行環境を設定する。

debian 系は別ファイル(/etc/kopano/debian-db.cfg)に db 接続情報を記載しているから、そこから一時的に値をコピーする。

/etc/kopano/server.cfg

mysql_host      = localhost
mysql_port      = 3306
mysql_user      = kopano-server
mysql_password  = <パスワード>
mysql_database  = kopanoserver

# LDAP設定になっていることを確認
user_plugin         = ldap
user_plugin_config  = /etc/kopano/ldap.cfg

Samba ad dc に接続するための情報を昔の形式で定義。プラス、属性に関する設定内容を明確化。
ubuntu manuals / kopano-ldap.cfg

/etc/kopano/ldap.cfg ※ファイルの最後の方に追記

…
# for Migration tool
ldap_protocol = ldaps
ldap_host = addc.hogeserver.hogeddns.jp
ldap_port = 636
ldap_loginname_attribute = sAMAccountName
ldap_user_unique_attribute = objectGUID
ldap_groupname_attribute = cn
ldap_group_unique_attribute = objectSid

externID置き換えスクリプトを実行

スクリプトを実行するために必要なライブラリをインストールする。

$ sudo apt install libnet-ldap-perl

手順通りに進んでいれば kopano-server は止まっているはずだが、念のため動いていないことを確認する。

$ sudo systemctl status kopano-server
● kopano-server.service - Kopano Server
   Loaded: loaded (/lib/systemd/system/kopano-server.service; enabled; vendor preset: enabled)
   Active: inactive (dead) since Sat 2019-07-20 23:43:51 JST; 1s ago
     Docs: man:kopano-server(8)
…

スクリプトを実行する。
スクリプトにより externID が書き換えられます。設定ミスなどにより不整合が発生するとユーザーが作り替えられてしまい ACL 等の復元が困難になる(私には復元方法が分からない)等の大問題になりかねません。試験環境等で十分なテストを実施してください。

$ sudo ./db-to-ldap-plugin.pl /etc/kopano/server.cfg
Found user 'Administrator' in database with user_id '3'
Found user 'honmyou' in database with user_id '4'
Found user 'hogewife' in database with user_id '5'
Found user 'hogehoge' in database with user_id '6'
Found user 'hogeuser' in database with user_id '7'
Found group 'FGroup' in database with user_id '8'
Found user 'hogemother' in database with user_id '15'
Found group 'GGroup' in database with user_id '17'
…
Committing changes to database
Done.

このように Found 行だけが表示されて Commit までたどり着けばOK。

これ以外の表示がされているときには何らかの問題が発生しているので、問題が解消するまで頑張る。

externID置き換えスクリプト実行環境の戻し

スクリプト実行のための特別設定を元に戻す。

/etc/kopano/server.cfg

mysql_password  = パスワードを削除する

/etc/kopano/ldap.cfg ※ファイルの最後の方に追記

…
# for Migration tool
#ldap_protocol = ldaps
#ldap_host = addc.hogeserver.hogeddns.jp
#ldap_port = 636
#ldap_loginname_attribute = sAMAccountName
#ldap_user_unique_attribute = objectGUID
#ldap_groupname_attribute = cn
#ldap_group_unique_attribute = objectSid

動作確認

kopano-server を起動して動作を確認する。

$ sudo systemctl start kopano-server

ログインして一通りデータを見る。また、カレンダーに設定されたアクセス権を表示させてみる。

そこで画面でエラーが表示され、server.log に以下のようなエラーが出た場合、ているときには何かが足りない。設定を見直してスクリプトを再実行して成功させる必要がある。

/var/log/kopano/server.log

Sat Jul 20 16:27:10 2019: [crit   ] user_safe_mode: Would delete security group 8

user_safe_mode = no の状態で実際にユーザーやグループが削除されてしまったら、データベースのリストアからやり直す(添付ファイルには影響がないはずなので、データベースのリストアだけでいいと思う)。

データがスムーズに閲覧でき、エラーログも出力されていないようであれば、恐らく移行は成功している。safe mode を解除して kopano-server を再起動する。

/etc/kopano/server.cfg

user_safe_mode = no
#user_safe_mode = yes

$ sudo systemctl restart kopano-server

以上で移行完了！

起きたこと

色々発生したので目次。

• スキーマ追加でエラー ldapadd編 ※未解決
• スキーマ追加でエラー ldb-tools編
  • ldb-toolsをインストールしていなかった
  • Sambaをインストールしていなかった
  • LDAPSで接続できない
  • パスワード指定ができていない
  • SASL認証なのにTLSを使おうとしてエラー
  • ベースとなるDC名の指定誤り
  • スキーマの更新が許可されていない
• /etc/kopano/ldap.cfgが読み込めない(AppArmor)
• kopano-serverがLDAPS接続しない
• ドメイン参加時にエラーメッセージが表示された
• Active Directory 管理センターでエラーメッセージが表示された
• Poxtfixでドメイン内のメールを配信できない
  • 宛先がDBのままだった
  • PostfixのLDAPモジュールをインストールしていない
  • LDAPSへの接続設定ができていない
  • 不要なTLS設定がされている
  • CA証明書を参照できない
• externID置き換えでエラー
  • 必要ライブラリをインストールしていなかった
  • 設定ファイルが開けない
  • ldap.cfgの設定が足らない 1
  • server.cfgの設定が足らない
  • ldap.cfgの設定が足らない 2

スキーマ追加でエラー ldapadd編 ※未解決

一番最初に見つけた方法。ldapadd コマンドで kopano.ldif を流し込む。

マニュアルにはgzのまま登録する方法が書かれているけれど、溶かして中身を確認してから投入してみる。

対象となるファイルはここにあるので、作業用のディレクトリにコピーしてきて展開してみる。

kopano.ldif

dn: cn=kopano,cn=schema,cn=config ← 識別名
objectClass: olcSchemaConfig
cn: kopano                        ← 管理者
…

このファイルを投入するには、ldapaddコマンドが必要みたい(Sambaパッケージの中にそれっぽいのがないか、ざっと見たけど分からなかった)なので、インストール。

$ sudo apt install ldap-utils

登録。コマンドサンプルは同一サーバーの中にLDAPサーバーがある前提になっているし、初めて Samba ad dc の根幹とも思える部分に手を入れるし…で、少しドキドキする。

$ ldapadd -H ldaps://addc.hogeserver.hogeddns.jp -x -D administrator@hogeserver.hogeddns.jp -W -f kopano.ldif
Enter LDAP Password: [admin君のパスワード]
adding new entry "cn=kopano,cn=schema,cn=config"
ldap_add: No such object (32)
        additional info: 00002030: objectclass: Cannot add cn=kopano,cn=schema,cn=config, parent does not exist!

※接続はSSLで保護されているけど、中身はPlainTextなので、-xで接続可能。
※パスワードはhistoryに覚えさせるのがいやだったから -Wとした。

エラー発生。親オブジェクトが見つからない。

…登録先の親はどこなの？と。色々探してみたり、phpLDAPadmin で hogeserver.hogeddns.jp を探してみれば、親になるのは
　　CN=schema,CN=configuration,DC=hogeserver,DC=hogeddns,DC=jp
になるのではないかと考えた。

kopano.ldif ※赤文字部分を追記

#
################################################################################
#
dn: cn=kopano,cn=schema,cn=configuration,dc=hogeserver,dc=hogeddns,dc=jp
objectClass: olcSchemaConfig
cn: kopano
#
################################################################################
#
olcAttributeTypes: (
  1.3.6.1.4.1.47732.1.1.1.1
…

その上で、もう一度登録にトライ。

$ ldapadd -H ldaps://addc.hogeserver.hogeddns.jp -x -D administrator@hogeserver.hogeddns.jp -W -f kopano.ldif
Enter LDAP Password: [admin君のパスワード]
adding new entry "cn=kopano,cn=schema,cn=configuration,dc=hogeserver,dc=hogeddns,dc=jp"
ldap_add: No such attribute (16)
        additional info: 0000200A: objectclass olcSchemaConfig is not a valid objectClass in schema

エラー発生。olcSchemaConfig は有効な objectClass スキーマにない。

ファイルの中身をそのまま登録できない時点で多分だめなんだけど、確信も持てないのでどうにか進めてみたけれども、結局なんか変だ。この方法は多分だめなんだろうと諦めることにした。

スキーマ追加でエラー ldb-tools編

$ bash kopano_schema_add.sh DC=hogeserver,DC=hogeddns.DC=jp ./ -H ldaps://addc.hogeserver.hogeddns.jp -U Administrator
Error: Can not find ldbmodify
       Please check your PATH variable

$ sudo apt install ldb-tools

$ bash kopano_schema_add.sh DC=hogeserver,DC=hogeddns.DC=jp ./ -H ldaps://addc.hogeserver.hogeddns.jp -U Administrator
Error: installed version ldbmodify is not supported

$ ldbmodify --help
…
Common Samba options:
  -d, --debuglevel=DEBUGLEVEL                 Set debug level
      --debug-stderr                          Send debug output to STDERR
  -s, --configfile=CONFIGFILE                 Use alternative configuration file
      --option=name=value                     Set smb.conf option from command line
  -l, --log-basename=LOGFILEBASE              Basename for log/debug files
      --leak-report                           enable talloc leak reporting on exit
      --leak-report-full                      enable full talloc leak reporting on exit
…

$ ldbmodify --help
…
Help options:
  -?, --help                      Show this help message
      --usage                     Display brief usage message

$ sudo apt install samba
$ sudo apt install ldb-tools
$ ldbmodify --help
…
Common Samba options:
 -d, --debuglevel=DEBUGLEVEL Set debug level
…

$ bash kopano_schema_add.sh DC=hogeserver,DC=hogeddns.DC=jp ./ -H ldaps://addc.hogeserver.hogeddns.jp -U Administrator
dos2unix: converting file kopano-ads.ldf.unix to Unix format...
dos2unix: converting file kopano-display-ads.ldf.unix to Unix format...
Failed to connect to ldap URL 'ldaps://addc.hogeserver.hogeddns.jp' - LDAP client internal error: NT_STATUS_INVALID_PARAMETER_MIX
Failed to connect to 'ldaps://addc.hogeserver.hogeddns.jp' with backend 'ldaps': LDAP client internal error: NT_STATUS_INVALID_PARAMETER_MIX
Failed to connect to ldaps://addc.hogeserver.hogeddns.jp - LDAP client internal error: NT_STATUS_INVALID_PARAMETER_MIX
Error: Can not find CN=user-Display,CN=401,CN=DisplaySpecifiers,CN=Configuration,DC=hogeserver,DC=hogeddns.DC=jp

[global]
…
    tls verify peer = ca_and_name
    tls cafile = /usr/share/ca-certificates/hogeserver.hogeddns.jp.crt
#   tls crlfile =
…

$ bash kopano_schema_add.sh DC=hogeserver,DC=hogeddns.DC=jp ./ -H ldaps://addc.hogeserver.hogeddns.jp -U Administrator
dos2unix: converting file kopano-ads.ldf.unix to Unix format...
dos2unix: converting file kopano-display-ads.ldf.unix to Unix format...
Failed to bind - LDAP error 49 LDAP_INVALID_CREDENTIALS -  <8009030C: LdapErr: DSID-0C0904DC, comment: AcceptSecurityContext error, data 52e, v1db1> <>
Failed to connect to 'ldaps://addc.hogeserver.hogeddns.jp' with backend 'ldaps': LDAP error 49 LDAP_INVALID_CREDENTIALS -  <8009030C: LdapErr: DSID-0C0904DC, comment: AcceptSecurityContext error, data 52e, v1db1> <>
Failed to connect to ldaps://addc.hogeserver.hogeddns.jp - LDAP error 49 LDAP_INVALID_CREDENTIALS -  <8009030C: LdapErr: DSID-0C0904DC, comment: AcceptSecurityContext error, data 52e, v1db1> <>
Error: Can not find CN=user-Display,CN=401,CN=DisplaySpecifiers,CN=Configuration,DC=hogeserver,DC=hogeddns.DC=jp

…
for arg in "$@" ; do
    case $arg in
    "-U")
        userpass="-U `eval echo '$'$[$argno+1]`"
        read -sp "Password: " temppass
        userpass=$userpass%$temppass
        ;;
    "-H")
…

$ bash kopano_schema_add.sh DC=hgoeserver,DC=hogeddns.DC=jp /home/hogeuser/work/kopano/ads/samba/kopano-samba-ads -H ldaps://addc.hogeserver.hogeddns.jp -U Administrator
Password: [ココでパスワードを入力している]dos2unix: converting file kopano-ads.ldf.unix to Unix format...
dos2unix: converting file kopano-display-ads.ldf.unix to Unix format...
Failed to bind - LDAP error 53 LDAP_UNWILLING_TO_PERFORM -  <SASL:[GSS-SPNEGO]: Sign or Seal are not allowed if TLS is used> <>
Failed to connect to 'ldaps://addc.hogeserver.hogeddns.jp' with backend 'ldaps': LDAP error 53 LDAP_UNWILLING_TO_PERFORM -  <SASL:[GSS-SPNEGO]: Sign or Seal are not allowed if TLS is used> <>
Failed to connect to ldaps://addc.hogeserver.hogeddns.jp - LDAP error 53 LDAP_UNWILLING_TO_PERFORM -  <SASL:[GSS-SPNEGO]: Sign or Seal are not allowed if TLS is used> <>
Error: Can not find CN=user-Display,CN=401,CN=DisplaySpecifiers,CN=Configuration,DC=hogeserver,DC=hogeddns.DC=jp

[global]
…
    # SASLでTLSを有効化
    ldap server require strong auth = allow_sasl_over_tls
…

$ sudo systemctl restart samba-ad-dc

$ bash kopano_schema_add.sh DC=hogeserver,DC=hogeddns.DC=jp /home/hogeuser/work/kopano/ads/samba/kopano-samba-ads -H ldaps://addc.hogeserver.hogeddns.jp -U Administrator
Password: dos2unix: converting file kopano-ads.ldf.unix to Unix format...
dos2unix: converting file kopano-display-ads.ldf.unix to Unix format...
Error: Can not find CN=user-Display,CN=401,CN=DisplaySpecifiers,CN=Configuration,DC=hogeserver,DC=hogeddns.DC=jp

$ bash kopano_schema_add.sh DC=hogeserver,DC=hogeddns.DC=jp …
                                         ピリオド… ↑

$ bash kopano_schema_add.sh DC=hogeserver,DC=hogeddns,DC=jp /home/hogeuser/work/kopano/ads/samba/kopano-samba-ads -H ldaps://addc.hogeserver.hogeddns.jp -U Administrator -writechanges
Password:[Administratorのパスワード入力] dos2unix: converting file kopano-ads.ldf.unix to Unix format...
ERR: (Unwilling to perform) "LDAP error 53 LDAP_UNWILLING_TO_PERFORM -  <00002035: schema_data_add: updates are not allowed: reject add request
> <>" on DN CN=Kopano-Quota-Override,CN=Schema,CN=Configuration,DC=hogeserver,DC=hogeddns,DC=jp at block before line 21
Modify failed after processing 0 records
Error: ldbmodify reported an error

[global]
…
    # スキーマ更新を有効化
    dsdb:schema update allowed = true
…

$ sudo systemctl restart samba-ad-dc

/etc/kopano/ldap.cfgが読み込めない(AppArmor)

ちゃんとファイルを作ったはずなのに読み込めない。

/var/log/kopano/server.log

Sun Jul  7 05:41:03 2019: [error  ] Failed to open plugin configuration file, using defaults.
Sun Jul  7 05:41:03 2019: [crit   ] Config error: Unable to open config file "/etc/kopano/ldap.cfg"
Sun Jul  7 05:41:03 2019: [crit   ] Config error: Option 'ldap_group_type_attribute_value' cannot be empty!
Sun Jul  7 05:41:03 2019: [crit   ] Config error: Option 'ldap_user_type_attribute_value' cannot be empty!
Sun Jul  7 05:41:03 2019: [crit   ] Cannot instantiate user plugin: Not a valid configuration file.
Sun Jul  7 05:41:03 2019: [crit   ] Unable to instantiate user plugin

server.cfgでファイル名を変えてみるとちゃんとエラー原因が出るから、何か別に原因があるはず。

Sun Jul  7 05:13:10 2019: [crit   ] Config error: Cannot normalize path "/etc/kopano/ldap.cfga": No such file or directory

これか…またしても3時間以上を盗られてしまった…

/var/log/syslog

Jul 7 05:41:03 localhost kernel: [26918.163143] audit: type=1400 audit(1562445663.088:125): apparmor="DENIED" operation="open" profile="/usr/sbin/kopano-server" name="/etc/kopano/ldap.cfg" pid=5649 comm=7A2D733A20 requested_mask="r" denied_mask="r" fsuid=113 ouid=0

/etc/apparmor.d/local/usr.sbin.kopano-server ※0バイトファイルかもしれない

/etc/kopano/ldap.cfg r,
/usr/share/kopano/ldap.active-directory.cfg r,
/usr/share/kopano/ldap.propmap.cfg r,

設定を反映。

$ sudo systemctl reload apparmor.service

でも、これだけじゃ動かないなぁ。

$ sudo apt install apparmor-utils
$ sudo aa-complain /usr/sbin/kopano-server
$ sudo kopano-admin -l -v
$ sudo aa-logprof
$ sudo systemctl reload apparmor
$ sudo aa-enfoce /usr/sbin/kopano-server

kopano-serverについてAppArmorは警告するけど処理を継続できるようにする…。
kopano-adminコマンドを実行後、ログから必要な情報をとりだしてAppArmorに登録、AppArmorの設定を読み込ませる。
最後に、AppArmorを厳格に適用するように修正して終わり。

この方法で取り出した設定を本文中に記載している。

kopano-serverがLDAPS接続しない

認証がうまくいかないのでログレベルを debug にして動かしてみた。

/var/log/kopano/server.log

Sun Jul  7 19:18:49 2019: [warning] LDAP (simple) bind on administrator@hogeserver.hogeddns.jp failed: Can't contact LDAP server
Sun Jul  7 19:18:49 2019: [crit   ] Cannot instantiate user plugin: Failure connecting any of the LDAP servers
Sun Jul  7 19:18:49 2019: [crit   ] Unable to instantiate user plugin
Sun Jul  7 19:18:49 2019: [debug  ] Accepted incoming connection from file:///var/run/kopano/server.sock

simple って…じゃあ、simple なら接続できるの？と addc.hogeserver.hogeddns.jp側の設定で TLS無効＆strong auth=No にしてみたら動く。

うーむ。気になっていたことがそのまま的中。
本来、TLSを使うように設定をしたいのだがエラーが出るのだ。

/etc/kopano/ldap.cfg

# すべてのLDAP接続をTLSで保護するように要求します。
# 確立できない場合、接続は拒否されます。
ldap_starttls = yes

この設定をした上で認証を動かしてみると、以下のエラーが出ている。

/var/log/kopano/server.log

Sun Jul  7 19:59:29 2019: [crit   ] Config error: Unknown option 'ldap_starttls' found!
Sun Jul  7 19:59:29 2019: [crit   ] Cannot instantiate user plugin: Not a valid configuration file.
Sun Jul  7 19:59:29 2019: [crit   ] Unable to instantiate user plugin
Sun Jul  7 19:59:29 2019: [debug  ] Accepted incoming connection from file:///var/run/kopano/server.sock

やー、マニュアルにも書いてあるこの設定ができないって何でだろ？

あぁ…サーバー指定が間違ってる…addc を付け忘れていた…

ドメイン参加時にエラーメッセージが表示された

お試し用に Windows10 Professional をドメイン参加させたところ、やたらと時間がかかり、以下のメッセージが表示された。

コンピューター名/ドメイン名の変更

このコンピューターのプライマリ ドメイン DNS 名を "" に変更できませんでした。
名前は "hogeserver.hogeddns.jp" のままになります。
エラー:

RPCサーバーを利用できません。

その後、ログインをするのにもものすごい時間がかかり、RSATはインストールすらまともにできない状態だった。

rpc server unavailable で検索してみると、どうやら接続に問題がありそうなことが見えてきたので ufw.log を見てみると 49152 ポートへのアクセスが遮断されてる。これか。

念のため利用ポートを調べてみる。
Samba wiki / Samba AD DC Port Usage
Microsoft / Active Directory ドメインと信頼関係のためのファイアウォールを構成する方法

$ sudo ufw allow to any port 49152:65535 proto tcp from 172.16.0.0/16 comment "SAMBA RPC"
$ sudo ufw allow to any port 49152:65535 proto tcp from fdnn:nnnn:nnnn:nnnn::/64 comment "SAMBA RPC"
$ sudo ufw allow to any port 49152:65535 proto tcp from 24nn:nnnn:nnnn:nnnn::/64 comment "SAMBA RPC"

これでスムーズに動作するようになった。

Active Directory 管理センターでエラーメッセージが表示された

起動直後に

どのドメインにも接続できません。接続できるようになったら、
更新するか、再試行してください。

が表示され、MYHOME(ローカル)を選択したところ

Active Directory Web サービス(ADWS)を実行しているドメイン
MYHOME で、利用可能なサーバーが見つかりません。

が表示される。

これは仕方がない。だって、Samba ad dc では ADWS を提供していないんだから。

Poxtfixでドメイン内のメールを配信できない

Sat Jul 13 18:42:20 2019: [error  ] [17767] RCPT line gave SMTP error 550 5.1.1 <honmyou@temp.hogeserver.hogeddns.jp>: Recipient address rejected: User unknown in local recipient table. (no retry)
Sat Jul 13 18:42:20 2019: [error  ] [17767] SMTP: Error while executing command 'DATA'. Response: 554 5.5.1 Error: no valid recipients
Sat Jul 13 18:42:20 2019: [warning] [17767] E-mail for user Administrator could not be sent, notifying user: cancel message (40580)

Jul 13 19:31:16 localhost postfix/smtpd[18392]: error: unsupported dictionary type: ldap
Jul 13 19:31:16 localhost postfix/smtpd[18392]: message repeated 3 times: [ error: unsupported dictionary type: ldap]

$ sudo apt install postfix-ldap

Jul 13 19:54:50 localhost postfix/trivial-rewrite[18907]: warning: dict_ldap_connect: Unable to bind to server ldap://addc.hogeserver.hogeddns.jp:389 with dn cn=administrator,ou=Users,dc=hogeserver,dc=hogeddns,dc=jp: 8 (Strong(er) authentication required)

Jul 13 20:47:12 localhost postfix/trivial-rewrite[20130]: error: dict_ldap_connect: Unable to set STARTTLS: 1: Operations error

server_host = ldaps://addc.hogeserver.hogeddns.jp:636
start_tls = yes
…
debuglevel=2

Jul 14 00:55:49 localhost postfix/smtpd[26281]: dict_ldap_debug: ldap_read: want=84, got=84
Jul 14 00:55:49 localhost postfix/smtpd[26281]: dict_ldap_debug:   0000:  01 01 04 00 04 36 53 54  41 52 54 2d 54 4c 53 3a   .....6START-TLS:
Jul 14 00:55:49 localhost postfix/smtpd[26281]: dict_ldap_debug:   0010:  20 54 4c 53 20 69 73 20  61 6c 72 65 61 64 79 20    TLS is already
Jul 14 00:55:49 localhost postfix/smtpd[26281]: dict_ldap_debug:   0020:  65 6e 61 62 6c 65 64 20  6f 6e 20 74 68 69 73 20   enabled on this
Jul 14 00:55:49 localhost postfix/smtpd[26281]: dict_ldap_debug:   0030:  4c 44 41 50 20 73 65 73  73 69 6f 6e 8a 16 31 2e   LDAP session..1.
Jul 14 00:55:49 localhost postfix/smtpd[26281]: dict_ldap_debug:   0040:  33 2e 36 2e 31 2e 34 2e  31 2e 31 34 36 36 2e 32   3.6.1.4.1.1466.2
Jul 14 00:55:49 localhost postfix/smtpd[26281]: dict_ldap_debug:   0050:  30 30 33 37                                        0037
Jul 14 00:55:49 localhost postfix/smtpd[26281]: error: dict_ldap_connect: Unable to set STARTTLS: 1: Operations error

server_host = ldaps://addc.hogeserver.hogeddns.jp:636
#start_tls = yes
…
debuglevel=2

Jul 14 00:13:59 localhost postfix/smtpd[23586]: warning: dict_ldap_set_tls_options: Unable to allocate new TLS context -1: Can't contact LDAP server

server_host = ldaps://addc.hogeserver.hogeddns.jp:636
tls_ca_cert_file = /etc/ssl/certs/hogeserver.hogeddns.jp.crt
…

externID置き換えでエラー

$ ./db-to-ldap-plugin.pl
Can't locate Net/LDAP.pm in @INC (you may need to install the Net::LDAP module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.26.1 /usr/local/share/perl/5.26.1 /usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at ./db-to-ldap-plugin.pl line 4.
BEGIN failed--compilation aborted at ./db-to-ldap-plugin.pl line 4.

$ sudo apt install libnet-ldap-perl

$ ./db-to-ldap-plugin.pl
unable to open /etc/zarafa/server.cfg config file at ./db-to-ldap-plugin.pl line 10, <DATA> line 755.

$ ./db-to-ldap-plugin.pl /etc/kopano/server.cfg
unable to open /etc/kopano/ldap.cfg config file at ./db-to-ldap-plugin.pl line 10.

$ sudo ./db-to-ldap-plugin.pl /etc/kopano/server.cfg
Use of uninitialized value $ldapopt{"ldap_protocol"} in concatenation (.) or string at ./db-to-ldap-plugin.pl line 65.
Use of uninitialized value in concatenation (.) or string at ./db-to-ldap-plugin.pl line 65.
Use of uninitialized value in concatenation (.) or string at ./db-to-ldap-plugin.pl line 65.
LDAP connection failed at ./db-to-ldap-plugin.pl line 66.

…
# for Migration tool
ldap_protocol = ldaps
ldap_host = addc.hogeserver.hogeddns.jp
ldap_port = 636

$ sudo ./db-to-ldap-plugin.pl /etc/kopano/server.cfg
DBI connect('database=kopano;host=localhost','root',...) failed: Unknown database 'kopano' at ./db-to-ldap-plugin.pl line 74.
Unknown database 'kopano' at ./db-to-ldap-plugin.pl line 74.

mysql_host      = localhost
mysql_port      = 3306
mysql_user      = kopano-server
mysql_password  = <パスワード>
mysql_database  = kopanoserver

$ sudo ./db-to-ldap-plugin.pl /etc/kopano/server.cfg
Found user 'honmyou' in database with user_id '4'
Use of uninitialized value in concatenation (.) or string at ./db-to-ldap-plugin.pl line 30.
Use of uninitialized value in string at ./db-to-ldap-plugin.pl line 30.
Use of uninitialized value in string at ./db-to-ldap-plugin.pl line 30.
Use of uninitialized value in concatenation (.) or string at ./db-to-ldap-plugin.pl line 38.
Error updating honmyou. No entry found in ldap for ( = honmyou)

ldap_loginname_attribute = sAMAccountName

$ sudo ./db-to-ldap-plugin.pl /etc/kopano/server.cfg
Found user 'root' in database with user_id '3'
Use of uninitialized value in string at ./db-to-ldap-plugin.pl line 30.
Error updating root. No entry found in ldap for (cn = root)
Found user 'honmyou' in database with user_id '4'
Use of uninitialized value in string at ./db-to-ldap-plugin.pl line 30.
Use of uninitialized value in lc at /usr/share/perl5/Net/LDAP/Entry.pm line 119.
…
Committing changes to database
Done. 

ldap_user_unique_attribute = objectGUID

やったこと

やったことも結構あるので目次。

• SSOに関する調査
• kopano-dagentについて改めて確認
• Kopanoのジャストインタイムなユーザー準備
• DBのユーザーとSamba ad dcのユーザー
• ストアデータのフック
• externID置き換えに関わる調査
  • アドレス帳のエントリー変換
  • データベース構成の確認
• LDAP Account Manager
• phpLDAPadmin

SSOに関する調査

結論としては焦りすぎ。

認証系の強化は、基本的にプラグインを使って行う模様。
であれば、これがいいのかも。
Kopano Wiki / Kopano WebApp Kerberos Single Sign On configuration

この中で紹介されているものの最新版は、多分ココ。
GitHub / BeyondTrust/pbis-open

でも、そうか…シングルサインオンはドメイン参加していることが前提だなぁ。
ユーザー管理の一元化とはちょっと別の話になりそうだ。

やりたいことがユーザーの一元管理なのであれば、それはLDAP連携で考えていけば良くて、その延長線上にドメイン参加したPCからのSSOがある訳で…将来の課題。

kopano-dagentについて改めて確認

Postfixの設定変更時に参照したマニュアルに LMTP は kopano-dagent が提供していると書かれていたので、/etc/kopano/dagent.cfg を見てみたら確かに設定が書かれていた。

改めて kopano-dagent の説明を読んでみると、インターネット形式のメールを Kopano にインポートするよ、LMTPデーモンとしても実行できるよ、と書かれている。

$ sudo systemctl status kopano-dagent
● kopano-dagent.service - Kopano DAgent Server
   Loaded: loaded (/lib/systemd/system/kopano-dagent.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2019-07-13 10:01:16 JST; 23h ago
     Docs: man:kopano-dagent(8)
           man:kopano-dagent.cfg(5)
 Main PID: 1895 (kopano-dagent)
    Tasks: 3 (limit: 9471)
   CGroup: /system.slice/kopano-dagent.service
           tq1895 /usr/sbin/kopano-dagent -l -F -c /etc/kopano/dagent.cfg
           mq1982 /usr/sbin/kopano-dagent -l -F -c /etc/kopano/dagent.cfg
$ sudo lsof -i:2003
COMMAND    PID   USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
kopano-da 1895 kopano    4u  IPv6  32108      0t0  TCP *:cfinger (LISTEN)

kopano-dagent は -l 付きで起動されていて、LMTPサーバーとして動作しており、実際にポートを使用していた。

Kopanoのジャストインタイムなユーザー準備

user_plugin を ldap にしている状態で、ユーザーテーブルを表示させてみた。

$ sudo mysql -p
MariaDB [(none)]> show databases;
MariaDB [kopanoserver]> show tables from kopanoserver;
+------------------------+
| Tables_in_kopanoserver |
+------------------------+
…
| users                  |
| versions               |
+------------------------+
MariaDB [kopanoserver]> select * from users;
+----+------------------------------+-------------+-----------+---------+
| id | externid                     | objectclass | signature | company |
+----+------------------------------+-------------+-----------+---------+
|  1 | NULL                         |      196610 |           |       0 |
|  2 | NULL                         |       65537 |           |       0 |
| 67 | <文字化け>                   |       65537 | 6604      |       0 |
| 68 | <文字化け>                   |       65537 | 6602      |       0 |
| 69 | <文字化け>                   |       65537 | 3547      |       0 |
| 70 | <文字化け>                   |       65537 | 3546      |       0 |
| 71 | <文字化け>                   |       65537 | 6566      |       0 |
| 74 | <文字化け>                   |      196610 | 6607      |       0 |
+----+------------------------------+-------------+-----------+---------+ 

user_plugin を db にして kopano-server を再起動してユーザーテーブルを表示されると、1,2,74を除くユーザーが作り替えられている。1,2,74が何を指しているのかは分からない。

MariaDB [kopanoserver]> select * from users;
+----+------------------------------+-------------+---------------------+---------+
| id | externid                     | objectclass | signature           | company |
+----+------------------------------+-------------+---------------------+---------+
|  1 | NULL                         |      196610 |                     |       0 |
|  2 | NULL                         |       65537 |                     |       0 |
| 74 | <文字化け>                   |      196610 | 6607                |       0 |
| 75?| <文字化け>                   |       65537 | 2019-06-01 14:30:37 |       0 |
| 76 | <文字化け>                   |       65537 | 2019-06-01 14:29:36 |       0 |
| 77 | <文字化け>                   |       65537 | 2019-06-01 14:30:06 |       0 |
+----+------------------------------+-------------+---------------------+---------+

さらにDBからLDAPに変えてみたところ、やはり1,2,74を除くユーザーが作り替えられている。

MariaDB [kopanoserver]> select * from users;
+----+------------------------------+-------------+-----------+---------+
| id | externid                     | objectclass | signature | company |
+----+------------------------------+-------------+-----------+---------+
|  1 | NULL                         |      196610 |           |       0 |
|  2 | NULL                         |       65537 |           |       0 |
| 74 | <文字化け>                   |      196610 | 6607      |       0 |
| 78 | <文字化け>                   |       65537 | 6604      |       0 |
| 79 | <文字化け>                   |       65537 | 6602      |       0 |
| 80 | <文字化け>                   |       65537 | 3547      |       0 |
| 81 | <文字化け>                   |       65537 | 3546      |       0 |
| 82 | <文字化け>                   |       65537 | 6566      |       0 |
+----+------------------------------+-------------+-----------+---------+

このようにユーザー管理の仕組みを切り替えるたびにIDが振り出され、全く新しいユーザーとして扱われるようだ。実際、WebAppでログインしてみたところ、初めてログインした時に表示される言語選択とかができる画面が表示された。ログイン後にメールボックスを見ればテストで大量に送受信したメールがなくなっていた…。

なるほど…Just in timeでユーザーを用意するというのはこういうことなのね。
ユーザーにフックされていないストアを見てみる…

$ sudo kopano-admin --list-orphans
Stores without users:
        Store guid                              Guessed username        Last login              Store size      Store type
        --------------------------------------------------------------------------------------------------------------------------
        004FD996E18649D4AA206AD747A11341        hogeuser                07/13/2019 05:12:02 PM  0.00 MB         private
        0433DCBDDFA847BB8188B0350D49F9F3        Guest                   <unknown>               0.00 MB         private
        067086FBFF024E0180EB5EC9A876B692        dhcpd                   <unknown>               0.00 MB         private
        069AA03EDC9141128346E08527434C68        hogeuser                07/13/2019 05:16:54 PM  0.00 MB         private
        09E1D55D02D44F1280A6E58BE035FD7B        dhcpd                   <unknown>               0.00 MB         private
…
        AAXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX        Administrator           07/14/2019 10:50:29 AM  0.44 MB         private
…

切り替えを繰り返していたので、孤立したストアが大量にある！

どうやら、このED6…のAdministratorがテストで使用したときのストアだなと思われるので、以下のコマンドでフックしてみた。

$ sudo kopano-admin --hook-store AAXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX -u Administrator
Store hooked.

WebAppにAdministratorでログインしてみたところ、テストで使用したデータが元に戻っていた。

DBのユーザーとSamba ad dcのユーザー

インストールしてユーザーを登録していたので、ユーザー一覧はこんな感じになっている(ここまでの設定ができていると /etc/kopano/server.cfg で user_plugin を db に戻すと確認することができる)。

$ sudo kopano-admin -l
User list for Default(4):
        Username        Fullname        Homeserver
        ------------------------------------------------
        SYSTEM          SYSTEM          Kopano
        root            Administrator
        webmaster       Web Master
        hogeuser        Hoge User

それを Samba ad dc の認証に切り替えたらこうなった。

$ sudo kopano-admin -l
User list for Default(6):
        Username        Fullname        Homeserver
        ----------------------------------------------------
        SYSTEM          SYSTEM          Kopano
        Administrator   Administrator
        honmyou         honmyou ← えぇ、本名ですとも。マスクしました。
        krbtgt          krbtgt  ← Kerberosサービスアカウント
        Guest           Guest
        dhcpd           dhcpd

server.cfg の user_plugin が変化すれば即座にこれに対応したユーザーが作られることが分かる。

krbtgt, Guest, dhpcd は見えなくていいユーザーだなぁ。
※後にフィルターをかけて見えなくした。

ちなみに krbtgt というのは kerberosサービスアカウント で、最初はWindows10 にインストールした RSAT の「Active Directory ユーザーとコンピューター」で見えなくてなんだろう？と思ったけれども、表示→拡張機能で表示させたところ見えるようになった。詳しくはここに。
Microsoft TechNet / Kerberos 認証に対する攻撃と対策：KRBTGT Account Password Reset Scripts
Microsoft Docs / AD フォレストの回復 - krbtgt パスワードをリセットします

ストアデータのフック

全ユーザーのストアを付け替える。

$ sudo kopano-admin --list-orphans
Stores without users:
        Store guid                              Guessed username        Last login              Store size      Store type
        --------------------------------------------------------------------------------------------------------------------------
        AAXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX        root                    07/15/2019 03:25:03 AM  293.79 MB       private
        BBXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX        honmyou                 07/15/2019 03:28:13 AM  178.85 MB       private
…
$ sudo kopano-admin --hook-store AAXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX -u Administrator
Store hooked.
$ sudo kopano-admin --hook-store BBXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX -u honmyou
Store hooked.
…

これでログインするとほとんどの情報が復元できていた。

ただし、ACLの情報は設定し切れていないようで、元々共有していたカレンダー等は参照できるのだが、新たに共有しようとするとエラーになる。アクセス権限は付け直しになる。
→ これを復元する方法を探しているが、どうにもうまくいかなかった。

externID置き換えに関わる調査

$ sudo ./db-upgrade-addressbook-entryids.pl
Can't locate XML/DOM.pm in @INC (you may need to install the XML::DOM module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.26.1 /usr/local/share/perl/5.26.1 /usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at ./db-upgrade-addressbook-entryids.pl line 5.
BEGIN failed--compilation aborted at ./db-upgrade-addressbook-entryids.pl line 5.

$ sudo apt install libxml-dom-perl

$ sudo ./db-upgrade-addressbook-entryids.pl
unable to open /etc/zarafa/server.cfg config file at ./db-upgrade-addressbook-entryids.pl line 16.

$ sudo ./db-upgrade-addressbook-entryids.pl /etc/kopano/server.cfg
Database kopanoserver can not be upgraded
Converting properties table step 1 of 11
DBD::mysql::st execute failed: Unknown column 'storeid' in 'field list' at ./db-upgrade-addressbook-entryids.pl line 181.
DBD::mysql::st fetchrow_array failed: fetch() without execute() at ./db-upgrade-addressbook-entryids.pl line 182.
Converting properties table step 2 of 11
…

MariaDB [kopanoserver]> show columns from users;
+-------------+------------------+------+-----+---------+----------------+
| Field       | Type             | Null | Key | Default | Extra          |
+-------------+------------------+------+-----+---------+----------------+
| id          | int(11) unsigned | NO   | PRI | NULL    | auto_increment |
| externid    | blob             | YES  | MUL | NULL    |                |
| objectclass | int(11)          | NO   |     | 0       |                |
| signature   | varbinary(255)   | NO   |     | 0       |                |
| company     | int(11) unsigned | NO   |     | 0       |                |
+-------------+------------------+------+-----+---------+----------------+

MariaDB [kopanoserver]> show columns from object;
+-------------+------------------+------+-----+---------+----------------+
| Field       | Type             | Null | Key | Default | Extra          |
+-------------+------------------+------+-----+---------+----------------+
| id          | int(11) unsigned | NO   | PRI | NULL    | auto_increment |
| externid    | blob             | YES  | MUL | NULL    |                |
| objectclass | int(11) unsigned | NO   | PRI | 0       |                |
+-------------+------------------+------+-----+---------+----------------+

MariaDB [kopanoserver]> show columns from objectproperty;
+----------+------------------+------+-----+---------+-------+
| Field    | Type             | Null | Key | Default | Extra |
+----------+------------------+------+-----+---------+-------+
| objectid | int(11) unsigned | NO   | PRI | 0       |       |
| propname | varchar(255)     | NO   | PRI | NULL    |       |
| value    | text             | YES  |     | NULL    |       |
+----------+------------------+------+-----+---------+-------+

SELECT u.id AS user_id, op.value AS user_name, o.id
 FROM users AS u
 JOIN object AS o ON u.externid=o.externid
 JOIN objectproperty AS op ON o.id=op.objectid AND op.propname='loginname';

SELECT u.id AS user_id, op.value AS user_name, o.id
 FROM users AS u
 JOIN object AS o ON u.externid=o.externid
 JOIN objectproperty AS op ON o.id=op.objectid AND op.propname='groupname';

SELECT u.id AS user_id, op.value AS user_name, o.id
 FROM users AS u
 JOIN object AS o ON u.externid=o.externid
 JOIN objectproperty AS op ON o.id=op.objectid AND
 ( op.propname='loginname' OR op.propname='groupname');

LDAP Account Manager

属性を設定する他の方法を探ってみると、 LDAP Account Manager というツールが Kopano に対応していそうなので、これを使ってみようと思う。
Server World / OpenLDAP : LDAP Account Manager インストール

$ sudo apt install ldap-account-manager

Apacheの設定は
/etc/ldap-account-manager/apache.conf
に書かれていて、インストールするだけでこれが有効になっている。

また、
/etc/ldap-account-manager/config.cfg
を見ると、このツール自体の初期ユーザーはどうやら lam / lam みたい。

https://temp.hogeserver.hogeddns.jp/lam でアクセスする。

右上の LAM configuration から Edit server profiles に進み、どんなユーザーを使えるのか確認してみると…

う、Kopanoはサポート対象外だ…再確認してみたところ Pro バージョンで対応しているとのことで、お値段199ドル、他の方法を探すことにする。

phpLDAPadmin

phpLDAPadmin にきちんと設定をすれば良いだけかも？と思ったのだけれど、テンプレートの書き方について探しても見つからない。これは今後の課題。

Kopano Forum / Kopanao Management GUI
Zarafa Community / Zarafa for LdapAdmin(リンク切れのためアーカイブへ)
Zarafa Wiki / PhpLDAPadmin Template
Zarafa Forum / Phpldapadmin templates