我使用的是 Ubuntu 22.04。我的机器使用 Realm 加入到我公司的域中。我没有使用 Adsys。 PAM 配置用于 Unix 和 SSS 身份验证。
当我在办公室或远程时，以域用户 sudo 登录时速度很快，但当我登录 VPN 时，sudo 有时需要几分钟才能提示我输入密码。 gdm锁屏也是如此。
我su使用了一个可以使用 sudo 的本地帐户，并sudo tail -f -n 100 /var/log/auth.log在问题发生时使用它来监视 /var/log/auth ( )。
我观察到这一点：
Jul 27 08:23:53 nick-precision-7560 pkexec: pam_unix(polkit-1:session): session opened for user root(uid=0) by (uid=1666422094)
Jul 27 08:23:53 nick-precision-7560 pkexec[10341]: nick: Executing command [USER=root] [TTY=unknown] [CWD=/home/nick] [COMMAND=/usr/lib/update-notifier/package-system-locked]
Jul 27 08:25:46 nick-precision-7560 sudo: pam_unix(sudo:auth): authentication failure; logname= uid=1666422094 euid=0 tty=/dev/pts/6 ruser=nick rhost= user=nick
Jul 27 08:25:47 nick-precision-7560 sudo: pam_sss(sudo:auth): authentication success; logname= uid=1666422094 euid=0 tty=/dev/pts/6 ruser=nick rhost= user=nick
Jul 27 08:25:47 nick-precision-7560 sudo: nick : TTY=pts/6 ; PWD=/home/nick ; USER=root ; COMMAND=/usr/bin/whoami
Jul 27 08:25:47 nick-precision-7560 sudo: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=1666422094)
Jul 27 08:25:47 nick-precision-7560 sudo: pam_unix(sudo:session): session closed for user root
pkexec这件似乎花了很长时间的作品也是如此。
周围有很多类似的问题，可接受的解决方案与主机文件有关。我认为这不是同一个问题，因为这只在我连接到 VPN 时才会发生。我确实怀疑这在某种程度上与名称服务器和 LDAP 有关。 FWIW 这是我的主机文件，如下所示：
127.0.0.1 localhost
127.0.1.1 nick-precision-7560 nick-precision-7560.companydomain.mycompany.com
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
我systemd-resolved在发生这种情况期间进行了监控，但没有在日志中看到任何内容。有趣的是，resolvectl status当我登录 VPN 时并没有改变，我以为它会改变。然而，登录 VPN 后，我看到它/etc/resolve.conf已更新，如下所示：
#@VPNC_GENERATED@ -- this file is generated by vpnc
# and will be overwritten by vpnc
# as long as the above mark is intact
# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
options edns0 trust-ad
nameserver 10.3.1.140
nameserver 10.3.1.43
search . companydomain.mycompany.com
我联系了我的 IT 部门，他们可以看到在事件发生时来自我的 IP 的流量到达了多个域控制器，并且没有看到任何流量在防火墙日志中被拒绝。
我不确定下一步该去哪里尝试调试这个问题。该问题不容易重现。仅当我在连接到域时很长时间没有登录或使用 sudo 时才会发生这种情况。但有时，当我期望它发生时，它却没有发生，甚至当我从身份验证日志中看到 unix 身份验证失败并且不得不使用 pam_sss 进行身份验证时也是如此。
更新： 我运行 Wireshark 并监控我的 TUN 适配器。最终发生了其中一个 sudo 挂起。我查看了日志，发现有大量 DNS、LDAP 和 SMB 流量。通过查看日志，我可以看到 Adsys 仍在运行，即使我没有使用它进行身份验证，并且它出现一些重复的故障，这些故障会生成大量网络流量并在日志中生成大量消息。我已经卸载了 Adsys，看看是否可以改善情况。至少我认为它应该清理网络流量和日志以发现问题。
此时，我知道我的计算机正在解析并与正确的域控制器通信，并且它正在使用正确的名称服务器。