У меня возникла странная проблема с Samba 3.6.23. Прямо сейчас у меня есть машина с Windows 2008 R2, у которой проблемы с доступом к общим ресурсам на доменном сервере Samba.
Когда я устанавливаю smbd для отладки журналирования, я получаю следующее:
[2015/03/23 17:33:03.306499, 3] smbd/sesssetup.c:662(reply_spnego_negotiate)
reply_spnego_negotiate: Got secblob of size 1840
[2015/03/23 17:33:03.306939, 10] libads/kerberos_verify.c:386(ads_secrets_verify_ticket)
libads/kerberos_verify.c:386: found previous password
[2015/03/23 17:33:03.315587, 10] libads/kerberos_verify.c:435(ads_secrets_verify_ticket)
libads/kerberos_verify.c:435: enc type [18] failed to decrypt with error Bad encryption type
[2015/03/23 17:33:03.319930, 10] libads/kerberos_verify.c:435(ads_secrets_verify_ticket)
libads/kerberos_verify.c:435: enc type [17] failed to decrypt with error Bad encryption type
[2015/03/23 17:33:03.320027, 3] libads/kerberos_verify.c:435(ads_secrets_verify_ticket)
libads/kerberos_verify.c:435: enc type [23] failed to decrypt with error Decrypt integrity check failed
[2015/03/23 17:33:03.320101, 10] libads/kerberos_verify.c:435(ads_secrets_verify_ticket)
libads/kerberos_verify.c:435: enc type [1] failed to decrypt with error Bad encryption type
[2015/03/23 17:33:03.320162, 10] libads/kerberos_verify.c:435(ads_secrets_verify_ticket)
libads/kerberos_verify.c:435: enc type [3] failed to decrypt with error Bad encryption type
[2015/03/23 17:33:03.328693, 10] libads/kerberos_verify.c:435(ads_secrets_verify_ticket)
libads/kerberos_verify.c:435: enc type [18] failed to decrypt with error Bad encryption type
[2015/03/23 17:33:03.332985, 10] libads/kerberos_verify.c:435(ads_secrets_verify_ticket)
libads/kerberos_verify.c:435: enc type [17] failed to decrypt with error Bad encryption type
[2015/03/23 17:33:03.333065, 3] libads/kerberos_verify.c:435(ads_secrets_verify_ticket)
libads/kerberos_verify.c:435: enc type [23] failed to decrypt with error Decrypt integrity check failed
[2015/03/23 17:33:03.333128, 10] libads/kerberos_verify.c:435(ads_secrets_verify_ticket)
libads/kerberos_verify.c:435: enc type [1] failed to decrypt with error Bad encryption type
[2015/03/23 17:33:03.333192, 10] libads/kerberos_verify.c:435(ads_secrets_verify_ticket)
libads/kerberos_verify.c:435: enc type [3] failed to decrypt with error Bad encryption type
[2015/03/23 17:33:03.333234, 3] libads/kerberos_verify.c:638(ads_verify_ticket)
libads/kerberos_verify.c:638: krb5_rd_req with auth failed (Bad encryption type)
[2015/03/23 17:33:03.333264, 10] libads/kerberos_verify.c:648(ads_verify_ticket)
libads/kerberos_verify.c:648: returning error NT_STATUS_LOGON_FAILURE
Этого было достаточно, чтобы указать мне на что-то невероятное. Итак, я немного поработал с tcpdumping и узнал, что для стилей имени машины и только ip согласовываются разные методы входа в систему. При доступе через имя-машины он пытается войти в Kerberos и терпит неудачу. При доступе через IP-адрес он пытается использовать NTLMv2, что отлично работает.
Интересно, что машина Win 2008 R2 находится в дочернем домене того, в котором находится сервер Samba. Однако у меня есть множество примеров, когда машины в дочернем домене правильно обращаются к машине Samba.
Удивительно, но у меня идентично настроенная система самбы (testparm показывает идентичный [global] settings) на другом сайте AD, который отлично работает на этом компьютере.
Я не знаю, куда ткнуть дальше.
Я не уверен, что делать дальше.
Я был свидетелем того же поведения, которое было вызвано несинхронизированными AD (Active Directory) после того, как сервер, на котором запущена samba, был повторно присоединен к домену.
После прочтения https://en.wikipedia.org/wiki/Kerberos_(protocol) Я пришел к выводу, что ошибка означает, что samba (служба) не может расшифровать билет Kerberos «клиент-служба», полученный от клиента, потому что в моем случае он был закодирован старым секретным ключом службы. Согласно Википедии, служебный секретный ключ - это хэш служебного пароля, хранящийся в AD. При повторном подключении к домену был создан новый пароль. Пока это изменение не было распространено на другие AD, клиенты получали от своих TGS (работающих на несинхронизированных AD) билеты, закодированные со старым секретом службы.