Problem bei der AD-Replikation zwischen UCS 3.2 und 2003 R2

Hallo,

der UCS 3.2 wurde als zusätzlicher DC in eine bestehende AD-Domäne eingefügt. Der Join gegen den PDC [2008 R2] funktionierte problemlos. Alle Daten wurden übertragen und befinden sich im Global-Catalog des UCS 3.2 und werden nach Änderungen vom 2008 R2 direkt und per s4sync ins LDAP übertragen. Soweit sieht alles sehr gut aus.

Allerdings bereitet mir ein zweiter DC [2003 R2] Probleme. Die gesamte DC relevante Kommunikation mit dem UCS 3.2 schlägt fehl - beispielsweise die AD-Replikation oder der Zugriff auf das AD des UCS 3.2.

Die Meldungen im Samba-Log sind wie folgt:

[2014/02/05 15:30:46.698583,  0, pid=1635] ../source4/librpc/rpc/dcerpc_util.c:681(dcerpc_pipe_auth_recv)
  Failed to bind to uuid e3514235-4b06-11d1-ab04-00c04fc2dcd2 for e3514235-4b06-11d1-ab04-00c04fc2dcd2@ncacn_ip_tcp:2115bbb8-e738-4c92-be16-3bfb58ef92ee._msdcs.nelle-ms.site[1025,seal,krb5] NT_STATUS_UNSUCCESSFUL
[2014/02/05 15:30:46.722727,  2, pid=1635] ../source4/librpc/rpc/dcerpc.c:1261(dcerpc_bind_recv_handler)
  dcerpc: bind_nak reason 9 - NT_STATUS_UNSUCCESSFUL

Auf der Seite des 2003 R2 erhalte ich verschiedene Meldungen, unter anderem dass der vorhandene Exchange 2003 (MSExchangeDSAccess) den UCS 3.2 DC auf Port 389 nicht erreichen kann. Es scheint, als ob die Vertrauensstellung (Kerberos?) zwischen den DCs UCS 3.2 <-> 2003 R2 nicht gegeben ist.

“samba-tool drs showrepl” zeigt für alle “inbound” und “outbound” Verbindungen zu dem 2003 R2 folgende Meldung

CN=Schema,CN=Configuration,DC=nelle-ms,DC=site
        Standardname-des-ersten-Standorts\SRV1 via RPC
                DSA object GUID: 2115bbb8-e738-4c92-be16-3bfb58ef92ee
                Last attempt @ Wed Feb  5 15:49:23 2014 CET failed, result 31 (WERR_GENERAL_FAILURE)
                26347 consecutive failure(s).
                Last success @ NTTIME(0)

Hat jemand einen Ansatzpunkt? Sind eventuell die Kerberos-Credentials des 2003 R2 nicht richtig/ nicht vollständig? Als KDC wird der lokale auf der UCS 3.2 verwendet.

Hallo,

da die Verbindung zwischen Ihrem UCS 3.2 System und dem vorhandenen 2008 R2 Server anscheinend zuverlässig funktioniert würde ich die Ursache hier auf Seite des 2003 R2 Systems suchen. Ich gehe davon aus, dass die Verbindung 2008 R2 - 2003 R2 ebenfalls problemslos funktioniert?
Unter Umständen erhalten Sie nähere Informationen in den Samba Logdateien, wenn Sie das Debuglevel erhöhen:

ucr set samba/debug/level=4 invoke-rc.d samba4 restart
Sehen Sie für eventuell relevante Hintergrundinformationen gern auch den SDB-Artikel Samba 4 Troubleshooting Guide - unter Umständen finden Sie hier ja hilfreiche Ansätze.
Mit den entsprechend beschriebenen LDB-Tools können Sie auffällige uuids prüfen und eventuelle fehlerhafte Einträge auch bearbeiten.

[2014/02/05 15:30:46.722727,  2, pid=1635] ../source4/librpc/rpc/dcerpc.c:1261(dcerpc_bind_recv_handler)
  dcerpc: bind_nak reason 9 - NT_STATUS_UNSUCCESSFUL

Das habe ich so leider noch nie gesehen, klingt aber tatsächlich nach Problemen im Kerberos-Bereich - ist die Uhrzeit auf allen Systemen synchron? Befindet sich das 2003 R2 System auf aktuellstem Patchlevel-Stand?

Mit freundlichen Grüßen,
Tim Petersen

Guten Morgen Herr Petersen,

vielen Dank für Ihre Antwort. Zu Ihren Fragen -

1. Verbindung 2008 R2 <-> 2003 R2
Ja, die AD-Replikation funktioniert einwandfrei. Einzig die SYSVOL-Synchronisation bereitet Probleme. Dieses Problem haben wir bisher nicht weiter verfolgt und synchronisieren bei Bedarf das SYSVOL manuell mit “robocopy”.

2. Patch Level
Alle beteiligten Systeme (2003 R2, 2008 R2, UCS 3.2) befinden sich auf dem aktuellen Patch-Level. EInzig den Exchange 2003 muss ich noch prüfen, da dieser separat aktuelisiert werden muss.

3. Systemzeit
Ich habe darauf geachtet - alle Systeme haben die selbe Systemzeit.

4. Samba4 Trouble Shooting Guide
Ich habe die Trouble Shooting Guide bereits durchgearbeitet. Mit dem 2008 R2 funktioniert alles wie

aus beiden Richtungen UCS 3.2 -> 2008 R2 und 2008 R2 -> UCS 3.2. Die Prüfung von

liefert sinnvolle Ergbenisse für alle 3 DCs. Einzig die Meldung

am Ende kann ich nicht einschätzen/ bewerten.

6. LDB-Tools
Die Prüfung mit

liefert nur einen Fehler

ERROR: incorrect DN string component for member in object CN=Domänen-Benutzer,CN=Users,DC=nelle-ms,DC=site - <GUID=38d8d57b-d42f-4fcd-93d9-de53c475877f>;CN=Administrator,cn=users,dc=nelle-ms,dc=site
Not fixing incorrect string version of DN
Please use --fix to fix these errors
Checked 1138 objects (1 errors)

den ich als irrelevant einschätze.

6. samba-tool drs showrepl mit debug level 4

root@ms-fs-ucs-001:/etc/samba# samba-tool drs showrepl
params.c:pm_process() - Processing configuration file "/etc/samba/base.conf"
Processing section "[netlogon]"
Processing section "[sysvol]"
Unknown parameter encountered: "acl xattr update mtime"
Ignoring unknown parameter "acl xattr update mtime"
Processing section "[IPC$]"
Processing section "[homes]"
Processing section "[printers]"
Processing section "[print$]"
pm_process() returned Yes
ldb_wrap open of secrets.ldb
GENSEC backend 'gssapi_spnego' registered
GENSEC backend 'gssapi_krb5' registered
GENSEC backend 'gssapi_krb5_sasl' registered
GENSEC backend 'schannel' registered
GENSEC backend 'spnego' registered
GENSEC backend 'ntlmssp' registered
GENSEC backend 'krb5' registered
GENSEC backend 'fake_gssapi_krb5' registered
Using binding ncacn_ip_tcp:ms-fs-ucs-001.nelle-ms.site[,seal]
Mapped to DCERPC endpoint 135
added interface eth0 ip=192.168.1.17 bcast=192.168.1.255 netmask=255.255.255.0
added interface eth0 ip=192.168.1.17 bcast=192.168.1.255 netmask=255.255.255.0
Mapped to DCERPC endpoint 1024
added interface eth0 ip=192.168.1.17 bcast=192.168.1.255 netmask=255.255.255.0
added interface eth0 ip=192.168.1.17 bcast=192.168.1.255 netmask=255.255.255.0
Received smb_krb5 packet of length 335
Received smb_krb5 packet of length 172
added interface eth0 ip=192.168.1.17 bcast=192.168.1.255 netmask=255.255.255.0
added interface eth0 ip=192.168.1.17 bcast=192.168.1.255 netmask=255.255.255.0
Standardname-des-ersten-Standorts\MS-FS-UCS-001
DSA Options: 0x00000001
DSA object GUID: 803fb946-a03c-4613-b407-f686a49935e3
DSA invocationId: 407e0d1c-5d19-4d0a-9847-8c36608b5c53

==== INBOUND NEIGHBORS ====

DC=DomainDnsZones,DC=nelle-ms,DC=site
        Standardname-des-ersten-Standorts\SRV2 via RPC
                DSA object GUID: 9b49c40b-cff3-4e86-b41c-dba7cb942db4
                Last attempt @ Tue Feb 11 09:26:21 2014 CET was successful
                0 consecutive failure(s).
                Last success @ Tue Feb 11 09:26:21 2014 CET

DC=DomainDnsZones,DC=nelle-ms,DC=site
        Standardname-des-ersten-Standorts\SRV1 via RPC
                DSA object GUID: 2115bbb8-e738-4c92-be16-3bfb58ef92ee
                Last attempt @ Tue Feb 11 09:26:22 2014 CET failed, result 31 (WERR_GENERAL_FAILURE)
                2567 consecutive failure(s).
                Last success @ NTTIME(0)
...

7. Debug Level = 4
Das Ereignis der AD-Replikation mit Debug Level 4

[2014/02/11 08:58:19.296778,  4, pid=2335] ../source4/lib/socket/interface.c:121(add_interface)
  added interface eth0 ip=192.168.1.17 bcast=192.168.1.255 netmask=255.255.255.0
[2014/02/11 08:58:19.296946,  4, pid=2335] ../source4/lib/socket/interface.c:121(add_interface)
  added interface eth0 ip=192.168.1.17 bcast=192.168.1.255 netmask=255.255.255.0
[2014/02/11 08:58:19.297034,  4, pid=2335] ../source4/dsdb/repl/drepl_notify.c:244(dreplsrv_notify_run_ops)
  started DsReplicaSync for CN=Configuration,DC=nelle-ms,DC=site to 2115bbb8-e738-4c92-be16-3bfb58ef92ee._msdcs.nelle-ms.site
[2014/02/11 08:58:19.309167,  3, pid=2334] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: TGS-REQ MS-FS-UCS-001$@NELLE-MS.SITE from ipv4:127.0.0.1:41297 for krbtgt/NELLE-MS.SITE@NELLE-MS.SITE [proxiable, forwarded, forwardable]
[2014/02/11 08:58:19.312949,  3, pid=2334] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: TGS-REQ authtime: 2014-02-11T08:57:34 starttime: 2014-02-11T08:58:19 endtime: 2014-02-11T18:57:34 renew till: unset
[2014/02/11 08:58:19.313450,  3, pid=2334] ../source4/smbd/service_stream.c:66(stream_terminate_connection)
  Terminating connection - 'kdc_tcp_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED'
[2014/02/11 08:58:19.313542,  3, pid=2334] ../source4/smbd/process_single.c:114(single_terminate)
  single_terminate: reason[kdc_tcp_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED]
[2014/02/11 08:58:19.314749,  2, pid=2335] ../source4/librpc/rpc/dcerpc.c:1261(dcerpc_bind_recv_handler)
  dcerpc: bind_nak reason 9 - NT_STATUS_UNSUCCESSFUL
[2014/02/11 08:58:19.314935,  0, pid=2335] ../source4/librpc/rpc/dcerpc_util.c:681(dcerpc_pipe_auth_recv)
  Failed to bind to uuid e3514235-4b06-11d1-ab04-00c04fc2dcd2 for e3514235-4b06-11d1-ab04-00c04fc2dcd2@ncacn_ip_tcp:2115bbb8-e738-4c92-be16-3bfb58ef92ee._msdcs.nelle-ms.site[1025,seal,krb5] NT_STATUS_UNSUCCESSFUL
[2014/02/11 08:58:19.315208,  4, pid=2335] ../source4/dsdb/repl/drepl_notify.c:196(dreplsrv_notify_op_callback)
  dreplsrv_notify: Failed to send DsReplicaSync to 2115bbb8-e738-4c92-be16-3bfb58ef92ee._msdcs.nelle-ms.site for CN=Configuration,DC=nelle-ms,DC=site - NT_STATUS_UNSUCCESSFUL : WERR_GENERAL_FAILURE

Ein weiteres Phänomen ist, dass Clients je nach verwendetem DC nicht auf Freigaben des 2003 R2 zugreifen können. Die Fehlermeldung ist, dass “nicht genug Systemresourcen” zur Verfügung stehen. Wird der UCS 3.2 ausgeschaltet, dann funktionieren Zugriffe auf Freigaben des 2003 R2 wieder - vermutlich da nun ein anderer DC/ Logon-Server gewählt wird.

Zu guter Letzt - ich bin auf verschiedene Threats zu dem Thema gestoßen, wie beispielsweise http://thr3ads.net/search?q=werr_general_failure https://lists.samba.org/archive/samba/2012-September/169302.html. Allerdings habe ich bisher keine Lösung zu dem Problem gefunden.

Hallo

[quote]1. Verbindung 2008 R2 <-> 2003 R2
Ja, die AD-Replikation funktioniert einwandfrei. Einzig die SYSVOL-Synchronisation bereitet Probleme. Dieses Problem haben wir bisher nicht weiter verfolgt und synchronisieren bei Bedarf das SYSVOL manuell mit “robocopy”.[/quote]

müsste nicht die AD DRS Replikation zwischen 2008 und 2003 dafür sorgen, dass die Daten auf dem 2003 landen. Wenn Sie den UCS abschalten und auf dem 2008 Änderungen vornehmen, werden diese auf das 2003 repliziert (falls ich das Szenario richtig verstanden habe, ein Domäne mit UCS, 2008 AD und 2003 AD)?

Auf welchen Funktionslevel befindet sich der UCS? Vielleicht verhindert hier ein falscher Wert die Kommunikation zw. UCS und 2003.

samba-tool domain level show

Ist der UCS Domaincontroller auf das 2003 repliziert (gibt es das Rechnerobjekt dort)?

Mit freundlichen Grüßen
Felix Botner

Ja, die Replikation zwischen dem 2008 und dem 2003 funktioniert reibungslos - sprich Änderungen von dem 2008 werden auf den 2003 übertragen. Diese Kombination besteht bereits seit Jahren. Der 2003 incl. Exchange 2003 wird durch den UCS mit Group-E als Groupware ersetzt. Mein Problem ist die Replikation zwischen dem 2003 und dem UCS. Diese funktioniert in beide Richtungen nicht. Liegt es eventuell an der Kombination mit Exchange 2003?

Die bisherige Strategie ist wie folgt:
[] UCS als DC in die Domäne aufnehmen
[
] Änderungen nur auf dem 2008 durchführen
[] Replikation von dem 2008 zu dem 2003 und dem UCS
[
] Abschaltung des 2003 samt Exchange 2003 sobald Groupware-Funktionen auf den UCS übertragen wurden
[] paralleler Betrieb des 2008 mit dem UCS für eine Übergangszeit
[
] Degradierung des 2008 und Übernahme sämtlicher AD-Rollen durch den UCS

# samba-tool domain level show

  Domain and forest function level for domain 'DC=nelle-ms,DC=site'

  Forest function level: (Windows) 2000
  Domain function level: (Windows) 2003
  Lowest function level of a DC: (Windows) 2003

Ja, der UCS wird bei dem 2003 als DC aufgeführt.

Active Directory-Standorte und -Dienste -> Sites -> Standardname-des- ... -> Servers -> ....

MfG,

Christian Rost

Mastodon