M365 / Entra / SSO - Anmelden mit Microsoft unzuverlässig

[mw_fisit]

Grundsätzlich funktioniert die Integration – aber nicht immer zuverlässig, insbesondere bei neu manuell angelegten Nebenstellen:

• E-Mail-Adresse der Nebenstelle passt exakt zum Entra-User
• Benutzer ist in der 3CX-Entra-Integration korrekt ausgewählt
• Sync wurde mehrfach deaktiviert/aktiviert
• Teilweise warten wir mehrere Tage

Ergebnis:

• Manche Nebenstellen lassen sich nie per Microsoft anmelden
• Andere „fangen sich“ nach 1–2 Tagen ohne erkennbaren Grund
• Bestehende/ältere Nebenstellen funktionieren, neue oft nicht

Aktueller Workaround

• Nebenstellen mit lokalem Passwort anlegen
• Passwort in Browsern/Clients der Mitarbeitenden hinterlegen

Das ist für Anwender und Kunden natürlich unbefriedigend.

Fragen in die Runde

1. Ist das vollständige Löschen und Neu-Anlegen einer Nebenstelle (inkl. Wartezeit) tatsächlich ein bekannter und empfohlener Fix, um das Microsoft-SSO „neu zu verheiraten“?
2. Gibt es offizielle Debug- oder Log-Möglichkeiten, mit denen man erkennen kann, warum eine Nebenstelle nicht mit Entra verknüpft wird?
3. Wie macht ihr das bei der Benutzeranlage?
   • Erst (AD -> AAD Connect) -> Entra → dann im 3CX das Konto einzeln auswählen und für den Sync aktivieren und die Nebenstelle dann anlegen lassen?
   • Oder Nebenstelle von Hand, Vor und Nachname inkl. Mail Adresse und dann die Aktivierung im 3CX für den User?
4. Wie geht ihr damit um, wenn Nebenstellennummern einer festen Logik folgen müssen (und daher nicht beliebig durch Auto-Sync erzeugt werden können)?

Hinweis: Vor-/Nachname sind korrekt gepflegt, Entra kommt aus AD-Connect (Hybrid), das bekannte „Name leer“-Problem trifft hier nicht zu.

Danke vorab für jeden praxisnahen Hinweis

Hier sieht man einige Nebenstellen wollen einfach nicht :S

 

[bitn]

Werden denn alle User synchronisiert oder eventuell nur nur ausgewählte ?

 

[mw_fisit]

Antwort: Es werden nur ausgewählte Benutzer synchronisiert

Die drei betroffenen Benutzer sind selbstverständlich in der Auswahl ebenfalls angehakt und sollten somit synchronisiert werden.

Fragen die ich mir stelle und nicht konkrete Infos aus den Dokus gefunden habe
1. Sync-Trigger: Wann und wie oft startet der M365-User-Sync in 3CX (zeitgesteuert / eventbasiert / manuell)?
2. Manueller Sync: Wie kann ich den Sync gezielt anstoßen, ohne die komplette M365-Anbindung (App/Autorisierung) neu aufzusetzen?
3. Logging: Wo finde ich aussagekräftige Logs?
- In der 3CX-GUI (Activity Log / Event Log): welche Filter/Kategorien sind relevant?
- Alternativ im Dateisystem: welche Pfade/Dateien (3CX-Version: Hosted / on-prem)?
4. SSO-Status: Wird ein Benutzer für SSO bereits als „bereit/erkannt“ angesehen, sobald der UserPrincipalName korrekt gematcht wurde,
oder erst nachdem sich der Benutzer einmal im Webclient angemeldet hat?
(Meine Vermutung: UPN-Match reicht aus und ist unabhängig vom ersten Login.)

Gibt es empfohlene Diagnoseschritte bei „einzelne Nutzer matchen nicht“, obwohl UPN/mail/proxyAddresses in Entra korrekt sind,

Meine Vermutung:
Die betroffenen User wurden bereits einmal angelegt durch den M365 Sync. Aber weil er die Nebenstelle neu angelegt hat da die Mail Adressen abweichend waren, wurden diese angelegten Nebenstellen die aus dem M365 Sync kamen nun wieder gelöscht, die Mail Adresen und UPNs korrigiert und dann sogar der ganze M365 Sync neu gemacht (App in Entra gelöscht und neu durchkonfiguriert)

- Aber dafür muss man ja richtig Debuggen können daher die Fragen oben

 

[bitn]

Hallo,

ich habe dieses Problem bisher bei keinem Kunden gehabt. Daher habe ich mir über diverse Punkte deiner Fragen keine Gedanken gemacht bisher.

Um das Log zu analysieren würde ich wie folgt vorgehen:
Das Loglevel der Anlage auf Ausführlich umstellen danach den 3CXSystemServer Dienst neustarten. Danach die Supportdaten der Anlage generieren und herunterladen. Dann in dem Ordner Logs 3CXSystemService.log nach Auffälligkeiten suchen.

Wenn alles nicht weiterhilft und ich nicht weiter komme würde ich ein Ticket eröffnen.

Beste Grüße

 

[mw_fisit]

Zusatzbeobachtung:
Im Log erscheint „Detected new extension 132 with email …“. Diese Extension 132 existiert aktuell nicht mehr (wurde nach einem initialen Auto-Provisioning wieder gelöscht).

Hintergrund:
- Erstlauf: 3CX hat den User nicht auf eine bestehende Nebenstelle gematcht und daher automatisch eine neue (132) angelegt.
- Danach wurden UPN/Identity und Nebenstellen bereinigt, Ziel war Matching auf bestehende Nebenstellen.
- Seitdem wird der User nicht mehr sauber gematcht; im Log taucht weiterhin die alte 132-Beobachtung auf bzw. wirkt, als würde 3CX noch mit dem alten Mapping arbeiten.

Frage:
Gibt es einen bekannten Cache/State (User↔Extension Mapping) in 3CX, der nach Löschung einer automatisch angelegten Extension bereinigt werden muss?
Wie kann man ein solches Mapping/Provisioning-State zurücksetzen, ohne die gesamte M365-Anbindung neu aufzusetzen?

 

[mw_fisit]

Meine Prüfung der Logs

Setup:


- Selective Sync: nur ausgewählte Benutzer werden synchronisiert (Mitarbeiter 1–3 sind angehakt)
- Auto-Extension Start: 130 (Aber die SSO Extensions sind auch "unterhalb" von Nebenstelle 130 und auch aktiv
- Loglevel: Verbose, Dienste neu gestartet, Supportdaten generiert (Analyse in Logs\3cxSystemService.log)

Wichtiger Kontext:
- Am 06.02. wurde zur “Bereinigung” die bestehende Microsoft/Entra App/Consent entfernt und die M365-Anbindung in 3CX neu autorisiert, sodass eine neue App/Consent-Konstellation entstanden ist.
- Das passt zeitlich zu den initialen Auth/Permission-Fehlern im Log.

Beobachtungen / Evidence (3cxSystemService.log):
1) Auth/Permission-Probleme direkt nach dem Reset (06.02. 15:02):
- POST /v1.0/subscriptions -> 401 Unauthorized
(_TMP/3cxSystemService.log:138212, :138213)
- Danach GET /v1.0/users -> 403 Forbidden + “Insufficient privileges”
(_TMP/3cxSystemService.log:138224, :138225, :138226)
- Unmittelbar danach: “subscriptions disabled for this sync”
(_TMP/3cxSystemService.log:138214)

2) Wiederkehrende Deaktivierung von Subscriptions in weiteren Läufen:
- “subscriptions disabled for this sync” tritt mehrfach auf (06.02 / 07.02 / 15.02 / 16.02)
(_TMP/3cxSystemService.log:142005, :188823, :189501)

3) Wiederkehrendes Graph-Throttling:
- 429 TooManyRequests (Substatus 3200, ActivityId vorhanden), oft täglich um ca. 05:00
(_TMP/3cxSystemService.log:142008, :189504, :204451)

4) Subscription-State/“Aufräumen”:
- Duplicate Subscriptions wurden erkannt und später bereinigt (13 -> 0) am 17.02. 08:45
(_TMP/3cxSystemService.log:206802, :210922)
- Service-Neustart triggert den UserSync-Job sichtbar (“Calling Execute on job GW-UserSync”)
(_TMP/3cxSystemService.log:206740, :210883)

5) User-spezifischer Sonderfall (Mitarbeiter 2):
- “Mailbox move in progress” beim Subscription-Delete (15.02. 03:10)
(_TMP/3cxSystemService.log:187265)
- Historischer Extension-Create (132) + später explizite Löschung der 132 ist im Log enthalten
(_TMP/3cxSystemService.log:138696, :140301, :140302)
=> wirkt historisch/transient, nicht als dauerhafter Mapping-Loop.

Aktueller Stand:
- Kein kompletter Ausfall: aktuelle Sync-Läufe laufen; für Mitarbeiter 1 und 3 gibt es Updates, für Mitarbeiter 2 aktuell “updated 0”.
(_TMP/3cxSystemService.log:214272 / :214218 / :214388)

# Also wie geht es weiter?

1) Welche konkreten Graph-Permissions/Consent sind für:
- GET /v1.0/users (inkl. userPrincipalName/mail/assignedPlans)
- Subscriptions auf /users und /users/{id}/contacts
zwingend erforderlich, um “Insufficient privileges” und “subscriptions disabled” zu vermeiden? (Durch den Klick und Consent Freischaltung wird ja eigentlich alles gesetzte aber zur Kontrolle!)

2) Was ist die empfohlene Vorgehensweise nach einem App/Consent-Reset, um den Subscription-State sauber zu initialisieren
(ohne mehrfaches Triggern/Neustarten und ohne komplette Neuinstallation)?

3) Gibt es Best Practices gegen wiederkehrendes 429 Throttling (z. B. Scheduling/Backoff-Handling), speziell um ~05:00?

4) Für user-spezifische States wie “Mailbox move in progress”: blockiert das Subscription-Operationen nur temporär
und wie kann man danach einen sauberen Re-Match/Re-Subscribe pro User erzwingen (ohne Full Reset)?

Danke vorab!

 

[mw_fisit]

Final Update / Lösung:

Bei uns hat SSO erst zuverlässig funktioniert, nachdem in der 3CX M365-Integration zusätzlich die Option
„Nutzerkontodetails synchronisieren“ (User details sync) aktiviert wurde.

Ohne diesen Haken konnten die Benutzer zwar teilweise synchronisiert/selektiert werden, aber SSO-Matching/Login blieb inkonsistent bzw. scheiterte.
Mit aktivierter Detail-Synchronisierung + Dienstneustart (3CXSystemService/3CXSystemServer) funktioniert SSO nun für alle ausgewählten Benutzer stabil.

Wichtig:
Die Synchronisierung überschreibt Felder in 3CX (u.a. Vorname/Nachname, E-Mail, Mobiltelefon)
Daher müssen die Quellwerte in AD/Entra/M365 vorab sauber gepflegt sein (kann viel Handarbeit sein)
- Vorname/Nachname korrekt
- MobilePhone / BusinessPhone im zulässigen Format (keine Sonderzeichen, keine Trennzeichen wie „/“, keine Leerstrings)
- Schreibweisen konsistent (auch UPN/Mail)

Nach Bereinigung der Benutzerdaten + Aktivierung des Haken + Speichern + Dienstneustart war die Anmeldung per SSO sofort möglich.

Also Danke an alle Hinweise und Aufklärung!

 

[mw_fisit]

Hm, leider noch nicht, anderer Kunde Nebenstelle ist bereits von Hand angelegt, leider kommt nachträglich kein Sync zustanden. ggf. war mit dem selben UPN mal ein anderer user aktiv der gelöscht wurde... hat jemand noch Tricks wie wir das resetten das er den user wieder matcht?