SSSD를 사용하여 Ubuntu 22.04를 Active Directory에 가입시킨 후 도메인을 찾을 수 없습니다.

SSSD를 사용하여 Ubuntu 22.04를 Active Directory에 가입시킨 후 도메인을 찾을 수 없습니다.

Ubuntu 20.04부터 SSSD 및 Realmd를 사용하여 이러한 서버를 Active Directory 도메인 중 하나에 연결합니다. 이것은 (거의) 즉시 작동합니다.

그러나 Ubuntu 22.04에서는 문제가 발생했습니다. 가능한 해결책이 없으므로 질문합니다.

우리 조직에는 1개의 AD 포리스트가 있습니다. 이 숲에는 ''라는 나무가 있어요.example.local".이 도메인에는 여러 하위 도메인이 있습니다."제품 예시.현지","사용자.예제.로컬","acc.example.local"."사용자.예제.로컬""라는 이름의 하위 도메인이 있습니다.dev.users.example.local".이 도메인에는 바로가기 신뢰가 있습니다."제품 예시.현지“(기억하는 것이 중요합니다).

서버가 도메인에 가입할 때"dev.users.example.local”, 사용자(포리스트의 모든 도메인)가 서버에 로그인할 수 있어야 합니다.

이는 Ubuntu 20.04(SSSD 버전 2.2.3 사용)에서 예상대로 작동합니다. Ubuntu 22.04에서는 가입된 도메인(dev.users.example.local) 및 바로 가기 신뢰가 있는 도메인의 사용자만 검색 가능하고 서버에 로그인할 수 있습니다.

sssctl을 사용하여 이 문제를 디버깅해 보겠습니다.

달리기sssctl domain-list

결과 반환:

  • dev.users.example.local
  • 제품 예시.현지

예상되는 결과:

  • dev.users.example.local
  • 사용자.예제.로컬
  • example.local
  • 제품 예시.현지
  • acc.example.local

SSSD 버전:

  • 우분투 22.04: 2.6.3
  • 우분투 20.04:2.2.3

SSSD 구성은 다음과 같습니다(Ubuntu 20.04에서 예상대로 작동).

[sssd]
domains = dev.users.example.local
config_file_version = 2
services = nss, pam

debug_level = 9

[domain/dev.users.example.local]
# Offline logins
# cache_credentials = true

# Providers
id_provider = ad
auth_provider = ad
access_provider = simple

# Uncomment if you want to use POSIX UIDs and GIDs set on the AD side
# ldap_id_mapping = False

# Uncomment if the trusted domains are not reachable
# ad_enabled_domains = ad.example.com

# Set default shell and override AD Home directory
default_shell = /bin/bash
override_homedir = /home/%d/%u

# Comment out if you prefer to use shortnames.
use_fully_qualified_names = True

# AD Specific settings
# ad_use_ldaps = True

debug_level = 9

[nss]
debug_level = 9

[pam]
debug_level = 9

PAM 구성: /etc/pam.d/sshd

# PAM configuration for the Secure Shell service

# Standard Un*x authentication.
@include common-auth

# Disallow non-root logins when /etc/nologin exists.
account    required     pam_nologin.so

# Uncomment and edit /etc/security/access.conf if you need to set complex
# access limits that are hard to express in sshd_config.
# account  required     pam_access.so

# Standard Un*x authorization.
@include common-account

# SELinux needs to be the first session rule.  This ensures that any
# lingering context has been cleared.  Without this it is possible that a
# module could execute code in the wrong domain.
session [success=ok ignore=ignore module_unknown=ignore default=bad]        pam_selinux.so close

# Set the loginuid process attribute.
session    required     pam_loginuid.so

# Create a new session keyring.
session    optional     pam_keyinit.so force revoke

# Standard Un*x session setup and teardown.
@include common-session

# Print the message of the day upon successful login.
# This includes a dynamically generated part from /run/motd.dynamic
# and a static (admin-editable) part from /etc/motd.
session    optional     pam_motd.so  motd=/run/motd.dynamic
session    optional     pam_motd.so noupdate

# add to the end (create Home Dir automatically when initial login)
session optional        pam_mkhomedir.so skel=/etc/skel umask=077

# Print the status of the user's mailbox upon successful login.
session    optional     pam_mail.so standard noenv # [1]

# Set up user limits from /etc/security/limits.conf.
session    required     pam_limits.so

# Read environment variables from /etc/environment and
# /etc/security/pam_env.conf.
session    required     pam_env.so # [1]
# In Debian 4.0 (etch), locale-related environment variables were moved to
# /etc/default/locale, so read that as well.
session    required     pam_env.so user_readenv=1 envfile=/etc/default/locale

# SELinux needs to intervene at login time to ensure that the process starts
# in the proper default security context.  Only sessions which are intended
# to run in the user's context should be run after this.
session [success=ok ignore=ignore module_unknown=ignore default=bad]        pam_selinux.so open

# Standard Un*x password updating.
@include common-password

realmd를 사용하면 특정 AD 그룹이 서버에 로그인할 수 있습니다.

Ubuntu 22.04에 새(및 이전 2.2.3) SSSD를 설치하려고 시도했지만 설치하지 못했습니다.

Active Directory를 변경하지 않고 어떻게 이를 달성할 수 있습니까? 이 구성에서 우리가 뭘 잘못했나요?

관련 정보