8
O365 mit AD FS - neue Domain - Anmeldung nicht möglich
Hallo zusammen,
ich habe hier folgendes Szenario:
Exchange On-Prem in Hybridstellung mit M365, alle Postfächer liegen bei M365, Authentifizierung über Active Directory Federation Services.
Der Kunde hat etliche verschiedene Domänen - der Großteil der Domänen ist im O365 als "Partnerverbunddomäne" hinterlegt. Dies kommt daher, weil auf dem lokalen AD FS Server die Domänen als "Federated" definiert wurden:
Wenn man sich im Postfach auf Outlook.com anmelden will, erhält man zunächst die normale Login-Maske von Microsoft. Sobald man hier seine Unternehmens-Email-Adresse einträgt, wird man automatisch auf die Login-Maske des AD FS des Unternehmens weitergeleitet.
Hier meldet man sich normalerweise einfach mit seinen Daten (E-Mail-Adresse und Passwort) an und landet im Postfach, soweit alles klar.
Nun hat der Kunde allerdings eine weitere zusätzliche Domäne bekommen. Diese Domäne wurde im O365 eingerichtet, die entsprechenden DNS-Einträge wurden gesetzt. Anschließend wurde die Domain auf dem AD FS Server entsprechend den anderen Domänen in "Federated" konvertiert, damit sich hier die Anmeldung so wie bei allen anderen Domänen verhält.
Dies hat auch normal funktioniert, anschließend wurde die Authentication als "Federated" angezeigt, wenn man die Domains per get-msoldomain abfragt.
Wenn ich nun einen User mit dem UPN-Suffix der neuen Domäne erstelle, wird dieser wie gewohnt zu O365 gesynct. Dort weise ich ihm eine Lizenz zu. Danach dauert es normalerweise maximal 30 Minuten und ich kann das Postfach des besagten Users öffnen.
Bei Postfächern mit einer Adresse der neuen Domain stoße ich hier jetzt allerdings auf einen Fehler, den ich vorher noch nie gesehen habe. Die Anmeldung schlägt fehl mit folgendem Fehler:
Diese Meldung kann ich leider nicht nachvollziehen. Nach meiner Kenntnis ist die neue Domain entsprechend allen anderen Domains eingerichtet. Das Postfach existiert natürlich, im Exchange Online ist es normal gelistet.
Wenn ich nach dem Fehlercode "AADSTS50107" recherchiere, werde ich leider so gar nicht fündig. Es gibt diverse Beiträge zu diesem Fehler, allerdings scheint in all diesen Beiträgen das Problem ein anderes zu sein - bei den meisten steht hier nämlich eine URL vom AD FS in der Fehlermeldung und keine E-Mail-Adresse, wie bei mir. So zum Beispiel auch in diesem Beitrag:
https://docs.microsoft.com/de-de/office365/troubleshoot/authentication/c ...
Ich sollte erwähnen, dass die AD FS ursprünglich nicht von mir eingerichtet wurden und ich das System auch nur übernommen habe. Würde mich daher auch nicht als Experten bezeichnen. Ich würde mich sehr über Tipps freuen, da ich hier an meine Grenzen stoße.
PS: Bitte entschuldigt die extern verlinkten Bilder - leider scheint es hier gerade ein Problem mit der Bild-Upload-Funktion zu geben.
Liebe Grüße
ich habe hier folgendes Szenario:
Exchange On-Prem in Hybridstellung mit M365, alle Postfächer liegen bei M365, Authentifizierung über Active Directory Federation Services.
Der Kunde hat etliche verschiedene Domänen - der Großteil der Domänen ist im O365 als "Partnerverbunddomäne" hinterlegt. Dies kommt daher, weil auf dem lokalen AD FS Server die Domänen als "Federated" definiert wurden:
Wenn man sich im Postfach auf Outlook.com anmelden will, erhält man zunächst die normale Login-Maske von Microsoft. Sobald man hier seine Unternehmens-Email-Adresse einträgt, wird man automatisch auf die Login-Maske des AD FS des Unternehmens weitergeleitet.
Hier meldet man sich normalerweise einfach mit seinen Daten (E-Mail-Adresse und Passwort) an und landet im Postfach, soweit alles klar.
Nun hat der Kunde allerdings eine weitere zusätzliche Domäne bekommen. Diese Domäne wurde im O365 eingerichtet, die entsprechenden DNS-Einträge wurden gesetzt. Anschließend wurde die Domain auf dem AD FS Server entsprechend den anderen Domänen in "Federated" konvertiert, damit sich hier die Anmeldung so wie bei allen anderen Domänen verhält.
Convert-MsolDomainToFederated -SupportMultipleDomains –DomainName namederneuendomain.deDies hat auch normal funktioniert, anschließend wurde die Authentication als "Federated" angezeigt, wenn man die Domains per get-msoldomain abfragt.
Wenn ich nun einen User mit dem UPN-Suffix der neuen Domäne erstelle, wird dieser wie gewohnt zu O365 gesynct. Dort weise ich ihm eine Lizenz zu. Danach dauert es normalerweise maximal 30 Minuten und ich kann das Postfach des besagten Users öffnen.
Bei Postfächern mit einer Adresse der neuen Domain stoße ich hier jetzt allerdings auf einen Fehler, den ich vorher noch nie gesehen habe. Die Anmeldung schlägt fehl mit folgendem Fehler:
AADSTS50107: The requested federation realm object 'max.mustermann@neuedomain.de' does not exist. Diese Meldung kann ich leider nicht nachvollziehen. Nach meiner Kenntnis ist die neue Domain entsprechend allen anderen Domains eingerichtet. Das Postfach existiert natürlich, im Exchange Online ist es normal gelistet.
Wenn ich nach dem Fehlercode "AADSTS50107" recherchiere, werde ich leider so gar nicht fündig. Es gibt diverse Beiträge zu diesem Fehler, allerdings scheint in all diesen Beiträgen das Problem ein anderes zu sein - bei den meisten steht hier nämlich eine URL vom AD FS in der Fehlermeldung und keine E-Mail-Adresse, wie bei mir. So zum Beispiel auch in diesem Beitrag:
https://docs.microsoft.com/de-de/office365/troubleshoot/authentication/c ...
Ich sollte erwähnen, dass die AD FS ursprünglich nicht von mir eingerichtet wurden und ich das System auch nur übernommen habe. Würde mich daher auch nicht als Experten bezeichnen. Ich würde mich sehr über Tipps freuen, da ich hier an meine Grenzen stoße.
PS: Bitte entschuldigt die extern verlinkten Bilder - leider scheint es hier gerade ein Problem mit der Bild-Upload-Funktion zu geben.
Liebe Grüße
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Kommentar vom Moderator colinardo am 15.07.2022 um 10:46:41 Uhr
Externe Bilder ins Forum hochgeladen und eingebunden.
Content-ID: 3337381562
Url: https://administrator.de/contentid/3337381562
Ausgedruckt am: 22.11.2024 um 05:11 Uhr
8 Kommentare
Neuester Kommentar
Moin,
Gruß,
Dani (Mod)
PS: Bitte entschuldigt die extern verlinkten Bilder - leider scheint es hier gerade ein Problem mit der Bild-Upload-Funktion zu geben.
bitte probier es nochmals.Gruß,
Dani (Mod)
Habe übrigens in meiner Verzweiflung mal den AD FS Server neugestartet. Leider keine Veränderung, Fehler besteht immer noch.
Moin,
schau dir bitte mit Hilfe von Claims X-Ray den Token einmal genauer an. Gerade Leerzeichen sind hier oftmals der Fehler. Das siehst du damit sehr gut.
Gruß,
Dani
schau dir bitte mit Hilfe von Claims X-Ray den Token einmal genauer an. Gerade Leerzeichen sind hier oftmals der Fehler. Das siehst du damit sehr gut.
Nun hat der Kunde allerdings eine weitere zusätzliche Domäne bekommen.
Das ist (keine) Subdomain einer bestehenden Domain?Nach meiner Kenntnis ist die neue Domain entsprechend allen anderen Domains eingerichtet.
Poste doch mal bitte von der neuen (Sub)Domain die AD FS Claims.Gruß,
Dani
Moin Dani,
Negativ, einfach eine neue zusätzliche Domain.
Hier von einem funktionierenden User (alte Domain):
Hier von einem nicht funktionierenden User (neue Domain):
Falls ich eine für das Troubleshooting relevante Stelle zensiert habe, bitte ich um kurze Info und Entschuldigung. Ich kann keine relevanten Unterschiede zwischen den beiden feststellen.
PS: Das Token Signing Certificate ist bei beiden Domains identisch beim X-Ray, das scheint also auch zu passen.
Das ist (keine) Subdomain einer bestehenden Domain?
Negativ, einfach eine neue zusätzliche Domain.
Poste doch mal bitte von der neuen (Sub)Domain die AD FS Claims.
Hier von einem funktionierenden User (alte Domain):
Hier von einem nicht funktionierenden User (neue Domain):
Falls ich eine für das Troubleshooting relevante Stelle zensiert habe, bitte ich um kurze Info und Entschuldigung. Ich kann keine relevanten Unterschiede zwischen den beiden feststellen.
PS: Das Token Signing Certificate ist bei beiden Domains identisch beim X-Ray, das scheint also auch zu passen.
@Dani PPS: Auch in den Raw Tokens kann ich keine Unterschiede festellen (außer die Gruppenmitgliedschaften und natürlich hier und da andere Hashes/IDs).
Moin,
Gruß,
Dani
PS: Das Token Signing Certificate ist bei beiden Domains identisch beim X-Ray, das scheint also auch zu passen.
Solange es sich um den einen und selben ADFS Server handelt, ist das auch in Ordnung. Sonst hast du ganz andere Probleme.außer die Gruppenmitgliedschaften und natürlich hier und da andere Hashes/IDs).
Könnte es an einer Gruppe liegen, dass z.B. auf die SID gefiltert wird? Error: requested federation realm object does not existPoste doch mal bitte von der neuen (Sub)Domain die AD FS Claims.
Ich meinte das Claims von der betroffenen Relay Party Trust im AD FS.Gruß,
Dani
Mahlzeit,
Das habe ich mir gedacht, alles klar.
Also eine erfolgreiche Authentifizierung am AD FS hängt bei mir jedenfalls nicht von einer speziellen Gruppenmitgliedschaft ab, falls du das meinst. Auch der verlinkte Beitrag trifft bei mir nicht zu, das hatte ich im Zuge meiner Recherche schon geprüft:
Sorry, ein Missverständnis. Diese hier meinst du, korrekt?
Gruß
Solange es sich um den einen und selben ADFS Server handelt, ist das auch in Ordnung. Sonst hast du ganz andere Probleme.
Das habe ich mir gedacht, alles klar.
Könnte es an einer Gruppe liegen, dass z.B. auf die SID gefiltert wird?
Also eine erfolgreiche Authentifizierung am AD FS hängt bei mir jedenfalls nicht von einer speziellen Gruppenmitgliedschaft ab, falls du das meinst. Auch der verlinkte Beitrag trifft bei mir nicht zu, das hatte ich im Zuge meiner Recherche schon geprüft:
Ich meinte das Claims von der betroffenen Relay Party Trust im AD FS.
Sorry, ein Missverständnis. Diese hier meinst du, korrekt?
Gruß
Update: Problem gelöst. @Dani Der Beitrag von dir bzw. die Kommentare darunter brachten mich nun doch zum Ziel.
Ursache meines Problems war, dass ich die neue Domain nicht in die Claim rule "Issue issuerid when it is not a computer account" mit aufgenommen habe. Das muss offensichtlich manuell durchgeführt werden, war mir nicht bekannt.
Danke dir vielmals für deine Unterstützung!
Ursache meines Problems war, dass ich die neue Domain nicht in die Claim rule "Issue issuerid when it is not a computer account" mit aufgenommen habe. Das muss offensichtlich manuell durchgeführt werden, war mir nicht bekannt.
Danke dir vielmals für deine Unterstützung!
