Beiträge von riawie

mal so ganz nebenbei, auch wenn Dein aktuelles Problem geklärt zu sein scheint...

Zitat von Hilde

- coaching@ einem AD-User im David Administrator mit dem korrekten Kürzel zugewiesen

Soll man das so verstehen das Du tatsächlich einen David Nutzer für eine Gruppen eMail Adresse anlegst und damit auch eine Nutzerlizenz dafür verbrennst?
Falls ja? Wozu?
Gruppen eMail Adressen brauchen ein Archiv mit passenden NTFS Rechten und eine Verteilregel, damit die Mails in das Archiv finden. Zusätzlich brauchen Nutzer welche unter dieser Adresse senden können einen passenden Eintrag in ihrer Benutzerkonfiguration.
Aber es ist weder ein AD Nutzer, noch eine Verknüpfung eines AD Nutzers zu einem David Benutzer nötig um ein Gruppen Postfach einzurichten bzw. zu nutzen.

Falls ich das falsch verstanden habe was Du da machts, nichts für ungut.
Falls ich es richtig verstanden habe, verbrennt Ihr da unnötig Benutzerlizenzen und habt aus meiner Nachfrage vielleicht einen Nutzen

So wie ich es sehe hat man ja eine Chayns Verbindung je Nutzer welche den Smart Client, Video Calls, oder - falls man den Chat auf Chayns umgstellt - den Chayns basierten Chat nutzen.
Damit dürfte man an dieser Stelle folglich nie mehr als die Anzahl der lizenzierten Nutzer an Verbindungen haben.
Eine eigene Chayns Site haben wir nicht bzw. nicht bewusst eingerichtet.

Was ist mit Verbindungen zu Sites gemeint?
Sind das (externe?) Nutzer welche sich mit einer Chayns Site die man erstellt verbinden um der Site zu folgen oder Dienste einer Site in Anspruch zu nehmen?

caddo was außer Smartclient, Video Calls und Chat macht Ihr mit Chanys?

Habt Ihr da tatsächlich ne Seite mit Mehrwert für Mitarbeiter oder Kunden online?

Insgesamt bin ich von der Chayns Geschichte eh ziemlich genervt, weil mir dadurch viel unnötiger Support Aufwand entsteht.

Der Chayns basierende David3 Smart Client fürs Smartphone wird nicht komplettiert, sondern wurde sogar vollständig zurückgezogen.
Statt dessen soll man nun die Chayns App bemühen.
Damit handelt man sich dann allerdings auch die ganze restliche Chayns Welt ein.
Was unsere Nutzer die eigentlich nichts weiter als einfachen Zugriff auf das David Ordner System und ihren David Kalender haben möchten jedoch schlicht überfordert.
Manche sind sogar so genervt davon das sie es komplett verweigern.
Für mich als Admin ist der Vollwertige Chayns Client ja recht praktisch, da Tobit inzwischen die ganze Kommunikation zum Produkt, als Support und kaufmännisches über Chayns abwickelt und sich das so auch am Smartphone schnell abrufen lässt.
Für unsere Nutzer geht es aber darum ihren Job konzentriert auf genau den Job erledigen zu können. die wollen nur sehen was sie zur Arbeit brauchen. Da passt dieser überfrachtete Chayns Client einfach nicht rein.

Mir erschließt sich ehrlich gesagt insgesamt bislang nicht der Sinn oder der Nutzen hinter chayns...

Zitat von Roland.K

Ich habe einige MDaemon-Server am laufen. Da installiere ich ein Zertifikat direkt in Windows und MDaemon greift dann darauf zu. Ist dann max. 15 Minuten im Jahr und fertig. Schade, dass das bei David so nicht geht.

Das dauert beim David Server wie oben beschrieben keine 5 Minuten, inklusive Start des David Administrators und ist deutlich flexibler als wenn der sich einfach irgendein System Zertifikat greifen würde.

Zitat von Roland.K

3. Firewall-Regeln deaktiviert

und schwups, Zertifikat hat sich aktualisiert

Danke für die Bestätigung das es genau daran lag

Schönes Wochenende.

Zitat von Roland.K

Es ist ein großer Mikrotik-Router. Eventuell müsste da mal ein Update gemacht werden .....

ich gehe eher davon aus das dort die Firewall für Euren Anwendungsfall ungünstig konfiguriert wurde.

Das kann wie ich weiter oben schon schrieb durchaus auch ohne aktuelle Konfigurationsänderung allein durch eine eingebundene - extern gepflegte - IP Blockliste passiert sein. Oder eben wie ich oben auch schon schrieb durch GeoIP Blocking mit Beschränkung der Zugriffe auf z.B. IP-Adressbereiche aus Deutschland oder Europa, je nach dem was Ihr so annehmt von wo aus man auf Euren Server zugreifen können muss.

Ich schalte hier bei uns z.B. den Port 80 auch nur für die Let's Encrypt Erneuerungen des David Servers weltweit frei und beschränke die Zugriffe ansonsten auf bekannt benötigte Bereiche.

Wenn Tobit mal DNS Validierung in das LE Modul einbauen würde wäre der Port 80 bei mir ganz und gar zu.
Wobei ich schon drüber nachdenke das LE Zertifikat schlicht wieder selbst automatisch zu managen, damit ich dann auf Port 80 verzichten kann. Klappt mit einem Bündel anderer Server ja auch prima mit dem LE ACME Script und DNS Validierung.

Zitat von nordtech

Müsste \\server\david\code\cert\ssl\{euredomain}\certificate_private_chain.pem sein - bzw. alle in diesem Ordner befindlichen Dateien.

nicht ganz, dort liegt nur ein Teil der nötigen Dateien.

Im Grunde müssten wohl die Webbox und der Mail Access Server gestoppt und dann der gesamte Inhalt des Pfades:

\\{ServerName}\david\code\cert\ssl

wiederhergestellt werden bevor man die Webbox und den Mail Access Server wieder startet.

Ob das schon alles war bin ich aber nicht zu 100% sicher.

Wenn das eine Telekom Business DSL Leitung ist könnte die Lösung allerdings auch schlicht in dem von der Telekom bereitgestellten Router und dessen Firewall zu suchen und vielleicht zu finden sein.

Ich gehe jedenfalls bei den aktuell verfügbaren Informationen davon aus das sehr unwahrscheinlich ist, das der David Server selbst Schuld an dem Problem ist.

Zitat von Roland.K

Plan b:

Ich instaliere ein Rapid-SSL-Zertifikat, was ich bereits auf vielen Servern direkt im Windows gemacht habe. Bei den Mailservern ist das dann als Zertifikat aufgetaucht und konnte einfach aktiviert werden. Greift David tatsächlich nicht auf im System installierte Zertifikate zurück? Gibt es wo eine Anleitung, wie ich solch ein Zertifikat in David einbaue?

Ich habe Dir doch oben erklärt wie Du so ein Zertifikat in den David Server bekommen kannst.
Ist wirklich nicht schwierig, einfach im David Administrator unter David > System > TLS-Verschlüsselung > TLS-Zertifikate per rechtsklick + Neu ein Zertifikat importieren und dieses dann mit den Diensten verknüpfen.

O.K. der Server ist also auf dem Port von deutschen IP Adressen aus zu erreichen und antwortet.

Das ist soweit schon mal gut.

Allerdings sagt das noch nichts darüber aus ob er auch von Amerikanischen oder anderswo auf der Welt gelegenen Adressen aus erreichbar ist.

Das ist zu 99% ein Firewall Problem.
Dieses Problem kann dabei sowohl bei Euch, als auch bei Eurem Internet Provider liegen.

Wenn Ihr selbst an Eurer Firewall in letzter Zeit ( wir reden von 60 Tagen rückwärts seit erstem auftreten des Problems) nichts geändert habt. Und Eure Firewall keine fremd gemanagten IP Blocklisten einbindet sollte Euer Problem also nicht bei Euch selbst liegen.
Dennoch solltet Ihr in jedem Fall die Logs der eigenen Firewall durchsehen.
Das ist normal kein großes Ding, zumal Ihr anhand der David Ereignismeldungen die genaue Uhrzeit kennt und somit genau wissen wo im Log gesucht werden muss (bitte drauf achten das viele Firewall Logs von dedizierten Firewall Appliances die Zeit in UTC angeben und daher im Winter eine Zeitdifferenz von 1 Stunde haben).

Wenn da im Firewall Log nichts auftaucht muss das Problem bereits eine Ebene weiter draußen bestehen.

Da Ihr Euren David Server per DynDNS ansprecht gehe ich mal davon aus das er hinter einem Internet Anschluss ohne feste IP-Adresse hängt.
Manche Provider mögen es nicht das man an solchen Anschlüssen Server betreibt.
Manche blockieren deswegen auch absichtlich Dienste wie Let's Encrypt.

Manchmal ist auch einfach nur beim Provider was kaputt (konfiguriert)

Sprech mit Eurem Internet Provider und frag nach ob es da ein Problem gibt.

Grundsätzlich läuft das mit SiteCare kommende automatische Let's Encrypt aber sehr stabil und zuverlässig, wenn man ihm nicht selbst ein Loch in den Fuß schießt und den externen Zugriff auf Port 80 in irgendeiner Firewall verhindert.

Zitat von Roland.K

ch betreue nur noch diesen David-Server. Bei anderen Systemen installiere ich das Zertifikat direkt auf dem Windows-Server. Kann david auch auf lokal auf dem Server installierte Zertifikate zugreifen?

Nein, aber Du kannst natürlich statt der mit SiteCare ohne extra Kosten möglichen Nutzung eines Let's Encrypt Zertifikat schlicht ein anderes Zertifikat über den David Administrator einbinden.

Dazu brauchst Du letztlich nur im David Administrator unter David > System > TLS-Verschlüsselung > TLS-Zertifikate per rechtsklick + Neu ein Zertifikat hinzufügen und dieses dann mit den gewünschten Diensten verknüpfen.
Macht halt aber nur Sinn wenn man da ein länger laufendes Zertifikat einbinden möchte.

Zitat von Roland.K

Da Port 80 für die Zertifikate verantwortlich ist, muss es dann wohl an dem liegen.

Ja, für Challenge response wird einzig Port 80 benötigt, was auch nicht änderbar ist.

Am besten erlaubst Du für kurze Zeit mal das Port 80 auch für die Webbox genutzt werden darf und nicht nur für Let's Encrypt. Dann kannst Du selbst von außen testen ob Du auf Eure Webbox zugreifen kannst. Wenn das klappt muss das Problem entweder in einer Geographischen Zugriffsbeschränkung, in Eurer oder der Firewall Eures Providers liegen.

Das:

Zitat von Roland.K

Ich hab das Zertifikat schon gelöscht, aber auch das hilft nicht.

War übrigens ein großer Fehler, denn jetzt hat Dein Server gar kein gültiges Zertifikat mehr zur Verfügung.
Hättest Du das nicht gelöscht wären dir rund 29 Tage geblieben Dein Problem in aller Ruhe zu lösen. Denn bei Let's encrypt sind die Zertifikate stets 90 Tage gültig, werden aber immer schon nach 60 Tagen erneuert um im Fall das diese automatische Erneuerung aus welchen Gründen auch immer mal nicht klappt ausreichend Zeit zur Reaktion und Fehlerbeseitigung zu haben.

Zitat von nordtech

Sofern die Meldung also nochmals kommt, probier's mit der dann gültigen URL einfach mal aus.

Das kannste knicken.

Diese Datei wird vom David Server nur für einen sehr kurzen Zeitraum zum Abruf zur Verfügung gestellt und anschließend sofort wieder entfernt. Das ist wichtig, weil dieser Challenge Response Prozess eine gewisse Anfälligkeit des ganzen Zertifizierungssystems darstellt.

Sobald man die Fehlermeldung bekommt ist die Datei daher auch schon längst nicht mehr auf dem Server verfügbar. Oder anders ausgedrückt: Das man diese Datei selbst nicht abrufen kann bedeutet nicht das es ein Problem auf dem eigenen David Server gibt.

Auch der gesamte Pfad zu dieser Datei wird nur kurz dynamisch für den Prozess erstellt und anschließend direkt wieder weggeräumt.

Zitat von nordtech

Leider weiß ich aus dem Stegreif nicht, wo David die obige "Verifikationsdatei" auf Dateisyste-Ebene ablegt. Sonst könnte man da ja auch mal schauen. Der Virenscanner auf dem Server hat nicht zugeschlagen?

Die Datei landet tatsächlich kurze Zeit auf der Platte um für die Webbox lesbar zu sein.
Das der Inhalt dieser Datei den Virenscanner triggert ist allerdings sehr unwahrscheinlich, denn dafür dauert der Prozess vom anlegen der Datei, bis der tatsächliche Abruf kommt dann doch zu lange, so das der Virenscanner bei der winzigen Datei längst wieder sein Interesse verloren hätte, egal wie übereifrig der sein mag.

Die Fehlermeldung bei nicht auffindbarer Datei würde übrigens auch etwas anders aussehen und nicht auf reset by peer lauten.

Wenn Euer Server über die DynDNS Adresse problemlos erreichbar ist deutet Connection reset by peer auf ein Firewall Problem hin.

Der Server von Let's encrypt kann die Challenge Response nicht von Eurem David abholen.

Das könnte nun Eure eigene Firewall sein, oder auch ein Problem mit Eurer Internetanbindung sein, das dort z.B. Geo location Eingrenzungen vorgenommen wurden welche verhindern das der gerade genutzte Let's encrypt Server, bzw. aus seinem gerede genutzten Adressbereich auf Euren Anschluss zugreifen darf.

Das ist interessant, denn beim Acrobat DC passiert das nicht.
Versuche ich es jedoch mit dem Acrobat Reader habe ich das gleiche Ergebnis wie Ihr.
Ich habe aber sowohl im Reader, als auch im vollwertigen Acrobat die gleiche Senden als eMail Funktion genutzt.

mal unverbindlich testen geht genau so lang wie Du den neuen Client die Standard Systemeinstellungen für mailto und Co nicht ändern lässt.

Auch danach lässt sich das noch wieder korrigieren, allerdings kannst Du mehreren Diskussionen hier im Forum leicht entnehmen das dies meist nicht reibungslos klappt.

Wenn Du aber den neuen Client von Hand gezielt startest und die bei dessen Start obligatorische Abfrage bezüglich nötiger Anpassungen einfach ablehnst kannst Du den neuen Client problemlos ausprobieren und immer wieder zurück.

Letztlich gehe ich allerdings davon aus das Tobit den alten Client in kürze schlicht aktiv entfernen wird, auch wen es weh tut

Der Return-Path wurde so eindeutig nicht vom David Server erzeugt, sondern von Server des Providers.

bei IONOS wird das ganz gut erklärt:

https://www.ionos.de/hilfe/e-m…haelt-unbekannte-adresse/

Ist also kein David Problem als solches.

Kann man mit dem David Server aber durchaus umgehen, allerdings nur mit einigem Aufwand.
Entweder man nutzt dazu die Tobit Relay Services (kosten Geld) oder man verschafft sich eine ordentliche feste IP Adresse aus einem IP Segment mit guter Reputation, setzt beim Provider passende DNS Records und sendet dann Mails direkt an die Empfänger, statt über Smarthost.

Nein, das kann ich Dir nicht erklären.

Ich hätte das selbst auch gern rein lokal und würde auch in Sachen Videokonferenz via David lieber auf eine rein lokale Authentifizierung setzen.
Da ich Chayns aber nun eh auf den Smartphones für den SmartClient nutze - weil damit die Suche in den Mails bei weitem besser ist als via EAS - habe ich auch keinen guten Grund mehr die Anmeldung am Server im mobil genutzten David Client nicht über Chayns laufen zu lassen.

Rein lokal im Unternehmensnetz arbeitende David Clients, welche den David Server auch via SMB erreichen und ihn rein über seinen SMB Namen ansprechen betrifft das Thema ja eh nicht, da in dem Fall die Anmeldung ja weiterhin komplett über SMB / Active Directory Single Sign On läuft.

Ich hatte diese Woche auch den ersten Fall.

Zum Glück nutzte der schon seit der Corona Zeit Chayns für Video Chats und entsprechend habe ich da dann auch den Login des Clients auf Chayns umgestellt. Zumindest damit läuft es nun ohne Klagen.

Zitat von Heinz

Wurde das auch gehen bzw. wie groß darf die Zahl mit den Minuten sein?

Sind da z.B. 60 Minuten oder mehr möglich?

reicht eine Woche?

Hab ich jedenfalls gerade mal zum Spaß mit @@Termin +10080@@ getestet, der Auftrag wurde einwandfrei zum Versand am nächsten Freitag angenommen

Ansonsten ließe sich noch der David Befehl

@@Archive =>user\100080F0\system\drafts@@

Dazu müsste allerdings die ID 100080F0 aus dem obigen Beispiel durch die tatsächliche UserID des jeweiligen David Nutzers ersetzt werden. Welche Du zu dem Zweck erst mal ermitteln müsstest.

Wir haben das daher damals - als wir sowas genutzt haben schlicht über den eben erwähnten Wartezustand und den Transit Ordner gelöst gehabt