NilsK

Moin, da bist du nicht der einzige, wie man dem Artikel ja entnehmen kann. :D Ist aber auch wirklich komplex. Gruß, Nils PS. Danke für die Rückmeldung! :)

Moin, na, da steht es doch auch noch mal ausdrücklich dabei: Der WAP kann entweder "claims-based" ADFS oder Kerberos. Wenn Kerberos, dann Domänenmitgliedschaft. Wenn Claims-based ADFS, dann keine Domänenmitgliedschaft. Für die Auswahl der passenden Authentifizierung ist das gewünschte Szenario wichtig: Wer soll denn von wo aus auf den Exchange zugreifen? Vermutlich geht es ja um den Zugriff von außen, wo der User ohnehin kein Kerberos-Ticket übermitteln kann. Da ist dann Claims-based ADFS das Mittel der Wahl: Der User bekommt eine Anmeldeseite von ADFS präsentiert, an der er sich mit seinem Domänenkonto anmeldet. Damit erhält er ein SAML-Token und kann dann auf den Exchange zugreifen. Und dafür muss der WAP kein Domänenmitglied sein, weil er dann nur Reverse Proxy für den ADFS-Server im LAN spielt. In dem von dir beschriebenen Artikel wird zwar Kerberos verwendet - aber da der User eben nicht mit einem gültigen Kerberos-Ticket ankommt, muss WAP dann doch die Anmeldeseite des ADFS anzeigen. Also kein Vorteil für den User, dafür ein Nachteil für die Sicherheit (weil eben der WAP Domänenmitglied sein und daher mit dem DC im LAN kommunizieren muss). Man könnte auch sagen: Hübscher Artikel, aber am Thema vorbei. Um Claims-based ADFS zu machen, dürfte diese Anleitung hilfreich sein: https://technet.microsoft.com/en-us/library/dn635116(v=exchg.150).aspx Gruß, Nils Gruß, Nils

Moin, sagt das Eventlog was zu einem unerwarteten Absturz? Ist die VM überhaupt für Crashdumps konfiguriert? Wieviele CPU-Cores hat denn der Host, dass ihr die VM so heftig damit füttert? Gibt es dafür definierte Anforderungen? Gruß, Nils

Moin, (Hervorhebung von mir) das heißt: Wenn der Backend-Server mit Windows-integrierter Anmeldung die User anmelden soll, dann muss der WAP Domänenmitglied sein. Ziemlich klar, denn sonst wird er ja die AD-Anmeldung nicht prüfen können. Das ist aber deiner Aussage nach gar nicht das, was du machen willst, denn du willst ja ADFS nutzen. In dem Fall ist der Reverse Proxy (also hier der WAP) natürlich kein Domänenmitglied, sondern nur der dahintergeschaltete ADFS. Gruß, Nils

Moin, ah, Moment. Ich sehe gerade, dass das eine Windows-Standardmeldung ist: https://msdn.microsoft.com/en-us/library/ms838297.aspx Dann ist "may not be assigned" nicht zu verstehen als "könnte sein, dass nicht", sondern als "darf nicht". Das tritt normalerweise dann auf, wenn der User, der Owner sein soll, nicht das Recht hat, den Besitz zu übernehmen. Wenn es aber, wie bei dir offenbar der Fall, doch funktioniert hat, dann würde ich noch mal prüfen, ob die Zugriffe wie gewünscht funktionieren. Ist das der Fall, dann könnte es z.B. sein, dass die Fehlermeldung zwar zu Recht getriggert wird (Datei wird angelegt, User als Besitzer hinzugefügt, der in dem Moment gar nicht den Besitz übernehmen darf, aber das Tool schreibt ihn trotzdem erfolgreich rein), aber das in dem Moment nicht in einem "echten" Fehler resultiert. Gruß, Nils

Moin, na dann ... es steht ja auch nur dabei "may not". Vermutlich antworten die Linux-Server nicht exakt so, wie das Tool es erwartet. Aber wenn es passt, scheint das "may" ja kein "is" zu sein. ;) Gruß, Nils

Moin, 1 kannst du ignorieren. 2 ja Gruß, Nils

Moin, nur mal ins Blaue geschossen: Hat der ausführende User das Recht "Wiederherstellen von Dateien", um sich über die Berechtigungen hinwegzusetzen? Gruß, Nils

Moin, ein Zertifikat weist nach, dass der Name wirklich zu dem Server gehört. Naheliegenderweise funktioniert das nicht, wenn ein Name zu jedem Computer gehört. Auf ein Zertifikat gehört ein eindeutiger FQDN, nichts anderes. Nicht zuletzt aus diesem Grund stellen kommerzielle CAs seit einigen Jahren keine Zertifikate mehr für Namen aus, die nicht zu einer öffentlich erreichbaren Domain gehören. Gruß, Nils

Moin, die Magie liegt bei solchen Tools in der Auswertung der vorhandenen Berechtigungen. Ein Crawler sammelt alle Berechtigungen ein, schreibt sie in eine Datenbank und lässt dort Auswertungen zu. Damit lassen sich Fragen dieser Art schnell und exakt beantworten: Wer (= welche User!) kommt eigentlich an den Vertriebsordner ran? Wo hat Anne Donnicht überall Berechtigungen? Warum kommt Martin Zorn immer noch an die GF-Daten, obwohl wir ihn aus der Gruppe entfernt haben? Und spätestens das ist mit Bordmitteln kaum in absehbarer Zeit zu machen. Gruß, Nils

Moin, wo hast du denn her, dass der WAP Domänenmitglied sein müsse? Meines Wissens muss er das nicht, und Microsoft rät auch explizit davon ab. Gruß, Nils

Moin, naja, hat schon mit Rollenkonzepten zu tun, nur ganz anders. Die Idee bei solchen Tools: Gib dem Data Owner (der ja kein IT-Admin ist) eine einfache Oberfläche, mit der er einstellen kann: "Ute und Uwe sollen im Vertriebsordner schreiben und lesen dürfen." Das Tool setzt dann im Hintergrund die richtigen Gruppenmitgliedschaften (auch mit A-G-DL-P, wenn man das will) und stellt das Ergebnis dem Data Owner so dar, dass er es versteht. Gruß, Nils

Moin, wenn w32tm trotz NTP-Konfiguration die lokale Uhr als Quelle angibt, ist oft die Firewall Schuld, weil sie NTP nicht durchlässt. (Andere Variante wären Tippfehler usw.) Wobei ich auch dringend zu Jans Hinweis rate. (Da muss die Firewall aber trotzdem NTP durchlassen.) Gruß, Nils

Moin, im Zweifel das ganze Rumgeschiebe mit den Gruppen. Die Idee bei so einem Tool ist, dass der Data Owner (z.B. der Abteilungsleiter) das selbst machen kann, ohne die IT behelligen zu müssen. Das Tool sorgt dann dafür, dass alles mit den Gruppen passt. Ist schon eine feine Sache. Gruß, Nils

Moin, öffne auf einem der beteiligten PCs mal ein CMD-Fenster als Admin. Führe dort aus: gpresult /R /Scope computer Taucht die Gruppe im Resultset auf? Falls nicht, prüfe mal das Ereignisprotokoll. Falls der Rechner wirklich im AD in der Gruppe Mitglied ist und seither neu gestartet wurde, scheint da etwas bei der Anmeldung des Rechners falsch zu laufen. Das sollte sich im Ereignisprotokoll niederschlagen. Gruß, Nils

Moin, wie XP-Fan schon sagt, ist das eine wenig sinnvolle Aufteilung. Bereich 1 hat so gut wie kein I/O. Bereich 2 hat wenig I/O. Bereich 3 ist der, wo die Leistung herkommen muss. Gruß, Nils

Moin, DHCP beruht auf dem Broadcast-Verfahren. Wenn du zwei DHCP-Server im Netz hast, antworten beide. Derjenige, von dem der Client als erstes eine Antwort bekommt, erhält dann den Zuschlag. Das kann mal dieser, mal jener sein. Daher hat man auch nie mehr als einen DHCP-Server in einem Netzwerksegment (von Redundanzkonzepten mal abgesehen). Gruß, Nils

Moin, bevor wir weitere konkrete Vorschläge zur Umsetzung machen, sollten wir vielleicht abwarten, ob der TO denn noch weitere Anforderungen nennt. Sonst ist das wenig zielführend. Gruß, Nils

Moin, ich habe die Konfig von 2. und 3. noch nicht verstanden. Die VMs sind auf 2., also SSDs. Und was für Speicher ist 3.? Was genau liegt da, und wie ist das konfiguriert? Und wie genau testest du da? Handelt es sich bei 2. um Enterprise-SSDs? Gruß, Nils

Moin, das AD hat kein Problem damit, mehrere Domänen im selben Subnetz zu betreiben. Alles andere wäre dann Frage des Konzepts und der Anforderungen, zu denen ja anscheinend noch nichts Belastbares bekannt ist. Ein einzelner DC ist bei 15 Usern nicht genug. DHCP hat mit dem AD nichts zu tun. Gruß, Nils

Moin, OK, dann klingt das für mich, als sollte man die vorhandene PKI einfach wegwerfen und eine neue ordentlich aufbauen. Gruß, Nils

Moin, Mach es doch lieber ordentlich. Neuen Server mit aktuellem OS und aktuellem SQL. Datenbank vom alten Server sichern und auf dem neuen wiederherstellen. P2V kann gehen, muss es aber nicht. Vor allem nicht mit antiken Systemen. Gruß, Nils

Moin, der DC wird durch das Entfernen der PKI nicht beeinträchtigt. Gruß, Nils

Moin, ob Admin oder nicht, ist für dein Problem ohne Bedeutung. Trotzdem ist es natürlich nicht OK, dass User auf einem PC Adminrechte haben, schon gar nicht auf so einem PC. Das Phänomen, das du beschreibst, ist so. Das wirst du auch nicht wirksam umgehen können, solange der Shared User auf dem Rechner angemeldet bleibt. Sinnvoll wäre also der Umstieg auf personalisierte Konten auf diesem Rechner. Den Anmeldevorgang könnte man ja ggf. vereinfachen, z.B. über eine PIN-Anmeldung an diesem Rechner. Gruß, Nils

Moin, naja, immerhin ist das Problem identifiziert und behebbar. Jetzt, nach deinem Hinweis, finde ich dazu auch dies. Das gab es bislang nicht als Requirement, weil die Port-443-Verbindung an der Stelle ja neu ist. https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/overview/ad-fs-2016-requirements Danke für die Rückmeldung! Gruß, Nils