macOS Server を利用するならば Open Directory を必ず起動させるべきであろう。OpenLDAP に独自のカスタマイズを施した Open Directory は野心的な設計がなされている。 Directory Server でありながらパスワードを記録しないため、LDAP ではパスワードの取得が一切できない。 パスワードは Open Directory の背後にある Apple Password Server (SASL Server) に認証方式に対応した HASH 値が記録され、パスワードそのものは記録されていないようだ。
この仕様は Open Directory を LDAP サーバとして他のサーバと連携させる際に大変悩ましい点であり、 Apple が macOS Server で利用する OSS によるサーバソフトウェアをカスタマイズした理由でもあるようだが、 統合されているうちは SSO の実現といったアカウント管理上の大きな利点を生んでいた。 また HASH 値とはいえ SASL Server に接続しないとパスワードがわからない点も面白い実装である。
SASL Server に接続する場合は例えば telnet localhost apple-sasl とすればよい。LIST と打つことで利用可能な認証方式を教えてくれる。
あるいは ldapsearch -LLL -x -b "" -s base 'objectclass=*' supportedSASLMechanisms または ldapsearch -x -b "" -s base -LLL supportedSASLMechanisms でも良い。
pwpolicy -n /LDAPv3/127.0.0.1 -getglobalhashtypes でも良かったが最近廃止されたので参照できない。
認証方式に対する HASH 値はパスワード作成時にのみ計算されるものとなっているので、Open Directory を利用するサービスに合わせて予め SASL の認証方式を有効にしておく必要性がある。
SASL の設定を変えるにはノード /LDAPv3/127.0.0.1 のエントリ Config/dirserv を編集するといいという。
この操作は以前は slapconfig -getauthmechanisms や slapconfig -setauthmechanisms などでできたが現在はできない。
Directory Utitilies.app を使用するか dscl -u diradmin -p /LDAPv3/127.0.0.1 -append /Config/dirserv apple-enabled-auth-mech SMB-NTLMv2 などすればいいだろう。
また /Library/Preferences/OpenDirectory/Configurations/LDAPv3/127.0.0.1.plist に無効化された認証方式が列挙されているので、場合によっては SIP を無効化した上で編集する必要性もあるらしい。
認証方式に対応する HASH 値を得たり HASH 値で認証したい場合は幾つか選択肢がある。
HASH 値を得たい場合は mkpassdb -dump で slot ID を参照して確認するか、Berkeley DB 形式のデータベース /var/db/openldap/authdata/id2entry.bdb を直接参照するといい。
HASH 値で認証したい場合は apple-sasl の TCP 3659 番ポートに接続するか、Open Directory Framework の ODRecord クラスを使用するかといった方法があるが、仕様が不明瞭で全てを実証できなかった。
Apple 製品にプロファイル（.mobileconfig）をインストールして一元管理する際に役立つ機能となっている。APNs（Apple Push Notification service）を利用する際は Profile Manager を有効にすると証明書を発行して貰える。ここで得た証明書は Dovecot などでプッシュ通知したい場合などにも使えるのだという。
macOS Server ユーザが最も落胆した点はファイル共有サービスの廃止であろうか。しかしながらファイル共有はほぼ完全な形で再現することが可能となっている。
Open Directory ユーザが SMB (Samba) を利用する場合は SMB-NTLMv2 を認証方式に加える必要性があるようだが、ACL はファイルシステムの機能となっているため、CLI から操作可能である。
ACL を追加する場合は chmod コマンドで操作でき、chmod -R +ai #2 'group:staff allow ... といったような書式で追加することができる。
+i は inherited フラグを意味しており、通常は -R と一緒に再帰的に使用する場合に指定する。詳しくは man を読むといいだろう。
ただし Open Directory を有効にするとローカルユーザからログインできない。オプションの Windows ファイル共有でアカウントをオンにせねばならない。 関連づけられた Apple ID で接続することもできそうにない。 マウントポイントの名称をディレクトリ名から変更したり、アクセスログを取る方法もよくわからない。ログの方は FSEvents である擬似的に再現可能ではある。 Apple に問い合わせた人によれば、アクセスログは tcpdump せよと言われたそうで、とても真似できそうにない。
Linux から接続する場合は一工夫必要で SMB 3.0 で接続する場合は NetBIOS 名を指定する必要性がある。
Finder から接続する場合は意識していないが、実際には指定されていることが macOS Server のログから読み取れる。故に次のようにする。
mount -t cifs 'ADDRESS' 'DIRECTORY' -o ro,nounix,username=****,sec=ntlmssp,password=****,domain=****
認証する際の ACL も未だに有効である。com.apple.access_smb グループに指定されたユーザだけがアクセス可能であるといった設定もできるが、初期設定では存在しないために適当に作る必要性がある。
dscl . -create /Groups/com.apple.access_smb dscl . -create /Groups/com.apple.access_smb PrimaryGroupID 421 dscl . -create /Groups/com.apple.access_smb RealName "SMB Service ACL"
上記は設定例である。現在ローカルなディレクトリサービスに予約済み ACL の gid は 395 から 400 だったので、空いている番号を適当に割り当てる。
com.apple.access_smb グループがない場合はログイン可能なすべてのユーザが認証可能になる。
ログイン可能かどうかは com.apple.access_disabled に指定されているか、パスワードサーバ上で isDisabled が指定されているかどうかなどで判定されているようだ。
特筆しておきたい点は、ファイル共有サービスだけならば macOS Server は不要らしいという点である。
ファイルに ACL を指定し、com.apple.access_smb グループを作るなどすれば、macOS だけでファイル共有サービスがある程度再現できてしまうようだ。
メールサーバは最も面倒な移転作業が必要になるであろうサービスの一つである。メモは IMAP サーバを用意できれば同時に提供される。 SSL/TLS 通信前提となるためパスワード認証でよければ、Dovecot + PAM + LDAP 構成で Dovecot 上で認証可能となるようなので、 Postfix の認証を Dovecot にやらせるようにしてしまえばよい。Postfix のメール転送は Dovecot の LMTP を有効にする方法が最も面倒がなくて良いように思われる。
CRAM-MD5 認証などを実施したい場合は、Dovecot で checkpassword を利用する選択肢がある。
パスワードがわからないと HASH 値の計算ができないため、checkpassword で HASH 値そのものを Dovecot に渡して検証は Dovecot にやらせる発想である。
PAM + LDAP だけでは macOS Server で使用できた ACL com.apple.access_mail の有効性などが確認できないように思われるので、checkpassword を利用する選択肢は最も無難である。
Open Directory には apple-user-mailattribute 属性があり、転送設定などをここで指定できたように記憶している。 かつては Workgroup Manager.app を使ってメール転送設定が編集できた。参照方法がわからないので、ひとまず /etc/aliases を編集する方が無難。
macOS の Mail.app のプッシュ通知は IMAP IDLE で実現されているため、デフォルトで有効な Dovecot では特に対応することがない。 さらに Profile Manager サービスで作成された APNs の証明書を用意すれば、Dovecot XAPS Daemon/XAPS PlugIn と組み合わせて iOS プッシュ通知対応のサーバを用意することができるという。 かつて au の @ezweb.ne.jp がやっていたような Exchange によるプッシュ通知を除けば、iOS の IMAP プッシュ通知に対応するにはこの選択肢以外には存在していないのだという。
macOS Server ではスパム対策は SpamAssassin や DNS BL などを用いていた。メールサービスは他にも DKIM への対応、好みにより Postgrey を導入などすべきことも多く、環境によってかなりカスタマイズされていたことだろう。
Apple は FreeRADIUS に Open Directory 用のモジュールを追加している。macOS にそのままインストールすれば従来通りに使用できるようだが、EAP-TLS などには対応していないしできない。 EAP が欲しければ別途対応が必要になる。Open Directory と組み合わせて AirMac 機器の管理がかつては出来ていたが、台数がそこまで少ないならばあまりこだわる必要性もないだろう。 WPA/WPA2 Enterprise への対応は用意した FreeRADIUS の設定をそのまま渡してしまえばいい。
Open Directory 上の ACL を参照したいならば、FreeRADIUS は exec モジュールが使えるので、外部スクリプトを使ってユーザの有効性を Open Directory に問い合わせるようにすれば良い。 この設定は後述の VPN でも応用することができるようになる。
macOS Server では Apache2 が使われていたが、こちらの移転難易度はそこまで難しくない。 macOS にそのまま含まれている上、特別に作業すべき点も元々少なかった。ただし認証機能だけは別である。
Apple は Apache2 に Open Directory 用のモジュールを追加することで Open Directory ユーザの Digest 認証に対応していた。 この方法は HASH 値が htdigest などで保管されていないという点で安全性が極めて高いと言えるが、macOS 上以外で対応する方法はかなり骨が折れそうで見当すらつかない。 Nginx を認証プロキシのように運用すれば再現できなくもなさそうであるが未検証である。
macOS Server では L2TP + IPSec の古い方式のリモートアクセス VPN に対応していたように記憶している。 この認証では MS-CHAPv2 などの認証方式が必要になり、Open Directory で対応可能であるが、SASL へ追加する必要性があるようだ。
VPN を実現したいのであれば、VyOS を導入してしまえば安上がりであろう。
また VyOS は VPN に strongSwan を用いているので、EAP-RADIUS で RADIUS に認証を投げてしまえば VPN 用に Open Directory との連携を考える必要性はなくなる。
VyOS は IKEv2 の VPN に対応しているが拠点間 VPN のみでリモートアクセス VPN は未対応である。
しかしながら strongSwan に設定ファイルを渡す設定も可能となっているので、マニュアルモードで設定することで IKEv2 のリモートアクセス VPN が可能となるだろう。
IKEv2 は L2TP より新しくかつ安全で高速であり macOS/iOS でも標準で利用可能なので、VPN は VyOS + Remote-Access IKEv2 + TLS over EAP-RADIUS を推奨したい。
もちろん RADIUS の方で対応すれば ACL com.apple.access_vpn が利用可能になるだろう。
カレンダーおよびアドレス帳、リマインダーのサービスを提供することができる。Apple が Open Source 化して公開しており、Python 2 で動作するようだ。 リマインダーはカレンダーサーバと共通のようだ。Postgres SQL サーバが必要となるようだが、色々と複雑な構成になっていて、まだうまくインストールできていない。 Open Directory との連携、プッシュ通知の実現が可能とのこと。ACL は従来通りの com.apple.access_calendar などがハードコードされており、Open Directory との連携ができれば有効になるようだ。
BIND9 が使われていたように思うが、Open Directory では必須であった。 実際、Open Directory のマスターを作成する際の REALM は正引きと逆引きが一致しないとエラーが起きるので、DNS と密接に関係している。移行にあたって特に面倒な設定はない。
その気になれば macOS でも運用できていた。ルータで JST に直結している NICT の NTP サーバを参照し、LAN 内はルータを参照する設定を推奨する。
macOS では BSD 由来の pf (Packet Filter) が用意されている。Linux で一般的な iptables/nftables などとは一味違った仕様である。 https://support.apple.com/ja-jp/HT203673 などを参考に適当にコピーすれば移行作業は終了しそうである。
macOS Server の機能とは少し違うが必要となったので簡単に方針をまとめておく。 PowerMac G5 には MODEM が存在していたが、それ以降 MODEM 搭載機種もなく、FAX サーバの機能は完全になくなってしまった。macOS には efax が Apple によって改修されてインストールされていた。 更に imagestopdf、faxnotify というスクリプトが用意されていた。imagestopdf は Core Graphics で TIF を PDF に変換し、faxnotify はシステム環境設定の設定内容を efax に反映させるものであった。 efax のオリジナルは 32 ビット CPU 前提のコーディングがなされるなど古い仕様になっているが、Debian のパッケージなどの efax は 64 ビット対応がなされているようだ。最近なら HylaFAX などの方が良いかもしれない。