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


9

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

Active Directory

  • корень леса и один домен: main.adlab.netdirect.ca
  • создан на Windows 2008 R2
  • 2008 FFL
  • 2008 DFL

Главный офис

  • AD1: Windows 2008 R2 DC
  • AD2: Windows 2008 R2 DC
  • Windows 7 Профессиональные клиенты

Филиал

  • SLES11SP2 (полностью обновлен!) С Samba 4 (пакеты 4.1.1-7.suse111 от sernet)
  • Samba 4 настроен как RODC

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

Произошла внутренняя ошибка.

Gee. Спасибо. Если я использую неверный пароль, я получаю:

Неверное имя пользователя или пароль.

Таким образом, аутентификация происходит, но 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 в филиале на роль RODC и обеспечив, чтобы все соответствующие записи DNS присутствовали как для Windows, так и для Samba RODC.

(некоторые необходимо было добавить вручную, так как они еще не добавлены 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;

Ответы:


2

Это длинный путь, но я бы попробовал: мне кажется, что существует некоторая несовместимость между win7 и RODC на базе Samba с точки зрения настроек уровня безопасности. Я также предположил бы, что некоторые настройки безопасности по умолчанию на win 7 слишком ограничены, чтобы samba не поддерживала их. Я попытаюсь ослабить настройки безопасности на win 7, изменив локальную политику: Конфигурация компьютера-> Настройки Windows-> Параметры безопасности-> Локальные политики-> Параметры безопасности.

Обычные подозреваемые включают, но не ограничиваются:

Сетевой клиент Microsoft: цифровая подпись сообщений (если сервер согласен). Сетевой клиент Microsoft: отправка незашифрованного пароля сторонним SMB-серверам. Сетевая безопасность: уровень аутентификации LAN Manager. Сетевая безопасность: требования подписи клиента LDAP. Сетевая безопасность: минимальная безопасность сеанса для NTLM SSP ( включая защищенный RPC) клиенты Требуется конфиденциальность сообщений Требуется безопасность сеанса NTLMv2 Требуется 128-битное шифрование


0

Похоже, проблемы могли быть связаны со всеми тупиками и незакрепленными проводами, связанными с исследовательской / испытательной установкой.

После восстановления среды и повторного выполнения AD и настройки RODC из реальной процедуры настройки этот сценарий работал без каких-либо проблем!

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.