exchangekoala

Hey Nils, Danke für deine konstruktive Antwort. Natürlich ist das VPN erst einmal eine Grenze zu unserem internen Netzwerk. Allerdings haben wir bis auf einen kleinen Teil alle Apps in die Cloud ausgelagert. Die restlichen Apps werden von extern nur per RDS Gateway über die VPN zugänglich gemacht. Ansonsten erfolgt keinerlei Zugriff auf das interne Netzwerk. Ich benötige meine DC's also nur noch für stumpfe Authentifzierungs-, DNS, und GPO Aufgaben. Um diesen letzten Punkt noch sicherer zu gestalten war mein Gedanke dann der RODC. Dieser wäre natürlich auch in ein eigenes VLAN etc. gekommen. Aber gut, wenn der Sicherheitsvorteil nicht merklich den Aufwand überwiegt, werde ich das noch einmal überdenken müssen. Danke trotzdem für deine technische Ausführung und Hilfe!

Ich schätze eure Hilfe sehr, aber warum muss es immer direkt abwertend werden? Muss den jeder Admin immer ein Experte auf jedem Gebiet sein und darf nicht mal eine Frage in den Raum stellen ohne direkt belächelt zu werden? Gerade wenn man sich mit zusätzlichen Sicherheitsgedanken befasst? Mein Grundgedanke war einen RODC statt einem RWDC für Außendienst und Homeoffice zur Verfügung zu stellen. Dieser hat wie der Name bereits sagt eine RO AD- Datenbank und ein RO DNS. Weiterhin eine unidirektionale Verbindung mit dem RWDC. Dazu kommt das er die Credentials cached und auch mit einem RWDC aktualisieren kann. @tesso Habe ich doch oben mit Proxy beschrieben? Weiterhin würde ich nur diesen RODC den VPN Clients zur Verfügung stellen. Damit diese nur mit ihm sprechen können. Ich muss in der Firewall nur den RODC freigeben und keinerlei interne RWDCs. Plus ich kann nur definierte Gruppen zum Caching freigeben und biete keine Angriffsfläche für alle Gruppen. Wenn dies insgesamt keine gute Idee sein sollte, bin ich gerne offen für Kritik. Aber sagt mir doch warum ich keinen nehmen sollte, sondern einen vollwertigen? Microsoft hat das Ding ursprünglich für Branch Offices entwickelt, warum nicht auch für AD oder HO Mitarbeiter? Klar die selben Mitarbeiter fallen auch in der Firma rum, aber einen Zugriff von extern kann ich weniger überwachen, bzw. nicht ausschließend das sich jemand Zugriff verschaffen möchte. z.B. nach Verlust oder Diebstahl.

Natürlich will ich nicht einen RODC ins Homeoffice stellen. Was ist das für eine Frage? Einen RODC statt einem regulären DC per VPN zu Verfügung stellen, dieser fungiert als "Proxy" für Passwortänderungen der User. Das kann dieser sehr wohl, er benötigt selbst nur eine Verbindung zum DC.

Hey Nils, Danke für den Link. Ich habe den Nachtrag von daabm zu Norberts Aussage falsch aufgenommen. Sprich der Client behält solange sein Passwort, bis er es dem DC mitteilen konnte und keiner sollte seine Vertrauensstellung verlieren. Dann wäre ich hier erst einmal beruhigt. Danke! Unabhängig davon, wäre es deiner Meinung nach sinnvoll einen RODC zu nutzen um die Außendienst Mitarbeiter zu versorgen?

Wenn der Client nicht alle 30 Tage sein Computer Kennwort mit dem DC abgleicht bzw. erneuert, kickt er sich selbst aus der AD und ein Rejoin oder Powershell Befehl ist notwendig.

Hallo zusammen, Durch die aktuelle Corona Nummer haben wir alle Mitarbeiter ins Homeoffice verfrachtet. Mir ist nun aber siedend heiß eingefallen, das die Machine Account Password Richtlinie nur auf 30 Tage steht und ich aufgrund der aktuellen Lage damit rechnen muss, dass nach mir Ostern mit ziemlicher Sicherheit alle Vertrauensstellungen um die Ohren fliegen. Mea Culpa! Ich habe nun den Gedanken, alle mit einer VPN auszustatten, überlege aber ob ein RODC hierfür ausreichend ist. Kann mir jemand mit der Frage weiterhelfen ? Gruß Exchangekoala

Wäre noch eine Idee, allerdings sitzen die VMs auf dem gleichen vSwitch im ESXi. Da kann noch nichts greifen.. ? Ist auch noch kein Cluster Aufbau, das da etwas dynamisch durch die Welt wandert. Ich schaue morgen nochmal kurz nach und ansonsten fliegt der dann tatsächlich nochmal raus. ??‍♂️ Nachtrag: Jetzt hat er nach dem Neustarten keinerlei DNS Probleme mehr... whatever... Es ist immer das DNS. Danke euch trotzdem!

Die Fehlermeldung habe ich so schon gesucht. Allerdings macht sie wie beschrieben keinen Sinn, da dieser Fehler nur nach einem Neustart auftritt. Führe ich danach manuell ein gpupdate aus, verschwindet dieser aus dem Report und die GPO wird aktualisiert. DCs sind vorhanden und auflösbar, der zweite SH macht diese Faxen ja auch nicht, beide sind erst 7 Tage alt und "baugleich".

Hey NorbertFe, Danke für deine Rückmeldung. Ja Leserechte sind vorhanden. Ich habe nun festgestellt ,das der für meinen Testuser zuständige Session Host die Loopback GPO an sich nicht übernommen hat. Trotz mehrmaliger Neustarts. (Durch den Connection Broker ist der Testuser natürlich immer auf dem gleichen SH gelandet und hat anschließend keine User GPOs zu Gesicht bekommen). Erstelle ich als Admin direkt nach einem Neustart einen Report der GPO's auf dem SH, meldet dieser mir das er Netzwerk / Domäne nicht finden kann. Nach einem manuell ausgelösten gpupdate hat er keine Beschwerden mehr. Der zweite SH verhält sich nach einem Neustart regelkonform und meldet keine Fehler mit der Domäne. Hast du hierzu vielleicht noch eine Idee? Achso, die User GPO's greifen natürlich jetzt. Allerdings bereitet mir das Verarbeiten der GPO's nach einem Neustart Sorgen.

Hallo zusammen, Ich versuche auf 2x RDS Session Hosts, diverse Einstellungen per GPO umzusetzen. Leider greifen die verlinkten Richtlinien nicht? Erstelle ich ein gpresult wird für den angemeldeten Benutzer einfach keine GPO angezeigt. Nicht mal eine fehlerhafte. Der Benutzer an sich ist in einer komplett anderen OU als logischerweise die RDS-FARM, allerdings sollte er durch die Loopback GPO die dort verlinkten User GPOs doch übernehmen oder? Wo ist mein Denkfehler? Gruß exchangekoala

Ok, nach einigem hin und her hat sich herausgestellt das es an der 10er Version der Remote Desktop App auf MacOS liegt. Das Verhalten tritt unter MacOS 10.14.6 sowie auch mit 10.15.1 auf. Als Workaround kann man die 8er Version verwenden, diese verbindet sich anstandslos. Der Microsoft Support hat mir das geschilderte Verhalten gerade noch bestätigt. Siehe Foto. Also alles richtig gemacht

Hallo zusammen, Ich habe ein kleines Problem was die Bereitstellung einer RemoteApp über den Azure Application Proxy betrifft. Zuerst kurz zur Grundkonfiguration: - RDS 2019 Dienste auf mit 3 VM's, 1x Web Access + Gateway, 1x Connection Broker, 1x Session Host - öffentliches Wildcard Zertifikat mit Public Domain - Split Brain DNS angelegt - Gateway aufgrund lokaler Adresse umgehen deaktiviert - Testlauf Gateway über extern + Firewall i.O. Sprich mein Setup mit Gateway funktioniert intern wie extern einwandfrei mit Windows, MacOS und Android. Nun zu meinem Problem, ich habe mir den Azure Application Proxy eingerichtet und einen Connector auf einer anderweitigen VM installiert. Weiterhin habe ich zwei Anwendungen in der Azure angelegt, einmal für domain.net/rdweb/ und domain.net/rpc/. Für /rdweb/ Azure Authentifzierung und für /rpc/ Passthrough Authentifzierung. Test ich nun von extern funktioniert die Verbindung über Windows oder Android einwandfrei und die RemoteApp wird sauber bereitgestellt. SingleSign On Funktionalität ist noch außen vor. Versuche ich es aber nun über den Mac, erhalte ich nach letztmaliger Anmeldung in der Remoteapp den Fehler 0x607. Da der Mac keinerlei Probleme bei der internen Verwendung des Gateway hat, kann es vermutlich nur am Application Proxy liegen. Hat jemand eine Idee? MacOS Mojave mit RDP 10 App. Auch auf einem zweiten Gerät erscheint der Fehler. Was ich bereits probiert habe: - Authentifizierung auf Netzwerkebene deaktiviert - Verschlüsselung auf Niedrig gestellt - Wildcard Zertifikat auf Session Host importiert - SSLCertificateSHA1Hash in der Registry gesucht, aber dieser Wert scheint nicht mehr zu existieren. Gruß echangekoala

Konnte das Problem selbst lösen. Grund war das der Benutzer aus einer Test Synchronisierung noch im Papierkorb der Azure AD lag. Das schon gelöschte Konto konnte man dann über die Powershell endgültig löschen. Danach wurden die Benutzer korrekt zugeordnet.

Ich habe noch weiter recherchiert und herausgefunden das ich die zu übertragenden Azure-AD Attribute einschränken kann. Wäre es eine Lösung das Attribut proxyadresses aus dem Sync zu nehmen, da der UPN ja dann sowieso schon gleich der Emailadresse ist?

Hallo zusammen, Ich habe mir jetzt schon diverse Anleitungen von Microsoft durchgelesen aber noch ein Verständnissproblem. Folgende Situation: Wir besitzen aktuell eine kleinere lokale AD-Infrastruktur die ich seit Oktober betreue. Da wir sowieso schon über einen Office 365 Plan verfügen möchte ich auch gerne die Vorteile der Azure DS für uns nutzen, wie z.B. die Connectoren für SSO für diverse Plattformen wie Salesforce oder auch Atlassian. Mein Vorhaben ist nun erst einmal einen saubere Synchronisation zwischen den lokalen AD-Benutzern und den Benutzern in der Azure bzw. Office 365 herzustellen. Ich habe den Azure AD Connect installiert, mir eine Test OU mit meinem Benutzer angelegt und bin dann erstmal in den Fehler gelaufen das mein lokaler Benutzer nicht den gleichen UPN wie der Benutzer in der Cloud hatte. Sprich vorname.nachname@xxx.local anstatt vorname.nachname@yyy.de und hatte dann doppelte Benutzer. Soweit so gut, Sync beendet, UPN lokal auf vorname.nachname@yyy.de angepasst und das Ganze nochmal von vorne. Nun meldet die Azure mir aber einen Sync Fehler aufgrund eines doppelten Attributes? Und zwar das die ProxyAdresse gleich lautet. Ich dachte er bezieht sich auf den UPN ? Sehe Screenshot anbei. Ich benötige den Wert der Email aber im lokalen AD für eine andere Anwendung. Wie kann ich den Fehler beheben? Mein endgültiges Ziel ist es, das sich alle Benutzer mit ihrer Emailadresse vorname.nachname@yyy.de bei allen Diensten und auch im Windows anmelden können.

Gestern Abend alles sauber migriert und Exchange 2013 deinstalliert. Meldung taucht nicht mehr auf. :)

ok, danke für die Unterstützung. Migration läuft, ich gebe dann noch einmal Rückmeldung.

Hatte den Hintergrund das ich diese Datenbank nicht mehr richtig ansprechen konnte und ein löschen über die GUI somit nicht möglich war. Keinerlei Ordner vorhanden aber entfernen ging trotzdem nicht. ja ist nicht die saubere Variante gewesen, war aber dann die naheliegendste. ok dann verschiebe ich den Rest per Shell. Kann mir der Version Mismatch irgendwann wieder vor die Füße fallen oder sollte sich das mit der Deinstallation des 2013er erledigt haben?

Hallo zusammen, Migriere gerade einen SBS2008 zu Exchange 2013 bzw. Exchange 2016. Aktuell bin ich ohne größere Schmerzen bei der letzten Postfachmigration von 2013 CU18 zu 2016 CU5 gelandet. Hier habe ich aber nun aus Unwissenheit den Fehler begangen und nicht zuerst das "Migration" Postfach migriert. Sprich folgende Fehlermeldung: "Versionskonflikt (tatsächlich 6 erwartet 5)" Passende Google Einträge aus diesem Forum und weitere habe ich gefunden und auch getestet, wie z.B.: https://www.frankysweb.de/exchange-2016-fehler-beim-verschieben-von-postfaechern-a-version-mismatch-was-detected/ Allerdings meldet er immer noch Fehler wenn ich über die GUI einen normalen Migrationstask anlegen möchte. Meine Arbitration Postfächer sind alle auf dem 16er und Versionsnummer wurde auch angehoben. siehe screenshot anbei. Ich könnte nun die restlichen postfächer auch über die Shell rüber schubsen, habe jedoch etwas Bauchschmerzen augrund der jetzigen Fehlermeldungen bzgl. der Versionierung. Auf dem alten Exchange 2007 habe ich noch eine überflüssige Öffentliche Ordner DB per ADSI.edit entfernt. Ob hier vielleicht noch ein Zusammenhang besteht? Jemand eine Idee? Gruß