Я настраиваю тестовую среду для клиента, который собирается развернуть samba4 на 1400 удаленных сайтах, и у меня возникла проблема. В конце концов, моя работа - сталкиваться с проблемами, а затем их решать.
Я настроил политику репликации паролей, чтобы разрешить кэширование определенных учетных записей на RODC, а затем заполнил эти учетные записи на RODC:
sles-shire:~ # samba-tool rodc preload 'win7-shire$' --server main.adlab.netdirect.ca
Replicating DN CN=WIN7-SHIRE,CN=Computers,DC=main,DC=adlab,DC=netdirect,DC=ca
Exop on[CN=WIN7-SHIRE,CN=Computers,DC=main,DC=adlab,DC=netdirect,DC=ca] objects[1] linked_values[2]
sles-shire:~ # samba-tool rodc preload 'win7-shire-2$' --server main.adlab.netdirect.ca
Replicating DN CN=WIN7-SHIRE-2,CN=Computers,DC=main,DC=adlab,DC=netdirect,DC=ca
Exop on[CN=WIN7-SHIRE-2,CN=Computers,DC=main,DC=adlab,DC=netdirect,DC=ca] objects[1] linked_values[1]
sles-shire:~ # samba-tool rodc preload 'bilbo' --server main.adlab.netdirect.ca
Replicating DN CN=Bilbo Baggins,OU=Shire,OU=Offices,DC=main,DC=adlab,DC=netdirect,DC=ca
Exop on[CN=Bilbo Baggins,OU=Shire,OU=Offices,DC=main,DC=adlab,DC=netdirect,DC=ca] objects[1] linked_values[2]
я знать что эти учетные данные кэшируются на контроллере домена только для чтения, поскольку, если я отброшу ссылку на сайт, я могу войти в систему с кешированным пользователем, но не с другим пользователем:
michael@sles-shire:~> smbclient //sles-shire.main.adlab.netdirect.ca/sysvol -U michael
Enter michael's password:
session setup failed: NT_STATUS_IO_TIMEOUT
michael@sles-shire:~> smbclient //sles-shire.main.adlab.netdirect.ca/sysvol -U bilbo
Enter bilbo's password:
Domain=[MAIN] OS=[Unix] Server=[Samba 4.1.1-SerNet-SuSE-7.suse111]
smb: \> ls
. D 0 Mon Nov 18 16:09:44 2013
.. D 0 Mon Nov 18 16:11:15 2013
main.adlab.netdirect.ca D 0 Wed Nov 20 17:54:13 2013
Так что аутентификация работает нормально! Но когда я пытаюсь войти в компьютер с Windows 7 (WIN7-SHIRE), я получаю сообщение об ошибке:
Произошла внутренняя ошибка.
Ну и дела. Спасибо. Если я использую неверный пароль, я получаю:
Имя пользователя или пароль неверны.
Итак, аутентификация происходит, но Windows 7 не любит что-то. Я вижу эти ошибки в журналах событий и думаю, что они имеют отношение к этой проблеме:
Система безопасности обнаружила ошибку аутентификации для сервера ldap / sles-shire.main.adlab.netdirect.ca. Код ошибки протокола аутентификации Kerberos: «Произошла внутренняя ошибка. (0xc00000e5)».
Система безопасности обнаружила ошибку аутентификации для сервера DNS / sles-shire.main.adlab.netdirect.ca. Код ошибки протокола аутентификации Kerberos: «Произошла внутренняя ошибка. (0xc00000e5)».
Если я уже вошел в систему и попробую использовать сетевые службы, которые я получаю:
Система безопасности обнаружила ошибку аутентификации для сервера cifs / sles-shire.main.adlab.netdirect.ca. Код ошибки протокола аутентификации Kerberos: «Произошла внутренняя ошибка. (0xc00000e5)».
Мой krb5.conf на сервере:
[libdefaults]
default_realm = MAIN.ADLAB.NETDIRECT.CA
dns_lookup_realm = true
dns_lookup_kdc = true
[realms]
[logging]
kdc = FILE:/var/log/krb5/krb5kdc.log
admin_server = FILE:/var/log/krb5/kadmind.log
default = SYSLOG:NOTICE:DAEMON
Вот настоящий кикер:
Такое поведение по-прежнему возникает, когда ссылка на сайт вверх. Я могу войти на компьютер домена с учетными записями, которые не кэшируются на RODC, но если они на RODC, я получаю ту же ошибку.
Я удостоверился, что все соответствующие записи SRV в AD DNS находятся на своих местах. Я обеспечил это, повысив в филиале контроллер домена Windows 2008 R2 до роли контроллера домена только для чтения и убедившись, что все соответствующие записи DNS присутствуют как для контроллера домена только для чтения, так и для контроллера домена только для чтения Samba.
(некоторые из них пришлось добавить вручную, поскольку они еще не добавлены самбой:
SRV _ldap._tcp.${SITE}._sites.DomainDnsZones.${DNSDOMAIN} ${HOSTNAME} 389
SRV _ldap._tcp.${SITE}._sites.ForestDnsZones.${DNSFOREST} ${HOSTNAME} 389
) (должна закрывать скобку)
Итак ... что сломано и как мне это исправить?
> dsquery * "CN=SLES-SHIRE,OU=Domain Controllers,DC=main,DC=adlab,DC=netdirect,DC=ca" -attr servicePrincipalName
servicePrincipalName
ldap/SLES-SHIRE;
ldap/4116d553-d66b-4c8b-9a60-90380ac69c04._msdcs.main.adlab.netdirect.ca;
ldap/SLES-SHIRE.main.adlab.netdirect.ca/main.adlab.netdirect.ca;
HOST/SLES-SHIRE.main.adlab.netdirect.ca/main.adlab.netdirect.ca;
ldap/SLES-SHIRE.main.adlab.netdirect.ca;
ldap/SLES-SHIRE.main.adlab.netdirect.ca/MAIN;
HOST/SLES-SHIRE.main.adlab.netdirect.ca/MAIN;
RestrictedKrbHost/SLES-SHIRE.main.adlab.netdirect.ca;
RestrictedKrbHost/SLES-SHIRE;
GC/SLES-SHIRE.main.adlab.netdirect.ca/main.adlab.netdirect.ca;
HOST/SLES-SHIRE.main.adlab.netdirect.ca;HOST/SLES-SHIRE;
> dsquery * "CN=WIN7-SHIRE,CN=Computers,DC=main,DC=adlab,DC=netdirect,DC=ca" -attr servicePrincipalName
servicePrincipalName
TERMSRV/WIN7-SHIRE.main.adlab.netdirect.ca;
TERMSRV/WIN7-SHIRE;
RestrictedKrbHost/WIN7-SHIRE;
HOST/WIN7-SHIRE;
RestrictedKrbHost/WIN7-SHIRE.main.adlab.netdirect.ca;
HOST/WIN7-SHIRE.main.adlab.netdirect.ca;
Это долгий путь, но я бы попробовал: мне кажется, некоторая несовместимость между Win7 и RODC на основе самбы с точки зрения настроек уровня безопасности. Я также предполагаю, что некоторые настройки безопасности по умолчанию в Win 7 слишком строгие, которые не поддерживает самба. Я попытаюсь ослабить настройки безопасности в Win 7, изменив локальную политику: Конфигурация компьютера-> Настройки Windows-> Настройки безопасности-> Локальные политики-> Параметры безопасности.
Обычные подозреваемые включают, но не ограничиваются:
Сетевой клиент Microsoft: цифровая подпись (если сервер соглашается) Сетевой клиент Microsoft: отправка незашифрованного пароля на сторонние серверы SMB Сетевая безопасность: уровень проверки подлинности LAN Manager Сетевая безопасность: требования подписи клиента LDAP Сетевая безопасность: минимальная сеансовая безопасность для NTLM SSP на основе ( включая безопасные клиенты RPC) Требуется конфиденциальность сообщений Требуется безопасность сеанса NTLMv2 Требуется 128-битное шифрование
Похоже, проблемы могли быть связаны со всеми тупиками и ослабленными проводами, связанными с исследовательской / тестовой установкой.
После восстановления среды и повторной настройки AD и RODC из реальной процедуры настройки этот сценарий работал отлично, без каких-либо проблем!