Posts by skleye

    Welche Version ist das jetzt? Die .dll gehört auch zur VC2015 Runtime, vielleicht musste man die bei Server 2012R2 damit reinholen. Ich habe hier auch noch eine 2012R2 Maschine am laufen mit Version 10.0.14393.2990 und der hat die VC2015 Runtime installiert. Ich kann dort aber leider nicht den Client installieren um das Verhalten zu testen.

    Ich vermute ein fehlerhaftes eDocPrintPro auf dem Rechner. Man druckt ja an den "STARFACE Fax" Drucker der wiederum an den eDocPort druckt und der wiederum über ein Profil und ein dazugehöriges Plugin von STARFACE das Fenster des Clients öffnet. Der meckert auch wenn der startet und der UCC Client nicht läuft.


    Prüf mal ob der Ordner c:\Program Files\Common Files\MAYComputer\eDocPrintPro\Plugins\STARFACE Fax existiert, ansonsten mal probieren den eDocPrintPro zu deinstallieren und dann den Client nochmal zu installieren. Alternativ wie unter Punkt 6.11.2 der "STARFACE UCC Client für Windows 7.2.0.X.pdf" (letzte Seite) beschrieben neu einrichten.

    Ist jetzt n Schuss ins Blaue und ohne Garantie, aber die ucrtbase.dll ist die "Universal C Runtime" und gehört eigentlich zum Windows "Lieferumfang". Hast du mal probiert die Datei umzubenennen, so dass der die aus C:\Windows\System32 verwenden muss?

    roady1969 So lange man die Länge von 13 Ziffern nicht überschreitet sollte das kein Problem sein. Siehe BNETZA. Vodafone unterstützt das z.B. auch und da muss man das bei Längen >11, bestehend aus Ortskennzahl (ohne führende 0) und der Nummer selbst, wobei 11 mMn. in 99% der Fälle reichen, nur mit denen abstimmen. Die Anschlüsse werden mit sog. variabler Rufnummernlänge standardmäßig konfiguriert und auf Wunsch mit fester Länge. Siehe Punkt 4.3


    Wollte ich nur der Vollständigkeit halber hinzufügen und gehe davon aus Scaramu hat das im Vorfeld bedacht ;)

    Hintergrund ist, ich bin mitten in den Vorbereitungen meines ersten Rollouts und habe einige Arbeitsplatz- und DECT-Telefone. Diese User sollen den UCC gerne nutzen, nur nicht die Softphone-Funktionalität, da ich die für die anderen ca. 130 Nutzer brauche, die am Stichtag dann auch eine Lizenz haben sollen.

    Der Client soll an die ca. 140 Windows-Rechner per Softwareverteilung ausgerollt werden und kann per CustomDefaultUser.config ein wenig "provisioniert" werden. Ich hab aber damit momentan keine andere Chance als entweder irgendwie den Rechnern von den Leuten mit den Hardware-Telefonen eine andere CustomDefaultUser.config zu geben in der der Haken nicht an ist oder ich lass den Haken standardmäßig aus und die, die kein Telefon am Tisch haben werden, klicken den selbstständig rein - aber das wird vielleicht nur die Hälfte raffen und das IT-Ticketsystem glüht. Letztendlich hält auch die Hardware-Telefon-User nichts davon ab den Haken nachträglich zu setzen und plötzlich ist der Lizenzpuffer für neue User weg und die Suche geht los, wer den Haken jetzt unberechtigterweise gesetzt hat...

    Bei uns sieht das genau so aus und dazu gabs auch schon mal einen Wunsch auf der alten Seite. Wir wechseln gerade von einer Lösung die das kann auf die Starface. War jetzt kein Projekt-Blocker aber war schon ein sehr unangenehmer "Schwund". Ich hatte nach Anraten meines SF-Lösungsanbieters mit FabianZ telefoniert, der da eine Möglichkeit sah eine Modullösung basteln zu können. "Basteln" deshalb, weil die Nachbearbeitungszeit nicht direkt im Moduldesigner verfügbar ist und schon erweiterte Kenntnisse erfordert. Dieses Modul müsste dann auf eine Taste im Telefon oder Client konfiguriert werden und würde dann bei jedem Druck eine Zeit X zur bestehenden Nachbearbeitungszeit aufaddieren. Eine Lösung seitens Starface mit zusätzlich nativer Unterstützung im Client bzw. der APIs wäre natürlich vorzuziehen.

    Ok theoretisch kann der Thread als Gelöst betrachtet werden. Ich hab die DC-Zertifikate jetzt mit 2048bit RSA aktiviert in der Hoffnung dass jetzt nicht irgend ein alter Kram stresst ;).


    Falls sich jemand Fragt was ich getan habe (Windows Server 2016 Umgebung):


    1. Auf dem Rechner mit der CA

    • MMC der Zertifizierungsstelle öffnen.
    • Unter "Zertifikatvorlagen" die Vorlage "Domänencontrollerauthentifizierung" rauswerfen. (Man wirft dabei nur eine Verknüpfung weg, nicht die Vorlage selbst.)
    • Die bereits vorhandene Vorlage "Kerberos-Authentifizierung" besitzt den 2048bit Schlüssel und wird über die "Zwecke" dann bei der nächsten Anfrage ausgewählt.


    2. In der GPO "Default Domain Controllers Policy" das Auto-Enrollment aktivieren

    • Zu "Computerkonfiguration"->"Richtlinien"->"Windows Einstellungen"->"Sicherheitseinstellungen"->"Richtlinien für öffentliche Schlüssel" navigieren.
    • "Zertifikatdienstclient - Einstellung für die automatische Registrierung" aktivieren, sowie die Haken bei "Neue Zertifikate registrieren, abgelaufene Zertifikate erneuern, ausstehende Anforderungen für Zertifikate verarbeiten und gesperrte Zertifikate entfernen" und "Zertifikate, die Zertifikatvorlagen von Active Directory verwenden, aktualisieren und verwalten" setzen.

    3. Auf dem/den DC/s "gpupdate /force" ausführen und zur Prüfung in die Computerzertifikate schauen ob das neue Zertifikat mit dem längeren Schlüssel existiert.


    Jetzt kann per TLS ohne Zertifikatsprüfung die AD-Anbindung in der Anlage konfiguriert werden. Ich habe das an einer Cloud-Anlage durchgeführt und hatte noch einen kleinen Fallstrick: Ich hatte die externe-IP, zu der die LDAPS-Anfragen gehen, der Einfachheit halber mit einem DNS-Namen versehen. Der ging nicht zu konfigurieren, nur die IP selbst ging - hab das aber nicht tiefer analysiert, da mir das Konstrukt so ausreicht.

    Mir geht's eher darum eine Grundsicherheit zu haben, auch wenn es nur ein RSA 1024bit ist. Selbst das wäre zunächst besser als unverschlüsselt. OpenJDK 11.0.14 ist vom 24.01.2022, warum sehen die kein Problem in ihrer Standard-Config?

    Ja, das ist eine Option, danke für den Link. Wenn man aber ein etwas größeres, komplexeres Firmen-Konstrukt hat, will man ungerne was kaputt machen. Die Frage ist auch warum das seitens SF enforced wird, denn die /etc/java/java-11-openjdk/java-11-openjdk-11.0.14.1.1-2.el8_5.x86_64/conf/security/java.security ist da nicht so streng:

    Code
    jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1 jdkCA & usage TLSServer, \
        RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224, \
        include jdk.disabled.namedCurves

    Ich hab mir mal eine VM mit der 7.2 installiert und das mal weiter analysiert. Ich hab den "Übeltäter" auch gefunden. Unter /etc/crypto-policies/back-ends/ gibt es die java.config, die ein Symlink auf /usr/share/crypto-policies/STARFACE/java.txt ist.

    Darin gibt es die Zeile

    Code
    jdk.certpath.disabledAlgorithms=MD2, MD5, DSA, RSA keySize < 2048

    die bei mir dieses Verhalten hervorruft. Ändere ich die Zeile ab auf

    Code
    jdk.certpath.disabledAlgorithms=MD2, MD5, DSA, RSA keySize < 1024

    funktionierts - da mein RSA Schlüssel, wie oben schon geschrieben, im Domaincontroller-Zertifikat nur 1024 bit hat. Nun fehlt nur eine Möglichkeit das auch auf einer Cloud-Anlage anzupassen...

    Ich vermute jetzt, die Mails landen im Gesendet Ordner des Accounts der für die SMTP-Anmeldung genutzt wird? Das macht der Exchange Online selbst. Wenn der Adressat natürlich die gleiche Person ist, ist es als ob man sich selbst eine Mail schreibt und die landet in Gesendete und im Posteingang. Ist aber offenbar kein soo neues "Feature" (https://docs.microsoft.com/de-…p-submission-improvements).


    Man kann die Mails übrigens auch mit einer fake-Adresse wie starface@domäne.de an den SMTP <tennant-name>.mail.protection.outlook.com ohne Authentifikation, mit Port 25 und STARTTLS übergeben. Allerdings muss man dann im Exchange Online einen Connector erstellen, um die externe IP der Starface als "E-Mail-Server der Organisation" zu hinterlegen und sollte natürlich auch den SPF von der Domäne so konfigurieren, dass die externe IP der Starface im Namen der Domäne senden darf, um nicht als Junk eingestuft zu werden. So machen wir das jedenfalls.

    Hallo,


    wir wollen unsere STARFACE Cloud-Anlage mit dem lokalen Active Directory verbinden für die Nutzeranmeldung. Jetzt geht natürlich die Kommunikation durchs Internet und man kann die Firewall auch dementsprechend einstellen, dass von Außen z.B. nur die Starface-IP die Ports 389 und 636 anfunken darf. Auf "Unverschlüsselt" funktioniert es auch, aber weder TLS ohne Zertifikatsprüfung noch TLS mit Zertifikatsprüfung (inkl. hinterlegtem CA-Zertifikat im "CA-Zertifikat für LDAPS") funktionieren. Ich vermute ganz stark es liegt am 1024bit Schlüssel. Hat man irgendwie die Möglichkeit die java.security Datei zu bearbeiten um das ein wenig lockerer zu stellen? Selbst 1024bit wären sicherer als Unverschlüsselt, wenn die Pakete durchs Internet fliegen.


    Log bei TLS mit Zertifikatsprüfung:

    Code
    [de.starface.core.component.activedirectory.provider.ADConnectionProvider] An exception was thrown while trying to secure the communication channel: LDAPException(resultCode=91 (connect error), errorMessage='An error occurred while attempting to connect to server <ip>:636:  IOException(LDAPException(resultCode=91 (connect error), errorMessage='An error occurred while attempting to establish a connection to server /<ip>:636:  SSLHandshakeException(Certificate Certificate(subject='CN=<dc-name>.<domain>.local', serialNumber=<sn>, notBefore=, notAfter=, signatureAlgorithm='SHA256withRSA', signatureBytes='<signature bytes>', issuerSubject='CN=<Fimenname>,DC=<domain>,DC=local') was not trusted by any of the configured trust managers.  The trust manager messages were:  PKIX path validation failed: java.security.cert.CertPathValidatorException: Algorithm constraints check failed on keysize limits: RSA 1024 bit key used with certificate: CN=<dc>.<domain>.local  The presented certificate chain containing certificates 'CN=<dc>.<domain>.local' cannot be trusted because none of the certificates in that chain were found in the JVM's default set of trusted issuers.), ldapSDKVersion=5.1.3, revision=028e004da97e22a274a4116316a73d0a90526e4b'))')

    Log bei TLS ohne Zertifikatsprüfung:

    Code
    [2022-05-26 01:08:53,790] [ERROR] [] [de.starface.core.component.activedirectory.provider.ADConnectionProvider] An exception was thrown while trying to secure the communication channel: LDAPException(resultCode=91 (connect error), errorMessage='An error occurred while attempting to connect to server <ip>:636:  IOException(LDAPException(resultCode=91 (connect error), errorMessage='An error occurred while attempting to establish a connection to server /<ip>:  SSLHandshakeException(Certificates do not conform to algorithm constraints), ldapSDKVersion=5.1.3, revision=028e004da97e22a274a4116316a73d0a90526e4b'))')

    Die Beschreibung klingt jetzt erstmal komisch, aber den Anwendungsfall hat man, wenn der neue Benutzer den man gerade über die REST API erstellt, auch später kein physisches Telefon haben wird, da er sich über den UCC Premium anmeldet, welcher erst nach der Erstanmeldung für das Softphone ein Telefon-Objekt erstellt. Oder ein User der erst im Nachgang sein iFMC konfiguriert, wodurch auch ein Telefon-Objekt erstellt wird.

    Unser Anwendungsfall ist eine im Laravel-Framework selbstgebaute IT-Verwaltung, die gewisse alltägliche Admin-Tasks (AD-Benutzer entsperren, anlegen, bearbeiten etc.), Verwaltung der ausgegebenen Hardware (SIMs, Telefone, Notebooks/Tablets), sowie Daten aus Drucker- (Siteaudit) und Routerverwaltung (GenieACS) zentral zur Verfügung stellt. Da wir jetzt demnächst eine STARFACE Cloud-Anlage einsetzen wollen und wir schon ein Testsystem von unserem Partner übergeben bekommen haben, hatte ich vor über die REST-API die Benutzeranlage bzw. den Import in unsere Verwaltung zu bauen. Am Zentralstandort haben wir laut alter Anlage 165 Nutzer/Geräte, die wollten wir natürlich ungerne über die UI anlegen und der eingebaute CSV-Import deckt bei weitem nicht alles ab (z.B. Anklopfen, weitere Nummern und deren Einstellungen wie Fax2Mail, ggf. Gruppenzugehörigkeit etc.). Die REST-API bietet sich an sich bestens dafür an. Ich bin jedoch gerade dabei zur nächsten Hürde einen Foreneintrag zu erstellen...