어제 발생한 상황은 다음과 같습니다. 별칭(CNAME)을 사용하여 액세스해야 하는 컴퓨터에 공유가 있습니다. 머신은 Windows Server 2012 R2를 실행하고 있으며 Windows 7 및 8 클라이언트를 서비스합니다.
Windows 7 클라이언트는 \SHARECNAME 또는 \IP.AD.DR.ESS 공유를 여는 데 문제가 없습니다. Windows 8 클라이언트는 \IP.AD.DR.ESS로만 공유를 열 수 있습니다.
결국 효과가 있었던 것은 CNAME이 HOSTNAME(setspn -S HOST/CNAME HOSTNAME 등)을 가리키도록 SPN 레코드를 생성하는 것이었고 갑자기 공유를 사용할 수 있게 되었습니다.
HOSTNAME 시스템에서 오류를 기록했습니다.
"Kerberos 클라이언트가 HOSTNAME$ 서버로부터 KRB_AP_ERR_MODIFIED 오류를 받았습니다. 사용된 대상 이름은 cifs/CNAME입니다." 이에 대한 정보는 많지 않았지만 적절한 SPN 레코드를 설정하는 방향을 알려주었습니다.
내가 이해하려고 하는 것은 고객 경험의 차이가 왜 발생하는가입니다.
감사합니다.
답변1
확실하지는 않습니다. 하지만 비활성화StrictNameChecking 레지스트리 설정을 지정하셨나요?
http://www.md3v.com/enable-windows-server-smb-2-0-alias-cname
SPN과 함께 IP 대 CName은 Kerberos가 관련되어 있음을 분명히 나타냅니다. 아마도 SMB 3.0 암호화가 나타날 것입니다. 이는 Server2012에서 Win8로의 연결에만 해당되지만 이는 SMB 2와 SMB 3의 주요 차이점 중 하나입니다. 공유에 대한 암호화가 기본적으로 활성화되어 있다고 생각하지 않지만 SMB 3으로 이동하면 프로토콜이 Kerberos 인증이 필요합니다.
답변2
새로운 NetApp에서도 비슷한 문제가 발생했습니다. 모든 W10/2012 클라이언트는 CNAME 공유에 액세스할 수 없었지만 W7/2008R2 클라이언트는 액세스할 수 있었습니다. CNAME SPN을 만들 필요가 없었습니다. 우리가 한 일은 setspn -l cname으로 표시된 CNAME에 대한 모든 SPN을 제거하는 것입니다.
참고: CNAME은 AD 컴퓨터 계정으로도 사용되었으며 이후에도 그대로 유지되었습니다.