UC Member Server am anderen Standort per VPN

Für den Join ist eine funktionale Netzwerk und vor allem DNS Erreichbarkeit ein Muss. Wenn man aus Netz B schon nicht das Netz A pingen kann, scheint ein Routing Problem zu bestehen? Der master ist ja der Joinpartner, der muss auf jeden Fall erreichbar sein, sonst braucht man am Joinvorgang nicht weiter debuggen (das Problem liegt dann eher am Netzwerk). Es wäre auch möglich den member an Standort A direkt in den master zu joinen (mit der richtigen Netzwerkkonfiguration) und erst danach zu Standort B zu bringen - ABER: das behebt nur das Join Problem, nicht die Connection Issues von Netz B nach A. Der Member könnte trotz Join Status im aktuellen Zustand nicht mit dem master kommunizieren (und auch nicht Backups machen).

Natürlich hast du Recht.

Habe gerade bei der FritzBox am Standort B in Einstellungen -> Internet-Zugangsdaten den Master als DNS Server eingestellt, statische Route zum Netzwerk am Standort B erstellt und bei Heimnetzwerk-Einstellungen den Master als Lokalen DNS-Server eingestellt und kann den Master jetzt anpingen, aber nur über die IP, über Hostname geht es nicht.

Bei der Installation des Memberservers bin ich bis Domänenbeitritt gekommen (zum ersten Mal kam nach “Einer bestehenden UCS-Domäne beitreten” sofort die
Serverrolle-Auswahl), er hat den Master erkannt und auch seinen kompletten Hostnamen angezeigt.

Domänenbeitritt klappt aber nicht, kommt die Meldung “ping to master failed”, obwohl ich per Konsole auf dem Memberserver Standort B den Master Standort A anpingen kann.

Ahja, eine Sache noch, hab bei der Memberserver-Installation keine Software-Komponente mitinstalliert, dachte man kann es auch später nachinstallieren, aber in der UCS-Console vom Memberserver im Browser gibt es gar kein App-Center.

Wie gesagt, DNS muss funktionieren. Wenn der master nicht per name pingbar ist, wird auch der Join fehlschlagen.

Ggf. ist es wirklich eine Option den member an Standort A zu joinen und dann rüber zu tragen - den Joinstatus wird er nicht unbedingt verlieren, wenn der master noch per IP erreichbar ist. Zumindest ist es wert das mal zu versuchen. Dann kommts noch drauf an, ob die verwendeten Programme auch mit der IP Kommunikation zurecht kommen.

Hmmm … ich denke, das an den VPN-Einstellungen etwas nicht passt.

Beide Standorte haben unterschiedliche Netzwerkadressbereiche ?

Also Standort A z.B. 192.168.9.0
Standort B z.B. 192.168.10.0

Soll denn sämtlicher Netzwerkverkehr aus Standort B über den Standort A laufen ?

Oder soll die Fritzbox bei Standort B nur den Verkehr zu Standort A über das VPN schicken und
die “normalen” Internetanfragen über den INet-Zugang von Standort B ?

Hast Du denn die Einrichtung des VPN Zuganges der Fritzboxen über die FritzBox-Web-Oberfläche eingerichtet oder das
VPN-Tool von AVM benutzt ?

Ping funktioniert auf einmal mit IP und mit Hostname, egal ob vom memberserver oder einem anderen Computer vom Standort B.
Bei dem Versuch der Domäne über UCS-Console im Browser mit dem Memberserver beizutreten, kommt jetzt andere Meldung:
“binddn for user Administrator not found”

Wenn ich in der Text-Konsole direkt am Memberserver denn Befehl “univention-ldapsearch” ausführe,
kommt “Can’t contact LDAP server (-1)”

[quote=“O. Bertgen”]
Beide Standorte haben unterschiedliche Netzwerkadressbereiche ?[/quote]

Ja, war immer so und das ist auch die Voraussetzung für VPN mit FritzBoxen

[quote=“O. Bertgen”]Oder soll die Fritzbox bei Standort B nur den Verkehr zu Standort A über das VPN schicken und
die “normalen” Internetanfragen über den INet-Zugang von Standort B ?[/quote]

Ja, die FritzBox soll bei Standort B nur den Verkehr zu Standort A über das VPN schicken und
die “normalen” Internetanfragen über den INet-Zugang von Standort B

[quote=“O. Bertgen”]
Hast Du denn die Einrichtung des VPN Zuganges der Fritzboxen über die FritzBox-Web-Oberfläche eingerichtet oder das
VPN-Tool von AVM benutzt ?[/quote]

Habe es über die FritzBox-Web-Oberfläche eingerichtet.

Beste Grüße
Morimystes

Damit das funktioniert, müsste der unter “ldap/server/name” (respektive “ldap/server/ip”) eingetragene Server auf dem Port “ldap/server/port” erreichbar sein. Diese Variablen setzen unter anderem /etc/ldap/ldap.conf.

Einfache Testmöglichkeit:

# nc -v -z name.des.masters 7389

erwartetes Resultat:

Connection to name.des.masters 7389 port [tcp/*] succeeded!

Viele Grüße,
Dirk Ahrnke

Vielen Dank für den Tip, Herr Ahrnke, bin noch nicht dazu gekommen es zu testen, weil ich es jetzt alles von vorne gemacht habe.

Habe an der FritzBox am Standort B nur in den Heimnetz-Einstellungen als lokalen DNS-Server den Master von Standort A gesetzt. Danach könnte ich sofort den Master von Standort A mit einem Windows 10-Rechner von Standort B anpingen, sowohl über IP als auch über Hostname. Der Domänenbeitritt mit dem Windows 10-Rechner klappte auch sofort.

Als nächstes habe ich die Installation des UCS-Memberservers am Standort B gestartet und er hat den Master sofort erreicht, hat sein Hostname angezeigt und die IP, davor lief der Domänenbeitritt nur bis 3%, jetzt aber bis 86%.

Danach kam der Fehler:

binddn for user Administrator not found

Habe danach noch mit weiteren Admin-Accounts versucht die Installation durchzuführen und mit jedem der gleiche Fehler…

Habe nirgendwo ein ähnliches Problem gefunden und nur noch eine Woche bis das Projekt fertig sein muss, glaube werde am Arbeitsplatz übernachten.

Kann mir vielleicht jemand helfen?

Beste Grüße
Morimystes

Na dann bitte mal das vollständige join.log posten.

Habe heute den Domänenbeitritt nochmal gestartet und auf einmal ging es, habe nichts geändert, der Memberserver läuft jetzt, aber einloggen dauert ewig und Samba hat er nicht installiert.
Der komplette Join.log ist im Anhang, waren zu viele Zeichen. Wie es aussieht, sind alle meine bisherige Domänenbeitritts-Versuche auch mitdrin.
Der Ping vom Memberserver über IP geht immer und über Hostname mal ja, mal nein.

Man kann doch sicher Samba4 manuell installieren oder?

Beste Grüße
Morimystes
JoinLog.txt (66.3 KB)

Diesen Befehl ausgeführt, Resultat war erfolgreich.

Kann es sein, dass es auf dem Memberserver am Standort B die Samba-Installation nicht klappt, weil auf dem Master am Standort A Probleme mit SSL gibt und ich den connector/s4/ldap/ssl='no' gesetzt habe, weil kein Zertifikatpfad angegeben ist und ich den SSL Zertifikat nicht finden kann. Dazu habe ich ein anderes Thema "Neuerstellte Benutzer Anmeldungsproblem" vor einiger Zeit erstellt.
Hängt es evtl. zusammen?

Beste Grüße
Morimystes

Hier ist die Ausgabe von

ucr search --brief ^ldap

ldap/acl/nestedgroups: yes
ldap/acl/read/anonymous: no
ldap/acl/read/ips: 
ldap/acl/slavepdc: yes
ldap/acl/user/password/change: no
ldap/autostart: yes
ldap/backup: 
ldap/base: dc=isff,dc=see
ldap/binaryattributes: 
ldap/cachesize: 20000
ldap/client/network_timeout: 
ldap/client/retry/count: 10
ldap/client/timelimit: 
ldap/client/timeout: 
ldap/database/bdb/checkpoint: 
ldap/database/bdb/db_config_options: set_flags
ldap/database/bdb/set_cachesize: 
ldap/database/bdb/set_flags: DB_LOG_AUTOREMOVE
ldap/database/bdb/set_lg_bsize: 
ldap/database/bdb/set_lg_max: 
ldap/database/ldbm/dbsync: 
ldap/database/mdb/checkpoint: 
ldap/database/mdb/envflags: 
ldap/database/mdb/maxsize: 2147483648
ldap/database/type: mdb
ldap/debug/level: 0
ldap/hostdn: cn=memberoude,cn=memberserver,cn=computers,dc=isff,dc=see
ldap/idlcachesize: 20000
ldap/idletimeout: 360
ldap/index/approx: cn,givenName,mail,sn,uid
ldap/index/autorebuild: yes
ldap/index/eq: aRecord,automountInformation,cNAMERecord,cn,description,dhcpHWAddress,displayName,entryUUID,gidNumber,givenName,homeDirectory,krb5PrincipalName,macAddress,mail,mailAlternativeAddress,mailPrimaryAddress,memberUid,objectClass,ou,pTRRecord,relativeDomainName,sambaAcctFlags,sambaDomainName,sambaGroupType,sambaPrimaryGroupSID,sambaSID,sambaSIDList,secretary,shadowExpire,sn,uid,uidNumber,uniqueMember,univentionCanonicalRecipientRewriteEnabled,univentionInventoryNumber,univentionLicenseModule,univentionLicenseObject,univentionMailHomeServer,univentionNagiosHostname,univentionObjectFlag,univentionObjectType,univentionPolicyReference,univentionServerRole,univentionService,univentionShareGid,univentionShareSambaName,univentionShareWriteable,univentionUDMOptionModule,univentionUDMPropertyCLIName,univentionUDMPropertyDefault,univentionUDMPropertyDeleteObjectClass,univentionUDMPropertyDoNotSearch,univentionUDMPropertyHook,univentionUDMPropertyLayoutOverwritePosition,univentionUDMPropertyLayoutOverwriteTab,univentionUDMPropertyLayoutPosition,univentionUDMPropertyLayoutTabAdvanced,univentionUDMPropertyLayoutTabName,univentionUDMPropertyLdapMapping,univentionUDMPropertyLongDescription,univentionUDMPropertyModule,univentionUDMPropertyMultivalue,univentionUDMPropertyObjectClass,univentionUDMPropertyOptions,univentionUDMPropertyShortDescription,univentionUDMPropertySyntax,univentionUDMPropertyTranslationLongDescription,univentionUDMPropertyTranslationShortDescription,univentionUDMPropertyTranslationTabName,univentionUDMPropertyValueMayChange,univentionUDMPropertyValueRequired,univentionUDMPropertyVersion,zoneName
ldap/index/pres: aRecord,automountInformation,cn,description,dhcpHWAddress,displayName,gidNumber,givenName,homeDirectory,krb5PrincipalName,macAddress,mail,mailAlternativeAddress,mailPrimaryAddress,memberUid,name,objectClass,ou,relativeDomainName,shadowMax,sn,uid,uidNumber,uniqueMember,univentionMailHomeServer,univentionObjectFlag,univentionPolicyReference,univentionUDMPropertyCLIName,univentionUDMPropertyDefault,univentionUDMPropertyDeleteObjectClass,univentionUDMPropertyDoNotSearch,univentionUDMPropertyHook,univentionUDMPropertyLayoutOverwritePosition,univentionUDMPropertyLayoutOverwriteTab,univentionUDMPropertyLayoutPosition,univentionUDMPropertyLayoutTabAdvanced,univentionUDMPropertyLayoutTabName,univentionUDMPropertyLdapMapping,univentionUDMPropertyLongDescription,univentionUDMPropertyModule,univentionUDMPropertyMultivalue,univentionUDMPropertyObjectClass,univentionUDMPropertyOptions,univentionUDMPropertyShortDescription,univentionUDMPropertySyntax,univentionUDMPropertyTranslationLongDescription,univentionUDMPropertyTranslationShortDescription,univentionUDMPropertyTranslationTabName,univentionUDMPropertyValueMayChange,univentionUDMPropertyValueRequired,univentionUDMPropertyVersion,zoneName
ldap/index/quickmode: false
ldap/index/sub: aRecord,associatedDomain,automountInformation,cn,default,description,displayName,employeeNumber,givenName,macAddress,mail,mailAlternativeAddress,mailPrimaryAddress,name,ou,pTRRecord,printerModel,relativeDomainName,sambaSID,sn,uid,univentionInventoryNumber,univentionOperatingSystem,univentionSyntaxDescription,univentionUDMPropertyLongDescription,univentionUDMPropertyShortDescription,zoneName
ldap/limits: users time.soft=-1 time.hard=-1
ldap/master/port: 7389
ldap/master: master.isff.see
ldap/maxopenfiles: 8192
ldap/online/master: 
ldap/overlay/memberof/dangling: ignore
ldap/overlay/memberof/member: uniqueMember
ldap/overlay/memberof/memberof: memberOf
ldap/overlay/memberof/modifiersname: cn=admin,dc=isff,dc=see
ldap/overlay/memberof/objectclass: 
ldap/overlay/memberof/refint: false
ldap/overlay/memberof: true
ldap/policy/cron: 5 * * * *
ldap/ppolicy/default: 
ldap/ppolicy/enabled: 
ldap/ppolicy: 
ldap/replication/preferredpassword: 
ldap/sasl/secprops/maxssf: 
ldap/server/addition: memberoude.isff.see
ldap/server/ip: 127.0.0.1
ldap/server/name: master.isff.see
ldap/server/port: 7389
ldap/server/type: 
ldap/sizelimit: 400000
ldap/threads: 16
ldap/tls/ciphersuite: 
ldap/tls/dh/cron: 
ldap/tls/dh/paramfile: /etc/ldap/dh_2048.pem
ldap/tls/dh/restart: 
ldap/tls/minprotocol: 
ldap/tool-threads: 1
ldap/translogfile:

Der Port 1024 für Samba 4 scheint offen zu sein

nc -v -z master.isff.see 1024
Connection to master.isff.see 1024 port [tcp/*] succeeded!

Und bei

net rpc join -v -U Morimystes memberoude

kam:

Failed to join domain: failed to find DC for domain ISFF - Undetermined error

Den Eintrag

ldap/server/addition: memberoude.isff.see

habe ich manuell eingegeben, davor war dort leer.

Der Memberserver ist von der Seite des Masters über Ping per IP und Hostname erreichbar.

Ich merke gerade, es sind mehrere Antworten hier in diesem Thema verschwunden…

Auf dem Memberserver wurden alle Join-Skripte erfolgreich ausgeführt, außer 2:

und

Hat noch jemand eine Idee?

Beste Grüße
Morimystes

Auf dem Master funktioniert wieder die Benutzeranmeldung nicht richtig, man wird mit einem temporären Profil angemeldet.

Ich glaube auf dem Master gibts Probleme mit DNS und Samba, wie kann man es überprüfen?
Gibt es sowas wie eine Befehlsrefenz/-liste für Univention oder etwas ähnliches?

Wie es aussieht, wegen den Problemen auf dem Master, funktioniert auch der Memberjoin nicht reibungslos, die letzten 2 Join-Skripte wollen nicht: [quote]
univention-ldap-server-init

und

univention-samba
[/quote]

Habe den Debug Level von Samba 4 auf dem Master etwas erhöht

[quote]
ucr set samba4/debug/level=4[/quote]
wurde angenommen.

Aber bei

sagt er mir

Habe es dann so probiert, nicht samba4, sondern nur samba

[quote]
ucr set samba/debug/level=4[/quote]
und [quote]/etc/init.d/samba restart[/quote]
wurde auch ausgeführt.

Aber auf einem Master in UCS-Domäne als Active Directory-kompatiblen Domänencotroller muss doch Samba 4 laufen und nicht Samba?

Bin komplett durcheinander…

Beste Grüße
Morimystes

Zunächst sei erwähnt, dass man unter UCS klaglos eine beliebige UCR-Variable erzeugen kann. Es ist nur fraglich, dass diese dann irgendetwas sinnvolles tut. Empfehlenswert wäre, vorab schon mal mit ucr search zu suchen.

Die Sache mit dem Init-Skript hat mir auch etwas Kopfzerbrechen bereitet.
In http://sdb.univention.de/content/6/245/en/troubleshooting-domain-joins-of-windows-clients.html ist auch von /etc/init.d/samba4 die Rede. Die Auflösung steht u.a. in http://sdb.univention.de/content/6/274/en/re_provisioning-samba4-on-a-dc-master.html, Unter UCS 3 hieß das Skript samba4, jetzt nur noch samba. Das hatte ich mittlerweile vergessen.

hth,
Dirk Ahrnke

Danke für die Tips, Dirk.

Mit Samba auf dem Master gibts eigentlich keine Probleme, außer dass SSL aus ist, weil ich den Zertifikat dafür nicht finden kann, wenn ich SSL einschalte, ohne den Zertifikatspfad anzugeben (ich kenne ihn nicht), gibts Probleme mit der Benutzeranmeldung auf den 3 Windows-Clients.

Nach meinem heutigen Versuch die 2 Join-Skripts

auszuführen, kam wieder das:

Ich habe alle Ports auf dem Master und Member anhand der Liste
http://sdb.univention.de/content/2/281/en/which-tcp-_-udp-ports-on-the-dc-master-must-be-accessable-by-other-ucs-systems.html
überprüft, der Member und der Master erreichen sich gegenseitig auf allen Ports, außer 123 (NTP) und 873 (Rsync), obwohl ich die 2 Ports auf Master und Member in firewall freigegeben habe.

Den MTU Wert habe ich auch auf beiden Seiten überprüft, 1500 war eingestellt, mit dem gabs Probleme, habe es auf 1414 (1386 + 20 IP header + 8 ICMP header) angepasst.

nslookup funktioniert auf dem Master und Member, hier Auszug vom Member:

[quote] # nslookup master.isff.see
Server: 172.16.80.64
Adress: 172.16.80.64#53

Name: master.isff.see
Adress: 172.16.80.64
Name: master.isff.see
Adress: 172.16.79.250
[/quote]

Die IP 172.16.79.250 ist vom zweiten interface für das interne Netz.

Und vom Master:

Über VPN sind 2 FritzBoxen auf verschiedene Standorten verbunden:

Master Seite ist das Netz 172.16.80.0/24
u Member Seite das Netz 172.16.16.0/20

VPN-Status steht auf grün.

Hat noch jemand eine Idee?
Bin für jede Hilfe dankbar.

Beste Grüße
Morimystes

Hm, dieses Sambazeugs geht manchmal über mein Verständnis hinaus, zumindest mit dem, was ich versuche, beständig reproduzierbar im Kopf zu behalten.
Dieses [quote]
Bad SMB2 signature for message
[/quote]
taucht zumindest in http://forge.univention.org/bugzilla/show_bug.cgi?id=44122 auf. Der Kontext ist zwar anders aber vielleicht hat es ja wirklich was mit dem dort verlinkten Bug zu tun.

Hmmmmm …

haben denn beide Server den gleichen Versionsstand ?
Habe oben in den jetzigen Beiträgen dazu nichts gefunden.

Was sagt denn
smbd --version
auf Master und Backup ?

Habe Befehle aus dem Bug-Artikel in http://forge.univention.org/bugzilla/show_bug.cgi?id=44122

ausgeführt und danach die 2 Join-skripte, kein Erfolg, wieder die gleiche Fehlermeldungen wie in meinem letzen Post.

Ja, haben sie. Beide

Habe in einem alten Post UCS 3.0.2 DC Backup join Fehler
den Befehl

gefunden, der spuckt folgendes aus:

Was heißt das?

Beste Grüße
Morimystes

Ich würde jetzt, um hier voranzukommen, den Member zurückbringen und versuchen vor Ort zu joinen (ggf. nach Neuinstallation). Ich sehe das nicht zu sinnvoll an, aus alten Threads (Version 3.0-2…) Befehle zu suchen und auszuführen.

Was muss mindestens funktionieren?

  1. Join eines Servers in den master wenn beide am gleichen Standort sind -> um sicher zu gehen dass überhaupt ein Server gejoint werden kann
  2. Netzwerk zwischen den Standorten IP und DNS Auflösung
  3. Kommunikation zwischen den Servern während des Joins
  4. Join des memberservers
  5. Kommunikation nach dem Join

Das ist aufeinander aufbauend und erst wenn bei dem vorhergehenden Punkten ein Haken gesetzt wird, kann man sich dem nächsten Schritt annehmen. Wo kann man denn jetzt schon alles Haken dran setzen?

Bei Punkten 1 bis 3 kann man ein Haken setzen.
Der Memberserver ist der Domäne (über VPN zwischen den zwei Standorten) beigetreten, alle Join-Skripte wurden erfolgreich ausgeführt, bis auf 2:

Ich werde aber morgen den Memberserver platt machen, nach Standort A tragen, dort installieren und versuchen der Domäne beizutreten. Das zieht sich schon Monate und keine Lösung in Sicht, mal sehen, ob ein kompletter Neuversuch am gleichen Standort klappt.

Ich habe den Masterserver (den mein Vorgänger installiert und konfiguriert hat und einfach verschwand, ohne Dokumentationen oder ähnliches dazulassen) in Verdacht, weil da die Zeitsynchronisation und Benutzeranmeldung eine Weile rumgespinnt haben. Benutzeranmeldung funktioniert jetzt dank Ihnen, Herr Hansen, habe SSL ausgeschaltet, aber Zeit macht immernoch Streß.

Beste Grüße
Morimystes

Sehr gut, gern auf dem Laufenden halten. Die Zeitsynchronisation des masters können wir im Anschluss an den memberserverfall dann auch anschauen.

Mastodon