cj_berlin

vor 5 Minuten schrieb NilsK:

Wichtig ist, dass der Account wirksam geschützt ist. Und dafür ist und bleibt die wichtigste Maßnahme, ihm ein sehr langes Kennwort zu geben

...und das Konto danach möglichst nicht mehr zu benutzen, außer im Notfall.

vor 6 Minuten schrieb NilsK:

hmja, kann man machen, aber in Wirklichkeit ist das Schlangenöl. Wer "den" Administrator angreifen will, kann ihn leicht anhand seines RID -500 identifizieren, egal, wie der Account heißt

...und genau deswegen sollte man es auch lassen. Im Troubleshooting-Fall behindert es den dazugerufenen Externen mehr als im Angriffsfall den Angreifer.

vor 9 Stunden schrieb NorbertFe:

https://github.com/spgoodman/ExchangeRecipientAdmin

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

vor einer Stunde schrieb daabm:

 

Ok, und wo ist das noch relevant? Ich hab noch nie einen Forest gesehen, in dem nicht jeder DC auch GC war - aber ich lasse mich gerne aufklären, warum man das noch machen sollte

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?

vor 57 Minuten schrieb NorbertFe:

Ok, und warum muss dazu jemand lokaler Admin sein?

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.

vor 1 Stunde schrieb dmks.23:

Quelle: ESE  ID: 225

Quelle: MSEXCHRepl ID: 2046

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.

vor einer Stunde schrieb NilsK:

dabei verlieren die doch ihren SID, oder?

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

vor 5 Minuten schrieb daabm:

UPN/sAMAccountName/CN etc. bekommen einen Timestamp, 

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". 

vor 4 Minuten schrieb teletubbieland:

Da hast Du schon Recht. Aber wie soll die Regel denn Aussehen ?

Kann man denn in der Regel unterschieden, ob etwas per SMTP am besten noch von einer bestimmten IP gesendet wird ?

Ich will ja nicht jede Mail zusätzlich im gesendet stehen haben.

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...

vor 10 Minuten schrieb teletubbieland:

Das dieser Mails annimmt unter weiter schickt an den Exchange. Dann sollte es unter gesendet auftauchen.

Alternativ auch einfach lokal einen SMTP Auth installiert.

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

vor 21 Minuten schrieb teletubbieland:

Ich vermute, dann ist die Sache mit einem kleinen Mailserver davor einfacher

...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.

vor 3 Stunden schrieb phatair:

 

Meine Frage ist jetzt, kann ich diesen msDS-CreatorSid Eintrag irgendwie löschen oder muss ich dazu das Gerät aus der Domäne nehmen und wieder aufnehmen?

Seht ihr es als kritisch an, wenn das msDS-CreatorSid Attribut bei den Server gefüllt ist, auch wenn es sich dabei um SIDs der aktuellen Server Admins handelt?

In Bezug auf LAPS sollte das ja kein Sicherheitsrisiko darstellen, da diese Accounts das LAPS Passwort sowieso lesen dürfen und wenn einer der Admins nicht mehr im Unternehmen ist, wird der Account sowieso deaktiviert.

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...

vor 7 Minuten schrieb Nobbyaushb:

pst auf shares sind nicht supportet!

...es sei denn, der Zugriff erfolgt von Terminalservern oder VDI  

Man sollte es dennoch lieber lassen.

vor 6 Minuten schrieb sg08234:

Ich tue mich nur mit im Freitext lesbaren Kennworten schwer (ist aber vielleicht eh egal).

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.

vor 7 Minuten schrieb RalphT:

 

Frage:

Ist jetzt eigentlich nur noch für diese Richtung Bedarf? Werden demnächst keine Admins mehr gebraucht, die sich mit den physischen Servern vor Ort auskennen müssen?

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.

vor 20 Minuten schrieb sg08234:

Meines Wissens nach wird ein GOP-Anmeldeskript aber eh immer mit erhöhten Rechten ausgeführt

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

vor 18 Minuten schrieb sg08234:

Der Benutzer hat Admin-Rechte.

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.