web-dev-qa-db-ja.com

SSSDは、一致するローカルユーザーに対してADアクセス検証を実行する必要がありますか？

私は、RHEL7とActive Directoryを統合するために必要なsssd構成を調査するために、何時間もハッピー時間を費やしてきました。それらの大部分には、SSSDとADの統合に関する多くの投稿、特にADでのローカルUIDルックアップを調べることが含まれています。これらは啓発的ですが、私のシナリオをカバーしているものはないようです。

現在の私の問題は、Windowsユーザー（Windowsユーザーのパスワードを使用して "DOMAIN1\sales1"）を使用してSSH経由でログインでき、SSSDがWindowsユーザーの状態を正しく検証することです。 Windowsユーザーが無効になっている場合、またはアカウントの有効期限が切れている場合、ログインは失敗します。

Windowsユーザーと同じIDのLinuxユーザーを使用してSSH経由でログインした場合（Linuxユーザーのパスワードを使用して "sales1"）、SSSDはADのWindowsユーザーを検索して照合しますが、[〜 ＃〜] not [〜＃〜]ADアカウントを検証しません。 AD-linuxユーザーの一致を支援するためにLinuxユーザーUIDをwindowsユーザーのuidNumber属性に適用しましたが、Linuxユーザー資格情報を使用してログインするときのADユーザー状態の検証に影響を与えるものは何もないようです。

sssd.conf

[sssd]
domains = domain1.local
config_file_version = 2
services = nss, pam
debug_level = 7


[domain/domain1.local]
ad_domain = domain1.local
krb5_realm = DOMAIN1.LOCAL
realmd_tags = manages-system joined-with-adcli 

id_provider = ad
auth_provider = ad
access_provider = ad
chpass_provider = ad

## We do NOT want offline caching of Windows authentications
cache_credentials = False
krb5_store_password_if_offline = False

## Found this ticket for sssd: https://fedorahosted.org/sssd/ticket/2851
## might be the GC lookup that is stopping expired users from being denied access
ad_enable_gc = False
ldap_id_mapping = False
override_homedir = /home/%u
default_Shell = /bin/bash
debug_level = 8

nsswitch.conf

passwd:     files sss
shadow:     files sss
group:      files sss
hosts:      files dns
bootparams: nisplus [NOTFOUND=return] files
ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
services:   files sss
netgroup:   files sss
publickey:  nisplus
automount:  files
aliases:    files nisplus

pam.d/password-auth-ac

（authconfigによって構成されたとおり）

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        [default=1 success=ok] pam_localuser.so
auth        [success=done ignore=ignore default=die] pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth        sufficient    pam_sss.so forward_pass
auth        required      pam_deny.so

account     required      pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 1000 quiet
account     [default=bad success=ok user_unknown=ignore] pam_sss.so
account     required      pam_permit.so

password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    sufficient    pam_sss.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
-session     optional      pam_systemd.so
session     optional      pam_oddjob_mkhomedir.so umask=0077
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_sss.so

SSSDを使用して達成しようとしていることはすべて実行可能ですか？

編集＃1

私はsssdとAD統合がRHELシステムに与える影響に非常に慣れていないため、要件を解決するための私のアプローチはすべて間違っていると思います。

Linuxユーザー認証（passwd、shadow、groups）を使用するアプリケーションを実行している既存のRHELスタンドアロンサーバーがあります。 Linuxアプリケーションへのアクセスを許可する前に、広告内のアプリケーションユーザーを検証する必要があります。アプリケーション[〜＃〜] must [〜＃〜]は、現在どちらも処理できないため、既存のLinuxユーザーIDとグループIDを引き続き使用します。長いWindowsユーザーまたは「@」が付いたユーザーID、およびacl動作の大部分は既存のグループに基づいて構築されます。

私の最初のアプローチ（この質問をすることにつながる）は、sssdとレルムを使用してRHELをADに結合し、次に（pam/sssdを介して）Linuxログインを取得して、Linuxユーザーに一致するADユーザーを見つけることでした。 WindowsユーザーのPOSIX属性、およびADアカウントの検証。

私が実際に達成する必要があるのは
-ADユーザーとアプリケーションを使用するローカルLinuxユーザーとの間にマップ/関係を確立する

そのようなマップ/関係が存在する場合：
-ログイン時にADパスワードのみが必要です
-ADアカウントのアクセスステータスを検証します（アカウントが有効/有効期限が切れていない/ GPOログオン権限/適切なADグループのメンバー）
-マップされたユーザーのローカルユーザー名、uid、gidを常に使用します

realm permit --groups [email protected]を使用すると、ADユーザーのログインを特定のADグループに制限できると思います（上記のアプリケーションのユースケース以外では、現在、WindowsユーザーがLinuxにログインすることは望ましくありません）。
ADユーザーを既存のLinuxユーザーにマップするための最良の方法がわかりません。アプリケーションは現在、Linuxユーザーアカウントを作成および維持しているため、どのソリューションでもこれを処理できる必要があります。

過去2週間に読んだことから、私の選択肢は次のとおりだと思います。
-SSSDローカルオーバーライドを使用して、ADユーザーとLinuxユーザーの間でマッピングします。
私はこれについての経験がないので、これが実行可能であることを示す指標として SSSDローカルオーバーライド のような記事に依存しています
-ADユーザーで定義されているPOSIX属性に依存します。
これは、これらの値が、POSIX属性も参照する接続先のすべてのサーバーでユーザーによって使用されることを意味します。これが長期的に意味があるかどうかはわかりません。テストでは、ユーザーがLinuxにログインしたときにWindowsユーザーで定義されたuid、uidNumber、およびgidNumberで、これらの値が使用されることが示されています。これは、これらの値がADユーザーで定義されていることを確認するためのメンテナンス作業を課します。
-IPAをインストールし、IDビューを使用します。
これをインストールまたは設定した経験はありませんが、私の読書はこれが可能なオプションであることを示しています。このオプションを使用するには、追加のインストール、構成、およびメンテナンスのコストがかかるようです。

したがって、これらが本当に唯一のオプションであるかどうか、または私が知らない他のオプションがあるかどうか、そして私の最小限のAD統合のニーズに最も適した利用可能なオプションを確認する必要があると思います。

active-directoryredhatpamrhel7sssd
3
gScott

はい、それは正しいです。実際のところ、SSSD自体がサービスを提供できるユーザーのみを気にするのはSSSDの設計上の決定です（getent passwd -s sss $ someuser）。

リモートパスワードでローカルユーザーを使い続けたい場合（なぜですか？sssdにはキャッシュがあります。）、id_provider = proxyとリモートauth_providerを使用します。たとえば、このトピックに関する私のブログ投稿を参照してください： https://jhrozek.wordpress.com/2015/07/17/get-rid-of-calling-manually-calling-kinit-with-sssds-help/

1
jhrozek