
나는 winbind를 통해 AD 계정에 대해 사용자를 인증하도록 설정된 여러 RHEL5 서버를 상속 받았습니다. AD에서 그룹 멤버십을 업데이트할 때까지는 모든 것이 잘 작동합니다. 일부 사용자의 경우 변경 사항이 "getent group <groupname>"의 출력에는 반영되지만 "groups" 명령의 출력에는 적용되지 않습니다.
예를 들어 다음을 고려해보세요.
[root@hcc1pl1 ~]# 그룹 플루반
플루반 : 도메인 사용자 시스템 인프라 개발
[root@hcc1pl1 ~]# getent 그룹 q1esb
q1esb:*:23136:q1qai,q1prodi
winbind가 사용하는 DC의 q1esb에 자신을 추가하면 멤버십이 업데이트된 것을 볼 수 있습니다.
[root@hcc1pl1 ~]# lsof -i | grep winbind
winbindd 31339 루트 17u IPv4 63817934 TCP hcc1pl1:56541->hcnas01:microsoft-ds (설정됨)
winbindd 31339 루트 21u IPv4 63817970 TCP hcc1pl1:53622->hcnas01:ldap (설정됨)
[root@hcc1pl1 ~]# ldapsearch -u -x -LLL -h hcnas01 -D "[이메일 보호됨]" -W -b "CN=Peter Lubans,OU=표준 사용자 계정,OU=사용자,OU=XXX,DC=XXX,DC=XXX" "(sAMAccountName=*)" memberOf
LDAP 비밀번호 입력:
...
memberOf: CN=q1esb,OU=보안 그룹,OU=그룹,OU=XXX,DC=XXX,DC=XXX
...
winbind는 캐싱(-n 플래그) 없이 실행 중입니다.
[root@hcc1pl1 ~]# ps -ef | grep winbind
루트 31339 1 0 13:50 ? 00:00:00 winbindd -n
루트 31340 31339 0 13:50 ? 00:00:00 winbindd -n
루트 31351 31339 0 13:50 ? 00:00:00 winbindd -n
루트 31352 31339 0 13:50 ? 00:00:00 winbindd -n
루트 31353 31339 0 13:50 ? 00:00:00 winbindd -n
이제 getent는 해당 그룹에 올바른 구성원이 있음을 보여줍니다.
[root@hcc1pl1 ~]# getent 그룹 q1esb
q1esb:*:23136:q1qai,plubans,q1prodi
하지만 업데이트된 멤버십이 내 계정 세부정보에 반영되지 않습니다.
[root@hcc1pl1 ~]# 그룹 플루반
플루반 : 도메인 사용자 시스템 인프라 개발
[root@hcc1pl1 ~]#
이 문제의 정말 짜증나는 부분은 이 컴퓨터의 다른 계정과 내가 처음부터 구성한 컴퓨터의 내 계정에서는 문제가 없다는 것입니다.
어떤 아이디어가 있나요?
답변1
이는 로그온 시 /var/cache/samba/netsamlogon_cache.tdb에 캐시된 그룹 정보로 인해 발생한 것으로 보입니다. 내 생각엔 '-n'이 winbind에게 LDAP에 대한 쿼리를 캐시하지 않도록 지시했지만 해당 TDB 파일에 멤버십 정보가 있다는 것만으로도 문제가 발생하기 충분했을 것 같습니다.
답변2
나는 가까스로 마르신의 잃어버린 물건을 손에 넣었다(https://marcinm.co.uk/group-membership-not-updating-in-winbind/) 그에게 이메일로 물어보세요. 나는 이것이 적어도 일부 사람들에게 도움이 될 것이라고 확신하므로 여기에 그의 전체 블로그 게시물이 있습니다.
대본
smbd를 실행하는 파일 서버 security=ads
(즉, 도메인 구성원으로 작동), 사용자는 Samba 공유에 연결하고 처음 연결할 때 그룹 멤버십을 올바르게 캡처하며 그 이후에는 업데이트되지 않습니다.
근본 원인
Samba는 AD 도메인 컨트롤러에 의해 계산될 때 그룹 멤버십을 업데이트하며 사용자가 smbd 및 winbind를 실행하는 서버에 로그인할 때만 계산됩니다. 이는 wbinfo -a
Kerberized SMB 로그인에 의해서만 트리거됩니다. 이는 심각한 제한 사항입니다. 즉, 사용자가 로그인하지 않은 컴퓨터에서는 그룹 멤버십이 전혀 알려지지 않음을 의미하므로, 사용자 로그인 없이 AD에서 사용자의 그룹 멤버십을 가져오지만 winbind에서 사용하는 시스템 계정으로 사용하는 대체 그룹 멤버십 코드가 개발되었습니다. 사용자 그룹 멤버십을 요청할 권한이 없으며 결과를 신뢰할 수 없는 불안정한 것으로 간주됩니다. 따라서 winbind는 이에 의존하지 않습니다. 그룹 멤버십이 전혀 알려지지 않은 경우 이를 호출하지만 캐시된 그룹 멤버십을 새로 고치는 데는 사용되지 않습니다. 그 결과, 일부 시나리오에서는 winbind가 사용자 그룹 멤버십을 한 번 캡처하고 그 이후로는 업데이트하지 않습니다.
그룹 멤버십의 캐싱을 비활성화하는 것은 불가능합니다. 즉, 에 줄을 넣어서 이러한 동작을 비활성화할 수 있는 방법이 없습니다 smb.conf
. 이는 Samba 문제가 아니라 AD 설계 문제입니다. 이러한 동작은 Windows 작동 방식과 일치합니다. 즉, 사용자가 로그인 중에 인증할 때 AD 그룹 멤버십이 업데이트되는 것입니다.
사용자의 그룹 멤버십을 강제로 새로 고치는 방법
netsamlogon_cache.tdb
그룹 멤버십은 tdbtool(Samba의 모든 버전) 또는 net cache samlogon
(Samba 4.7 이상) 에서 조사할 수 있는 파일에 캐시됩니다 . 해당 파일에서 캐시된 항목을 삭제하면 대체 업데이트 코드를 호출하고 그 결과를 다시 입력하여 그룹 구성원의 일회성 업데이트가 트리거되고 netsamlogon_cache.tdb
그 후에는 영원히 다시 캐시됩니다.
tdbtool 방식:
$ wbinfo -n user.name
S-1-5-21-3023451936-689652692-1079546996-40725 SID_USER (1)
SID에 추가 \0
하고 따옴표로 묶습니다.
$ tdbtool netsamlogon_cache.tdb delete "S-1-5-21-3023451936-689652692-1079546996-40725\0"
그룹 멤버십은 OS에 처음 필요할 때 업데이트됩니다. tdb 파일이 채워질 때까지 몇 분 정도 기다립니다.
넷 캐시 samlogon 방식:
$ net cache samlogon list|head
SID Name When cached
---------------------------------------------------------------------------------------------------------------------------
S-1-5-21-3023451936-689652692-1079546996-40725 DOM\user.name Tue Apr 27 07:59:19 AM 2018 BST
S-1-5-21-3023451936-689652692-1079546996-41432 DOM\user.name2 Tue Apr 27 02:13:33 PM 2018 BST
$ net cache samlogon delete S-1-5-21-3023451936-689652692-1079546996-40725
이전과 동일 - 그룹 멤버십은 OS에 처음 필요할 때 업데이트됩니다. tdb 파일이 채워질 때까지 몇 분 정도 기다립니다.
답변3
내 생각은 매우 모호하지만 인프라 마스터(도메인 전체의 그룹 구성원 업데이트를 담당하는)와의 통신과 관련이 있을 수 있다는 것입니다.
답변4
나는 비슷한 것을 가지고 있었다. 문제를 해결하기 위해 "authconfig --disablecache --update"를 실행했습니다. 물론 로그온 속도가 느려졌습니다.