Назад | Перейти на главную страницу

Сбой клиентов Win7 с кешированными учетными данными на RODC samba4

Я настраиваю тестовую среду для клиента, который собирается развернуть samba4 на 1400 удаленных сайтах, и у меня возникла проблема. В конце концов, моя работа - сталкиваться с проблемами, а затем их решать.

Active Directory

Главный офис

Филиал

Я настроил политику репликации паролей, чтобы разрешить кэширование определенных учетных записей на 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

) (должна закрывать скобку)

Итак ... что сломано и как мне это исправить?


Информация о SPN

> 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 из реальной процедуры настройки этот сценарий работал отлично, без каких-либо проблем!