Klienci Win7, którzy zawiodli z buforowanymi danymi uwierzytelniającymi na samba4 RODC

9

Konfiguruję środowisko testowe dla klienta, który zamierza wdrożyć samba4 w 1400 zdalnych witrynach i mam problem. W końcu moim zadaniem jest napotkać problemy, a następnie je rozwiązać.

Active Directory

  • root lasu i pojedyncza domena: main.adlab.netdirect.ca
  • utworzony w systemie Windows 2008 R2
  • 2008 FFL
  • 2008 DFL

Główne biuro

  • AD1: Windows 2008 R2 DC
  • AD2: Windows 2008 R2 DC
  • Klienci Windows 7 Professional

Oddział

  • SLES11SP2 (w pełni zaktualizowany!) Z pakietami Samba 4 (4.1.1-7.suse111 z sernetu)
  • Samba 4 skonfigurowana jako RODC

Skonfigurowałem zasady replikacji haseł, aby umożliwić buforowanie niektórych kont na RODC, a następnie zapełniłem te konta na 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]

Ja wiem , że te poświadczenia są buforowane na RODC ponieważ gdybym upuścić link strony mogę zalogować się przy użyciu pamięci podręcznej użytkownika, ale nie inny użytkownik:

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

Więc uwierzytelnianie działa dobrze! Ale kiedy próbuję zalogować się do komputera z systemem Windows 7 (WIN7-SHIRE), pojawia się błąd:

Wystąpił błąd wewnętrzny.

Ojej. Dzięki. Jeśli użyję niepoprawnego hasła, otrzymam:

Nazwa użytkownika lub hasło są nieprawidłowe.

Tak więc uwierzytelnianie ma miejsce, ale Windows 7 czegoś nie lubi . Widzę te błędy w dziennikach zdarzeń i myślę, że dotyczą one tego problemu:

System bezpieczeństwa wykrył błąd uwierzytelnienia dla serwera ldap / sles-shire.main.adlab.netdirect.ca. Kod błędu z protokołu uwierzytelniania Kerberos brzmiał: „Wystąpił błąd wewnętrzny. (0xc00000e5)”.

System bezpieczeństwa wykrył błąd uwierzytelnienia dla serwera DNS / sles-shire.main.adlab.netdirect.ca. Kod błędu z protokołu uwierzytelniania Kerberos brzmiał: „Wystąpił błąd wewnętrzny. (0xc00000e5)”.

Jeśli jestem już zalogowany i próbuję korzystać z usług sieciowych, otrzymuję:

System bezpieczeństwa wykrył błąd uwierzytelnienia dla serwera cifs / sles-shire.main.adlab.netdirect.ca. Kod błędu z protokołu uwierzytelniania Kerberos brzmiał: „Wystąpił błąd wewnętrzny. (0xc00000e5)”.

Mój krb5.conf na serwerze:

[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

Oto prawdziwy kicker:

Zachowanie nadal występuje, gdy łącze do witryny jest aktywne . Mogę zalogować się do komputera domeny z kontami, które nie są buforowane na RODC, ale jeśli są na RODC, pojawia się ten sam błąd.

Zapewniłem, że wszystkie odpowiednie rekordy SRV w AD DNS są na miejscu. Zapewniłem to, promując system Windows 2008 R2 DC w oddziale do roli RODC i upewniając się, że wszystkie odpowiednie rekordy DNS są dostępne zarówno dla RODC dla Windows, jak i Samby.

(niektóre trzeba było dodać ręcznie, ponieważ nie zostały jeszcze dodane przez sambę:

SRV _ldap._tcp.${SITE}._sites.DomainDnsZones.${DNSDOMAIN} ${HOSTNAME} 389
SRV _ldap._tcp.${SITE}._sites.ForestDnsZones.${DNSFOREST} ${HOSTNAME} 389

) (należy zamknąć nawias)

Więc… co jest zepsute i jak to naprawić?


Informacje o 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;
MikeyB
źródło

Odpowiedzi:

2

To długa szansa, ale spróbuję: wydaje mi się, że istnieje pewna niezgodność między RODC opartym na win7 i sambie pod względem ustawień poziomu bezpieczeństwa. Zakładam również, że niektóre domyślne ustawienia bezpieczeństwa w win 7 są zbyt restrykcyjne, że samba nie obsługuje. Spróbuję rozluźnić ustawienia bezpieczeństwa w win 7 poprzez zmianę lokalnych zasad: Konfiguracja komputera-> Ustawienia systemu Windows-> Ustawienia zabezpieczeń-> Zasady lokalne-> Opcje bezpieczeństwa.

Do typowych podejrzanych należą między innymi:

Klient sieci Microsoft: podpisuj cyfrowo komunikację (za zgodą serwera) Klient sieci Microsoft: wysyłaj niezaszyfrowane hasło do zewnętrznych serwerów SMB Bezpieczeństwo sieci: Poziom uwierzytelnienia LAN Manager Bezpieczeństwo sieci: Wymagania podpisywania klienta LDAP Bezpieczeństwo sieci: Minimalne bezpieczeństwo sesji dla NTLM SSP ( w tym bezpiecznych klientów RPC) Wymagaj poufności wiadomości Wymagaj bezpieczeństwa sesji NTLMv2 Wymagaj szyfrowania 128-bitowego

strongline
źródło
0

Wygląda na to, że problemy mogły mieć związek ze wszystkimi ślepymi zaułkami i luźnymi drutami związanymi z instalacją eksploracyjną / testową.

Po przywróceniu środowiska i ponownym uruchomieniu AD i konfiguracji RODC z rzeczywistej procedury konfiguracji, ten scenariusz działał idealnie bez żadnych problemów!

MikeyB
źródło