SSSD 是否應該為匹配的本地使用者執行 AD 訪問驗證？
我花了很多很多時間探索集成 RHEL7 和 Active Directory 所需的 sssd 配置*。*其中很大一部分包括查看此處有關 SSSD 和 AD 集成的許多文章，特別是與 AD 中的本地 UID 查找有關的文章。雖然這些很有啟發性，但似乎沒有一個能涵蓋我的情況。
我目前的問題是我可以使用 windows 使用者（“DOMAIN1\sales1”使用 windows 使用者的密碼）通過 SSH 登錄，並且 SSSD 將正確驗證 windows 使用者的狀態。如果 windows 使用者被禁用，或者帳戶已過期，則登錄失敗 - 一切正常。
如果我使用與 windows 使用者具有相同 id 的 linux 使用者（“sales1”使用 linux 使用者的密碼）通過 SSH 登錄，SSSD 將在 AD 中查找並匹配 windows 使用者，但不會驗證 AD 帳戶。我已將 linux 使用者 UID 應用於 windows 使用者的 uidNumber 屬性，以幫助 AD-linux 使用者匹配，但在使用 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 = 8nsswitch.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 nispluspam.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 系統的影響非常陌生，所以我認為我解決需求的方法都是錯誤的。
我有一個現有的 RHEL 獨立伺服器，它執行一個使用 linux 使用者身份驗證（passwd、shadow、groups）的應用程序。在允許他們訪問 linux 應用程序之前，我被要求在廣告中驗證應用程序使用者。應用程序必須繼續使用現有的 linux 使用者和組 id，因為它目前不能處理長 windows 使用者或帶有“@”的使用者 id，並且很大一部分 acl 行為是建立在現有組上的。
我最初的方法（導致提出這個問題）是使用 sssd & realm 將 RHEL 加入 AD，然後（通過 pam/sssd ）獲取 linux 登錄名，為 linux 使用者找到匹配的 AD 使用者，很可能使用windows 使用者上的 POSIX 屬性，並驗證他們的 AD 帳戶。
我認為我真正需要實現的是
- 在 AD 使用者和使用該應用程序的本地 linux 使用者之間建立映射/關係
當存在這樣的映射/關係時：
僅在登錄時需要 AD 密碼
驗證 AD 帳戶訪問狀態（帳戶啟用/未過期/GPO 登錄權限/正確 AD 組的成員）
始終使用本地使用者名、uid、和映射使用者的gid
我認為使用
realm permit --groups adgroup@dlomain.ad將允許我將 AD 使用者登錄限製到特定的 AD 組（我們目前不希望 Windows 使用者登錄到 linux，在上述應用程序案例之外）。我不確定將 AD 使用者映射到現有 linux 使用者的最佳方式。該應用程序目前創建和維護 linux 使用者帳戶，因此任何解決方案都需要能夠使用它。
根據我在過去 2 週內閱讀的內容，我認為我的選擇是：
- 使用 SSSD 本地覆蓋在 AD 和 linux 使用者之間進行映射。
我沒有這方面的經驗，所以我依靠像SSSD Local overrides這樣的文章作為可行的指標
- 依靠在 AD 使用者上定義的 POSIX 屬性。
這確實意味著使用者將在他們連接到的每台伺服器上使用這些值，這些伺服器也引用 POSIX 屬性。我不確定從長遠來看這是否明智。測試表明，當使用者登錄 linux 時，在 windows 使用者上定義的 uid、uidNumber 和 gidNumber 使用這些值。這確實需要維護工作以確保在 AD 使用者上定義這些值。
- 安裝 IPA 並使用 id 視圖。
我沒有安裝或設置它的經驗，但我的閱讀表明這是一個可能的選擇。使用此選項似乎確實需要額外的安裝、配置和維護成本。
所以我想我現在需要確認這些是否確實是唯一的選項，或者是否還有其他我不知道的選項，以及最適合我最小的 AD 集成需求的可用選項。
是的，這是正確的。事實上，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/