Posts by joeheb

    Moin,

    wir setzen zur Umleitung ausserhalb unserer Öffnungszeiten eigentlich die Module "Zeitgesteuerte Umleitung" und die Feiertagsumelitung von OByte ein. Mit der zeitgesteuerten Umleitung funktioniert auch alles super. Wenn die Umleitung jedoch über das Modul Feiertagsumleitung geschieht, bleibt die Leitung einfach stumm. Das Problem haben wir schon seit gefühlten Ewigkeiten (ich meine mich sogar zu erinnern, dass es das entsprechende Modul mal von Starface selbst gab und das gleiche Problem hatte). Wir behelfen uns bisher immer damit, dass wir an Feiertagen, wenn sie denn anstehen, einfach temporär den entsprechenden Wochentag in die Zeitgesteuerte Umleitung packen. Aber das nervt auf Dauer natürlich und bietet eine Menge Fehlerpotential...

    Irgendwer ne Idee, woran das liegen könnte?

    Vielen lieben Dank

    roady1969 : Wie von _mkurz geschrieben ist es nicht notwendig, den Basistreiber zu verwenden, es reicht aus, eine ältere Version des Treibers zu verwenden (Button "vorheriger Treiber" im Gerätemanager). Nach einem Neuaufsetzen von einem Notebook muss ein älterer Treiber natürlich händisch rausgesucht werden.

    Ob es technisch möglich ist oder nicht, sollte dafür nicht entscheidend sein. Aus Security Sicht ist das einfach großer Mist. Hierbei umgeht man potentiell sämtliche Securitymaßnahmen, die zwischen den Netzen über Firewalls realisiert werden.

    Geht hier seitens Starface eigentlich was vorwärts? Gibt es eine Möglichkeit hier etwas zu erfahren? Die Empfehlung seitens Starface die automatische Kontensperrung zu deaktivieren und damit die Sicherheit der IT zu schwächen ist ja schon eher semi...

    Sooo, ich nochmal. Der Bug stellt sich jetzt tatsächlich als deutlich fieser raus, als zunächst angenommen. Ich schildere mal den Ablauf (ist jetzt komplett unabhänig davon, ob jemand sein Passwort geändert hat oder nicht):
    - User startet den UCC Client
    - User versucht sich anzumelden mit dem falschen Passwort (bspw. weil er sich vertippt)
    - Starface UCC meldet korrekterweise, dass das Passwort nicht stimmt
    - User tippt das korrekte Passwort ein
    - Starface UCC öffnet sich
    Ab diesem Zeitpunkt beginnt die Starface wieder im 30 Sekunden Rhythmus, fehlgeschlagene Loginversuche gegen das AD abzufeuern. Selbst wenn ich mich über den Abmelden Button vom UCC Client abmelde, geht das einfach weiter. Solange, bis ich den UCC Client explizit beende. Erst dann hören die fehlgeschlagenen Loginversuche auf.

    Ich geb das nun nochmal an den Support weiter und bin sehr gespannt, was zurückkommt. Ich melde mich :)

    Edit: Das passiert übrigens auch, wenn man den Haken bei Passwort speichern nicht reinnimmt.

    Mit der Erklärung kann ich sehr gut leben. Dennoch sind da weiterhin zwei Dinge, die auch mit der Erklärung nach meinem Verständnis nicht sein müssen:
    1. Warum kann der Anwender sich weiterhin für ca. 15 Minuten mit dem alten Passwort anmelden?
    2. Warum versucht die Starface weiterhin im Hintergrund den User mit den alten Credentials zu authentifizieren, wenn gar keine neue Authentifizierungsanforderung rein kommt?

    Dass die Session offen bleibt wäre ja zu verkraften, dass die Konten gesperrt werden, nervt halt hart...

    PS: Die Starface bekommt übrigens sehr wohl mit, dass die User Session eigentlich zu annulieren wäre. Und zwar im Rhytmus von 30 Sekunden in Form von fehlgeschlagenen Loginversuchen im AD ;) Also könnte man in der Entwicklung eins von beidem umsetzen. Entweder die überflüssigen Authentifizierungsversuche bei einer schon bestehenden Session unterlassen, oder alternativ das Annnulieren der Session bei entsprechender Rückmeldung aus dem AD.

    100% ACK, gar keine Frage.

    Mit der aktuellen Exchange Lücke bin ich sehr vorsichtig geworden alle Systeme an den AD zu hängen (und wir haben zum Glück kein Exchange) :)

    Wir sind da zum Glück mit einem blauen Auge davon gekommen. Die Heuristik Erkennung unseres AV hat die Webshell direkt weggeblockt :cool:
    Aber unser Exchange wird zukünftig auch nicht mehr direkt am Netz hängen. Das ganze hat schon leicht paranoid gemacht...


    Das erinnert mich an "tlsdontverifyserver=yes":
    https://support.starface.de/forum/showthre…cherheitsrisiko!

    Oh, den kannte ich noch nicht. Ist natürlich auch unschön. In einem Lab, wo man mal eben keine Zertifikate hat, ok, aber in prod? :D

    Mich stört ja nicht, dass solche Fehler passieren, auch wenn sie bestimmt vermeidbar wären, ich hab auch schon echt genug Mist gemacht. Mich stört, dass das nicht als Bug anerkannt wird mit dem Hinweis "Sorry, wir fixen das schnellstmöglich".

    So. also ich habe jetzt die Rückmeldung vom Support, dass das nunmal so ist. Nach der Passwortänderung akzeptiert die Starface einfach für eine gewisse Zeit das alte Paswort (warum auch immer da Passwortinformationen auf der Starface zwischengespeichert werden). Und auch wenn die Starface merkt, dass dass das Passwort falsch ist, bleibt die UCC Client Session dann dauerhaft bestehen und wird nicht terminiert. Davon ab geht die Starface dann dennoch im Hintergrund so lange gegen das AD mit den falschen Credentials bis das Benutzerkonto gesperrt ist. Die Empfehlung des Support war, die Sperre nach X erfolglosen Loginversuchen zu deaktivieren, oder alternativ den Benutzern den Komfort eines gespeicherten Kennwortes zu untersagen.

    Bin ehrlich gesagt etwas angefressen von der Antwort, aber soweit ich das sehe bleibt mir nichts, als das erstmal hinzunehmen....


    Fairerhalber muss man sagen, dass sich lediglich die erste Aussage final bestätigt hat, die anderen waren Fehlmeldungen unserer Anwender. MAcht es aber aus unserer Sicht nicht besser, weil sich die Accounts dadurch sperren....


    - Wenn wir im AD unser PW ändern, kann man sich im Anschluss für einige Zeit (noch nicht geprüft, geschätzt ca 10 Minuten) sowohl mit den alten, als auch mit den neuen Credentials an der Starface anmelden.
    - Wenn die Anwender ihr PW ändern, geben sie im Anschluss das neue Passwort auch in den UCC Client ein, welches dann auch akzeptiert wird. Hier passiert es dann aber sporadisch (ich konnte zumindest noch kein Muster erkennen), dass die Anwender sich nach einiger Zeit (ca 20 Minuten) melden, dass ihr AD Konto gesperrt wurde. HIEr sehen wir dan in den Security Eventlogs, dass die Loginversuche von der Starface kommen.
    - Bei der Ersteinrichtung des UCC Clients (nach Rechnerwechsel oder ähnliches), kommt es selten vor, dass die Erstauthentifizierung fehl schlägt (unklar, ob das PW falsch eingegeben wurde, oder nicht). Beim zweiten Versuch klappt es dann, aber dennoch wird kurz danach im AD das Konto durch die fehlerhaften Loginversuche der Starface gesperrt.

    OK, ich habe das jetzt nochmals selbst nachzuvollziehen versucht. Das ist ja immer etwas schwierig, wenn man Anwender hat, die einem sehr gemischtes Feedback geben und teilweise garantieren, etwas auf eine bestimmte Art gemacht zu haben... :)

    Also ob die Leute sich wirklich mit ihrem neuen Passwort bereits am UCC Client anmelden, kann ich nicht mit Sicherheit bestätigen. Was ich aber zu 100% reproduzieren kann ist, dass sich der UCC Client nach dem Ändern des Passwortes eine Zeit lang mit dem alten Passwort anmelden lässt. Heisst, der Anwender ändert sein Passwort, startet dann seinen UCC Client (oder er ist schon offen, je nachdem ob das PW beim Login oder im während er angemeldet ist geändert wurde), welcher natürlich weiterhin einen Autologin durchführt, weil er ja das alte Passwort noch immer akzeptiert. Für den Anwender ist zu dem Zeitpunk natürlich alles in Butter. Aber ab diesem Zeitpunkt sehe ich auf dem AD Controller exakt alle 30 Sekunden einen Login der fehlschlägt. Wenn die 10 Versuche dann voll sind, wird das Konto natürlich deaktiviert.

    Kann das jemand reproduzieren? Hier wird vermutlich der einzige Weg über ein Ticket gehen, oder kriegt das Starface hier auch mit?

    Danke

    Edit: Habe unseren PArtner angefragt, ein Ticket zu eröffnen. Wäre dennoch interessant zu wissen, ob das alle betrifft. Wir sind übrigens auf der 6.7.3.11

    Wie geschrieben, hinterlegen die User nach dem Ändern ihr neues Kennwort im UCC Client. Und können den Starface Client ja auch starten und danach nutzen. Die Erklärung ist somit nicht wirklich zufriedenstellend. Das erklärt auch nicht, warum ich mich nach einer PAsswortänderung am Webinterface eine Zeit lang sowohl mit dem neuen, als auch mit dem alten anmelden kann...

    Hallo zusammen,

    wir haben mit unserer Starface ein paar sonderbare Probleme bei der LDAP Authentifizierung. Alle unsere User melden sich per AD Credentials an und das funktioniert auch.
    Wir kämpfen seit einger Zeit mit sporadisch gesperrten Benutzerkonten in der AD. Nachdem wir uns das Problem nun mal näher betrachtet haben, haben wir im Eventlog festgestellt, dass die fehlerhaften Loginversuche, welche zur Sperrung des Kontos führen, immer von unserer Starfaceanlage kommen. In diesem Zuge konnten wir ein paar Dinge beobachten:
    - Wenn wir im AD unser PW ändern, kann man sich im Anschluss für einige Zeit (noch nicht geprüft, geschätzt ca 10 Minuten) sowohl mit den alten, als auch mit den neuen Credentials an der Starface anmelden.
    - Wenn die Anwender ihr PW ändern, geben sie im Anschluss das neue Passwort auch in den UCC Client ein, welches dann auch akzeptiert wird. Hier passiert es dann aber sporadisch (ich konnte zumindest noch kein Muster erkennen), dass die Anwender sich nach einiger Zeit (ca 20 Minuten) melden, dass ihr AD Konto gesperrt wurde. HIEr sehen wir dan in den Security Eventlogs, dass die Loginversuche von der Starface kommen.
    - Bei der Ersteinrichtung des UCC Clients (nach Rechnerwechsel oder ähnliches), kommt es selten vor, dass die Erstauthentifizierung fehl schlägt (unklar, ob das PW falsch eingegeben wurde, oder nicht). Beim zweiten Versuch klappt es dann, aber dennoch wird kurz danach im AD das Konto durch die fehlerhaften Loginversuche der Starface gesperrt.

    So richtig erkennen, wo das PRoblem liegt, kann ich noch nicht, ich würde aber auf Grund des Verhaltens vermuten, dass die Starface im Hintergrund irgendwelche Caching Mechanismen für die LDAP Auth hat. Kann mich hier jemand erleuchten, was exakt im Hintergrund passiert? Das Problem ist etwas nervig... :)

    Vielen Dank

    Wir möchten gerne Neon testen, um eine Platform für gelegentliche ONlinemeetings mit externen zu haben. Dafür haben wir nun eine Connectleitung aktiviert. ISt es für die Aktivierung des Neon Rechts notwendig, die Kontodaten bereits zu hinterlegen, oder sollte Neon auch im Rahmen der Freiminuten zum Testen funktionieren? Danke