Traceback (most recent call last):
File “/usr/sbin/univention-adsearch”, line 202, in
filter += (j[0] + “=” + j[1])
IndexError: list index out of range
hatte auch das modul gerade neu installiert
ich befürchte es hängt an der ad erweiterung vom kerio
Warum die Vermutung? Gibt’s Gemeinsamkeiten der funktionierenden oder der nicht funktionierenden Benutzer bzgl. dieser Kerio-Attribute/-Einstellungen?
ne leider nicht. bin völlig planlos
Ich momentan leider auch.
Bitte probieren Sie eine Re-Initialisierung des AD-Connectors aus. Einfach den dort aufgeführten Schritten folgen und anschließend das Log /var/log/univention/connector.log (nicht die connector-status.log, die ist uninteressant) hier posten.
Schade 
Können Sie bitte die Ausgabe des folgenden Befehls posten:
univention-adsearch 'objectclass=user' dn,usncreated,usnchanged
root@ucs:~# univention-adsearch ‘objectclass=user’ dn,usncreated,usnchenged
univention-adsearch
filter: objectclass=user
DN: CN=S1,CN=Computers,DC=Pandora,DC=local
uSNCreated: 11956
DN: CN=Administrator,CN=Users,DC=Pandora,DC=local
uSNCreated: 11949
DN: CN=S2,OU=Domain Controllers,DC=Pandora,DC=local
uSNCreated: 11960
DN: CN=Gast,CN=Users,DC=Pandora,DC=local
uSNCreated: 11937
DN: CN=IUSR_S1,CN=Users,DC=Pandora,DC=local
uSNCreated: 12440
DN: CN=krbtgt,CN=Users,DC=Pandora,DC=local
uSNCreated: 11938
DN: CN=Björn Hoffmann,OU=SBSUsers,OU=Users,OU=MyBusiness,DC=Pandora,DC=local
uSNCreated: 12550
DN: CN=Ortrud Gross,OU=SBSUsers,OU=Users,OU=MyBusiness,DC=Pandora,DC=local
uSNCreated: 12519
DN: CN=Alexandra Settan,OU=SBSUsers,OU=Users,OU=MyBusiness,DC=Pandora,DC=local
uSNCreated: 12612
DN: CN=User Template,OU=SBSUsers,OU=Users,OU=MyBusiness,DC=Pandora,DC=local
DN: CN=IWAM_S1,CN=Users,DC=Pandora,DC=local
uSNCreated: 12441
DN: CN=Mobile User Template\0ADEL:b4334a16-8325-4627-8a6b-c02b4214020e,CN=Deleted Objects,DC=Pandora,DC=local
DN: CN=Aushilfe\0ADEL:fd22e1d4-59fa-4b47-8e1d-c8e9d570d9f9,CN=Deleted Objects,DC=Pandora,DC=local
DN: CN=Maria Matlok,OU=SBSUsers,OU=Users,OU=MyBusiness,DC=Pandora,DC=local
DN: CN=Thomas Matlok,OU=SBSUsers,OU=Users,OU=MyBusiness,DC=Pandora,DC=local
DN: CN=MK01,OU=SBSComputers,OU=Computers,OU=MyBusiness,DC=Pandora,DC=local
uSNCreated: 12499
DN: CN=CB01,OU=SBSComputers,OU=Computers,OU=MyBusiness,DC=Pandora,DC=local
uSNCreated: 12500
DN: CN=Kathrin Bergmann,OU=SBSUsers,OU=Users,OU=MyBusiness,DC=Pandora,DC=local
DN: CN=MM01,OU=SBSComputers,OU=Computers,OU=MyBusiness,DC=Pandora,DC=local
uSNCreated: 12520
DN: CN=BH01,OU=SBSComputers,OU=Computers,OU=MyBusiness,DC=Pandora,DC=local
uSNCreated: 12527
DN: CN=as01,OU=SBSComputers,OU=Computers,OU=MyBusiness,DC=Pandora,DC=local
uSNCreated: 12609
DN: CN=MiniMac,OU=SBSComputers,OU=Computers,OU=MyBusiness,DC=Pandora,DC=local
uSNCreated: 12624
DN: CN=KATHRINBERGMA01,OU=SBSComputers,OU=Computers,OU=MyBusiness,DC=Pandora,DC=local
uSNCreated: 12688
DN: CN=MacBj,OU=SBSComputers,OU=Computers,OU=MyBusiness,DC=Pandora,DC=local
uSNCreated: 12689
DN: CN=tm01,OU=SBSComputers,OU=Computers,OU=MyBusiness,DC=Pandora,DC=local
uSNCreated: 12699
DN: CN=Dell01,OU=SBSComputers,OU=Computers,OU=MyBusiness,DC=Pandora,DC=local
uSNCreated: 12706
DN: CN=PR-01,OU=SBSComputers,OU=Computers,OU=MyBusiness,DC=Pandora,DC=local
uSNCreated: 12715
DN: CN=Christian Zengel\0ADEL:546a5486-eb01-4cf5-8e27-aa88841edf44,CN=Deleted Objects,DC=Pandora,DC=local
DN: CN=s3,CN=Computers,DC=Pandora,DC=local
uSNCreated: 377878
DN: CN=KATHRIN-PC,CN=Computers,DC=Pandora,DC=local
uSNCreated: 447215
DN: CN=Ortrud-PC,CN=Computers,DC=Pandora,DC=local
uSNCreated: 447409
DN: CN=ALEXANDRA,CN=Computers,DC=Pandora,DC=local
uSNCreated: 447451
DN: CN=Hannah hs. Staudt,OU=SBSUsers,OU=Users,OU=MyBusiness,DC=Pandora,DC=local
uSNCreated: 448580
DN: CN=MAC22VMWARE,CN=Computers,DC=Pandora,DC=local
uSNCreated: 461390
DN: CN=Reinhild Paquee,OU=SBSUsers,OU=Users,OU=MyBusiness,DC=Pandora,DC=local
DN: CN=DESKTOP-GNESREK,CN=Computers,DC=Pandora,DC=local
uSNCreated: 5578954
DN: CN=X1OG,CN=Computers,DC=Pandora,DC=local
uSNCreated: 6600555
DN: CN=X1TM,CN=Computers,DC=Pandora,DC=local
uSNCreated: 6634188
DN: CN=ucs\0ADEL:2a1a2640-a22a-4d92-8109-9553deac072f,CN=Deleted Objects,DC=Pandora,DC=local
uSNCreated: 6714851
DN: CN=Test\0ADEL:09e37c02-7a81-4e6a-a84c-d9860a4984c6,CN=Deleted Objects,DC=Pandora,DC=local
DN: CN=ucs,CN=Computers,DC=Pandora,DC=local
uSNCreated: 6716714
DN: CN=Test Test,OU=SBSUsers,OU=Users,OU=MyBusiness,DC=Pandora,DC=local
uSNCreated: 6717619
results: 42
root@ucs:~#
die hervorgehobenen Benutzer werden im UCS nicht angezeigt
Ich glaube, Sie haben sich beim Abschreiben vertippt, das eine Attribut heißt usnchanged, Sie schrieben aber usnchenged (e anstelle von a), daher taucht das Attribut nirgends in der Ausgabe auf.
Sehe ich das richtig, dass die ganzen hervorgehobenen User kein Attribut usncreated haben? Falls nicht, gehe ich ganz stark davon aus, dass ihnen auch das Attribut usnchanged fehlt. Da der AD-Connector dieses Attribut immer in seinem Suchfilter hat, werden keine Benutzer zurückgeliefert, bei denen das Attribut nicht existiert.
In einem Active Directory wird das Attribut usnchanged immer dann gesetzt, wenn das Objekt vom System verändert wird. Wenn es also bei gewissen Benutzern nicht existiert, so kann ich mir nicht erklären, warum es dort nicht existiert.
Nehmen Sie sich doch mal einen der Benutzer, z.B. CN=Reinhild Paquee, modifizieren Sie sie, und führen Sie anschließend das hier aus & pasten Sie die Ausgabe:
univention-adsearch 'CN=Reinhild Paquee' dn,usncreated,usnchanged
hab ihren Vor- und Nachnamen, Beschreibung und E-Mail geändert
root@ucs:~# univention-adsearch ‘CN=Reinhild Paquee’ dn,usncreated,usnchanged
univention-adsearch
filter: CN=Reinhild Paquee
DN: CN=Reinhild Paquee,OU=SBSUsers,OU=Users,OU=MyBusiness,DC=Pandora,DC=local
results: 1
hab auch mal den CN geändert was nichts gebracht hat
root@ucs:~# univention-adsearch ‘CN=Reinhild Paqu’ dn,usncreated,usnchanged
univention-adsearch
filter: CN=Reinhild Paqu
DN: CN=Reinhild Paqu,OU=SBSUsers,OU=Users,OU=MyBusiness,DC=Pandora,DC=local
results: 1
Interessant. Das ist dann ein AD-seitiges Problem und hat erst mal nichts mit Univention zu tun. Der AD-Connector benötigt nun mal dieses Standardfeld um festzustellen, welche Objekte sich im AD geändert haben und daher synchronisiert werden müssen. Solange diese Attribute nicht vorhanden sind, wird das also nicht funktionieren.
Ich denke das liegt am AD Schema von Kerio Connect
Pablo setz mal ne Ucs VM bei den Offenbachern oder Versicherungsmakler auf obs da auch so ist.
Dann haben wir Gewissheit
Trotzdem müssen wir das hinbekommen
Ginge ein Takeover???
Ich weiß nicht, mit was für Filtern bei einem Takeover gearbeitet wird, um die Benutzer auszulesen. Wenn einfach nur mit objectClass=user gefiltert wird (also kein expliziter Filter auf uSNCreated oder uSNChanged), dann könnte es funktionieren. Da beim Takeover die Accounts nur einmalig ausgelesen werden sollen und es auf den Änderungszeitpunkt nicht ankommt, könnte ich mir gut vorstellen, dass es funktioniert.
Sinnvollerweise sollten Sie es testen, indem Sie den AD-Server clonen und in einer Testumgebung (netzwerktechnisch vom Produktivnetz getrennt!) das Takeover ausführen. Geht natürlich nur dann so einfach, wenn der AD-Server eine virtuelle Maschine ist.
Genau! Aber vorm TO kommt eine Zusammenfassung!
Richtig, aber das ersetzt trotzdem keinen echten Test, um zu verifizieren, dass die Accounts nicht nur gefunden, sondern ihre Einstellungen auch richtig übernommen werden. Wenn man bei einem Takeover etwas falsch macht, so kann es schlicht zu Modifikationen des Quell-ADs kommen. Daher ist Experimentieren mit einem Produktivsystem wirklich nicht angesagt.
Natürlich kann man die Zusammenfassung vor dem Takeover (auch hier ist der UCS-Server bereits ins AD gejoint, sprich da wurde das Quell-AD bereits verändert) als Anhaltspunkt nehmen. Aber Ihre Frage war »Ginge ein Takeover?«, und um das wirklich zu beantworten, hilft nur ein waschechter Test, vor allem, da es beim AD-Connector bereits Probleme gab. Der AD-Connector ist nämlich die gleiche Softwarekomponente, die das Auslesen der Accounts beim Takeover durchführt, wenn ich mich nicht irre, und meine Hoffnung ist schlicht, dass hier aber der Filter nicht zum Einsatz kommt.
Das Entscheidende ist das Wort »Hoffnung«. Auch daher: Gewissheit verschafft nur ein Test.
wir reden von 5-10 accounts
wenn alle stricke reissen müssen wir eine neue ad aufsetzen und den alten server in die domäne nehmen
die workstation profile können wir dann mit einem tool übernehmen.
macht halt alles mehr arbeit
problem ist dass wir noch zwei kunden haben mit deutlich mehr postfächern
dieser kunde muss zwischen 3. und 14.9 umgestellt werden, da sonst kerio ausläuft
problem hier ist dann dass kein active sync mehr geht, also keiner der emailclients mehr verbinden wird:frowning:
In einem anderen Thema hat jemand das gleiche Problem. Bei ihm hat es sich in Luft aufgelöst, als er dann die Synchronisation von Passwort-Hashes aktiviert hat. Ich weiß zwar nicht, warum das geholfen hat, aber vielleicht hilft es ja auch bei Ihnen.
Habs gestern getestet und es funktioniert auch bei uns
ja 1000 dank. das nimmt mir den druck für die migration. tschö keriööö
Das ist ein Rechte-Problem im AD (Der Computer-Account des UCS im AD hat keine Rechte auf usnChanged usw.) und kann wie folgt gelöst werden:
Active-Dierctory-Benutzer und Gruppen Verwaltung öffnen
Rechts-Klick auf die Domäne, z.B. example.local
Zu ausgewählte Benutzer und Gruppen den UCS Rechner hinzufügen (im Auswahldialog unter Objekttypen auch Computer anhaken)
Die Aufgabe “Liest alle Benutzerinformationen” zuweisen
Anschließend muss wahrscheinlich der AD Connector einen kompletten Resync machen.
Das habe ich Analog zu dem Artikel S4 Connector neu initialisieren gemacht. Der Artikel beschreibt den S4 Connector, habe das entsprechend auf den ad connector angewandt.