CentOS8.3をSSSDでActive Directoryに参加させる

9300 ワード
Linux ActiveDirectory sssd CentOS Linux テキストリンク

0.Intro

仕事でとある製品を試用することになり環境構築をしました。Linuxをドメイン参加させるのは初めてだったので勝手がわからず大変苦労しました。
製品の手順書には
1.DNSへ登録
2.adcliを叩く
のみしか書いてなかったのですが、どうもうまくいかない。でもこれだけだと「そもそも認証も出来ないしホントに手順これだけ？」というところから試行錯誤が始まりました。
最初はSamba + Winbindで何とかできそうなところまで出来たのですが、ADアカウントでログインできるようになかなかならないし、そもそも手順書と違うし。
なのでsssdを使ってログインする方法を探りやっとこさ出来ました。
みんな簡単そうにやっているのに非常に手こずりました。realm joinで一発みたいなこと書いていてるのにまるで成功しなかったし。
僕みたいな人のお役に立てたらと記事にしました。

※この記事はまだbetaです。この後実際にマシンをクリーンインストールして一から再構築する予定です。その時に編集が入るかも。これは僕の備忘録でもあります。

1.環境

このような環境であると仮定して話を進めます。もちろんAD ServerはWindows Serverです。
OSの名前:centos
OSのバージョン:8.3
ドメイン名: brains-mind.local
Kerberosレルム: BRAINS-MIND.LOCAL
ドメインコントローラー1: ad1.brains-mind.local(10.120.X.X)
ドメインコントローラー2: ad2.brains-mind.local(10.65.X.X)
参加させるマシンのFQDN: search.brains-mind.local
コンピューター名: search
ドメイン認証を行うためのユーザーアカウント(Domain Admin): myaccount

2.事前準備

  • selinuxの無効化(別記事におまかせ)
  • avahiの無効化(別記事におまかせ)
  • プロキシの設定
/etc/environment
http_proxy="http://10.120.X.XXX:9080"
HTTP_PROXY="http://10.120.X.XXX:9080"
https_proxy="http://10.120.X.XXX:9080"
HTTPS_PROXY="http://10.120.X.XXX:9080"

※必要に応じて(会社なら大抵必要でしょう)

3.必要なものをインストール

今回は以下

  • adcli
  • sssd
  • krb5-workstation
  • mod_auth_gssapi

4.基本の設定

/etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
10.130.X.X search
10.120.X.X ad1.brains-mind.local
10.65.X.X ad2.brains-mind.local
/etc/resolv.conf
nameserver 10.120.X.X
nameserver 10.65.X.X

あとポートにdnsを設定。設定するのはADサーバーです

nmcli connection modify ens2 ipv4.dns 10.120.X.X
nmcli connection down ens2; nmcli connection up ens2

5.kerberosの設定

/etc/krb5.conf)
[logging]
    default = FILE:/var/log/krb5libs.log
    kdc = FILE:/var/log/krb5kdc.log
    admin_server = FILE:/var/log/kadmind.log

[libdefaults]
    dns_lookup_realm = false
    dns_lookup_kdc = true
    ticket_lifetime = 24h
    renew_lifetime = 7d
    forwardable = true
    rdns = false
    pkinit_anchors = FILE:/etc/pki/tls/certs/ca-bundle.crt
    spake_preauth_groups = edwards25519
    default_realm = BRAINS-MIND.LOCAL
    default_ccache_name = KEYRING:persistent:%{uid}

[realms]
BRAINS-MIND.LOCAL = {
     kdc = brains-mind.local
     admin_server = brains-mind.local
 }

[domain_realm]
 .brains-mind.local = BRAINS-MIND.LOCAL
 brains-mind.local = BRAINS-MIND.LOCAL

6.adcliを発効

adcli join -v --show-password --os-name=OSの名前 --os-version=OSのバージョン -K /etc/krb5.keytab --service-name=host --service-name=HTTP -D ドメイン名 -R Kerberosレルム（全て大文字） -S ドメインコントローラー -H 参加させるマシンのFQDN -N コンピューター名 -U ドメイン認証を行うためのユーザーアカウント

今回だと

adcli join -v --show-password --os-name=centos --os-version=8.3 -K /etc/krb5.keytab --service-name=host --service-name=HTTP -D brains-mind.local -R BRAINS-MIND.LOCAL -S ad1.brains-mind.local -H search.brains-mind.local -N search -U [email protected]

今回ハマった理由の一つがここです。krb5.keytabってこのコマンドで生成されるんですね。ADサーバーで生成しないといけないとか色々調べて困ってたのですが、クライアント側のLinuxで出来てしまう。大事な役割を果たすkrb5.keytabにずいぶん振り回されました。
生成されたkeytabがきちんと機能しているかや、そもそもdomain参加に成功しているか、といったことは、kinit 、klist -K　等のコマンドで調べられます。

7.sssdの設定

/etc/sssd/sssd.conf
[sssd]
domains =  brains-mind.local
config_file_version = 2
services = nss, pam,ssh
default_domain_suffix = brains-mind.local

[domain/brains-mind.local]
ad_domain = brains-mind.local
krb5_realm = BRAINS-MIND.LOCAL
debug_level = 5
id_provider     = ad
auth_provider   = ad
chpass_provider = ad
sudo_provider   = ad
dyndns_update = false
ldap_schema = ad
ad_server = ad1.brains-mind.local,ad2.brains-mind.local
enumerate = false
ldap_id_mapping = true
use_fully_qualified_names = True
krb5_keytab = /etc/krb5.keytab
ldap_krb5_keytab = /etc/krb5.keytab
ldap_sasl_authid = [email protected]
default_shell=/bin/bash
override_homedir=/home/%u

[nss]

[ssh]

[pam]

ここが一番苦労しました。もう仕様なのかバグなのか、調べれば調べるほどわからなくなる。ネットの情報も千差万別でどれが本当なのやら。
結局 /var/log/sssd/配下のログとにらめっこしながら探り当てました(本来そう言うもんですけどねw)
ここでポイントとなるのは

  • ldap_id_mapping = true
  • krb5_keytab = /etc/krb5.keytab
  • ldap_krb5_keytab = /etc/krb5.keytab
  • ldap_sasl_authid = [email protected]

だと思います。ldap_sasl_authidについて、書式は
ldap_sasl_authid = (マシン名)$@(ドメイン名)
とのことでした。

編集後はPermissionの設定をお忘れなく

sudo chmod 600 /etc/sssd/sssd.conf
sudo chown root:root /etc/sssd/sssd.conf

8.smbの設定

/etc/samba/smb.conf
[global]
workgroup = BRAINS-MIND
security = ads
realm = BRAINS-MIND.LOCAL
password server = *
template homedir = /home/%U
template shell = /bin/bash
kerberos method = secrets and keytab
client signing = yes
client use spnego = yes
log file = /var/log/samba/log.%m

デフォルトの記載は全く必要ないので全部削除してこの記載の通りにすればよいと思われます。

9.設定の反映とサービス登録

今までの設定を/etc/nsswitch.confやPAMに反映させます。
PAMの /etc/pam.d/system-auth　と　 /etc/pam.d/password-auth　についてはざっくりとでも見ておいたほうがよいと思われます。

authconfig --enablesssd --enablesssdauth --enableforcelegacy --update

そしてサービス再起動と登録

systemctl start sssd && systemctl enable sssd

以上で設定完了です。

10.確認

実際に機能しているかどうかはまず

id myaccount

で自分のAD上の情報が引っ張るか確認。

それと

ssh myaccount@localhost

で、ログイン出来るか確認出来ます。
ログインが成功したら/homeにフォルダ出来ています。この場合は /home/myaccount
ですね。

11.SSO

今回の検証したかった製品はブラウザベースでSSOが出来る製品でした。
しかしCentOSから直接や、ssh接続でならログインまで出来るのに、ブラウザから製品を開こうとするとエラーとなりました。
ログを見ると

/var/log/httpd/error_log
[Fri Dec 25 15:07:58.337453 2020] [auth_gssapi:error] [pid 1797:tid 139985499928320] [client 10.130.XXX.XXX:53007] GSS ERROR In Negotiate Auth: gss_accept_sec_context() failed: [Unspecified GSS failure. Minor code may provide more information (Clock skew too great)]
[Fri Dec 25 15:07:59.770713 2020] [auth_gssapi:error] [pid 1797:tid 139985491535616] [client 10.130.XXX.XXX:53007] GSS ERROR In Negotiate Auth: gss_accept_sec_context() failed: [Unspecified GSS failure. Minor code may provide more information (Clock skew too great)]
[Fri Dec 25 15:08:00.527564 2020] [auth_gssapi:error] [pid 1797:tid 139985483142912] [client 10.130.XXX.XXX:53007] GSS ERROR In Negotiate Auth: gss_accept_sec_context() failed: [Unspecified GSS failure. Minor code may provide more information (Clock skew too great)]

という具合に。「Clock skew too great」ということはAD ServerとKerberos 5 クライアント(CentOS)の時間差が5分以上ということです。
しかし時計とDateコマンドを見てもそんなに開いていない。
原因はtimezoneでした。AD ServertがJST、CentOSがUTCでした。つまりCentOSが9時間おかしかったんですね。
(それでなんでログイン出来ていたのか謎ですがw)
timezoneを両方合わせたら無事にSSO出来るようになりました。こんな落とし穴あったんですね。

謝辞

ここまで設定するにあたって以下のサイトに大いに助けられました。ありがとうございました。
samba/Linux参加 - Chaperone

toj 1701 Stamps
Spring IOCとDIにおけるその注釈の詳細