AD-Connector synchronisiert die mailPrimaryAddress nicht mehr

openldap
kopano
ad-connection
ucs-4-2

#1

Hallo,

gestern habe ich endlich den Schritt gewagt von Zarafa auf Kopano umzustellen.
Owncloud und Zarafa habe ich deinstalliert, UCS Update auf 4.2-0 errata26 durchgeführt und danach
Owncloud 10 und Kopano installiert. Soweit lief alles super.

Jetzt wollte ich kontrollieren, ob die User schon als Kopano User festgelegt sind und stellte fest, das die
Primäre E-Mail-Adressen nicht mehr eingetragen sind.
Hat jemand eine Idee, was da schiefgelaufen ist?

Gegoogelt habe ich, das es helfen könnte die Variable
directory/manager/web/modules/users/user/properties/mailPrimaryAddress/syntax auf string
zu setzen. Das hab ich gemacht, in der Annahme, das ich dann die Adressen manuell nachtragen kann.
Leider ohne Erfolg.

Ich wäre für jeden Tipp dankbar.

Viele Grüße
Alexander Altenhoff


#2

Durch einige Recherchen, habe ich folgende Meldungen in der connector.log gefunden
Könnte mein Problem hier liegen?

> 04.06.2017 16:53:36,105 LDAP        (PROCESS): sync to ucs: Resync rejected dn: CN=Alexander Altenhoff,OU=Admin,OU=Benutzer,DC=myDomain,DC=local
04.06.2017 16:53:36,107 LDAP        (WARNING): encode_ad_object: encode attrib terminalServer failed, ignored!
04.06.2017 16:53:36,111 LDAP        (PROCESS): sync to ucs:   [          user] [    modify] uid=altenhoff,ou=admin,ou=benutzer,dc=myDomain,dc=local
04.06.2017 16:53:36,121 LDAP        (WARNING): encode_ad_object: encode attrib terminalServer failed, ignored!
04.06.2017 16:53:36,121 LDAP        (ERROR  ): failed in post_con_modify_functions
04.06.2017 16:53:36,121 LDAP        (ERROR  ): Traceback (most recent call last):
  File "/usr/lib/pymodules/python2.7/univention/connector/__init__.py", line 1326, in sync_to_ucs
    f(self, property_type, object)
  File "/usr/lib/pymodules/python2.7/univention/connector/ad/password.py", line 311, in password_sync_kinit
    object = connector._object_mapping(key, ucs_object, 'ucs')
  File "/usr/lib/pymodules/python2.7/univention/connector/__init__.py", line 1660, in _object_mapping
    object_out['attributes'][self.property[key].post_attributes[attr_key].con_attribute] = self.property[key].post_attributes[attr_key].mapping[0](self, key, object)
  File "/usr/lib/pymodules/python2.7/univention/connector/ad/", line 70, in to_proxyAddresses
    mailPrimaryAddress = object['attributes'].get('mailPrimaryAddress', [None])[0]
IndexError: list index out of range

Leider habe ich noch keinen passenden Ansatz gefunden, der dieses Problem beschreibt bzw. behebt.

Gibt es jemanden, der eine Idee hat, was hier passiert ist??

Vielen Dank

Alexander Altenhoff


#3

Kann man die “mailprimaryadress” eventuell manuell setzen?


#4

hm… “mailprimaryadress” müsste die “primäre Mailadresse” sein - ist die bei den Benutzern auch gesetzt? (Prüfung über die UMC am Benutzer)


#5

Vielen Dank für die erste Antwort.

Ja, das ist die primäre Mailadresse. Im Benutzer ist das Feld nach dem Update auf 4.2 leer.
Da ich mit einer AD synchronisiere, sind die Felder gesperrt.
Vor- und Nachname sowie das Passwort werden richtig übernommen.
Da die Mailadresse, die Voraussetzung ist, um dem User die Kopano Berechtigung zu geben
komme ich ohne einen Eintrag nicht weiter.


#6

Ah okay - wenn der UCS in eine AD Domäne integriert ist, erfolgt die Administration über das AD und dessen Tools (RSAT Tools von einem Windows Rechner aus). Dann würde ich dort mal schauen ob die Benutzer eine Mailadresse zugewiesen bekommen haben.


#7

Im Active Directory sind die Mailadressen eingetragen.
In der Version 4.1-4 errata429 ist unter Benutzer bzw. unter Domäne/LDAP-Verzeichnis, das Feld “primäre Mailadresse”
mit der Mailadresse belegt.
Es hat vor dem Update auf 4.2. auch alles soweit funktioniert.
Kann es eventuell ein Datenbankproblem sein?


#8

Hmm, interessant… Vom Quellcode des AD-Connectors her kann ich mir den Traceback allein noch nicht erklären. Liefert folgende LDAP-Suche eine mailadresse?

univention-ldapsearch uid=altenhoff mailPrimaryAddress


#9

univention-ldapsearch uid=altenhoff mailPrimaryAddress
gibt folgendes zurück:

# extended LDIF
#
# LDAPv3
# base <dc=nuesken,dc=local> (default) with scope subtree
# filter: uid=altenhoff
# requesting: mailPrimaryAddress
#

# Altenhoff, Admin, Benutzer, xxxxxxx.local
dn: uid=Altenhoff,ou=Admin,ou=Benutzer,dc=xxxxxx,dc=local

# search result
search: 3
result: 0 Success

# numResponses: 2
# numEntries: 1


#10

Kurze Ergänzung:

Bei univention-ldapsearch uid=altenhoff mailAlternativeAddress bekomme ich auch nichts zurück.
Aber bei univention-ldapsearch uid=altenhoff mail liefert die korrekte Mailadresse.


#11

Hallo,

ein wenig aus Verzweiflung, habe ich den AD-Connector einfach mal deinstalliert.
Leider lassen sich die Mailadressen der Benutzer nach wie vor nicht eintragen.

Die AD Sperre bleibt:
Hinweis: Die Benutzer sind Teil einer Active Directory Domäne.UCS kann nur bestimmte Attribute verändern.

Hat vielleicht noch jemand eine Idee, wie ich die Mailadresse des Users eintragen kann?

Viele Grüße

Alexander Altenhoff


#12

Ich würde den AD Connector wieder installieren und danach die grundsätzlich Funktionalität prüfen und wieder herstellen - eine einfache Deinstallation löst den Join in die AD Domäne nicht auf.

Können Sie mal bitte (nach der Wiederherstellung der Funktion) eine komplette Ausgabe von

univention-ldapsearch uid=altenhoff 
univention-adsearch cn=altenhoff

Hier bitte schauen, dass keine sensiblen Daten aus Versehen übermittelt werden.


#13

adsearch2.txt (65 Bytes)
ldatsearch.txt (2,8 KB)
adsearch.txt (69 Bytes)
ldatsearch2.txt (2,5 KB)

Wie es mir scheint, funktioniert die AD Verbindung überhaupt nicht.
Mittlerweile habe ich die Umstellung wiederholt. jetzt sind nicht alle Benutzer ohne Primary E-Mail,
so das ich z.B. mit meinem User wieder per WebApp auf mein Konto zugreifen kann.
Ändere ich etwas an einem Konto im AD kommt sofort:

26.06.2017 16:01:35,423 LDAP        (WARNING): sync to ucs was not successfull, save rejected
26.06.2017 16:01:35,423 LDAP        (WARNING): object was: CN=Alexander Altenhoff,OU=Admin,OU=Benutzer,DC=maDomain,DC=local

und der “normale” Sync Versuch meldet:

26.06.2017 16:03:15,872 LDAP        (PROCESS): sync to ucs: Resync rejected dn: CN=User2,OU=Auftrag,OU=Benutzer,DC=myDomain,DC=local
26.06.2017 16:03:15,877 LDAP        (PROCESS): sync to ucs:   [          user] [    modify] uid=user2,ou=auftrag,ou=benutzer,dc=myDomain,dc=local
26.06.2017 16:03:15,886 LDAP        (ERROR  ): failed in post_con_modify_functions
26.06.2017 16:03:15,887 LDAP        (ERROR  ): Traceback (most recent call last):
  File "/usr/lib/pymodules/python2.7/univention/connector/__init__.py", line 1323, in sync_to_ucs
    f(self, property_type, object)
  File "/usr/lib/pymodules/python2.7/univention/connector/ad/password.py", line 311, in password_sync_kinit
    object = connector._object_mapping(key, ucs_object, 'ucs')
  File "/usr/lib/pymodules/python2.7/univention/connector/__init__.py", line 1657, in _object_mapping
    object_out['attributes'][self.property[key].post_attributes[attr_key].con_attribute] = self.property[key].post_attributes[attr_key].mapping[0](self, key, object)
  File "/usr/lib/pymodules/python2.7/univention/connector/ad/proxyAddresses.py", line 70, in to_proxyAddresses
    mailPrimaryAddress = object['attributes'].get('mailPrimaryAddress', [None])[0]
IndexError: list index out of range

Passiert etwas mit den Usern, wenn ich den Join zum AD komplett löse?
Geht das nachträglich überhaupt?

Hier noch die Liste meiner Problem:

univention-connector-list-rejected

        UCS rejected

AD rejected

    1:    AD DN: CN=User1,OU=Auftrag,OU=Benutzer,DC=myDomain,DC=local
         UCS DN: uid=User1,ou=auftrag,ou=benutzer,dc=myDomain,dc=local
    2:    AD DN: CN=User3,OU=Innendienst,OU=Benutzer,DC=myDomain,DC=local
         UCS DN: uid=User3,ou=innendienst,ou=benutzer,dc=myDomain,dc=local
    3:    AD DN: CN=User4,OU=Auftrag,OU=Benutzer,DC=myDomain,DC=local
         UCS DN: uid=User4,ou=auftrag,ou=benutzer,dc=myDomain,dc=local
    4:    AD DN: CN=User5,OU=Buchhaltung,OU=Benutzer,DC=myDomain,DC=local
         UCS DN: uid=User5,ou=buchhaltung,ou=benutzer,dc=myDomain,dc=local
    5:    AD DN: CN=User6,OU=Innendienst,OU=Benutzer,DC=myDomain,DC=local
         UCS DN: uid=User6,ou=innendienst,ou=benutzer,dc=myDomain,dc=local
    6:    AD DN: CN=User2,OU=Auftrag,OU=Benutzer,DC=myDomain,DC=local
         UCS DN: uid=User2,ou=auftrag,ou=benutzer,dc=myDomain,dc=local
    7:    AD DN: CN=User7,OU=Produktion,OU=Benutzer,DC=myDomain,DC=local
         UCS DN: uid=User7,ou=produktion,ou=benutzer,dc=myDomain,dc=local
    8:    AD DN: CN=User8,OU=Innendienst,OU=Benutzer,DC=myDomain,DC=local
         UCS DN: uid=User8,ou=innendienst,ou=benutzer,dc=myDomain,dc=local
    9:    AD DN: CN=User9,OU=Auftrag,OU=Benutzer,DC=myDomain,DC=local
         UCS DN: uid=User9,ou=auftrag,ou=benutzer,dc=myDomain,dc=local
   10:    AD DN: CN=User10,OU=Admin,OU=Benutzer,DC=myDomain,DC=local
         UCS DN: uid=User10,ou=admin,ou=benutzer,dc=myDomain,dc=local
   11:    AD DN: CN=Alexander Altenhoff,OU=Admin,OU=Benutzer,DC=myDomain,DC=local
         UCS DN: uid=altenhoff,ou=admin,ou=benutzer,dc=myDomain,dc=local

        last synced USN: 74973019

#14

FYI: das ist in einen Supportfall übergegegangen. Letztendlich lag es an dem Attribut “proxyaddresses” nach entfernen wurde auch das Attribut “mail” zuverlässig synchronisiert.