Samba-ad-dcにphpLDAPadminで接続してみる

先日、KopanoとAlfrescoの移行について投稿したが、ユーザーは各アプリケーションで管理されて別々の状態。せっかくSamba-ad-dcを導入したのだから、ユーザーの一元管理がしたい。



Samba-ad-dcがどんな風にデータを管理しているのか理解し切れていないという背景がありつつ、LDAP認証の環境を整理するなら…と、phpLDAPadminの導入を思い立った。接続できるまでに案外時間がかかったので、メモを残しておくことにした。

 

これから設定する環境

いつもは大概同じサーバーにすべてを詰め込んでしまうやり方だが、今回は違っている。

Samba-ad-dcサーバー
 → addc.hogeserber.hogeddns.jp ← 現在、本番稼働中
phpLDAPadminを動かすホスト
 → temp.hogeserver.hogeddns.jp ← 色々なテストを実行するテンポラリ環境

元々はAll in oneなサーバーを運用していたが、DNSも含んでいたが故に設定のためのちょっとした再起動でインターネットにつながらなくなる。家族からの視線が痛い…

そこで、基本的なアプリケーション(DNSとかDHCPとかSamba-ad-dcとか…)を1つのサーバーにまとめ、そのほかの便利なアプリケーションは別のサーバーで動作させることでこの問題を解決しようと活動している。

今後のために、LDAPサーバーは他のホストからのアクセスと認証ができるように設定しておく必要がある。

 

phpLDAPadminからのアクセス方法

phpLDAPadminからSamba-ad-dcへの接続にはいくつかの方法がある(ように思う)が、ここでは2通りの設定を試す。

  • LDAP
    ポート389でアクセス、通信は暗号化されない。
  • LDAPS
    ポート636でアクセス、通信は暗号化される。

SASLだとKerberos認証を利用するっぽいのだけれど、今はまだ知識的に足らないので、今後の課題とする。

やってみた感じでは、最初はLDAPで接続してみて、その後にLDAPSにグレードを上げる方が色々安心な気がする。仕組みが全部理解できていれば良いのだが、そうでもないのにエラーが発生したときのメッセージから原因を探りにくくてきつかったから。できるところから少しずつ設定を育成していく感じで。

 

phpLDAPadminのインストール

temp.hogeserver.hogeddns.jp側の設定

パッケージのインストール

temp.hogeserver.hogeddns.jp に phpLDAPadminをインストールする。

$ sudo apt install phpldapadmin

 

この段階で /etc/apache2/conf-enabled/phpldapadmin.conf が有効になっている。temp.hogeserver.hogeddns.jpはApacheが動作していて、SSLの接続も準備済みなので
https://temp.hogeserver.hogeddns.jp/phpldapadmin
でアクセスが可能になっている。

アクセスすれば画面は表示されるが、設定はこれから、ログインはできない。

もし、Virtual Hostでサブドメイン等を使ってアクセスしたい場合はphpldapadmin.confを無効化し、Virtual Host定義の中でincludeすればいい。

パッチの適用

phpLDAPadmin をテストで動かしているときに不思議なエラー表示がされたりして困っていたのだが、探してみたら、ちょっとだけプログラム修正が必要みたい。
stack overflow / Cant create new entry. PHPLDAPADMIN

/usr/share/phpldapadmin/lib/functions.php
※54行目 関数名を修正
function __autoload($className) {
function my_autoload($className) {

※777行目 1行追加
return base64_encode($encrypt);
}
spl_autoload_register("my_autoload");
/**
* Decryption using blowfish algorithm

※1083行目 アンダースコアを2つ追加
$code .= 'return $c;';

 $CACHE[$sortby] = create_function('$a, $b',$code);
$CACHE[$sortby] = __create_function('$a, $b',$code);
}

※1091行目 関数を1つ追加
/**
* Is compression enabled for output
*/
function __create_function($arg, $body) {
static $cache = array();
static $maxCacheSize = 64;
static $sorter;

if ($sorter === NULL) {
$sorter = function($a, $b) {
if ($a->hits == $b->hits) {
return 0;
}

return ($a->hits < $b->hits) ? 1 : -1;
};
}

$crc = crc32($arg . "\\x00" . $body);

if (isset($cache[$crc])) {
++$cache[$crc][1];
return $cache[$crc][0];
}

if (sizeof($cache) >= $maxCacheSize) {
uasort($cache, $sorter);
array_pop($cache);
}

$cache[$crc] = array($cb = eval('return function('.$arg.'){'.$body.'};'), 0);
return $cb;
}

function isCompress() {
return (isset($_SESSION[APPCONFIG]) && $_SESSION[APPCONFIG]->getValue('appearance','compress')

 

修正後の再起動等は必要なかった。

 

LDAPにアクセス

この場合、Samba-ad-dcは通信のTLS(Transport Layer Security)をオフにして、さらにセキュリティレベルを下げて phpLDAPadmin からアクセスする。

LAN内部の話ではあるものの、脆弱性とかいわれるレベルらしいので、接続して中身が確認できたらLDAPSに挑戦すべきだろうと思われる。

Samba-ad-dcの設定

addc.hogeserver.hogeddns.jp側の設定

Samba-ad-dc が提供するLDAPのセキュリティレベルを下げる。

/etc/samba/smb.conf ※赤文字部分を追記
[global]…
ldap server require strong auth = no

 

Sambaサーバーを再起動。

$ sudo systemctl restart samba-ad-dc

 

LDAPで接続するためにポートを空けておく。

$ sudo ufw allow to any port 389 proto tcp from 172.16.0.0/16 comment SAMBA LDAP
$ sudo ufw allow to any port 389 proto tcp from 24xx:xxxx:xxxx:xxxx::/64 comment SAMBA LDAP
$ sudo ufw allow to any port 389 proto tcp from fdxx:xxxx:xxxx:xxxx::/64 comment SAMBA LDAP

※下の2行はIPv6でマスクを掛けている。使っているなら開けておく。

 

phpLDAPadminの設定

temp.hogeserver.hogeddns.jp側の設定

最低限の認証レベルで接続するための設定となる。

/etc/phpldapadmin/config.php ※対象となる行を探して設定
/* Hide the warnings for invalid objectClasses/attributes in templates. */
$config->custom->appearance['hide_template_warning'] = true;

/* A convenient name that will appear in the tree viewer and throughout
phpLDAPadmin to identify this LDAP server to users. */
$servers->setValue('server','name','LDAP Hogeserver');

/* Examples:
'ldap.example.com',
'ldaps://ldap.example.com/',
'ldapi://%2fusr%local%2fvar%2frun%2fldapi'
(Unix socket at /usr/local/var/run/ldap) */
$servers->setValue('server','host','addc.hogeserver.hogeddns.jp');

/* Array of base DNs of your LDAP server. Leave this blank to have phpLDAPadmin
auto-detect it for you. */
#$servers->setValue('server','base',array('dc=example,dc=com'));

/* The DN of the user for phpLDAPadmin to bind with. For anonymous binds or
'cookie','session' or 'sasl' auth_types, LEAVE THE LOGIN_DN AND LOGIN_PASS
BLANK. If you specify a login_attr in conjunction with a cookie or session
auth_type, then you can also specify the bind_id/bind_pass here for searching
the directory for users (ie, if your LDAP server does not allow anonymous
binds. */
$servers->setValue('login','bind_id','administrator@hogeserver.hogeddns.jp');

 

$config->custom->appearance[‘hide_template_warning’] = true;

ログインした後、各種の値を見ようとすると「テンプレートにあるオブジェクトがない」「テンプレートにある属性がない」という警告が多数表示される。オブジェクトや属性がなくても Samba-ad-dc は問題なく動作しているので問題はないことから、この警告を表示させないように設定。

$servers->setValue(‘server’,’name’,’LDAP Hogeserver‘);

接続先のサーバーが分かる名前を付けておいた。

$servers->setValue(‘server’,’host’,’addc.hogeserver.hogeddns.jp‘);

接続先のサーバー。ldap://addc.hogeserver.hogeddns.jp と設定しても問題なく接続できていた。

#$servers->setValue(‘server’,’base’,array(‘dc=example,dc=com’));

ログイン直後に表示するDN(Distinguished Name)を設定できる。未指定の場合、すべてのDNが表示されるので、コメント化した。

$servers->setValue(‘login’,’bind_id’,’administrator@hogeserver.hogeddns.jp‘);

ログインリンクをクリックした際に表示されるログインID。
Symfowareについての考察blog / SCM-Managerの認証をActiveDirectoryで行うを参考に値を設定。
ログインした後に調べてみたら、例えばこの administrator さんは以下のDNで表現できる。この形式で設定するのも可。
CN=Administrator,CN=Users,DC=hogeserver,DC=hogeddns,DC=jp

ログインしてみる

ここまで設定すればログインできるはず。
https://temp.hogeserver.hogeddns.jp/phpladpadmin
※httpのみ提供しているのであればhttpでアクセスしてログイン。

ログインしてSamba-ad-dcでどんなデータが管理されているのかを見てみると、作ったユーザーやDNSのゾーンなんかが見えて面白い。

ここまでできたら、LDAPSに設定を変えていく。開いたポートは閉じてしまおう。

$ sudo ufw delete allow to any port 389 proto tcp from 172.16.0.0/16 comment SAMBA LDAP
$ sudo ufw delete allow to any port 389 proto tcp from 24xx:xxxx:xxxx:xxxx::/64 comment SAMBA LDAP
$ sudo ufw delete allow to any port 389 proto tcp from fdxx:xxxx:xxxx:xxxx::/64 comment SAMBA LDAP

 

LDAPSにアクセス

通信を暗号化して安全にする。ここまででLDAPに接続できるようになっている前提で記載。

Samba-ad-dcの設定

addc.hogeserver.hogeddns.jp側の設定

Samba-ad-dc側がLDAPSでサービスを提供できるように設定を変更。やり方は
Samba Wiki / Configuring LDAP over SSL (LDAPS) on a Samba AD DC
に記載されている。

Sambaは動くように動くようにアシストしてくれるイメージだが、イメージ通りで既に独自のサーバー証明書、鍵、認証局証明書ができている。期限は作成日から700日とされていて、実際にそうなっていた。

/var/lib/samba/private/tls
├ cert.pem
├ key.pem
└ ca.pem

 

これを使っても良いし、自分で作った証明書を利用してもいい。

ウチでは以前、オレオレ認証局を作って運用しているので、オレオレサーバー証明書に署名して利用することにした。

秘密鍵は以下の条件を満たす必要がある。

  • パーミッションが600であること。
  • パスフレーズなしでアクセスできること。

まずはパーミッションを確認。

$ sudo ls -l /etc/ssl/private/
total 12
-rw------- 1 root root 1480 Apr 10 20:08 addc.crt
-rw------- 1 root root 1675 Apr 10 20:08 addc.key
-rw-r----- 1 root ssl-cert 1704 Apr 8 21:55 ssl-cert-snakeoil.key

 

続いてパスフレーズなしでアクセスできるかどうか確認。
stack overflow / How do I verify/check/test/validate my SSH password?

$ sudo ssh-keygen -y -f /etc/ssl/private/hogeserver.key
ssh-rsa XXXXXX・・・

※パスワードが必要な場合、ここでパスフレーズを求められるらしい。ここではパスフレーズを求められなかったので、パスフレーズがないことが分かる。

秘密鍵は適合しているようなので、smb.confに以下を追記。

/etc/samba/smb.conf
[global]…
# LDAPSを有効化
tls enabled = true
tls keyfile = /etc/ssl/private/hogeserver.key
tls certfile = /etc/ssl/private/hogeserver.crt
tls cafile =

# LDAP接続の時に緩めた設定を元に戻す
# ldap server require strong auth = no

[netlogon]…

 

Sambaが作ってくれた証明書を使う場合にはこんな指定になる。
    tls keyfile  = tls/key.pem
tls certfile = tls/cert.pem
tls cafile = tls/ca.pem

※試していない。

証明書の設定ができたら、Sambaの再起動。

$ sudo systemctl restart samba-ad-dc.service

 

LDAPSのポートを開放する。

$ sudo ufw allow to any port 636 proto tcp from 172.16.0.0/16 comment SAMBA LDAPS
$ sudo ufw allow to any port 389 proto tcp from 24xx:xxxx:xxxx:xxxx::/64 comment SAMBA LDAPSSO対応に
$ sudo ufw allow to any port 389 proto tcp from fdxx:xxxx:xxxx:xxxx::/64 comment SAMBA LDAPS

 

 

phpLDAPadminの設定

temp.hogeserver.hogeddns.jp側の設定

LDAPSで接続したときに、addc.hogeserver.hogeddns.jpから提示される証明書を信用するために、以下を参考にオレオレ認証局の証明書を登録する。
cloudpack.media / 独自のルートCA証明書を追加する方法(Ubuntu, CentOS 7)

認証局は以前の投稿で作っているので…
  hogeserver にある /etc/ssl/hogeCA/cacert.pem
を持ってきて、
  /usr/share/ca-certificates/hogeserver.hogeddns.jp.crt
という名前で保管。

Sambaが作ってくれた証明書なら addc.hogeserver.hogeddns.jp の /var/lib/samba/private/tls/ca.pem を持ってくれば多分大丈夫。

登録したオレオレ認証局の証明書を設定ファイルに追記。
/etc/ca-certificats.conf

hogeserver.hogeddns.jp.crt

 

以下のコマンドで登録。

$ sudo update-ca-certificates
Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...

Adding debian:hogeserver.hogeddns.jp.pem
done.
done.

 

その上で、LDAPSで接続ができるように設定する。

/etc/phpldapadmin/config.php ※対象となる行を探して設定
/* Hide the warnings for invalid objectClasses/attributes in templates. */
$config->custom->appearance['hide_template_warning'] = true;

/* A convenient name that will appear in the tree viewer and throughout
phpLDAPadmin to identify this LDAP server to users. */
$servers->setValue('server','name','LDAP Hogeserver');

/* Examples:
'ldap.example.com',
'ldaps://ldap.example.com/',
'ldapi://%2fusr%local%2fvar%2frun%2fldapi'
(Unix socket at /usr/local/var/run/ldap) */
$servers->setValue('server','host','ldaps://addc.hogeserver.hogeddns.jp');

/* The port your LDAP server listens on (no quotes). 389 is standard. */
$servers->setValue('server','port',636);

/* Array of base DNs of your LDAP server. Leave this blank to have phpLDAPadmin
auto-detect it for you. */
#$servers->setValue('server','base',array('dc=example,dc=com'));

/* The DN of the user for phpLDAPadmin to bind with. For anonymous binds or
'cookie','session' or 'sasl' auth_types, LEAVE THE LOGIN_DN AND LOGIN_PASS
BLANK. If you specify a login_attr in conjunction with a cookie or session
auth_type, then you can also specify the bind_id/bind_pass here for searching
the directory for users (ie, if your LDAP server does not allow anonymous
binds. */
$servers->setValue('login','bind_id','administrator@hogeserver.hogeddns.jp');

 

LDAPと違うところといえば、host指定の先頭に ldaps:// を付けたことと、ポート636を指定したことくらい。

ログインしてみる

ここまで設定すればログインできるはず。
https://temp.hogeserver.hogeddns.jp/phpladpadmin
※httpのみ提供しているのであればhttpでアクセスしてログイン。

LDAPで接続したときと表示される内容は全然変わらないが、暗号化されていて安心。

以上で設定完了。

 

やったこと

色々な設定の問題が発生した。思っていたより難しかった印象。

 

ログインできない

ログイン時に以下のエラーが発生。色々なパターンがあるみたい。

Error: Strong(er) authentication required (8) for user

 

(1) LDAPサーバーがStrong Authを要求している

Samba-ad-dcのデフォルトは「Strong Auth」を要求している。

smb.conf[grobal]パラメータ ldap server require strong auth で指定が可能で、デフォルトは yes となっている。

LDAPに接続しようとしたとき、Samba側の設定は必要ない?くらいの感覚だったが、このパラメータを no にしないと接続できなかった。

 

(2) LDAP&TLSで接続しようとしているがTLSが有効になっていない

デフォルトではTLSは無効になっているので、有効化する。

/etc/papldapadmin/config.php
$servers->setValue('server','host','ldap://addc.hogeserver.hogeddns.jp');
$servers->setValue('server','port',389);
$servers->setValue('server','tls',true);

 

 

証明書の確認でエラーが出ていた

LDAPSで接続しようとしたら、以下のエラーが出た。

Error: Could not start TLS. Please check your LDAP server configuration.

 

(1) オレオレ証明書なのにオレオレ認証局が登録されていない

LDAPSのサーバーが提示してくるオレオレサーバー証明書を信用できないと、エラーが出力される。phpLDAPadminをインストールしているホストにオレオレ認証局の証明書をインストールしておく必要がある。

phpLDAPadminをインストールしたサーバーから接続テストしてみる。

$ openssl s_client -showcerts -connect addc.hogeserver.hogeddns.jp:636
CONNECTED(00000005)
depth=0 C = JA, ST = Tokyo, O = Hoge, CN = share.hogeserver.hogeddns.jp, emailAddress = webmaster@hogeserver.hogeddns.jp
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = JA, ST = Tokyo, O = Hoge, CN = share.hogeserver.hogeddns.jp, emailAddress = webmaster@hogeserver.hogeddns.jp
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:C = JA, ST = Tokyo, O = Hoge, CN = share.hogeserver.hogeddns.jp, emailAddress = webmaster@hogeserver.hogeddns.jp
i:C = JA, ST = Tokyo, O = Hoge, CN = hogeserver.hogeddns.jp, emailAddress = webmaster@hogeserver.hogeddns.jp
-----BEGIN CERTIFICATE-----
<省略>
-----END CERTIFICATE-----
---
Server certificate
subject=C = JA, ST = Tokyo, O = Hoge, CN = share.hogeserver.hogeddns.jp, emailAddress = webmaster@hogeserver.hogeddns.jp

issuer=C = JA, ST = Tokyo, O = Hoge, CN = hogeserver.hogeddns.jp, emailAddress = webmaster@hogeserver.hogeddns.jp

---
No client certificate CA names sent
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: RSA+SHA256:ECDSA+SHA256:RSA+SHA384:ECDSA+SHA384:RSA+SHA512:ECDSA+SHA512:RSA+SHA224:ECDSA+SHA224:RSA+SHA1:ECDSA+SHA1
Shared Requested Signature Algorithms: RSA+SHA256:ECDSA+SHA256:RSA+SHA384:ECDSA+SHA384:RSA+SHA512:ECDSA+SHA512:RSA+SHA224:ECDSA+SHA224:RSA+SHA1:ECDSA+SHA1
Peer signing digest: SHA256
Peer signature type: RSA
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 1597 bytes and written 462 bytes
Verification error: unable to verify the first certificate
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX・・・
Session-ID-ctx:
Master-Key: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX・・・
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1561062987
Timeout : 7200 (sec)
Verify return code: 21 (unable to verify the first certificate)
Extended master secret: yes
---

 

エラーが出てる…

オレオレ認証局の証明書を登録したら、エラーを解消できた。

$ openssl s_client -showcerts -connect addc.hogeserver.hogeddns.jp:636

Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 1597 bytes and written 462 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384

 

(2) LDAPSなのにTLSをtrueにしていた

LDAPSで接続する場合、それだけでTLSはONになっている(通信内容を見たわけではないが、Samba-ad-dc側の設定がTLSを要求しているから、まず間違いない)。

それなのに、試行錯誤の途中で書いたこの設定が残っていた。

/etc/papldapadmin/config.php
$servers->setValue('server','host','ldaps://addc.hogeserver.hogeddns.jp');
$servers->setValue('server','port',636);

/* Use TLS (Transport Layer Security) to connect to the LDAP server. */
$servers->setValue('server','tls',true);

 

これだと、ログインができない。

/etc/papldapadmin/config.php ※LDAPSの接続
$servers->setValue('server','host','ldaps://addc.hogeserver.hogeddns.jp');
$servers->setValue('server','port',636);

/* Use TLS (Transport Layer Security) to connect to the LDAP server. */
#$servers->setValue('server','tls',true);

 

または、

/etc/papldapadmin/config.php ※LDAP + TLSの接続
$servers->setValue('server','host','addc.hogeserver.hogeddns.jp');
#$servers->setValue('server','port',636);

/* Use TLS (Transport Layer Security) to connect to the LDAP server. */
$servers->setValue('server','tls',true);

 

のいずれかで安全に接続できる。本文中では前者を採用している。

 

(3) 接続先サーバー名が証明書のサーバー情報と一致しない

どうにかログインできたが、エラーが大量に出力された。

Array
(
    [class] => N/A
    [function] => debug_dump
    [file] => /usr/share/phpldapadmin/lib/functions.php
    [line] => 700
    [debug] => Array
        (
            [Incoming MSG] => Array
                (
                    [title] => Could not start TLS. (LDAP Hogeserver)
                    [body] => Error: Could not start TLS. Please check your LDAP server configuration.
                    [type] => error
                )

            [existing] => Array
                (
                    [0] => Array
                        (
                            [title] => Could not start TLS. (LDAP Hogeserver)
                            [body] => Error: Could not start TLS. Please check your LDAP server configuration.
                            [type] => error
                        )

                    [1] => Array
                        (
                            [title] => Authenticate to server
                            [body] => Successfully logged into server.
                            [type] => info
                        )

                )

        )

)

 

色々探してみたら、config.phpで指定しているサーバーと証明書が一致していないことが原因でこの問題が発生する、と教えてくれた。
Stack Exchange / phpldapadmin with STARTTLS

その観点で確認してみると…

$ openssl s_client -showcerts -connect addc.hogeserver.hogeddns.jp:636
CONNECTED(00000005)
depth=1 C = JA, ST = Tokyo, O = Hoge, CN = hogeserver.hogeddns.jp, emailAddress = webmaster@hogeserver.hogeddns.jp
verify return:1
depth=0 C = JA, ST = Tokyo, O = Hoge, CN = share.hogeserver.hogeddns.jp, emailAddress = webmaster@hogeserver.hogeddns.jp
verify return:1
---
Certificate chain
0 s:C = JA, ST = Tokyo, O = Hoge, CN = share.hogeserver.hogeddns.jp, emailAddress = webmaster@hogeserver.hogeddns.jp
i:C = JA, ST = Tokyo, O = Hoge, CN = hogeserver.hogeddns.jp, emailAddress = webmaster@hogeserver.hogeddns.jp

 

確かに証明書が合ってないな(汗

この証明書はaddcサーバーに持たせた「Webサーバーの転送機能」でSSLを提供するために別のサーバーで作った証明書を流用したものであって、このサーバーを表しているのではなかった(適当だなぁオレ…)。

そこで、以前の投稿をベースにこのサーバー用の証明書を再度作成してSambaに読み込ませたところ、この問題が解消した。

$ openssl s_client -showcerts -connect addc.hogeserver.hogeddns.jp:636
CONNECTED(00000005)
depth=1 C = JA, ST = Tokyo, O = Hoge, CN = hogeserver.hogeddns.jp, emailAddress = webmaster@hogeserver.hogeddns.jp
verify return:1
depth=0 C = JA, ST = Tokyo, O = Hoge, CN = addc.hogeserver.hogeddns.jp, emailAddress = webmaster@hogeserver.hogeddns.jp
verify return:1
---
Certificate chain
0 s:C = JA, ST = Tokyo, O = Hoge, CN = addc.hogeserver.hogeddns.jp, emailAddress = webmaster@hogeserver.hogeddns.jp
i:C = JA, ST = Tokyo, O = Hoge, CN = hogeserver.hogeddns.jp, emailAddress = webmaster@hogeserver.hogeddns.jp

 

なお、件の参照元では、IPアドレスで指定したのをFQDNに変えたら直ったと書かれていたので試しにIPアドレス指定で接続してみたところ、問題なく接続できた。
これはCNじゃなくてSubject Alternative Nameを見ているのかな?と思ったけど確証はない。

試行錯誤の過程で、temp.hogeserver.hogeddns.jp側から、addc.hogeserver.hogeddns.jpが提示している証明書の中身をさらっと確認できないかな~と思っていたら、こんな方法があった。
stackoverflow / How to Check Subject Alternative Names for a SSL/TLS Certificate?

通信内容に証明書の情報があるから、それを情報表示コマンドに流し込んでいる模様。
$ openssl s_client -showcerts -connect addc.hogeserver.hogeddns.jp:636 | openssl x509 -noout -text
depth=1 C = JA, ST = Tokyo, O = Hoge, CN = hogeserver.hogeddns.jp, emailAddress = webmaster@hogeserver.hogeddns.jp
verify return:1
depth=0 C = JA, ST = Tokyo, O = Hoge, CN = addc.hogeserver.hogeddns.jp, emailAddress = webmaster@hogeserver.hogeddns.jp
verify return:1
Certificate:
Data:
Version: 3 (0x2)

X509v3 Subject Alternative Name:
DNS:addc.hogeserver.hogeddns.jp, DNS:addc, IP Address:172.16.nnn.nnn, IP Address:24xx:xxxx:xxxx:xxxx:nnnn:nnnn:nnnn:nnnn, IP Address:FDxx:xxxx:xxxx:xxxx:nnnn:nnnn:nnnn:nnnn

 

 

テンプレートのワーニングが大量に出る

例えば、Administratorの情報を見ようとすると、大量のワーニングが出力される。

warn Automatically removed objectClass from template
Samba: Machine: sambaSAMAccount removed from template as it is not defined in the schema
warn Automatically removed objectClass from template
Thunderbird: Address Book Entry: mozillaOrgPerson removed from template as it is not defined in the schema
warn Automatically removed objectClass from template
Samba: Account: sambaSAMAccount removed from template as it is not defined in the schema
warn Automatically removed objectClass from template
Courier Mail: Account: courierMailAccount removed from template as it is not defined in the schema
warn Automatically removed attribute from template
Courier Mail: Account: uidNumber removed from template as it is not defined by an ObjectClass
warn Automatically removed attribute from template
Courier Mail: Account: gidNumber removed from template as it is not defined by an ObjectClass
warn Automatically removed objectClass from template
Samba: Group Mapping: sambaGroupMapping removed from template as it is not defined in the schema
warn Automatically removed objectClass from template
Generic: LDAP Alias: alias removed from template as it is not defined in the schema
warn Automatically removed objectClass from template
Generic: LDAP Alias: extensibleObject removed from template as it is not defined in the schema
warn Automatically removed objectClass from template
Generic: DNS Entry: dnsDomain removed from template as it is not defined in the schema
warn Automatically removed attribute from template
Generic: DNS Entry: dc removed from template as it is not defined by an ObjectClass
warn Automatically removed objectClass from template
Courier Mail: Alias: courierMailAlias removed from template as it is not defined in the schema

 

phpLDAPadminに定義されているテンプレートがあって、そこにあるクラスオブジェクトや属性に「ない」ものがあると警告が表示される模様。
Samba-ad-dcは現時点では問題なく動いているから何かを追加しなきゃならない状態にはないと思われるので、ここでは警告表示を止めることにした。
phpLDAPadmin / FAQ

/etc/phpldapadmin/config.php
$config->custom->appearance['hide_template_warning'] = true;

 

Samba-ad-dcが開いているポートの確認

そもそも、現在動いているSamba-ad-dcのLDAP機能へのアクセスはできるのだろうか?片っ端から確認。
Wikipedia / TCPやUDPにおけるポート番号の一覧

# Lightweight Directory Access Protocol (LDAP)
$ sudo lsof -i:389
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
samba 1538 root 23u IPv6 23125 0t0 TCP *:ldap (LISTEN)
samba 1538 root 32u IPv4 23129 0t0 TCP *:ldap (LISTEN)
samba 1539 root 23u IPv6 22939 0t0 UDP *:ldap
samba 1539 root 29u IPv4 22940 0t0 UDP *:ldap
samba 1539 root 31u IPv6 22941 0t0 UDP [24xx:xxxx:xxxx:xxxx::nnnn]:ldap
samba 1539 root 32u IPv6 22942 0t0 UDP [24xx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx]:ldap
samba 1539 root 33u IPv6 22943 0t0 UDP [fdxx:xxxx:xxxx:xxxx::nnnn]:ldap
samba 1539 root 34u IPv4 22944 0t0 UDP 172.16.nnn.nnn:ldap

# Lightweight Directory Access Protocol over TLS/SSL (LDAPS)
$ sudo lsof -i:636
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
samba 1538 root 28u IPv6 23126 0t0 TCP *:ldaps (LISTEN)
samba 1538 root 33u IPv4 23130 0t0 TCP *:ldaps (LISTEN)

# Microsoft Global Catalog (LDAP service which contains data from Active Directory forests)
$ sudo lsof -i:3268
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
samba 1538 root 30u IPv6 23127 0t0 TCP *:3268 (LISTEN)
samba 1538 root 34u IPv4 23131 0t0 TCP *:3268 (LISTEN)

# Microsoft Global Catalog over SSL (similar to port 3268, LDAP over SSL)
$ sudo lsof -i:3269
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
samba 1538 root 31u IPv6 23128 0t0 TCP *:3269 (LISTEN)
samba 1538 root 35u IPv4 23132 0t0 TCP *:3269 (LISTEN)

 

ついでにKerberosに関係しそうなポートも全部見てみる。

# Kerberos authentication system
$ sudo lsof -i:88
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
samba 1540 root 23u IPv6 23109 0t0 TCP *:kerberos (LISTEN)
samba 1540 root 30u IPv6 23110 0t0 UDP *:kerberos
samba 1540 root 34u IPv4 23113 0t0 TCP *:kerberos (LISTEN)
samba 1540 root 35u IPv4 23114 0t0 UDP *:kerberos
samba 1540 root 38u IPv6 23117 0t0 UDP [24xx:xxxx:xxxx:xxxx::nnnn]:kerberos
samba 1540 root 40u IPv6 23119 0t0 UDP [24xx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx]:kerberos
samba 1540 root 42u IPv6 23121 0t0 UDP [fdxx:xxxx:xxxx:xxxx::nnnn]:kerberos
samba 1540 root 44u IPv4 23123 0t0 UDP 172.16.nnn.nnn:kerberos

# Kerberos Change/Set password
$ sudo lsof -i:464
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
samba 1540 root 32u IPv6 23111 0t0 TCP *:kpasswd (LISTEN)
samba 1540 root 33u IPv6 23112 0t0 UDP *:kpasswd
samba 1540 root 36u IPv4 23115 0t0 TCP *:kpasswd (LISTEN)
samba 1540 root 37u IPv4 23116 0t0 UDP *:kpasswd
samba 1540 root 39u IPv6 23118 0t0 UDP [24xx:xxxx:xxxx:xxxx::nnnn]:kpasswd
samba 1540 root 41u IPv6 23120 0t0 UDP [24xx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx]:kpasswd
samba 1540 root 43u IPv6 23122 0t0 UDP [fdxx:xxxx:xxxx:xxxx::nnnn]:kpasswd
samba 1540 root 45u IPv4 23124 0t0 UDP 172.16.nnn.nnn:kpasswd

# klogin, Kerberos login
$ sudo lsof -i:543

# kshell, Kerberos Remote shell
$ sudo lsof -i:544

# Kerberos administration
$ sudo lsof -i:749

# kerberos-iv, Kerberos version IV
$ sudo lsof -i:750

# kerberos_master, Kerberos authentication
$ sudo lsof -i:751

# passwd_server, Kerberos password (kpasswd) server
$ sudo lsof -i:752

# userreg_server, Kerberos userreg server
$ sudo lsof -i:753

# krb5_prop, Kerberos v5 slave propagation
$ sudo lsof -i:754

# krbupdate [kreg], Kerberos registration
$ sudo lsof -i:760

# Kerberos Post Office Protocol (KPOP)
$ sudo lsof -i:1109

# knetd Kerberos de-multiplexor
$ sudo lsof -i:2053

# eklogin Kerberos encrypted remote login (rlogin)
$ sudo lsof -i:2105

 

さいごに

考えていた以上に時間がかかってしまったが、どうにか認証されてSamba-ad-dcの管理項目をツリー状に簡単にたどっていける環境ができた。

そして、認証に関して少しだけ理解が進んだことは、今後の設定で活きてくるだろう。

なかなかの成果!だと思うことにした。

お気軽にどうぞ ~ 投稿に関するご意見・感想・他

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です