☰

윈도우7 삼바 문제

tag-icon • tag-icon linux windows-7 redhat samba
윈도우7 삼바 문제

한 명의 사용자에게만 영향을 미치는 이상한 삼바 문제가 있습니다. 삼바 설정은 다음과 같습니다.

Red Hat Enterprise Linux Server 릴리스 5.4(Tikanga) - Samba 서버

삼바 버전 3.0.33-3.14.el5 - 삼바 버전

도메인 컨트롤러 WIN2008R2 표준 - Windows DC

Windows 7 64비트 - 클라이언트 PC

사용자는 몇 주 전에 PC를 강제 종료한 후 이 문제에 직면했다고 언급했습니다. 맞습니다. \\sambaservernameWindows에서 액세스할 때 모든 사용자에 대해 삼바 서버의 모든 공유가 표시되지만 이 사용자의 경우 PC를 시작한 후에는 액세스할 수 없습니다 \\sambaservername. 오류 메시지

Windows에서 액세스할 수 없습니다.\\sambaservername

문제를 해결하기 위한 현재 해결 방법은 다음과 같습니다.

\\sambaservername예를 들어 하나의 공유에 액세스해 보십시오 \\sambaservername\sharedfolder1. 하지만 그렇게 해도 처음에는 먼저 오류가 발생하며 오류 메시지는 다음과 같습니다.

로그온 실패: 알 수 없는 사용자 이름이거나 비밀번호가 틀립니다.

사용자는 자격 증명을 다시 입력해야 공유에 액세스할 수 있습니다. 그 후에는 \\sambaservername문제 없이 액세스할 수 있습니다 . 그러나 일단 컴퓨터를 재부팅하면 문제가 지속됩니다.

지금까지 수행된 문제 해결:

  1. 다음 설정을 확인하십시오.

    이동: 제어판 → 관리 도구 → 로컬 보안 정책 선택: 로컬 정책 → 보안 옵션

    "네트워크 보안: LAN Manager 인증 수준" → LM 및 NTLM 응답 보내기 "NTLM SSP에 대한 최소 세션 보안" → 선택 취소: 128비트 암호화 필요

  2. 사용자에게 비밀번호를 재설정하고 다시 시도하라고 안내했지만 문제가 계속 발생합니다.

  3. 사용자의 PC에서 내 계정을 사용해 보았지만 문제가 없습니다. 나를 포함하여 여러 다른 Windows 7 PC에서 사용자 계정을 시도했지만 문제가 여전히 지속됩니다. Windows XP에는 이 문제가 없습니다.

  4. Windows 7 PC에 저장된 자격 증명이 없는지 확인하십시오. 제어판에서 자격 증명 관리자를 확인하고 이 명령을 입력했습니다.rundll32.exe keymgr.dll, KRShowKeyMgr

  5. 삼바 서버에서 winbindd 데몬을 다시 시작했지만 소용이 없습니다.

캐싱 문제로 인해 발생한 것으로 의심되지만 문제가 어디에 있는지 확실하지 않습니다. 사용자가 액세스하는 중에 오류가 발생할 때 \\sambaservername마다 다음 오류가 삼바 서버에 기록됩니다.

[2012/10/10 17:10:26, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
  Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
  Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
  Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
  Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
  Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
  Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
  Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
  Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
  Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
  Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!

그러나 해결 후에는 더 이상 오류가 발생하지 않습니다. 아래 나열된 기사를 읽은 후 디렉토리에 몇 가지 수정 사항을 적용해야 한다고 생각합니다 \var\samba\cache.

삼바 서버를 사용하는 사용자가 여러 명 있는데 아무런 영향 없이 이 문제를 해결하고 싶습니다.

다음 기사를 보았습니다.

"winbind 오프라인 로그온(G) 이 매개변수는 Winbind가 캐시된 자격 증명을 사용하여 pam_winbind 모듈로 로그인하도록 허용해야 하는지 여부를 제어하도록 설계되었습니다.활성화되면 winbindd는 성공적인 로그인의 사용자 자격 증명을 로컬 캐시에 암호화하여 저장합니다.

기본값: winbind 오프라인 로그온 = false

예: winbind 오프라인 로그온 = true "

로컬 캐시에서 한 사용자의 항목을 삭제하는 방법에 대한 아이디어가 있습니까?

답변1

나는 확실하지 않다nbtstat -R명령(이것은"원격 캐시 이름 테이블을 제거하고 다시 로드합니다.") 또는 nbtstat -RR하나("이름 해제 패킷을 WIN으로 보낸 다음 새로 고침을 시작합니다.") 당신이 찾고 있는 종류의 새로 고침을 시행하기 위해 무엇이든 할 수 있습니다...

매뉴얼을 확인하고 싶으시다면,이봐..

답변2

ntpd가 도메인 컨트롤러와 동기화되었는지 확인하세요. 오늘까지 같은 문제가 있었는데 문제가 되는 서버와 도메인 컨트롤러 사이에 45분의 시간 차이가 있는 것을 발견했습니다. ntpdate를 실행하면 제대로 작동했습니다.

답변3

내 경험에 따르면 이는 일반적으로 도메인 컨트롤러의 시간 드리프트로 인한 결과이거나 귀하의 경우 하나의 클라이언트에만 문제가 있는 경우(연결하는 클라이언트 컴퓨터)입니다. Kerberos는 인증 서버 요청과 인증 서버 응답(AS_Req 및 AS_rep) 모두에 시간 관련 매개 변수를 포함하기 때문에 불일치가 크면 세션 토큰이 거부됩니다.

AS_Req에는 요청된 토큰의 수명이 포함됩니다. AS_REQ = ( PrincipalClient , PrincipalService , IP_list , Lifetime )

AS_Rep에는 DC 타임스탬프와 적용된 수명이 포함됩니다. AS_REP = { PrincipalService , Timestamp , Lifetime , SKTGS }

따라서 시간 차이가 수명을 벗어나면 연결이 거부됩니다.

추측: 수명이 분 단위로 지정되어 있다는 것을 문서로 확인할 수는 없었지만, 간헐적으로 작동하는 기계가 있었기 때문이라고 생각합니다. 제가 생각할 수 있는 유일한 이유는 그것이 바로 국경에 있다는 것뿐이었습니다. 일생의. 따라서 약 30초 동안 작동한 다음 분이 바뀌고 연결이 거부됩니다.

관련 정보