Я встановлюю тестове середовище для клієнта, який збирається розгорнути samba4 на 1400 віддалених сайтах, і я зіткнувся з проблемою. Це моя робота, зрештою, зіткнутися з проблемами і потім їх вирішити.
Активна Директорія
- лісовий корінь та один домен: main.adlab.netdirect.ca
- створено на Windows 2008 R2
- 2008 FFL
- 2008 DFL
Головний офіс
- AD1: Windows 2008 R2 DC
- AD2: Windows 2008 R2 DC
- Клієнти Windows 7 Professional
Філія
- SLES11SP2 (повністю оновлений!) З Samba 4 (пакети 4.1.1-7.suse111 з сернета)
- 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]
Я знаю, що ці облікові дані кешуються на RODC, оскільки якщо я перейду на посилання на сайт, я можу увійти з кешованим користувачем, але не з іншим користувачем:
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 DC у філії до ролі 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;