Active Directoryアカウントを使用するためにサーバーにインストールしてsssd
接続できますが、ADユーザーのUIDが非常に間違っていることがわかりました。 sssdマシン) 。ファイル/etc/sssd/sssd.conf
が見えます...
[sssd]
domains = ucera.local
config_file_version = 2
services = nss, pam
[domain/ucera.local]
ad_domain = co.local
krb5_realm = CO.LOCAL
realmd_tags = manages-system joined-with-samba
cache_credentials = False
id_provider = ad
krb5_store_password_if_offline = False
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = False
fallback_homedir = /home/%u
access_provider = ad
default_domain_suffix = co.local
なぜこれが起こるのかご存知ですか?デバッグ提案がありますか?
私も時々AD ユーザーを使用してコンピュータにログインする際に問題があります。例えば。サーバーにsshを試すと、私のパスワードは拒否されますが、そのsu
ユーザーをrootとしてsshに接続し、そのADユーザーとしてサーバーに直接sshすることができます(サーバーがそのユーザーを所有していることを認識していないようです)。入力して「警告」を受け取りましたsu
。
答え1
に基づいて記事これを見つけて問題が解決したようです。 sssd.conf ファイルは次のようになります。
[sssd]
domains = ucera.local
config_file_version = 2
services = nss, pam
[domain/ucera.local]
ad_domain = co.local
krb5_realm = CO.LOCAL
realmd_tags = manages-system joined-with-samba
cache_credentials = False
id_provider = ad
krb5_store_password_if_offline = False
default_shell = /bin/bash
ldap_id_mapping = False
ldap_user_uid_number = uidNumber
ldap_user_gid_number = gidNumber
ldap_group_gid_number = gidNumber
use_fully_qualified_names = False
fallback_homedir = /home/%u
access_provider = ad
default_domain_suffix = co.local
多様性:
ldap_id_mapping = False
objectSID
主な修正は、ADユーザー属性に基づいて計算するのではなく、AD posix IDを使用することだと思います。- また、設定を追加し、AD
ldap_..._...id_number = ...
のユーザーの対応する属性フィールドに設定しました。パート(1)が完了した後、マシンのUIDは変更されません。 sssd.confの唯一の違いは、この問題のないsssdを使用している他のサーバーと比較した変更(1)です。私の考えでは、他のコンピュータにすでにこのUIがあるので、ldap_id_mapping = False
ADユーザーがそのコンピュータに初めてログインすると、自動的にAD posix UIDが取得されます。この混乱したサーバーではUIDが正しく設定されていないため、AD属性をuidNumber
明示的に適用する必要がありました。gidNumber
その後、SSD サービスを再起動します。
ADとSSSDの経験はあまりありませんので、私が間違って理解したことがあればコメントで教えてください。