1. 説明
Hadoop のデフォルトのセキュリティ スイートは Kerberos であり、Kerberos のさまざまなコンポーネントを各ノードに手動でインストールできます。オペレーティング システム ベンダーが提供する統合セキュリティ スイートを使用することもできます。FreeIPA はその 1 つです。HDP は、Ambari インストールでの FreeIPA の展開もサポートしています。
FreeIPA は CentOS が提供するオープンソースのコンポーネントです (私はこのオペレーティング システムしか使用したことがなく、RedHat での名前はこれではないようです)。しかし、それはオープンソースソフトウェアのコレクションのようなものだと思います. 百度百科事典では、次のように定義されています。
FreeIPA は、統合されたセキュリティ情報管理ソリューションです。FreeIPA には、Linux (Fedora)、389 Directory Server
MIT Kerberos、NTP、DNS、Dogtag (証明書システム)、およびその他の ID、認証、およびポリシー機能が含まれています。
2. インストールと展開の手順
FreeIPA のインストールと展開に関するドキュメントは多数ありますが、ここでは私が遭遇した問題のみを記録し、より重要だと考えています。
2.1 CentOS のバージョンの問題
- CentOS 6.6 は非推奨です。理由: https://bugs.centos.org/view.php?id=8757&nbn=2
- FreeIPA のインストールは、CentOS のバージョンと最も一致しています。つまり、オペレーティング システムのバージョンが CentOS 6.5 であるとすると、CentOS 6.5 から FreeIPA をインストールするのが最適です。OSのバージョンは6.5なのに、インストールしたFreeIPAはインターネット上のyumソースのもので（6.7らしい）、結果が間違っているという問題に遭遇したためです。
2.2 スペースを入れる
IPAClient をインストールする際は、スペースなどの記号を入力しないように注意してください。
[root@ipa112 ~]# ipa-client-install --domain=example.com --realm=EXAMPLE.COM --principal=admin@EXAMPLE.COM --password=hadoop123 --enable-dns-updates --permit --no-ntp
Provide your IPA server name (ex: ipa.example.com): ipa110.example.com --输入ipaserver,需要注意后面一定不要带空格，否则就会抛出异常2.3 ノード名は FQDN の要件を満たす必要があります
FreeIPA クラスターは FQDN にパスワードを設定する必要があります。
理由: freeipa にはドメインの概念があり (kerberos にもあります)、kerberos ではすべてのノードがドメイン内にある必要があります。freeipaをインストールする際にkerberosも一緒にインストールします。
インストール プロセス中に、インストール スクリプトは自動的に現在のマシン名 (freeipa のマスター ノード) を取得し、対応するドメイン名を解決します。
そのインストール スクリプトのプロンプト情報から取得できます: ドメイン名はホスト名に基づいて決定されています.
また、私たちのマシン名は hadoop.sec19 のように呼ばれてはなりません. 後の sec19 で区別することは絶対に不可能です.のドット。freeipa の観点から見ると、そのドメイン名は sec19 であり、
これによりすべてのマシンが同じドメインに属しなくなります。
2.4 DNS の説明
DNS はマシン名の解決に使用されます. FreeIPA デュアル マシン (つまり、マスター/スレーブ サーバー) をインストールする場合は、DNS が必要です。理由
: 次のようなコマンドを実行する必要があります:
ipa-replica-prepare hadoop197.example.com --ip-address 192.168.116.197
このとき、DNS 上の解決に進み、見つからない場合は直接エラーを報告します。この時点では、スレーブ ノードはインストールできません。
freeipa の単一ノードのみをインストールすると、DNS を使用できません。
3 つの FreeIPA コンポーネント
上の図は RedHat から提供されたコンポーネント関係図であり、この図から組織的な関係を大まかに理解することができます。Directory Server がそのコアである場所
3.1 ディレクトリ サーバー
FreeIPA のディレクトリ サービスは、LDAP プロトコルに基づくオープン ソース ソフトウェアであるオープン ソースの 389 DS を使用します。全身のシステムの基本と言えます。Kerberos ユーザー データは、Directory Server データベースに格納されます。
3.1.1 ドキュメントの説明
Directory Server は LDAP サービスであり、LDAP ベースのサービスには Windows AD が含まれます。DS の場合、関連する可能性のあるファイルは次のとおりで、その場所がリストされています。
| ファイルまたはディレクトリ | 位置 |
|---|---|
| ログファイル | /var/log/dirsrv/slap-{インスタンス} |
| 構成ファイル | /var/dirsrv/slap-{インスタンス} |
| データベースファイル | /var/lib/dirsrv/slapd-{インスタンス} |
注 1: ここでのインスタンスは、インストールとデプロイを実行するときに設定されます. たとえば、この記事では、その値は EXAMPLE.COM であり、ログ パスは /var/log/dirsrv/slap-EXAMPLE.COM です注
3.1.2 マルチマスターの説明
一般的に言えば、2 つの IPAServer、つまり 2 つのマスターを展開し、人工的にそれらをマスター ノードとスレーブ ノードに分割します。しかし、それは「間違った」説明です。しかし、FreeIPA のスクリプトは区別されるため、このように記述します。実際、DS 自体では、「マスター/スレーブ」マスターを区別せず、複数のマスターを持つことができます (2 つ以上のマスターのネットワーク レベル構成はテストされておらず、ここの記録はその公式の説明です) )
各マスターは情報のプロバイダーとコンシューマーの両方です。マスターがデータを更新すると、対応する変更が他のマスターにプッシュされます。競合がある場合は、競合アルゴリズムによって処理されます。それでも解決できない場合は、競合がマークされ、管理者が処理します。
変更ごとに、この変更を一意に識別できる変更状態番号 (Change state NumberCSN) が設定されます。この番号は、この変更を定義できるマスターのタイムスタンプと識別子の 2 つの部分で構成されます。競合解決アルゴリズムは非常に単純で、「後で修正した人が勝つ」というものです。
3.1.3 構成変更
FreeIPA を使用するにあたり、必要に応じて対応する構成を変更することがあります。FreeIPA では、WebUI インターフェイスの変更と LDAP 形式のファイルの 2 つの変更方法を提供しています。以下は、私が遭遇した2つの変更の説明です
3.1.3.1 パスワード規則の変更
ユーザー パスワード ポリシーは、非常に一般的な構成です。ユーザーは Web UI から構成できます。ユーザーがパスワード ポリシーを
構成していない場合、デフォルトのパスワード ポリシーが使用されます。以下: 次の表
は、特定の項目の説明:
| 名前 | 意味 |
|---|---|
| 最大有効期間 (日) | ユーザーパスワードの最大期間。デフォルトは 90 日です |
| 最小有効期間 (時間) | ユーザーがユーザー パスワードを変更した後、再度変更できるようになるまで一定時間待機する必要があります。このタイムテーブルは最短の変更タイムテーブルで、デフォルトは 1 時間です。単位も時間です。ユーザーがパスワードを変更した直後に元のパスワードを変更できないようにするためです。そうしないと、メッセージがポップアップ表示されます: 制約違反: パスワードを変更するには早すぎます |
| 履歴サイズ（パスワード数） | 以前のパスワード履歴を記録する |
| 最小の長さ | パスワードの最小長。デフォルトは 8 です。つまり、パスワードの長さは 8 文字以上です。パスワードの長さを確認する必要がない場合は、0 に設定できます。 |
| 最大失敗 | 失敗の最大数。つまり、ログイン時または kinit 時にユーザーが許可する間違ったパスワードの最大数です。 |
注: 間違ったパスワードを何度も入力した場合は、ロックを解除する必要があります. このとき、kinit コマンドを実行すると、次の情報が表示されます。
[root@hdp136 ~]# kinit lch
kinit: Clients credentials have been revoked while getting initial credentialsこの時点で、KDC ノード (つまり、IPAServer ノード) でコマンドを実行します。
[root@hdp134 ~]# kadmin.local <-----执行kadmin.local
Authenticating as principal admin/admin@EXAMPLE.COM with password.
kadmin.local: getprinc lch <---查看用户信息情况
Principal: lch@EXAMPLE.COM
Expiration date: [never]
Last password change: Tue Feb 27 11:11:02 CST 2018
Password expiration date: Mon May 28 11:11:02 CST 2018
Maximum ticket life: 1 day 00:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Tue Feb 27 11:11:02 CST 2018 (lch@EXAMPLE.COM)
Last successful authentication: Tue Feb 27 11:12:23 CST 2018
Last failed authentication: Tue Feb 27 14:11:07 CST 2018
Failed password attempts: 6 <--------------打印信息表明已经超过最大失败次数
Number of keys: 4
Key: vno 3, aes256-cts-hmac-sha1-96, Special
Key: vno 3, aes128-cts-hmac-sha1-96, Special
Key: vno 3, des3-cbc-sha1, Special
Key: vno 3, arcfour-hmac, Special
MKey: vno 1
Attributes: REQUIRES_PRE_AUTH
Policy: [none]
kadmin.local: modprinc -unlock lch@EXAMPLE.COM <---输入的命令进行解锁
Principal "[email protected]" modified.3.1.3.2 LDIF の変更
Ldif は LDAP データ交換フォーマットです。LDIF は ASCII 形式で、サーバーとクライアント間、または 2 つのサーバー間でデータを交換およびエクスポートするために使用されます。また、LDAP サーバー データベースの変更にも使用されます。FreeIPA の構成情報は、ldif を介して設定され、データベースにインポートされます。以下は、マスター ノードとスレーブ ノード間のデータ交換のバッファ サイズを変更する例です。
ipa サーバーのスレーブ ノードで作成されたユーザー情報はマスター ノードに同期できませんが、ログには次のように記録されます。
sasl_io_recv failed to decode packet for connection....この時点で、バッファ サイズのサイズを変更する必要があります。
1. 次の内容で package.ldif ファイルを作成します。
[root@ipa110 /]# cat package.ldif
dn: cn=config
changetype: modify
replace: nsslapd-sasl-max-buffer-size
nsslapd-sasl-max-buffer-size: 2097152- コマンドを実行してldifをインポートします
[root@ipa110 /]# ldapmodify -h localhost -D "cn=directory manager" -w hadoop123 -f package.ldif -ZZこのうち、-w の後ろの hadoop123 は管理者パスワードで、ipa-server-install 実行時に入力するパスワードです。複数のノードで実行してから再起動し、バッファを使用して有効にします。
3.2 SSSD
3.2.1 オペレーティング システムのユーザー
SSSD は RedHat の図には記載されていません。IPAServer ではなく、IPAClient に属しています。主に Linux システムのユーザー管理に使用されます。
useradd コマンドを使用してユーザーを作成すると、Linux の /etc/passwd ファイルに記録されることがわかっています。ただし、freeipa で作成したユーザーの情報は /etc/passwd には保存されず、DS のデータベースに保存されます。では、どのように機能するのでしょうか?
Linux には構成ファイルがあります。
[root@hdp136 ~]# cat /etc/nsswitch.conf
...
passwd: files sss
... この構成ファイル内のファイルは、/etc/passwd などの Linux のローカル ファイルを参照し、sss は Linux のカーネル プロセスを参照します。
[root@hdp136 ~]# service sssd status
sssd (pid 1799) is running...ユーザーを使用して Linux システムにログインする場合、プロセスは次のようになります。
sssd 自体にはキャッシュがあり、ldap サーバーにアクセスしてユーザー情報を照会することはありません。そのため、ネットワークによるログインの遅延を心配する必要はありません。
3.2.2 SSSD ログ設定
SSSD がログレベルを変更する必要がある場合は、次のように変更できます。
[root@hdfs142 sssd]# vi /etc/sssd/sssd.conf
[domain/example.com]
cache_credentials = True
debug_level = 9 ---修改这个值然后重启sssd次に、対応する sssd を再起動します。つまり、詳細な手順は /var/log/ssssd/ldap_child.log で確認できます。