22
Office365 Domain verbinden
Moin!
Ich stehe vor folgendem Problem:
Kunde hat einen eigenen Exchange Server und möchte nun auch Teams nutzen. Die passende Lizenz (Apps for Business) dazu hat er.
Die bisherige O365-Einrichtung wurde standardmäßig mit der *.onmicrosoft.com erstellt. Diese werden auch für Teams genutzt.
Kunde möchte nun aber seine eigene Domain in O365 hinterlegt haben, um die *.onmicrosoft.com zu vermeiden.
Ich sehe nun folgendes Problem kommen: Ich setze die TXT-Einträge und beweise gegenüber O365, dass ich diese Domain besitze und nutzen darf. So weit, so gut. Ich kann also nun Benutzer erstellen mit der normalen Domain der Firma. Jedoch wird dann Outlook meckern, da Outlook standardmäßig immer zuerst bei Microsoft anklopft, um festzustellen, ob der Emailverkehr darüber läuft. Das führt dann natürlich zu einer Fehlermeldung in Outlook. Dieses Verhalten kann man anscheinend mit einer Änderung in der Registry ändern. Das ist jedoch mehr oder weniger mit Aufwand verbunden.
Habt ihr Ideen, wie ich das am besten angehe?
Ich stehe vor folgendem Problem:
Kunde hat einen eigenen Exchange Server und möchte nun auch Teams nutzen. Die passende Lizenz (Apps for Business) dazu hat er.
Die bisherige O365-Einrichtung wurde standardmäßig mit der *.onmicrosoft.com erstellt. Diese werden auch für Teams genutzt.
Kunde möchte nun aber seine eigene Domain in O365 hinterlegt haben, um die *.onmicrosoft.com zu vermeiden.
Ich sehe nun folgendes Problem kommen: Ich setze die TXT-Einträge und beweise gegenüber O365, dass ich diese Domain besitze und nutzen darf. So weit, so gut. Ich kann also nun Benutzer erstellen mit der normalen Domain der Firma. Jedoch wird dann Outlook meckern, da Outlook standardmäßig immer zuerst bei Microsoft anklopft, um festzustellen, ob der Emailverkehr darüber läuft. Das führt dann natürlich zu einer Fehlermeldung in Outlook. Dieses Verhalten kann man anscheinend mit einer Änderung in der Registry ändern. Das ist jedoch mehr oder weniger mit Aufwand verbunden.
Habt ihr Ideen, wie ich das am besten angehe?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1210778436
Url: https://administrator.de/contentid/1210778436
Ausgedruckt am: 13.11.2024 um 08:11 Uhr
22 Kommentare
Neuester Kommentar
Moin,
der Richtige weg wäre es wohl dein AD mittels Azure DA Connect zu synchronisieren. Dann werden deine ausgewählten AD User (Auswahl geschieht via OU) zu MS synchronisiert und du lizensiert nicht mehr auf onmicrosoft.com sondern auf deine Domäne. Das onmicrosoft.com brauchst du dann nicht mehr und User-Anlage läuft weiterhin im lokalen AD.
Wir haben es wie folgt gelöst:
AD synct unser in M365 Portal via Azure AD Connect
Lizenzen werden auf die Firma.de-Domain zugewiesen
Mailserver steht inhouse
Es funktioniert alles wie es soll
Den TXT-Record setzt du übrigens nur um die als Domain-Inhaber zu authentifizieren. Der TXT-Record hat nichts mit deinem MX-Record, Autodiscover, etc. zu tun.
Gruß
Doskias
der Richtige weg wäre es wohl dein AD mittels Azure DA Connect zu synchronisieren. Dann werden deine ausgewählten AD User (Auswahl geschieht via OU) zu MS synchronisiert und du lizensiert nicht mehr auf onmicrosoft.com sondern auf deine Domäne. Das onmicrosoft.com brauchst du dann nicht mehr und User-Anlage läuft weiterhin im lokalen AD.
Wir haben es wie folgt gelöst:
AD synct unser in M365 Portal via Azure AD Connect
Lizenzen werden auf die Firma.de-Domain zugewiesen
Mailserver steht inhouse
Es funktioniert alles wie es soll
Den TXT-Record setzt du übrigens nur um die als Domain-Inhaber zu authentifizieren. Der TXT-Record hat nichts mit deinem MX-Record, Autodiscover, etc. zu tun.
Gruß
Doskias
1
Oh Danke.
Das habe ich bisher noch nie gemacht.
Mal sehen, ob dabei nix kaputt geht. ;)
Das habe ich bisher noch nie gemacht.
Mal sehen, ob dabei nix kaputt geht. ;)
Ich hab es auch nur einmal gemacht und es ist nichts schief gegangen.
Wie gesagt: Du legst den TXT-Record nur an um MS zu zeigen, dass die Domain dir gehört. Damit ist es dann für MS erstmal legitim, dass sie dort verwaltet wird.
Wir haben dann anfangs auch mit onmicrosoft gearbeitet und dort lizensiert obwohl der Mailserver bei uns steht. Ging auch, war nur auf Dauer nervig die User immer per Hand abzulegen.
Wir haben dann im nächsten Schritt die Azure AD Synchronisierung eingerichtet und pauschal "alle" User synchronisiert, die in Frage kamen. Ein Teil hat sich dann mit Azure-Ad-Onmicrosoft lizensiert und ein anderer mit firma.de angemeldet und alle haben problemlos unseren internen Mailserver mittels Firma.de abrufen können.
Dann haben wir nach und nach die Accounts von onmicrosoft auf Firma.de umgezogen und auch da hat es nur kurz gehakt als die Lizenzen neu zugeordnet worden.
Wir legen jetzt wie gesagt die User bei uns im AD an, der Mailserver steht bei uns und Azure nutzen wir nur für die Lizenzverwaltung und künftig für Teams. Ich hab den Wechsel im laufenden Betrieb gemacht und es hat kein Anwender was davon gemerkt. Erst als ich die O365 installiert habe, haben die davon etwas mitbekommen .-)
Du schaffst das schon.
Gruß
Doskias
Wie gesagt: Du legst den TXT-Record nur an um MS zu zeigen, dass die Domain dir gehört. Damit ist es dann für MS erstmal legitim, dass sie dort verwaltet wird.
Wir haben dann anfangs auch mit onmicrosoft gearbeitet und dort lizensiert obwohl der Mailserver bei uns steht. Ging auch, war nur auf Dauer nervig die User immer per Hand abzulegen.
Wir haben dann im nächsten Schritt die Azure AD Synchronisierung eingerichtet und pauschal "alle" User synchronisiert, die in Frage kamen. Ein Teil hat sich dann mit Azure-Ad-Onmicrosoft lizensiert und ein anderer mit firma.de angemeldet und alle haben problemlos unseren internen Mailserver mittels Firma.de abrufen können.
Dann haben wir nach und nach die Accounts von onmicrosoft auf Firma.de umgezogen und auch da hat es nur kurz gehakt als die Lizenzen neu zugeordnet worden.
Wir legen jetzt wie gesagt die User bei uns im AD an, der Mailserver steht bei uns und Azure nutzen wir nur für die Lizenzverwaltung und künftig für Teams. Ich hab den Wechsel im laufenden Betrieb gemacht und es hat kein Anwender was davon gemerkt. Erst als ich die O365 installiert habe, haben die davon etwas mitbekommen .-)
Du schaffst das schon.
Gruß
Doskias
Servus,
ich hoffe das sprengt den Rahmen des Threads nicht, aber macht es hier eigentlich überhaupt Sinn User im MS365 Admin Portal anzulegen oder sollte man immer lokal zuerst die User anlegen? Meiner Erfahrung nach funktioniert der Sync der User von der AzureAD zur lokalen AD nicht so gut wie andersherum (fehlende Benutzer auf lokalem Exchange, fehlende AD-Gruppenzuordnungen, etc.).
ich hoffe das sprengt den Rahmen des Threads nicht, aber macht es hier eigentlich überhaupt Sinn User im MS365 Admin Portal anzulegen oder sollte man immer lokal zuerst die User anlegen? Meiner Erfahrung nach funktioniert der Sync der User von der AzureAD zur lokalen AD nicht so gut wie andersherum (fehlende Benutzer auf lokalem Exchange, fehlende AD-Gruppenzuordnungen, etc.).
Das wäre jetzt meine Frage: Synct der auch andersherum?
Was ist eigentlich mit den Passwörtern? Übernimmt das Azure AD die vom lokalen AD?
Was ist eigentlich mit den Passwörtern? Übernimmt das Azure AD die vom lokalen AD?
Moin
Gruß
Doskias
Gruß
Doskias
Zitat von @Remotedesktopverbindung:
ich hoffe das sprengt den Rahmen des Threads nicht, aber macht es hier eigentlich überhaupt Sinn User im MS365 Admin Portal anzulegen oder sollte man immer lokal zuerst die User anlegen?
Das kann man so pauschal nicht beantworten. Es hängt immer davon ab was du vor hast und wieviel daten du mit MS teilen willst. Es werden ja alle Eigenschaften des Objektes mit MS synchronisiert. Hast du ggf. im AD private Telefonnummern deiner User, oder Profilbilder, etc. hinterlegt werden diese von MS ebenfalls synchronisiert. Willst du diese Daten mit MS teilen? Darfst du diese Daten mit MS teilen (Stichwort DSGVO)? Wir haben damals mit M365-Accounts angefangen, weil durch einen Fehler eines DL unser Firma.de schon bei MS registriert war und die Erstellung des TXT-Records sich krankheitsbedingt verzögert hat. Wir brauchten aber kurzfristig ein O365 und da hat es schon Sinn gemacht die User im M365 anzulegen, damit wir es nutzen konnten. Das war allerdings ohne Synchronisationich hoffe das sprengt den Rahmen des Threads nicht, aber macht es hier eigentlich überhaupt Sinn User im MS365 Admin Portal anzulegen oder sollte man immer lokal zuerst die User anlegen?
Meiner Erfahrung nach funktioniert der Sync der User von der AzureAD zur lokalen AD nicht so gut wie andersherum (fehlende Benutzer auf lokalem Exchange, fehlende AD-Gruppenzuordnungen, etc.).
Wenn gesynct werden soll, so ist die Empfehlung von lokalem AD ins Azure. Hat unser betreuendes Systemhaus gerate. Ob das die offizielle MS-Empfehlung ist kann ich nicht sagen. Wir fahren so aber ganz gut. Wir haben uns von Anfang an an die Empfehlung gehalten und einen Sync vom Azur zu uns nicht versucht. Ich kann daher deine Erfahrung weder bestätigen noch widerlegen.Gruß
Doskias
Gruß
Doskias
1Zitat von @plamhh:
Das wäre jetzt meine Frage: Synct der auch andersherum?
Was ist eigentlich mit den Passwörtern? Übernimmt das Azure AD die vom lokalen AD?
Das wäre jetzt meine Frage: Synct der auch andersherum?
Was ist eigentlich mit den Passwörtern? Übernimmt das Azure AD die vom lokalen AD?
Der Sync zwischen Azure AD und lokalen Ad ist (mit Ausnahme, dass ein Tool dafür benötigt wird) identisch mit dem Sync zweier lokalen DCs. Es wird alles gesynct, daraus folgt auch die Kennwörter.
Du kannst dich dann im Office-Web (sofern freigegeben) mit deiner Firmen-Mail-Adresse und deinem Firmen-Kennwort anmelden. Sperrst du den User im lokalen Ad wird er im Azure gesperrt. Änderst du in der Firma dein Kennwort, wird es synchronisiert und im Azure geändert. Die Synchronisation erfolgt mit dem Tool alle 15 Minuten und bei uns dominiert das lokale AD. Sprich: Lösche ich im Azure einen User oder ändere das Kennwort, dann wird es vom lokalen AD beim nächsten Intervall wieder "korrigiert"
Gruß
Doskias
Zitat von @plamhh:
Das wäre jetzt meine Frage: Synct der auch andersherum?
Was ist eigentlich mit den Passwörtern? Übernimmt das Azure AD die vom lokalen AD?
Das wäre jetzt meine Frage: Synct der auch andersherum?
Was ist eigentlich mit den Passwörtern? Übernimmt das Azure AD die vom lokalen AD?
Das hängt vom gebuchten M365-Plan ab. Bei M365 Business Standard werden die Passwörter aus dem lokalen AD in das Azure AD synchronisiert, nicht aber anders herum. Für das Kennwort-Zurückschreiben ins lokale AD benötigst du mindestens AzureAD P1 oder einen Plan, der AzureAD P1 beinhaltet.
Ich hätte da noch eine weitere Frage:
Es sind ja schon etliche User angelegt in O365 mit der *onmicrosoft Adresse. Diese werden schon für die Aktivierung der Office Apps genutzt. Wenn ich jetzt das lokale AD mit Azure synchronisiere, dann legt er ja neue User mit den gleichen Namen an. Geht das überhaupt? Und wenn ja, wie füge ich die User zusammen, damit der lokale AD User zum Alias der *onmicrosoft wird? Alternativ wäre die ganzen onmicrosoft-User zu löschen und die Lizenzen neu zuweisen. Dann müsste ich die Aktivierungen der ganzen Officeinstallation händisch ändern. Das möchte ich verhindern, zumal es immer wieder mal User gibt, die aus Versehen Dateien im Onedriveordner abgelegt haben. Die wäre ja dann weg, wenn ich die onmicrosoft-Konten lösche.
Es sind ja schon etliche User angelegt in O365 mit der *onmicrosoft Adresse. Diese werden schon für die Aktivierung der Office Apps genutzt. Wenn ich jetzt das lokale AD mit Azure synchronisiere, dann legt er ja neue User mit den gleichen Namen an. Geht das überhaupt? Und wenn ja, wie füge ich die User zusammen, damit der lokale AD User zum Alias der *onmicrosoft wird? Alternativ wäre die ganzen onmicrosoft-User zu löschen und die Lizenzen neu zuweisen. Dann müsste ich die Aktivierungen der ganzen Officeinstallation händisch ändern. Das möchte ich verhindern, zumal es immer wieder mal User gibt, die aus Versehen Dateien im Onedriveordner abgelegt haben. Die wäre ja dann weg, wenn ich die onmicrosoft-Konten lösche.
Japp er legt neue an. User@onmicrosfot.com ist nicht user@firma.de. Du musst die Lizenzen dann neu zuweisen. Ich habe versucht den User im Azure umzubenennen, aber das ging nach hinten los. Der User war schon da, daher wurde kein neuer angelegt, aber das Hash war anders, also wurde das Kennwort nicht synchronisiert.
Da wir ohnehin kein OneDrive nutzen war das bei uns kein Problem. Wenn du das OneDrive in der Lizenzzuordnung oder für die ganze Domain deaktivierst, dann kann auch keiner versehentlich da was ablegen und du schützt deine Daten. Immerhin kann man mit OneDrive sehr gut Daten an der Firewall vorbei schleusen.
Bei mir machen die User die Anmeldung am O365 selbst. Es ist ja "nur" Mail-Adresse und Domain-Kennwort. Das kennen die schon und brauchen keinen der die Hand dabei hält
. Rundmail gabs vorweg und die Sache war durch.
Da wir ohnehin kein OneDrive nutzen war das bei uns kein Problem. Wenn du das OneDrive in der Lizenzzuordnung oder für die ganze Domain deaktivierst, dann kann auch keiner versehentlich da was ablegen und du schützt deine Daten. Immerhin kann man mit OneDrive sehr gut Daten an der Firewall vorbei schleusen.
Bei mir machen die User die Anmeldung am O365 selbst. Es ist ja "nur" Mail-Adresse und Domain-Kennwort. Das kennen die schon und brauchen keinen der die Hand dabei hält
. Rundmail gabs vorweg und die Sache war durch.
Du brauchst die *.onmicrosoft.com-Konten nicht löschen. Schau dir mal den verlinkten Artikel von MS an:
Vorbereiten einer nicht routingfähigen Domäne mit AzureAD
Ich habe das wie folgt gelöst:
Lokal: AD mit der Domäne "firma.local". (Ja, ich weiß....local ist sch....).
AzureAD: Domänen "firma.onmicrosoft.com" und "firma.de".
In M365 ist "firma.de" die Standard-Domäne und jeder User hat eine Adresse bzw. Benutzername nach dem Schema "vorname.nachname@firma.de" UND "vorname.nachname@firma.onmicrosoft.com". So würde der Sync nicht funktionieren. Nun kommt der verlinkte Artikel ins Spiel. Hier gibt man jedem Benutzer ein zusätzliches UPN-Suffix im lokalen AD, so das man ein AzureAD<->lokales AD Paar bekommt. Der Nutzer hat dann sowohl in AzureAD als auch im lokalen AD mindestens einen identischen Benutzernamen. So klappt der Sync.
Der Benutzer hat dann also lokal "hans.meier@firma.local" und "hans.meier@firma.de" und in AzureAD "hans.meier@firma.onmicrosoft.com" und "hans.meier@firma.de".
Ich empfehle dringend, sich mit der Bereitstellung von M365 intensiv zu beschäftigen. Das ist nicht mal eben
in einer Stunde abgekaspert. Zumal du eingangs noch einen lokalen Exchange erwähnt hast, für den dann ggf. eine Hybrid-Bereitstellung notwendig wäre.
Gruß NV
Vorbereiten einer nicht routingfähigen Domäne mit AzureAD
Ich habe das wie folgt gelöst:
Lokal: AD mit der Domäne "firma.local". (Ja, ich weiß....local ist sch....).
AzureAD: Domänen "firma.onmicrosoft.com" und "firma.de".
In M365 ist "firma.de" die Standard-Domäne und jeder User hat eine Adresse bzw. Benutzername nach dem Schema "vorname.nachname@firma.de" UND "vorname.nachname@firma.onmicrosoft.com". So würde der Sync nicht funktionieren. Nun kommt der verlinkte Artikel ins Spiel. Hier gibt man jedem Benutzer ein zusätzliches UPN-Suffix im lokalen AD, so das man ein AzureAD<->lokales AD Paar bekommt. Der Nutzer hat dann sowohl in AzureAD als auch im lokalen AD mindestens einen identischen Benutzernamen. So klappt der Sync.
Der Benutzer hat dann also lokal "hans.meier@firma.local" und "hans.meier@firma.de" und in AzureAD "hans.meier@firma.onmicrosoft.com" und "hans.meier@firma.de".
Ich empfehle dringend, sich mit der Bereitstellung von M365 intensiv zu beschäftigen. Das ist nicht mal eben
in einer Stunde abgekaspert. Zumal du eingangs noch einen lokalen Exchange erwähnt hast, für den dann ggf. eine Hybrid-Bereitstellung notwendig wäre.
Gruß NV
Von unterschiedlichen Domains hat mir unser Systemhaus abgeraten. Aber gut zu sehen, dass es auch gegangen wäre. Aber:
Wir haben "nur" M365 dazu genommen.
Lokal: User@firma.de und User@firma.local
Azure: User@Firma.de
Exchange- Steht im Raum neben mir.
Eine Hybrid-Bereitstellung ist nicht erforderlich.
Wir nutzen M365 für:
- Office-Lizenzen
- MS-Teams
- OneDrive ist deaktiviert
- OfficeWeb ist deaktiviert
Solange du deinen MX Record bei dir behältst und daran nichts änderst ist keine Hybrid-Bereitstellung erforderlich.
Zitat von @NixVerstehen:
Ich empfehle dringend, sich mit der Bereitstellung von M365 intensiv zu beschäftigen. Das ist nicht mal eben
in einer Stunde abgekaspert. Zumal du eingangs noch einen lokalen Exchange erwähnt hast, für den dann ggf. eine Hybrid-Bereitstellung notwendig wäre.
Hier muss ich widersprechen.Ich empfehle dringend, sich mit der Bereitstellung von M365 intensiv zu beschäftigen. Das ist nicht mal eben
in einer Stunde abgekaspert. Zumal du eingangs noch einen lokalen Exchange erwähnt hast, für den dann ggf. eine Hybrid-Bereitstellung notwendig wäre.
Wir haben "nur" M365 dazu genommen.
Lokal: User@firma.de und User@firma.local
Azure: User@Firma.de
Exchange- Steht im Raum neben mir.
Eine Hybrid-Bereitstellung ist nicht erforderlich.
Wir nutzen M365 für:
- Office-Lizenzen
- MS-Teams
- OneDrive ist deaktiviert
- OfficeWeb ist deaktiviert
Solange du deinen MX Record bei dir behältst und daran nichts änderst ist keine Hybrid-Bereitstellung erforderlich.
Oh, Danke für den Hinweis mit dem .local
Das wurde hier in dem Fall auch gemacht. Das muss ich noch anpassen.
Wie ist das eigentlich, wenn ich den Sync ausgeführt habe, taucht dann im O365 die Domain firma.de automatisch mit auf? Müsste ja dann so sein, sonst könnte ich ja keine User anlegen in O365 mit der Domain firma.de
Ist meine Annahme richtig?
Das wurde hier in dem Fall auch gemacht. Das muss ich noch anpassen.
Wie ist das eigentlich, wenn ich den Sync ausgeführt habe, taucht dann im O365 die Domain firma.de automatisch mit auf? Müsste ja dann so sein, sonst könnte ich ja keine User anlegen in O365 mit der Domain firma.de
Ist meine Annahme richtig?
Zitat von @plamhh:
Oh, Danke für den Hinweis mit dem .local
Das wurde hier in dem Fall auch gemacht. Das muss ich noch anpassen.
Wie ist das eigentlich, wenn ich den Sync ausgeführt habe, taucht dann im O365 die Domain firma.de automatisch mit auf? Müsste ja dann so sein, sonst könnte ich ja keine User anlegen in O365 mit der Domain firma.de
Ist meine Annahme richtig?
Oh, Danke für den Hinweis mit dem .local
Das wurde hier in dem Fall auch gemacht. Das muss ich noch anpassen.
Wie ist das eigentlich, wenn ich den Sync ausgeführt habe, taucht dann im O365 die Domain firma.de automatisch mit auf? Müsste ja dann so sein, sonst könnte ich ja keine User anlegen in O365 mit der Domain firma.de
Ist meine Annahme richtig?
Nein. Du musst erst den TXT-Record erstellen und die Domaine dann hinzufügen. Nur wenn die Domäne bei dir verwaltet ist, werden auch User mit der entpsrechenden Domäne angelegt.
Also muss ich doch den TXT-Record setzen beim Hoster, damit Microsoft erkennen kann, dass die Firma diese Domain besitzt? Und erst dann kann ich das Azure AD Connect einrichten?
Du kannst im M365-Admincenter eine bereits in deinem Besitz befindliche Domäne zu M365 hinzufügen. Der Setup-Assistent gibt dir dann die beim Hoster zu setzenden DNS-Einträge (TXT, SRV, etc.) vor. Die Einträge bezüglich Mail darfst du natürlich nicht beim Hoster ändern, sonst sägst du dir deinen lokalen Exchange ab.
Edit: @Doskias: Hier zeigen sich dann meiner Meinung nach die "Krähenfüße", wenn man auf die Hybrid-Bereitstellung verzichtet. Aber das muss jeder für sich selbst entscheiden.
Edit: @Doskias: Hier zeigen sich dann meiner Meinung nach die "Krähenfüße", wenn man auf die Hybrid-Bereitstellung verzichtet. Aber das muss jeder für sich selbst entscheiden.
Zitat von @plamhh:
Also muss ich doch den TXT-Record setzen beim Hoster, damit Microsoft erkennen kann, dass die Firma diese Domain besitzt? Und erst dann kann ich das Azure AD Connect einrichten?
Also muss ich doch den TXT-Record setzen beim Hoster, damit Microsoft erkennen kann, dass die Firma diese Domain besitzt? Und erst dann kann ich das Azure AD Connect einrichten?
Ja wie Nix-Verstehen schon schreibt und ich gestern auchg eschrieben habe: Mit dem TXT-Record zeigst du, dass es deine Domäne ist. Den musst du zuerst setzen. Dann wird die Domäne dir hinzugefügt und erst dann kann das Azure Ad Connect eingerichtet werden, weil erst dann die Domäne zu der du synchronisieren willst auch da ist.
@NixVerstehen:
Ich mach deinem Namen mal alle Ehre und verstehe nicht was du mit Krähenfüße meinst.
Bekomme ich aber dann nicht das Problem, dass Outlook versucht, zuerst den O365-Exchange zu erreichen? Und da er gar nicht existiert, spukt Outlook dann eine Fehlermeldung und es funktioniert dann einfach nicht mehr.
Zitat von @plamhh:
Bekomme ich aber dann nicht das Problem, dass Outlook versucht, zuerst den O365-Exchange zu erreichen? Und da er gar nicht existiert, spukt Outlook dann eine Fehlermeldung und es funktioniert dann einfach nicht mehr.
Bekomme ich aber dann nicht das Problem, dass Outlook versucht, zuerst den O365-Exchange zu erreichen? Und da er gar nicht existiert, spukt Outlook dann eine Fehlermeldung und es funktioniert dann einfach nicht mehr.
Nein, wieso? Outlook sollte doch dein Autodiscover fragen und den sollte dein DC auf deinen internen Mailserver verweisen. Dein MX-Record verweist weiterhin auf deine feste IP an deinem Standort. Auch hier ändert sich nichts. Der TXT-Record ist nichts anderes als ein Eintrag mit einem festen wert auf der Domäne, ähnlich einer Textdatei auf deinem PC. MS prüft ob ein TXT-Eintrag mit dem von MS angegebenen Wert vorliegt. Ist das der Fall bist du offenbar für die Domaine verantwortlich, weil sonst hättest du es ja nicht geschafft den TXT-Record mit den Werten aus dem Azure-Portal zu erstellen. Für mehr dient der TXT-Record nicht. Du erstellst ihn neu, MS prüft ihn, du löscht ihn. Fertig. Mehr passiert an der Stelle nicht.
Gruß
Doskias
Das ist dieses Verhalten hier von Outlook, das hatten wir schon mal gehabt.
https://www.leibling.de/outlook-365-anmeldeprobleme/
https://www.leibling.de/outlook-365-anmeldeprobleme/
Ja und? Da steht doch ganz unten:
Und in dem Link steht dann:
Und das ist genau das vorgehen, was du machst um dein AD mit dem Azure-AD zu synchronisieren. Sprich: Wenn du den Sync wie beschreiben einrichtest, dann hast du auch das Outlook-Problem nicht. Dann macht dein Outlook nämlich (einfach gesprochen) folgendes:
Es startet und findet per Autodiscover deinen Mailserver (intern). Dann wird Office 365 geprüft ob eine Lizenz für den User vorliegt (extern zu O365). Das ist der Fall, also versucht sich dann dein Outlook 365 (lokal) mit dem Exchangeserver (lokal) zu verbinden und nutzt dabei die Credentials, die bei der Lizenz (extern) hinterlegt sind. Dadurch das du aber deinen lokalen und den Azure-Ad synchronisierst, ist das Kennwort im Azure-Ad identisch mit dem lokalen, wodurch die Azure-Ad Credentials genutzt werden können um sich lokal anzumelden.
Update 2019:
Der saubere Weg wäre das eigene AD mit Office 365 zu verbinden, dies ist jedoch umfangreich. Dann folgt ein Link zu https://www.leibling.de/office-365-mit-active-directory-verbinden/
Der saubere Weg wäre das eigene AD mit Office 365 zu verbinden, dies ist jedoch umfangreich. Dann folgt ein Link zu https://www.leibling.de/office-365-mit-active-directory-verbinden/
Und in dem Link steht dann:
Die Domain der Emailadresse im AD als UPN einzurichten (DC > Active Directory Domänen und Vertrauensstellungen > Links den obersten Punkt rechte Maustaste > Eigenschaften > Benutzerprinzipalnamen Suffixe die Domain hinzufügen – z.B. domain.de).
Den Benutzern im AD den Anmeldenamen an die Emailadresse anpassen (DC > Active Directory Benutzer und Computer > Benutzer Eigenschaften öffnen > Register Konto > Benutzeranmeldename so Einstellen das er zusammen mit der Domain aus der Drop Down Box die Emailadresse ergibt).
Unter admin.microsoft.com eine eigene Domain erstellen (bitte dazu eine nicht verwendete Adresse verwenden wie administration oder so – die echten Adressen werden nachher syncronsiert werden mit dem AD) – z.B. sollte euer AD beispiel.local heißen, dann die Domain beispiel.onmicrosoft.com erstellen (wählt den Namen sorgfälltig, er kann im nachhinein nicht geändert werden).
Fügt nun die echte Domain hinzu unter admin.microsoft.com > Setup > Domänen (hierzu könnt ihr einen DNS TXT Eintrag erstellen, damit wird verifiziert das die Domain euch gehört), wenn ihr Exchange usw. lokal (ON Premise) nutzt, erstellt bitte nicht die MX Einträge usw.
Nun auf dem DC im AD eine OU erstellen für die Office 365 Benutzer und diese dorthin verschieben (DC >Active Directory Benutzer und Computer).
Auf einem Memberserver (DCs werden nicht unterstützt) noch die Software Azure AD Connect installieren und einrichten mit den Daten des Kontos das ihr erstellt habt, gebt auch direkt die OU an mit euren Office 365 Benutzern, damit diese nun übertragen werden.
Anschließend könnt ihr die User anpassen unter admin.microsoft.com > Benutzer > Aktive Benutzer und diesen bei Bedarf die entsprechende Lizenz oder Dienste zuordnen.
Den Benutzern im AD den Anmeldenamen an die Emailadresse anpassen (DC > Active Directory Benutzer und Computer > Benutzer Eigenschaften öffnen > Register Konto > Benutzeranmeldename so Einstellen das er zusammen mit der Domain aus der Drop Down Box die Emailadresse ergibt).
Unter admin.microsoft.com eine eigene Domain erstellen (bitte dazu eine nicht verwendete Adresse verwenden wie administration oder so – die echten Adressen werden nachher syncronsiert werden mit dem AD) – z.B. sollte euer AD beispiel.local heißen, dann die Domain beispiel.onmicrosoft.com erstellen (wählt den Namen sorgfälltig, er kann im nachhinein nicht geändert werden).
Fügt nun die echte Domain hinzu unter admin.microsoft.com > Setup > Domänen (hierzu könnt ihr einen DNS TXT Eintrag erstellen, damit wird verifiziert das die Domain euch gehört), wenn ihr Exchange usw. lokal (ON Premise) nutzt, erstellt bitte nicht die MX Einträge usw.
Nun auf dem DC im AD eine OU erstellen für die Office 365 Benutzer und diese dorthin verschieben (DC >Active Directory Benutzer und Computer).
Auf einem Memberserver (DCs werden nicht unterstützt) noch die Software Azure AD Connect installieren und einrichten mit den Daten des Kontos das ihr erstellt habt, gebt auch direkt die OU an mit euren Office 365 Benutzern, damit diese nun übertragen werden.
Anschließend könnt ihr die User anpassen unter admin.microsoft.com > Benutzer > Aktive Benutzer und diesen bei Bedarf die entsprechende Lizenz oder Dienste zuordnen.
Und das ist genau das vorgehen, was du machst um dein AD mit dem Azure-AD zu synchronisieren. Sprich: Wenn du den Sync wie beschreiben einrichtest, dann hast du auch das Outlook-Problem nicht. Dann macht dein Outlook nämlich (einfach gesprochen) folgendes:
Es startet und findet per Autodiscover deinen Mailserver (intern). Dann wird Office 365 geprüft ob eine Lizenz für den User vorliegt (extern zu O365). Das ist der Fall, also versucht sich dann dein Outlook 365 (lokal) mit dem Exchangeserver (lokal) zu verbinden und nutzt dabei die Credentials, die bei der Lizenz (extern) hinterlegt sind. Dadurch das du aber deinen lokalen und den Azure-Ad synchronisierst, ist das Kennwort im Azure-Ad identisch mit dem lokalen, wodurch die Azure-Ad Credentials genutzt werden können um sich lokal anzumelden.
@Doskias: Genau so sieht's aus.
@plamhh: Und bitte unbedingt die Warnung beherzigen, Azure AD Connect aus Sicherheitsgründen NICHT auf einem DC zu installieren. Siehe auch hier:
Azure AD Connect Voraussetzungen
@plamhh: Und bitte unbedingt die Warnung beherzigen, Azure AD Connect aus Sicherheitsgründen NICHT auf einem DC zu installieren. Siehe auch hier:
Azure AD Connect Voraussetzungen
