cj_berlin

Das aber mit Support von MS, weil es ja das neue RecipientManagement Snap-In verwendet.

Du würdest Dich wundern, wie viele "Verzeichnisdienst-Architekten" und Admins sich in den Design-Workshops den Sachverhalt noch erklären lassen... Das gleiche bei der Platzierung von FSMO-Rollen

Moin, das kannst Du alles machen, nur gehört der Lizenzserver ja nicht inhaltlich zu einer bestimmten Bereitstellung, sondern kann mehrere Bereitstellungen, einzelne Server usw. bedienen.

Moin, auf den DC kommt gar nichts drauf außer DC + DNS, also auch kein Broker. Gründe sind vielfältig und liegen tatsächlich nicht nur im Bereich Security. Aber auch dort. Von allen RDS-Rollen ist der Lizenzserver die einzige, die ich mich unter Umständen noch zwingen lassen würde, auf einem DC unterzubringen. RDWeb + RDG zusammen kommt darauf an, ob man RDWeb auch extern veröffentlichen möchte. Falls nicht, wäre Broker + RDWeb eine mögliche Alternative, dann kommt man für beide mit einem Zertifikat aus. Wieviele Sessions auf einen RDSH kommen, kommt auf die Ausstattung des RDSH an. Ich habe durchaus Session Hosts mit dreistelligen Userzahlen betrieben, aber die waren dann meistens Physik.

Warum müsstest Du dafür irgendwas neu machen? Und warum gibt es dafür bereits zwei Postfächer?

Na aus Gründen natürlich!

Moin, wenn der Zeitstempel korrekt gesetzt wird, scheint alles zu funktionieren. In einer DAG werden ja mehr Logs vorgehalten, wenn mehrere Kopien vorhanden sind, daher würde ich etwas mehr Zeit zwischen den Backups verstreichen lassen, so dass vielleicht ein paar Tausend Logs auflaufen, und dann schauen, wieviele davon verschwinden.

Danke für das Vertrauen darauf, dass wir alle Event IDs von Exchange auswendig können. Aber mal anders gefragt: Nach einem Backup mit zwei Kopien, wird da der Backup-Zeitstempel auf der Datenbank gesetzt? Falls ja, hast Du kein Problem, und es sind in der Tat "zu wenige" Logs.

Moin, wenn Logs nicht gelöscht werden können, wird es im Application EventLog protokolliert. Auch wenn sie abgeschnitten werden, wird es dort protokolliert. Dass man nach dem Hinzufügen und Entfernen von Kopien den Information Store neu starten muss, hast Du berücksichtigt? Sicherst Du die aktive oder die passive Kopie? Falls die aktive Kopie klappt und die passive nicht, ist die Cluster-Kommunikation kaputt. Exchange schneidet die Logs nicht auf Null an, sondern behält einige. Vor Einführung der DAG waren das, meine ich, acht (á 5 MB), ab Exchange 2010 sind es mehr, allerdings á 1MB, 100 könnte hinkommen.

Nö, auch Verteilergruppen haben eine SID. Die kommt nur nicht in den Anmeldetoken der Mitglieder.

Ist bei euch irgendwas davon mit personenbezogenen Informationen verknüpft oder alles generisch? Sprich: Wenn eine Lisa Müller bei euch anfängt, kriegt sie dann muellerl2, obwohl aktuell keine L. Müller in dieser Domain beschäftigt ist, aber mal beschäftigt war?

Moin, das Stichwort lautet "Shared Activation".

SenderIPRange ist eine valide Bedingung für die Mailflow Rule. Und diese Rule könnte dann beispielsweise etwas in den Betreff reinschreiben, was die Mailbox Rule dann auswerten und daraufhin die Mail in "Sent Items" verschieben würde. Das wäre auch eine Server-Regel, unabhängig von Outlook...

Aber er schickt sie doch auch nur per SMTP weiter, da hast Du nichts gewonnen????

...und was würde damit erreicht werden?

Moin, AFAIK ist das nur bei Exchange Online möglich. On-prem werden Mails, die über SMTP mit Authentifizierung eingereicht werden, nirgends gespeichert (außer beim Empfänger, wenn er intern war). Hier Flashback: Auf diese Idee sind schon einige gekommen, und ich meine, es gibt auch ein Tool, welches das macht. Wenn es nur um den Nachweis geht, kannst Du das ja per Mailflow Rule kennzeichnen und zurück an die Mailbox schicken, und dort per Mailbox Rule anhand der Kennzeichnung in Sent Items verschieben. Oder so.

Moin, nein, der Wert im Attribut verleiht dem User keine Berechtigungen am Computer-Objekt - meistens wird der User aber auch Owner sein, und daraus leiten sich die Rechte an, wenn auch nicht automatisch. Das ist aber per se ein Problem. Das Attribut ist nur dafür da, das MachineQuota überwachen zu können.

Moin, hast Du mal probiert, es zu löschen? Warum sollte das kritisch sein? So wie es jetzt ist, ist der jeweilige Admin ja vermutlich sogar Owner des Computer-Objektes - das wäre evtl. kritisch, wenn das Admin-Account kompromittiert wird. Aber die SID eines Accounts kann doch jeder lesen, also nicht "Jeder", sondern jeder Und welchen Bezug hat es zum LAPS? Wenn ein Angreifer wissen will, wer LAPS-Attribute lesen darf, fragt er auch danach und nicht nach obskuren Attributen...

...es sei denn, der Zugriff erfolgt von Terminalservern oder VDI Man sollte es dennoch lieber lassen.

Das ehrt Dich - ist aber in diesem speziellen Fall vermutlich eh egal, denn wenn ich einen Deiner User phishe (hat Adminrechte, wir erinnern uns!), komme ich an CredMan aller lokaler Benutzer auf dieser Maschine so oder so ran.

Ich glaube, dieses Forum ist der falsche Ort, um auf diese Frage eine objektive Antwort zu erwarten. Klar werden weiterhin Admins gebraucht, aber bei offiziellen Lehrgängen sind die Schulen ja nicht ganz unabhängig von den Herstellern, und die pushen ja sehr stark in die Cloud. Man findet aber durchaus gute Weiterbildungsmöglichkeiten zu den klassischen Themen, so bei https://www.it-administrator.de/trainings/ oder auch bei anderen Verlagen.

Hast Du da auch ne Quelle zu, aus der Dein Wissen stammt?

Und spätestens hier ist es dann vollkommen wurscht, welche vermeintlichen Sicherheitsmaßnahmen Du wo ergreifst. Leg einfach auf dem Master-PC gleichlautende Konten mit gleichen Kennwörtern an, sensibilisiere die User, dass sie die Kennwortänderungen 2x machen müssen, und vergiss den ganten CredMan-Kram.

So etwas wäre ja auch nur beim Versand aus Funktionspostfächern überhaupt zustimmungsfähig. Wenn eine Mail mit einem persönlichen Absender vor Verlassen der Organisation ohne Wissen des Absenders bearbeitet werden kann, müsste das die Beschäftigtenvertretung sofort auf die Barrikaden treiben. Und in der Tat ist ein solcher Workflow im DMS eher zu Hause als im Mailsystem.

Warum ist IPMI böse? (Immer vorausgesetzt, Hardware-Managrment ist vom produktiven Traffic getrennt)