Das kann man auch in nen cronjob / systemd.service+timer packen aber von alleine macht er das nicht meines wissens. Ansonsten in der weboberfläche halt bei ldap händisch syncen..

So... grad mal ne funktion zusammengewürfelt..

grom-test-2:~ # type grom_downsync
grom_downsync is a function
grom_downsync ()
{
        unset orgs;
        orgs=$(grommunio-admin domain query --format=csv orgID |uniq | sed '/^orgID/d;s/\r/ /g');
        for org in $orgs;
        do
                grommunio-admin ldap downsync --complete --organization $org;
        done;
}

    crpb
    Ja nurkann ich mich mit keinen der User mit dessen ad Passwörtern anmelden - dass eine Bruppe falsch gesynct wird manuell obwohl ich nur attribut person esetzt hatte


    Das Importierender User kann man ja über webhook/api triggern, wenn ich einen euen AD user ertellt habe über absible oder so.
    Ich habe den Server schon komplett neu installiert und nciht nur neu initialisiert und das Problem ist Identisch geblieben, also eher kein Bug im System - den Provider mit dem ich in Kontakt stee hat sich das angesehen und war auch überfragt und will es an Seine Kontakte bei Grommunio weitergeben.
    Ich Frage noch zusätzlich hier, evtl habt ihr was ähnliches gehabt, oder known bug usw.

      Also bezgl. Gruppe sieht das aus als wäre die Domain nicht bekannt da gruppenmitglieder nur aus den bekannten Domains sein dürfen oder ist diese auch mit eingepflegt und falls Organisation auch in der gleichen?
      EDIT: das sollte auch halbwegs ersichtlich sein mittels grommunio-admin wobei ich hatte damals das nur für Nutzer eingeschickt hatte. Müsste selbst noch mal schauen ob er bei gruppen was ordentliches ausspuckt oder ob man das evtl. erweitern könnte.
      EDIT2: sollte man sehen können? .. wobei wenn ich das richtig intepretiere mit meinen grundschul python skills geht das nur auf die gleiche domain?

      Das mit dem einloggen.. ich kenne das problem wenn man ssl/tls auf ldap aktiviert aber kein für das grommunio-system bekanntes zertifikat nutzt. Downsync und so kann zwar gehen aber beim authentifizieren schlägt er dann fehl.
      Aber oben deine ldapsearch beispiele zeigen unverschlüsselt was ja auch ok sein kann und dann habe ich solches verhalten auch noch nicht beobachten können.

        crpb
        Die Gruppe ist in der gleichen Domain nur hat irgendwer in dem Feld Email, wo bei den usern die richtige mail ist eine eher untypische mail hinterlegt wurde.
        Wir haben keienn Exchange sondern ein sehr altes maildove/postfix Mailserver ohne LDAP und es gibt eigentlich keine Mailkonten für gruppen nur klassiker, wie info@ usw.
        Vielleicht ist nur die gruppe zu sehen weil es dem filter der Domain nicht enstprcjt als einziges AD Objekt.

        Ich werde dann mal die user ohne die STARTTLS neu syncen und versuchen mich anzumelden..............

          Ja oder halt das zertifikat einbinden... dat müsste /usr/share/pki/trust/anchors/ in SuSe sein und dann update-ca-certificates (jo in der man der auch der pfad 😛)

            crpb Ich habe mal die alte installation dessen Snapshot wiederhergestellt und damit geht es ohne das STARTTLS sich anzumelden.
            Muss dann im AD(?) Ein angeres Zertifikat hinterlegen oder muss ich das was ich für die domain genommen habe für https irgendwie in der DA hinterlegen?

              crpb Die Domain hat ssl ich muss nur das Grommunio openldap vermutlich anpassen, dass dass die domain certkram in Vertrauenswürdig sit

                Das stammzertifikat der lokalen domäne. Also bei nem windows netz mit zertifikatsdienst/server kannste ja einfach jenes exportieren und dann auf dem server entsprechend mittels dem update-ca-certificates einbinden.
                https://learn.microsoft.com/en-us/troubleshoot/windows-server/certificates-and-public-key-infrastructure-pki/export-root-certification-authority-certificate

                Bei nem samba-ad-dc das /var/lib/samba/private/tls/ca.pem wenn ich mich nun nicht irre o_0.

                Wenn es ein AD ist, in der LDAP Konfiguration LDAPS ohne Start TLS verwenden, z.B.:

                ldaps://icc-ad1.xxxx.local ldaps://icc-ad2.xxxx.local

                Die Datei /etc/openldap/ldap.confergänzen:

                URI ldaps://icc-ad1.xxxx.local ldaps://icc-ad2.xxxx.local
                BASE OU=XXX,DC=xxxxx,DC=local
                TLS_REQCERT allow

                Das TLS_REQCERT allow ist wichtig.

                Grund: das Admin-UI ist in Python geschrieben und Python akzeptiert fast jedes Zertifikat, der Kernel gromox verwendet eine SSL Library und die ist heikler, da muss man dann TLS_REQCERT allow setzen.
                gromox-zcore und gromox-http restarten, dann sollte es funktionieren. Eine gültige LDAP Konfiguration vorausgesetzt.

                Ergänzung: URI und BASE müssen wie in der /etc/gromox/ldap_adaptor.cfg gesetzt sein.

                Also ich mache das mittels update-ca-certificates und dann halt

                |      1 | ldap_uri               | ldaps://bxxxx...local:636 ldaps://mxxx..local:636

                des war nun aus der sql tabelle wegen org ldap aber selbe in grün.

                kein anpassen in der ldap.conf notwendig gewesen.

                  crpb Ist auch ein möglicher Weg, die ldap.cfg anzupassen hat den Vorteil das jedes Zertifikat akzeptiert wird.

                    crpb @WalterH
                    Ja man muss echt nichts weiter machen ich habe es jetzt am laufen - für die Anderen mit der gleichen Frage

                    LDAP mit STARTTLS:
                    vorraussetzung ist, dass man eine Win Domain hat und auch schon einen Zertifizierungsserver hat.
                    Man mus dann diesen als Ziel nehmen für den sync, wil im Zertifikat bei Windows ist der Hostame drin und, wenn man einen anderen Server nimmt geht es nciht und der DNS sollte auch mit dem Zertifizierungsserver gehen.

                    1. CA-Zertifikat vom Windows AD Server exportieren( HIER WIE OPEN BESCHRIEBEN DAS ZERTIFIKAT DES ZERTIFIZIERUNGSSERVERS NEHMEN)

                    1. CA-Zertifikat exportieren:
                      • Auf einem Windows-Rechner:
                        1. Zertifikatsverwaltung öffnen:
                        2. Drücke Win + R, gib certlm.msc ein und bestätige mit Enter.
                        3. Navigiere zu "Vertrauenswürdige Stammzertifizierungsstellen > Zertifikate".
                        4. Suche das Zertifikat deiner Domänenzertifizierungsstelle (CA).
                        5. Rechtsklick auf das Zertifikat, wähle "Alle Aufgaben > Exportieren".
                        6. Wähle das Format Base-64 codiertes X.509 (.CER) aus und speichere die Datei.

                    2. CA-Zertifikat auf openSUSE hinzufügen

                    1. Kopiere die exportierte Zertifikatsdatei nach /etc/pki/trust/anchors auf dem openSUSE-Host.
                    2. Aktiviere das neue Zertifikat mit folgendem Befehl:
                      sudo update-ca-certificates

                    3. Verbindung testen

                    1. Teste die Zertifikate, indem du eine Verbindung zum Server herstellst:
                      openssl s_client -connect <server-hostname-oder-ip>:443 -CApath /etc/ssl/certs
                      Überprüfe, ob das Zertifikat korrekt erkannt wird.

                    4. Verbindung mit LDAP testen

                    1. Verwende ldapsearch, um die Verbindung zu prüfen. Der Schalter -ZZ aktiviert die verschlüsselte Kommunikation:
                      ldapsearch -H ldap://EUER_ZERTIFIZIERUNGSSERVER.local/ -ZZ (Als Beispiel hier müsste man noch den Benutzer hinzufügen mit dem gesynct wird und evtlder base DN des Pfades oder Syntax, was gesucht werden soll, wie in den Grommunio LDAP Filter in der Webgui unter LDAP Directory)
                      Das wars - ich musste nurnoch den falschen Server den ich genommen hatte auf den Zertifizierungs Server setzten, meine user gelöscht neu gesynct und im webmail anmelden und freuen!

                    Was ich am längsten für hgebraucht hab zu merken: die CA in diesem Fall, ermöglichen nur den Zugriff auf dem Server, auf dem sie erstellt wurden und das DNS sollte gehen - ich hab nen fehler gefunden wir haben alles neu Vergeben bei allen Servern wegen segmentierung, also oben die addressen sind vor kurzen eh nichtmehr aktuell und es wurde keine reverse zone vergeben für das neue netz und es schlägt fehl, deswegen musste ich den Hostnamen als ladp quellserver nehmen - diese Auflösung geht.

                      das Einzige was bleibt ist dass eine gruppe mit importiert wird, obwohl der Filter nur auf personen gesetzt ist, aber das ist noch erträglich, weil sie keine der 5 freien Plätze einnimmt.

                      WalterH Wenn ich es richtig gelesen habe ist nur für starttls + ldap der 636 Port andere Verschlüsselte Protokolle gehn über beide.

                        LDAPS, das S steht für Secure und das ist Port 636 bei LDAP. Bei HTTP ist unsecure Port 80 und HTTP Secure also HTTPS ist Port 443. Hoffe, das klärt die Frage. StartTLS kann auch über 389 funktionieren, da TLS (secure) erst später eingeschaltet wird.

                        WalterH ist redundant, LDAPS ist Port 636, wie HTTPS Port 443 ist.

                        jo i know.. wurde vom kunden so rein gehackt und solang es funktioniert fass ich es auch nicht an 😛

                          © 2020-2024 grommunio GmbH. All rights reserved. | https://grommunio.com | Data Protection | Legal notice