Nach Takeover: Keine Replizierung von DC Master

UCS - Univention Corporate Server
,
#1

Seit dem Takeover habe ich vereinzelt das Problem, dass sich Benutzer morgens nicht anmelden können. Es kommt die Meldung, das der Benutzername/Kennwort (Windows 7) falsch ist.

Ich habe mich dann als lokaler Admin angemeldet und bei den Netzwerkeinstellungen geschaut. Die IP wurde über DHCP verteilt (ich habe für die Clients “feste” IPs in der Rechnerkonfiguration festgelegt, damit ich sie per Remote steuern kann).

Wenn der Rechner dann ein paar Minuten steht und nochmal neugestartet wird, dann ist meistens eine Anmeldung möglich.

Es betrifft unterschiedliche Clients, daher schließe ich aus, das es eine Sache vom Client ist, sondern eher vom UCS beim DHCP.

Welche Tipps zur Ursachenfindung gibts es für das Problem?

#2

Ich habe festgestellt, dass ich, bei Rechnern, die sich nicht mehr anmelden können, bei der Namensauflösung der Domäne (ping meinedomaene.lan) eine Antwort vom 2. Domaincontroller bekomme (backup DC).

Kann es sein, dass mir da etwas noch fehlt, was ich installieren muss? Oder muss man noch was am Samba einstellen, damit das ganze passt? Kann es sein, dass meine Kopie des LDAP fehlt oder nicht gesynct wurde?

DomainController:

UCS: 4.1-4 errata410
App Center compatibility: 4
Installed: dhcp-server=10.0.1 fetchmail=6.3.21 kde=4 kopano-core=8.1.1.10-8.1-2 kopano-webapp=3.2.0.335-19.1 pkgdb=9 samba4=4.5 squid=3.1 uvmm=5 z-push-kopano=2.3.5

(Backup)DomainController:

UCS: 4.1-4 errata410
App Center compatibility: 4
Installed: agorumcore-pro=7.5.5-3415 kde=4 kvm=1.1.2 samba4=4.5

Auf meinem Windows2008R2 Printserver wird folgende Meldung ausgegeben:

Das Sicherheitssystem konnte keine sichere Verbindung mit dem Server ldap/ucs100092.laprinta.lan/laprinta.lan@LAPRINTA.LAN herstellen. Es war kein Authentifizierungsprotokoll verfügbar.

Ich denke dass das alles irgendwie zusammen hängt und daher die Instabilität im Netzwerk verursacht

#3

Weitere nachforschungen haben ergeben, dass der Replikations-Mechanismus nicht läuft.

Auf dem Master-DC habe ich folgendes Ergebnis

samba-tool drs showrepl
Default-First-Site-Name\UCS100091
DSA Options: 0x00000001
DSA object GUID: e2ab1f68-a3ff-4fa4-b27f-466fcc866343
DSA invocationId: 1ed677d7-0745-4509-a6a1-3802867a5f04

==== INBOUND NEIGHBORS ====

==== OUTBOUND NEIGHBORS ====

==== KCC CONNECTION OBJECTS ====

Auf dem “Backup DC” habe ich:


Default-First-Site-Name\UCS100092
DSA Options: 0x00000001
DSA object GUID: dae920c1-31c5-428f-8f6c-d6287325e491
DSA invocationId: cadd4d28-5f8b-4d2a-a5db-44d5dbfa4b16

==== INBOUND NEIGHBORS ====

DC=ForestDnsZones,DC=laprinta,DC=lan
        Default-First-Site-Name\UCS100091 via RPC
                DSA object GUID: 95d7d79e-c7a2-4da2-8fbd-4a515160f725
                Last attempt @ Tue Apr 25 14:44:37 2017 CEST failed, result 1311 (WERR_NO_LOGON_SERVERS)
                3174 consecutive failure(s).
                Last success @ Fri Apr 14 09:45:21 2017 CEST

DC=DomainDnsZones,DC=laprinta,DC=lan
        Default-First-Site-Name\UCS100091 via RPC
                DSA object GUID: 95d7d79e-c7a2-4da2-8fbd-4a515160f725
                Last attempt @ Tue Apr 25 14:44:38 2017 CEST failed, result 1311 (WERR_NO_LOGON_SERVERS)
                3174 consecutive failure(s).
                Last success @ Fri Apr 14 09:45:21 2017 CEST

....

Wie kann ich die Replizierung jetzt wieder aktivieren, da diese seit dem Tag, wo ich den “alten Server” ausgeschaltet habe, nicht mehr funktioniert

#4

Haben Sie schon versucht, den Backup-DC schlicht neu zu joinen? Beim Join-Vorgang wird das komplette LDAP und auch das komplette Samba-AD vom DC Master bezogen.

#5

Nein, das habe ich noch nicht gemacht, weil ich auch gar nicht weiß, wie ich das machen könnte, ohne meine Daten auf dem Backup-DC zu verlieren bzw. den Master zu “zerstören”.

In Windows hätte ich es mit dem “raus aus der Domäne - rein in die Domäne” versucht. Aber das ist ja hier anders zu beweerstelligen.

Muss ich da dann auch das Computerkonte löschen und neu anlegen?

#6

Das ist unter Univention zum Einen trivial und zum Anderen auch ungefährlich, weil nur die Konfigurationen neu geschrieben und LDAP-Inhalte neu vom Master bezogen werden. Installierte Software, Datenbanken, Dateien im Dateisystem werden dabei nicht angefasst.

Das Rechnerobjekt müssen Sie im Normalfall nicht löschen. Es genügt, auf dem DC Backup den Befehl univention-join als root auszuführen und die Logindaten des Domänen-Administrators einzugeben (Benutzername nur administrator, nicht mydomain\administrator).

#7

Vielen Dank für die Hinweise. Ich habe das erneute Joinen ausgeführt. Das führte zu einem Fehler:

**************************************************************************
* Join failed!                                                           *
* Contact your system administrator                                      *
**************************************************************************
* Message:  FAILED: 96univention-samba4.inst
**************************************************************************

Im join.log ist folgendes zu finden:

Could not find machine account in secrets database: Failed to fetch machine account password from secrets.ldb: Could not find entry to match filter: '(&(flatname=LAPRINTA)($
ERROR(<class 'samba.join.DCJoinException'>): uncaught exception - Can't join, error: Not removing account dns-UCS100092 which looks like a Samba DNS service account but does not have servicePrincipalName=dns/ucs100092.laprinta.lan
  File "/usr/lib/python2.7/dist-packages/samba/netcmd/__init__.py", line 176, in _run
    return self.run(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/samba/netcmd/domain.py", line 659, in run
    keep_existing=keep_existing)
  File "/usr/lib/python2.7/dist-packages/samba/join.py", line 1260, in join_DC
    ctx.do_join()
  File "/usr/lib/python2.7/dist-packages/samba/join.py", line 1154, in do_join
    ctx.cleanup_old_join()
  File "/usr/lib/python2.7/dist-packages/samba/join.py", line 249, in cleanup_old_join
    ctx.cleanup_old_accounts()
  File "/usr/lib/python2.7/dist-packages/samba/join.py", line 242, in cleanup_old_accounts
    ldb.binary_encode("dns/%s" % ctx.dnshostname)))
keeping existing samaccount: CN=ucs100092,OU=Domain Controllers,DC=laprinta,DC=lan
Failed to join against the S4 Connector server ucs100091.
Forest           : laprinta.lan
Domain           : laprinta.lan
Netbios domain   : LAPRINTA

Kann ich den erwähten “Benutzer” einfach löschen und einen erneuten Join starten?

#8

Ist das der Name des Backup-DCs, den Sie gerade neu joinen wollen? Falls ja, so sollten Sie jetzt in der Tat auf dem DC Master alle Vorkommen davon entfernen, sowohl im OpenLDAP als auch im Samba4-AD. Anschließend den Join-Prozess erneut versuchen.

#9

Vielen Dank für die schnelle Unterstützung. Leider ist es zu einem weiterem Fehler gekommen

Configure 98univention-samba4-dns.inst                     failed


**************************************************************************
* Join failed!                                                           *
* Contact your system administrator                                      *
**************************************************************************
* Message:  FAILED: 98univention-samba4-dns.inst
**************************************************************************


Configure 98univention-samba4-dns.inst Tue Apr 25 16:35:09 CEST 2017
2017-04-25 16:35:09.835980122+02:00 (in joinscript_init)
Waiting for RID Pool replication: ...................................................................................................................................................................................
Error no rIDSetReferences replicated for ucs100092
Tue Apr 25 16:39:08 CEST 2017: finish /usr/sbin/univention-join
#10

Da sind Sie nicht der Einzige, der so ein Problem hatte. Anscheinend kann es verschiedene Ursachen dafür geben, siehe Bug 30836.

Laut Bug sollten solche Probleme eigentlich gefixt sein, und die von Ihnen angegebene Versionsnummer sollte den Bugfix auch enthalten. Daher kann es entweder sein, dass die Ursache eine andere aber die Symptome dieselben sind, oder aber dass der Bugfix doch nicht funktioniert hat.

Wie im Bugreport vermerkt, würde ich nun den folgenen Workaround versuchen:

  1. Den DC Backup einmal rebooten
  2. Auf dem DC Backup die Join-Scripte mittels Aufruf von univention-run-join-scripts manuell ausführen
  3. Falls die alle durchgelaufen sind: Gratulation, Ihr DC Backup sollte nun funktionieren
#11

Danke für den Link. Ich habe die empfohlenen Schritte ausgeführt, die aber zu dem gleichen Ergebiss führen.

Running 98univention-samba4-dns.inst                       failed (exitcode: 1)


RUNNING 98univention-pkgdb-tools.inst
EXITCODE=already_executed
RUNNING 98univention-samba4-dns.inst
2017-04-26 08:33:20.635503212+02:00 (in joinscript_init)
Waiting for RID Pool replication: ...................................................................................................................................................................$
Error no rIDSetReferences replicated for ucs100092
EXITCODE=1

Mi 26. Apr 08:37:18 CEST 2017
univention-run-join-scripts finished

Welche Möglichkeit habe ich jetzt noch, diese Replikation in Gang zu bekommen bzw. welche Ursache könnte es noch sein? Benötigen sie einen ausführlichen Log des Joins um evtl. vorher auftretende Ereignisse zu begutachten?

#12

Danke für’s join.log, aber das zeigt auch keine offensichtliche Ursache. Ich habe noch weiter gegooglet, und die bisherigen Fälle (Einträge im Bugzilla), in denen das auftrat, waren alle recht vertrackt. Ich denke nicht, dass das im Rahmen eines kostenlosen Supportforums geklärt werden kann, und empfehle, dafür einen Supportcase bei Univention selber zu eröffnen. Das kostet natürlich Geld, aber da bekommen Sie auch diejenigen mit dem tiefsten Wissen rund um das Thema.

#13

Vielen Dank für die Unterstützung. Ich denke auch, dass es hier irgendwie mit dem Takeover und der früheren (Zentyal)Installation zusammenhängt und das jetzt Informationen im AD sind, die “falsch” oder “nicht mehr benötigt” werden.

Da wir uns aktuell keinen Support mit Replikation “leisten” können (1.200+ €), die Frage: Wie bekomme ich den Rechner jetzt als “Member”-Server ohne DC. Einfach die “AD”-Anwendung auf dem Backup-DC löschen? Wie “bereinige” ich das meine Domäne dann, damit ich eine falschen Verweise auf den Backup-DC mehr übrig habe?

#14

Öff, gute Frage. Ich würde einen Rollenwechsel eines Servers nicht empfehlen und statt dessen zu einer Neuinstallation & dem Umzug der vorhandenen Daten/Dienste raten.

Falls Sie’s trotzdem probieren wollen, so ohne Garantie:

  1. Zuerst deinstallieren Sie vom DC Backup alles, was mit Samba bzw. Active Directory zu tun hat.
  2. Als nächstes entfernen Sie aus dem DC Master alle Verweise auf den Host im LDAP und im Samba-AD.
  3. Weiterhin entfernen SIe das Paket univention-server-backup und installieren statt dessen univention-server-member.
  4. Setzen Sie nun die UCR-Variable server/role auf memberserver.
  5. Als Letztes joinen Sie den DC Backup erneut und hoffen, dass das genügt.

Sie werden dann trotzdem Überreste der Backup-Funktionalität auf dem System haben (z.B. vermute ich, dass die SSL-Zertifikate weiterhin dann herumliegen, und es werden bestimmt einige Pakete installiert sein, die man auf einem DC Backup benötigt, nicht aber auf einem Member Server). Ob das in Summe gut funktioniert, kann ich nicht sagen, und supportet ist das erst recht nicht.

#15

Hmm, das hört sich ja nicht “berauschend” an :wink:

Mit “Neuinstallation & dem Umzug” meinten die bestimmt nur das, was auf dem Backup-DC hinterlegt ist oder meinten sie die gesamte Infrastruktur?

Sollte ich bei der Neuinstallation dann es nochmal versuchen als “BackupDC” oder dann nur als “Member”`? Ein späterer Rollenwechsel ist ja nicht empfohlen - also auch nicht von “Member” nach “BackupDC”

Trotzdem muss ich ja die Domäne (auch bei einem Umzug auf ein neues System) irgendwie bereinigen, oder?

Sie sprechen erneut von dem LDAP und dem Samba-AD. Meines Wissens ist das doch das selbe, oder? Wenn nicht, welche Tools setze ich dann am Besten ein, um die jeweilige Datenbank anzusprechen (vielleicht ist da ja noch was, was ich bereinigen sollte)

#16

Beim weiteren forschen bin ich auf folgende Artikel gestoßen:

https://help.univention.com/t/win7-join-klappt-nicht/4001/14
http://sdb.univention.de/content/6/222/en/samba-4-troubleshooting.html?highlight=troubleshooting%20samba%204
sdb.univention.de/content/6/274/en/re_provisioning-samba4-on-a-dc-master.html

Folgendes hat mich auf einen “heiße Spur” gebracht:

samba-tool drs showrepl

Wenn ich das auf dem DC ausführe, dann sieht der Anfang wie folgt aus:

root@ucs100091:~# samba-tool drs showrepl
Default-First-Site-Name\UCS100091
DSA Options: 0x00000001
DSA object GUID: e2ab1f68-a3ff-4fa4-b27f-466fcc866343
DSA invocationId: 1ed677d7-0745-4509-a6a1-3802867a5f04

==== INBOUND NEIGHBORS ====

DC=DomainDnsZones,DC=laprinta,DC=lan
...

Das gleiche auf dem BackupDC ausgeführt:

root@ucs100092:~# samba-tool drs showrepl
SPNEGO(gssapi_krb5) creating NEG_TOKEN_INIT failed: NT_STATUS_NO_LOGON_SERVERS
SPNEGO(gssapi_krb5) creating NEG_TOKEN_INIT failed: NT_STATUS_NO_LOGON_SERVERS
Default-First-Site-Name\UCS100092
DSA Options: 0x00000001
DSA object GUID: c5344c02-9e2e-4d63-9e9b-073a0747827a
DSA invocationId: 203ab781-1ff1-49eb-a0b7-84bb1970d389

==== INBOUND NEIGHBORS ====

DC=DomainDnsZones,DC=laprinta,DC=lan
...

Also habe ich auf dem BackupDC mal mit kinit versucht mich anzumelden und dann mit klist die Meldung ausgeben lassen

root@ucs100092:~# kinit Administrator
Administrator@LAPRINTA.LAN's Password:
kinit: krb5_get_init_creds: unable to reach any KDC in realm LAPRINTA.LAN
root@ucs100092:~# klist
klist: No ticket file: /tmp/krb5cc_0

Könnte ein “Re-Provisioning” auch diesen “Fehler” beheben?

Mit “samba-tool dbcheck --cross-ncs --fix” hatte ich vor dem Rejoinen die 25 Fehler beheben lassen. Nach dem Rejoinen sind jetzt wieder 4 Fehler in der Datenbank

Außerdem kommt es auf dem DC zu folgender Ausgabe:

root@ucs100091:~# univention-s4connector-list-rejected

UCS rejected


S4 rejected

    1:    S4 DN: DC=@,DC=laprinta.lan,CN=MicrosoftDNS,DC=DomainDnsZones,DC=laprinta,DC=lan
         UCS DN: zonename=laprinta.lan,cn=dns,dc=laprinta,dc=lan

        last synced USN: 6948

Und das dazugehörige Log besagt:

26.04.2017 16:13:43,127 LDAP        (PROCESS): sync to ucs: Resync rejected dn: DC=@,DC=laprinta.lan,CN=MicrosoftDNS,DC=DomainDnsZones,DC=laprinta,DC=lan
26.04.2017 16:13:43,133 LDAP        (PROCESS): sync to ucs:   [           dns] [    modify] zonename=laprinta.lan,cn=dns,dc=laprinta,dc=lan
26.04.2017 16:13:43,137 LDAP        (ERROR  ): Unknown Exception during sync_to_ucs
26.04.2017 16:13:43,137 LDAP        (ERROR  ): Traceback (most recent call last):
  File "/usr/lib/pymodules/python2.7/univention/s4connector/__init__.py", line 1472, in sync_to_ucs
    result = self.property[property_type].ucs_sync_function(self, property_type, object)
  File "/usr/lib/pymodules/python2.7/univention/s4connector/s4/dns.py", line 1638, in con2ucs
    ucs_host_record_create(s4connector, object)
  File "/usr/lib/pymodules/python2.7/univention/s4connector/s4/dns.py", line 975, in ucs_host_record_create
    newRecord = univention.admin.handlers.dns.host_record.object(None, s4connector.lo, position=None, dn=searchResult[0][0], superordinate=superordinate, attributes=[], update_zone=False)
  File "/usr/lib/pymodules/python2.7/univention/admin/handlers/dns/host_record.py", line 155, in __init__
    univention.admin.handlers.simpleLdap.__init__(self, co, lo, position, dn, superordinate, attributes=attributes)
  File "/usr/lib/pymodules/python2.7/univention/admin/handlers/__init__.py", line 592, in __init__
    self._validate_superordinate()
  File "/usr/lib/pymodules/python2.7/univention/admin/handlers/__init__.py", line 623, in _validate_superordinate
    raise univention.admin.uexceptions.insufficientInformation(_('The DN must be underneath of the superordinate.'))
insufficientInformation: The DN must be underneath of the superordinate.
Tool zum validieren des DC
Nach Takeover: kinit: krb5_get_init_creds: unable to reach any KDC in realm
#17

Ihr Samba auf dem DC Backup ist im aktuellen Zustand nicht vollständig aufgesetzt. Daher sind sämtliche Ergebnisse, die Sie momentan auf dem DC Backup mit Samba-Tools ermitteln unzuverlässig und sollten komplett ignoriert werden. Das führt nur auf falsche Fährten. Auch die Kerberos-Meldungen sind falsche Fährten, weil Kerberos das lokale Samba nutzt, das ja nun schlicht nicht vollständig korrekt aufgesetzt wurde.

Sie sprechen erneut von dem LDAP und dem Samba-AD. Meines Wissens ist das doch das selbe, oder?

Nein. Auf einem UCS-System laufen ein bis zwei LDAP-Verzeichnisse:

  1. Das OpenLDAP auf Port 7389, das immer da ist, auch wenn kein AD installiert ist. Dies ist die primäre Datenquelle. Die Univention Management Console greift auf dieses LDAP zu. Alle Linux-Dienste, die auf ein LDAP zugreifen, greifen vorkonfiguriert auf dieses LDAP zu.
  2. Wenn Samba mit AD-Funktionalität installiert ist, so läuft ein zweites, von Samba selber gestelltes LDAP-Verzeichnis, dieses auf dem Standard-LDAP-Port 389.

Zwischen beiden Verzeichnissen gibt es eine bidirektionale Synchronisation, die vom Programm univention-s4connector implementiert wird.

Sie können beide Verzeichnisse durchsuchen. Dazu gibt es Helfertools, die einem die Verbindungsparameter bereits vorbelegen:

  1. univention-ldapsearch durchsucht das OpenLDAP auf Port 7389.
  2. univention-s4search durchsucht das Samba-AD-LDAP

Darauf aufbauen gibt’s zwei Tools, die die Ausgabe lesbarer machen und als Pipe hinter die oben genannten Tools gehängt werden können:

  • ldapsearch-wrapper macht die Zeilenumbrüche langer Zeilen wieder rückgängig
  • ldapsearch-decode64 wandelt Base64-encodierte Daten wieder in Binärdaten um. Das betrifft u.a. deutsche Umlaute, die decodiert wieder gut lesbar sind, aber auch echte Binärdaten wie in DNS-Einträgen im Samba-AD-LDAP, die decodiert einfach nur Zeichenmüll sind.

Bearbeiten geht mit Standard-LDAP-Tools. Wenn ich von “bearbeiten” spreche, meine ich meist:

  • dass Sie zuerst die Univention Management Console nutzen, um offensichtliche Einträge zu entfernen, z.B. Rechnerobjekte, DNS-Einträge etc.
  • mit univention-ldapsearch prüfen, ob noch irgendwo Einträge vorkommen, z.B. univention-ldapsearch | less und dann in less nach dem Rechnernamen suchen
  • wenn noch Einträge vorhanden sind, dann mit einem geeigneten Tool entfernen (das kann z.B. der in der Management Console eingebaute Teil »LDAP-Verzeichnis« sein, externe Tools wie phpLDAPAdmin oder auch Kommandozeilenutilities wie ldapvi oder die immer vorhandenen ldapmodify / ldapdelete)
  • dann die Synchronisation durch den S4-Connector abwarten, dazu die Logdatei /var/log/univention/connector-s4.log beobachten
  • im Samba-AD-LDAP mit univention-s4search auf Restbestände prüfen analog zur Prüfung mit univention-ldapsearch
  • Restbestände im Samba-AD-LDAP entfernen, auch hier wieder mit Tools wie den Windows Remote Server Administration Toolkit, phpLDAPAdmin oder Kommandozeilenutilities wie ldapvi oder ldbedit

Ein Re-Provisioning findet immer auf dem Master statt. Ob das in irgend einer Form etwas helfen könnte, ist ein Blick in die Glaskugel, und die sagt: »ein klares vielleicht, vielleicht auch nicht«. Sie sollten sich bewusst sein, dass bei einem Re-Provisioning Daten verloren gehen, weil schlicht nicht alle Felder zwischen OpenLDAP und dem Samba LDAP synchronisiert werden. Da beim Re-Provisioning das Samba LDAP komplett weggeworfen wird, gehen dann entsprechend diejenigen Felder verloren, die halt nicht synchronisiert werden. In vielen Situationen ist das absolut zu verschmerzen und nicht kritisch, aber es ist nichts, was ich mal eben so machen würde.

Falls Sie damit herumexperimentieren wollen, so würde ich dringend dazu raten:

  • vor dem Experiment einen Snapshot aller UCS-Systeme im ausgeschalteten Zustand zu machen (sofern Virtualisierung vorhanden, was sie immer sein sollte),
  • auf dem DC Backup Samba anzuhalten,
  • alle Bestände des DC Backup aus beiden LDAPs auf dem DC Master zu entfernen,
  • dann das Samba auf dem DC-Master neu zu provisionieren,
  • gut zu testen, ob generell noch alles funktioniert in der Domäne,
  • anschließend den DC Backup erneut zu joinen.

Mit “Neuinstallation & dem Umzug” meinten die bestimmt nur das, was auf dem Backup-DC hinterlegt ist oder meinten sie die gesamte Infrastruktur?

Definitiv nur den DC Backup neu aufsetzen und vom bisherigen DC Backup die Nutzdaten (Datenbanken, Dateien, angepasste Konfigurationen) übernehmen. Ich meinte nicht, die komplette Infrastruktur neu aufzusetzen.

2 Likes
#18

Habe am Wochenende das “Reprovisinig” gewagt und habe einen Teilerfolg erzielen können

So sind jetzt die Datenbanken (OpenLDAP und Samba) konsistent und ich habe beim s4connector keine Rejects mehr

root@ucs100091:~# univention-s4connector-list-rejected

UCS rejected


S4 rejected


There may be no rejected DNs if the connector is in progress, to be
sure stop the connector before running this script.


        last synced USN: 4411

Ich habe dann alle Verweise auf den alten DC (es war ja ein Takeover) entfernt. Auch alle vermeintlichen Benutzer, die den alten Servernamen im Usernamen hatten. Auch Benutzer die ich in der alten Domäne hatte und bisher noch nicht wieder verwendet habe, habe ich gelöscht.

Dann habe ich den BackupDC aus der Geräteliste entfernt und dann einen erneuten rejoin versucht. Leider ist dabei wieder der Fehler aufgetreten mit der RID Pool Replikation

Configure 98univention-samba4-dns.inst Sat Apr 29 22:43:02 CEST 2017
2017-04-29 22:43:02.556631299+02:00 (in joinscript_init)
Waiting for RID Pool replication: ...................................................................................................................................................................................
Error no rIDSetReferences replicated for ucs100092

Vielleicht wäre es möglich, mir noch ein paar Hintergrundinfos zum Thema “RID Pool” zugeben, damit ich weitere Überlegungen und Tests machen kann, damit ich das Thema endlich mal abschließen kann und die Auswirkung des Fehlers (Benutzer können sich manchmal nicht am Client anmelden, weil Benutzername und Kennwort falsch) behoben wird.

Frage: Wäre es ein Workaround, wenn ich in der /etc/krb5.conf des BackupDC statt 127.0.0.1 die IP Adresse des DC eintrage, damit das Symtome während der Hauptarbeitszeit verschwindet, bis ich die Ursache des Fehlers gefunden habe?

#19

Ich rate ganz dringend davon ab, in beliebigen Dateien einfach so herumzuändern. Ich kann nicht absehen, was so eine Änderung bewirken würde, und Sie letztlich auch nicht, wie ich Ihren Worten entnehme. All solche Änderungen führen nur dazu, dass Sie Ihr System immer weiter verändern und vom Standard abweichen. Das wird sich irgendwann rächen, z.B. wenn plötzlich Sachen nicht mehr funktionieren oder Updates fehlschlagen.

Ich rate weiterhin dazu, den DC Backup komplett neu zu installieren bzw. nur einen normalen Memberserver anstelle eines DC Backups einzusetzen. Ein Memberserver ohne Samba muss z.B. den RID-Pool gar nicht synchronisieren, denn das passiert nur auf Hosts, auf denen auch Samba installiert ist (auf einem DC Backup muss Samba installiert sein, auf Memberservern ist es hingegen optional und sollte nur installiert werden, wenn Dienste wie Freigaben auf dem Memberserver angelegt werden sollen).

Anmeldung morgens nicht möglich
#20

https://help.univention.com/t/kinit-unable-to-reach-any-kdc-in-realm/2757/2

Ursache war schließlich: Weil die Variabel samba/interfaces/bindonly = yes und die Variabel samba/interfaces = “eth0” gesetzt wird (durch die Installation von Agorum oder KVM, hört samba nicht mehr auf das Interface lo. Deshalb schlägt die Kommunikation mit Keberos fehl.

ucr set samba/interfaces="$(ucr get samba/interfaces) lo"

Danach einen Neustart und es kommt zu keiner erkennbaren Fehlermeldung mehr

Mastodon