Ubuntu18.04をAD(アクティブディレクトリ)に参加させました。(下図が、今回のネットワークのイメージ。)

本来は、「realmd-sssd」で参加したかったのですが、ADDCサーバ(ad.test.local)が動作するsamba4のバージョンの関係で「smbd-Winbind」しか使えませんでした。つまり、「Samba」と「Winbind」を使って、Samba4で動作するADにクライアントPC(Ubuntu)を参加させます。

(もし、エラーが発生したら、表示されたエラーメッセージやdmesg、syslog、journalctl -xeなどを利用してエラーメッセージを確認し、ネットで回避策を検索してください。)

【前提条件】

  1. ADが適切に設定され動作している(Samba4-CentOS6、internal DNSを利用)。
  2. クライアントPC(Ubuntu18.04LTS)は、NetworkManagerでwi-fi接続している。
  3. ローカルネットワーク(192.168.xxx.0/24)にADとUbuntuが接続している。
  4. IPv6は無効化。
  5. ①ADDCサーバ:192.168.xxx.yyy
    ②ADDCサーバ名(サーバのホスト名):ad.test.local
    ※samba4でADDCを実装。
    ③domain name(ドメイン名):TEST.LOCAL
    ④ドメイン名の短縮名:TEST
    ⑤realm(レルム):TEST.LOCAL
    ⑥クライアントPCのホスト名:ub-pc.test.local
    ⑦クライアントPCのIPアドレス:DHCPクライアント(動的に払い出し 192.168.xxx.ab)
    ⑧アクセスポイントのSSID:ap-test
    ⑨ADユーザ名:ad-user
    ⑩クライアントPCのユーザ名(管理者権限あり、設定用):ub-user

ADDCサーバ側の設定変更はありません。したがって、クライアントPC(Ubuntu18.04LTS)の設定のみ記載し、動作確認をします。
(※いつも忘れるのでメモ。ad.test.localのSambaのバージョン確認:/usr/local/samba/sbin/smbd -V)

メインの作業は、ADユーザ名(ad-user)でログインできるまでクライアントPCのユーザ名ub-userで作業を進めます。

1.必要なモジュールのインストール。

ub-user@ub-pc:~$ sudo apt install samba krb5-config krb5-user winbind libpam-winbind libnss-winbind

このとき、インストール中に下記のメッセージが表示されます。(環境によっては、表示内容が異なるかも?)

「Configuring Kerberos Authentication」(ケルベロス認証の設定)

(1) Configuring Kerberos Authentication

Kerberosパッケージインストール中に表示されます。
Kerberos Server で使用するrealmを尋ねられているので、

TEST.LOCAL

と入力し「OK」が選択されているのを確認して、「Enterキー」を押下。(もし、「OK」が選択されていなければ「Tabキー」を押して、色を反転させ選択状態にしておく。)

図1-2,1-3は、ADDCサーバ(ad.test.local)を指定しておきます。必要に応じて、変更してください。(表示されないかも)

(2) PAM Configuration

pam-auth-update が実行されているようです。

Winbind NT/Active Directory authentication にチェックが入っていることを確認する。必要であれば、「Create home directory on login」にチェックを入れる。(「↓」で、移動し、スペース キーを押せば、チェックされる。)とくに理由がないのであれば、チェックを入れておきます。

「OK」が選択されていることを確認して、「Enterキー」を押下。

インストールが完了する。

2.IPv6無効化。

ローカルネットワークは、IPv4で構築されています。
IPv6が有効になっていると、名前解決のときに、最初にIPv6アドレスを取得してしまい、ADDCサーバへJoinできません。ADDCサーバが見つからないのです。
したがて、IPv6を無効化します。

ub-user@ub-pc:~$ sudo vi /etc/sysctl.conf

#以下の行を最終行に追記。

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

:wq

上書き保存

ub-user@ub-pc:~$ sudo sysctl -p

を実行すると、設定が有効となり、下記が表示されます。

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

念の為に、確認。

ub-user@ub-pc:~$ cat /proc/sys/net/ipv6/conf/all/disable_ipv6

を実行すると、「1」と表示されます。確認完了。

3.nsswitch.confの設定。

リゾルバ用設定ファイルです。(/etc/hostsの新型だそうです。)名前解決する際の、参照先の優先順序を記入しておきます。つまり、名前解決ができるように、hostsのdnsをfilesのあとに移動。

また、Winbind機構はネームサービススイッチ(nss)を経由して、ADDCサーバの認証統合が利用できます。したがって、Winbindの項目も追記しておきます。passwordとgroupでいいようです。

nsswitch.conf は再起動しなくてもすぐに反映されます。

4.resolv.confの設定。

ADDCサーバにアクセスするときADDCサーバのホスト名(ad.test.local)が利用できるように、名前解決をします。ここの設定がうまくいかないばあいは、回避策をあとで提示します。(回避策1回避策2

resolv.confの設定を変更しても、反映されません。勝手に、書き換えられてしまいます。これは仕様です。したがって、まず、NetworManagerを起動して、必要事項を入力します。

(1) NetworkMangerで設定

今回は、Wi-Fi接続を前提に設定します。(有線LANの場合も、同様に設定しますが、ドメイン名を設定するところは違うと思われます。)

(2) ドメイン名関連の設定

ここで何をしたいか。「search ドメイン名」をresolv.confに追加設定させたい。

では、ドメイン名を設定します。Ubuntu16.04LTSでは、(1)で設定できたのですが、18.04LTSからは設定欄が消えていた。したがって、Ubuntu18.04LTSでは、/etc/NetworkManager/system-connections/ 配下にSSID名(接続名)で、設定値が保存されいるので、それを利用します。(有線では、有線の接続名で保存されている。)

ここでの設定値は、/run/systemd/resolve/resolv.conf に反映されるので、一度、etc配下にあるresolv.confを削除し、かわりに /run/systemd/resolve/resolv.conf からシンボルリンクを配置します。

ub-user@ub-pc:~\$ sudo rm -rf /etc/resolv.conf
ub-user@ub-pc:~\$ sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf

下準備完了。

次に、/etc/NetworkManager/system-connections/ap-test にドメイン名を設定する。

ub-user@ub-pc:~$ sudo reboot #<==再起動

では、「search ドメイン名」 が反映されているか確認。

こちらも確認。

大丈夫です。

NetworkManagerを再起動します。(これは、不要。再起動後なので。)

ub-user@ub-pc:~$ sudo systemctl restart NetworkManager.service

では、動作確認してみます。(名前解決の確認)

端末からpingをADDCサーバのad.test.localに向けて打ちます。

ホスト名(ad.test.local)が、きちんと名前解決できていました。このとき、IPv6が有効であれば、IPv6のアドレスを取得して、応答が返ってきませんでした。つまり、IPv6の名前解決は成功するのですが、実際には使えません。したがってADにJoinできません。

※Linux Mint 18.3では、設定が少し異なります。
/run/systemd/resolve/resolv.conf は存在しないので、/etc/resolv.conf はそのまま利用します。また、nameserverが反映されないので、「/etc/NetworkManager/NetworkManager.conf 」の「dns=dnsmasq」をコメントアウトします。

(4) hosts の設定

自分(クライアントPC)をADに加えてもらうために、ドメイン名(ub-pc.test.local)を設定します。

再起動しなくても、自動でこの設定は反映されているはずです。

念の為に、

ub-user@ub-pc:~$ hostname -a
ub-pc.test.local

と表示されればOKです。

ADDCサーバの名前解決ができない場合の回避策として、このhostsファイルにADDCサーバのIPアドレスを追記します。追記場所は、127.0.1.1の下でよいでしょう。(3)で名前解決ができていれば不要です。

192.168.xxx.yyy      ad.test.local

ちょっとカッコ悪い設定ですが、一応、動作することを目的とするなら、良し、としておきます。

5.smb.confの設定。

Sambを使って、ADに参加させます。

そのために、ldapやwinbind関連の設定をします。設定内容は [global] セクションで行います。

ub-user@ub-pc:~$ sudo systemctl restart smbd.service

smbdが起動済みなら、reloadでもOKです。

6.krb5.confの設定。

Winbindを利用してADの認証情報を利用します。通常、認証には、ケルベロス認証(複数サーバと複数ユーザの認証を一元管理するシステム)が利用されているので、その設定をしておきます。

※注意!ケルベロス認証では認証サーバ(今回はADDCサーバ)とクライアントPCの間での時刻の同期が必須です。おそらく5分以上ずれると認証は失敗します。本来は、クライアントPCのNTPサーバをADDCサーバに設定するのですが、うまくいかなかったので、放置しています。クライアントPCもADDCサーバもネット経由で時刻を取得しています。これで、今まで5分以上時刻がずれたというとこはありません。つまり、運用上問題なしと判断しています。(ただし、クライアントPCがWindows7のときは数回5分以上ずれていたことがあります。それでも、ネット上のタイムサーバと同期させれば、問題は解決しました。)

もし、ADDCサーバの名前解決に失敗するときは、「kdc = 192.168.xxx.yyy」を追記する。そのとき「kdc = ad.test.local」は、コメントアウトしておきます。つまり、kdcの値に、直接ADDCサーバのIPアドレスを記入。ちょっと、かっこ悪いが、動作すれば良し、とします。

7.pamの設定。

この設定は、クライアンPCへログインするときの認証に関係。

1.(2)で、「pam-auth-update」が実行され、そこで、設定が終わっていれば、特に何もする必要はありません。もし、オプションなど設定を変えたいのであれば、「sudo pam-auth-update」を再度実行して、必要事項にチェック(基本的には、デフォルトのまま)し、「OK」を選択して「Enter」を押しておきます。もしくは、「/etc/pam.d/common-*」等を直接編集します。

念の為に、クライアントPCの設定情報(デフォルトのまま)を表示しておきます。

ここで、一度、システムを再起動。

8.ADにJOIN。

(1) Kerberos動作確認

チケット作成

ub-user@ub-pc:~$ sudo kinit Administrator
Password for Administrator@TEST.LOCAL:

チケット表示

ub-user@ub-pc:~$ sudo klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: Administrator@TEST.LOCAL

Valid starting Expires Service principal
2018-06-21T17:45:46 2018-06-22T03:45:46 krbtgt/TEST.LOCAL@TEST.LOCAL
renew until 2018-06-22T17:45:33

もし、keytabがない場合は、作成。

ub-user@ub-pc:~$ sudo net ads keytab create -U Administrator

ADにジョイン。

ub-user@ub-pc:~$ sudo net ads join -U Administrator
Enter Administrator’s password:
Using short domain name — TEST
Joined ‘UB-PC’ to dns domain ‘test.local’
DNS Update for ub-pc.shigi.local failed: ERROR_DNS_UPDATE_FAILED
DNS update failed: NT_STATUS_UNSUCCESSFUL

「DNS Update for ub-pc.test.local failed: ERROR_DNS_UPDATE_FAILED
DNS update failed: NT_STATUS_UNSUCCESSFUL」DNSのアップデートに失敗しています。
これは、おそらくADDCサーバであるad.test.local(Samba4)がinternal DNS(sambaに実装されたnamed)を利用していることが原因のようです。実際には、ub-pc.test.localは名前解決はできるので、運用に問題もありません。また、Wiresharkで、ub-pcとad.test.localのやり取りを見ても、きちんと名前解決されています。きちんとDNSは利はたらいています。また、同様に、アップデーも行われているようです。(ネットの情報による:https://lists.samba.org/archive/samba/2013-December/177584.html

9.Winbindサービス起動。

Winbindの動作確認として、次のコマンドを実行して、情報が取得できるか確認してもよいでしょう。

wbinfo -u
wbinfo -g
getent passwd
getent group

10.ADユーザとしてログイン。

(1) lightdmに変更。

デスクトップマネジャーをgdm3からlightdmに変更します。(gdm3のログイン画面で、再ログインするとフリーズしたり、ログイン名入力欄が表示されないなど挙動が不安定になる。)

「/etc/lightdm/lightdm.conf.d/00-login-user-list.conf」は、存在しません。そのまま vi でタイピングして保存すれば作成されます。

再起動してad-userで再ログインします。

11.動作確認。

(1) ホームディレクトリができている。

端末から、

を実行して、ホームディレクトリのユーザ名とグループ名を確認します。

ユーザ名は、ad-user で、グループ名は、domain admins となっています。このとき、domainとadminsの間に半角の空白が入っているので、設定で指定するときには、「domain\ admins」としておきます。

(2) 端末でbashが使える。

ad-use@ub-pc:~\$ echo \$SHELL
/bin/bash

(3) 端末でsudoが使える。

端末で、ad-userからub-userへユーザを変更してもよいですが、念の為、一度、ログアウトしてub-userで再ログインします。

端末から

一度、ログアウトして、ad-userで再ログイン。

端末から、例えば、

ad-user@ub-pc:~$ sudo apt update

正常に実行できることを確認します。

(4) 管理者権限のアプリでADユーザのパスワードが使える。

あとは、いろいろなアプリが管理者権限(ad-user)で利用できるように、たとえば、synapticなど。

ad-userを必要なグループに追加します。

グループへの追加は、必要に応じて実施します。

以上で、作業は完了です。無事に、クライアントPCがアクティブディレクトリに参加できました。