最近、RedHatLinux上でWebアプリ(Web/APサーバ設定含む)を行ったのですが、その際にハマったエラーの解決策をメモしておきます。ググっても、RedHatLinux公式のカスタマーポータル等で探しても、中々それらしき記述がなく、めちゃくちゃ時間を潰しました。
■発生事象
今回は、外部ActiveDirecotry上に設定されたID/パスワードを使用して、WebアプリのBASIC認証を行う形をとっていました。ですが、何度認証を行ってもBASIC認証ダイアログが出続けログインが出来ません。
SSSDのログには、BASIC認証を行ったタイミングで以下のようなエラーが表示されていました。
March 07 00:00:00 httpd [999999]: pam_sss(webapp:auth): authentication success; logname= uid=0 euid=0 tty= ruser= rhost= user=user_name March 07 00:00:00 httpd [999999]: pam_sss(webapp:account): Access denied for user user_name: 6 (Permission denied)内容を見ると、認証は成功するのに該当ユーザの権限が無いためにエラーとなっているように見えます。ただ、ActiveDirectoryにはユーザは間違いなく登録されてており、該当サーバへのアクセスが許可されたグループに所属、現にSSHでは接続できていました。謎です。
■発生環境
[構成]OS:RedHatLinux 8.2
Web/Apサーバ:Apache 2.4.xx
- BASIC認証のため、mod_authnz_pamモジュール使用
- WebアプリはPython3.xを使用して構築(Apacheと連携させるため、mod_httpdを使用)
認証:PAM
ActiveDirecotry連携:SSSD 2.x
具体的なBASIC認証の設定は以下サイトを参考に行いました。
[参考]Apache module mod_authnz_pam
※pamの設定のみ以下のように変更して、ローカルユーザでの認証もできるようにしていました。
#%PAM-1.0 auth include system-auth account include system-auth session include system-auth
■事象分析
エラー内容より「pam_sss
によるwebapp(参考サイトでtlwikiとなっていたPAMサービス名)のaccount
チェックにおいてアクセス権限エラーが出ている」と言うことは分かります。そのため、
pam_sss
のaccount
を呼び出している箇所をコメントアウトしてみました。
/etc/pam.d/system-auth #account [default=bad success=ok user_unknown=ignore] pam_sss.so ←こちらコメントアウト
まさかですが、これでBASIC認証自体は可能となりました。
同じ
pam_sss
を使用しているであろうSSH接続では発生していないことから、Webアプリ限定のエラーだと分かります。
ちなみにaccount
は以下の役割を果たしているそうです。(10.2. PAM 設定ファイルについて)
account: このモジュールインターフェースは、アクセスが許可されることを確認します。
たとえば、ユーザーアカウントの有効期限が切れたか、または特定の時間にユーザーがログインできるかどうかを確認します。
アクセス許可の確認と書いてあるとおり、コメントアウトすることでGPOベースのアクセス制御が外れた状態になることが分かりました。というか、このGPOベースのアクセス制御の設定に問題が有りました。
■発生原因
SSSDのバージョンアップに際し、セキュリティ向上の観点からデフォルトでActiveDirectoryのGPOベースのアクセス制御が有効となったようです。さらに、本アクセス制御対象はデフォルト以外のPAMサービスがデフォルトで「拒否」状態となっており、デフォルトではない「Webアプリ用PAMサービス」は「拒否」となり、GPOベースのアクセス制御自体が許可されていない状態でした。
エラーメッセージは、ユーザではなく、PAMサービスに対する権限エラーだったのですね。
[参考]
Cannot log in to ClearCase WAN server after enabling SSSD-based authentication to Windows Active Directory on Red Hat Linux 8.x.
2.6.3. SSSD の GPO ベースのアクセス制御の設定
■解決方法
解決方法としては以下2パターンが考えられます。①GPOベースのアクセス制御時、デフォルト以外のPAMサービスの扱いを「拒否」から「許可」に設定変更(=記載追加)する。
以下のとおり
sssd.conf
のADドメインのセクションに記載を追加し、SSSDサービスを再起動することで対応。
/etc/sssd/sssd.conf ad_gpo_default_right=permit
②GPOベースのアクセス制御時、作成したPAMサービスを「許可」するよう設定追加する。
以下のとおり
sssd.conf
のADドメインのセクションに記載を追加し、SSSDサービスを再起動することで対応。
/etc/sssd/sssd.conf ad_gpo_map_interactive = + webapp
解決策として①だと影響範囲が大きそうでしたので②を採用しました。
■まとめ
今回、ActiveDirectoryやSSSD設定が自分の担当ではなかったことで原因調査がかなり難航しました。振り返りとしては、早期にSSSDのデバッグログ出力設定変更などの相談をしておくと良かったのかなとも思いましたが、原因箇所が特定出来ない中では中々難しいですね。
個人的には良い経験となったと思いますので、この内容を今後に活かしていければ良いなと考えています。
Linux
0 件のコメント:
コメントを投稿