cj_berlin

Ja, der Begriff ist sehr schlecht gewählt, denn bei allen Subnetzmasken kürzer als 28 sind die vier Adressen alle im gleichen Subnetz und die Kommunikation erfolgt direkt zwischen 192.168.0.2 und 192.168.0.21 ohne irgendwelchen "vias". Auf IP-Ebene. Auf Layer 2 sieht es natürlich anders aus, aber da ist es auch wurscht, ob die Switche überhaupt managebar sind und IP-Adressen haben, denn die Ethernet-Frames gehen ja nur von MAC zu MAC und nicht von IP zu IP. Ich lese also heraus, Du willst quasi Kabel verfolgen. Da solltest Du etwas suchen, was LLDP kann.

Die Logs kannst Du gern mit PowerShell auslesen. Aber die Daten sind nur in den Logs enthalten. Wenn Auditing aktiv ist.

Moin, nur aus den Event Logs, sofern Auditing aktiv ist.

Moin, das hilft Dir zwar jetzt nicht direkt, aber kannst Du für unser besseres Verständnis erklären, warum es notwendig wurde, die VM neu einzurichten, statt sie mit Hyper-V-Mitteln auf ein anderes Volume und dann zurück zu verschieben? Welche Version ist der Host? Welche Netzwerkkarte hast Du eingesteckt? Hast Du versucht, die alte Netzwerkkarte zuerst sauber zu deinstallieren - per devmgr_show_nonpresent_devices=1 ?

Du müsstest mal Deine Anfrage nochmal etwas präzisieren. Brauchst Du etwas, was die Physik mappt (also Switches, Ports, WLAN-Verbindungen) oder IP (wo dann Switche und WLAN egal wäre)? Denn Deine Skizze liegt komplett in einem einzigen Subnet; auch sprichst Du von ARP, was ebenfalls nur in jeweils im eigenen VLAN funktioniert. Auf der anderen Seite sprichst Du von "Routen", was ja mehrere Subnetze und vermutlich auch mehrere VLANs vermuten lässt. Was also nun? Für die Physik helfen LLDP, CDP, evtl. tatsächlich auch ARP. Für IP musst Du mit Routern sprechen, das wären dann andere Protokolle.

Doch, ich. Aber von MAPI over HTTP, nicht von SimpleMAPI. Schon, aber mit einem freigegebenen Postfach solltest Du dich nicht authentifizieren können, da das Konto von einem Solchen ja deaktiviert ist

Deinem Kunden erklären, dass diese Funktionalität zwar in Exchange Online existiert, on premises hingegen weder umgesetzt noch vorgesehen ist. entweder das ERP-System überzeugen, MAPI oder EWS für den Mailversand zu nutzen (fällt vermutlich flach) oder tricksen: Du könntest beispielsweise per Transportregel die Mails an ein Postfach schicken. Dort würden sie zwar im Eingang und nicht in den Gesendeten landen, aber wenn es eine Ressourcen-Mailbox ist, in der sonst gar nichts landet, wäre es vielleicht als kosmetischer Fehler akzeptabel? Nachtrag: Du könntest natürlich auch ganz übel tricksen und die Mails per Transportregel CC/BCC an das Absender-Postfach schicken lassen. Dort baust Du dann eine Postfachregel nach dem Motto "Mails, die von mir kommen, verschiebe in die Gesendeten"

Roaming Profiles sind super, solange man sie nicht zum täglichen Roaming benutzt, sondern nur zum gelegentlichen permanenten Rechnerwechsel. Verbessern die User Experience bei Letzterem ganz erheblich.

<OT>Wissen vs. Tool </OT>

Siehe https://gist.github.com/Manouchehri/fd754e402d98430243455713efada710

Aber die TSA hat doch nichts mit CA zu tun. Ich kenne auch niemanden, der eine TSA selber betreibt, ob die CA nun von Microsoft ist oder von anderen.

https://docs.microsoft.com/en-us/windows/win32/secauthz/well-known-sids

Moin, um das ein wenig aufzuräumen: Timestamping ist wichtig und richtig, hat aber nichts damit zu tun, wo das Signierungs-Zertifikat herkommt. Letzteres kann selbstsigniert, aus eigener PKI (vermutlich meint der TO das mit "auf dem DC" ) oder gekauft sein. Das Vertrauen der Clients muss man so oder so herstellen. Wie man ein Zertifikat "testen" kann, ist relativ unklar - vermutlich bekommst Du ein Zertifikat, das zwei Wochen gültig ist. Da kannst Du auch gleich ein selbstsigniertes nehmen. Denkt daran: In Office kann man nach wie vor nicht sagen "nur Skripte mit Signatur von Anbieter X, Y und Z zulassen". D.h. wenn ihr signierte Makros generell zulasst, könnte ein Angreifer einfach ein Makro signieren, und das wäre zugelassen. aus https://support.microsoft.com/en-gb/office/macros-in-office-files-12b036fd-d140-4e74-b45e-16fed1a7e5c6

Man kann schon, es ist nur nicht supported.

Moin, was passiert denn, wenn Du auf dem Windows 10-Client den IMAP-Sync manuell initiierst, dann den Client bootest und dich danach gleich wieder dort anmeldest, ohne Schwenk auf Windows 11? Funktioniert der Sync dann automatisch? Falls ja, dann müsstest Du vermutlich die OST roamen...

Hat er ja. pfSense Router, auf dem NUT läuft. Nur kann anscheinend NUT nicht so gut mit Windows...

Der Einwand von @NilsK ist aber nicht von der Hand zu weisen - wenn Benutzer aus "ihren eigenen Strukturen" kommen, das heißt, nicht eurer Organisation angehören und ihre Geräte auch nicht, wird die Lizenzierung des Ganzen richtig spannend. Nächste Frage, um Dich von Network Traces als Methode zur Logon-Protokollierung abzuhalten: Könnt ihr die benötigten Daten nicht aus dem VPN ziehen? Dort lassen sie sich vielleicht sogar einem User zuordnen, denn die IP, welche der VPN-Server vergibt, ist ja vermutlich nicht für jeden User fix...

Authentifizieren tun sich die User aber trotzdem. Insofern hat der Einwurf von @daabm auch ohne AD Bestand. Oder verbinden sie sich direkt zur Datenbank auf einem Datenbark-Port und mit der dort vorhandenen internen Authentifzierung?

Moin, grundsätzlich schon, Einstieg hier: https://docs.microsoft.com/de-de/windows/win32/wmisdk/changing-access-security-on-securable-objects Besser ist jedoch

Deutlich. Ich kann die guten Erfahrungen, die @Sunny61 gemacht hat, dennoch nicht 100% bestätigen. Allerdings sehe ich als Consultant natürlich nur die Problemfälle, meine Betrachtung ist also alles andere als objektiv

Moin, ein Tip: Wenn Du Skript-Code, Configs, CSV-Dateien usw. postest, verwende bitte den Code-Button (links neben dem Smiley). Das erlaubt den Helfenden, den Text verlustfrei in den Editor ihrer Wahl zu kopieren und, wenn es eine unterstützte Sprache ist, gibt es sogar hier im Forum schon Syntax-Hervorhebung. Ansonsten: Da bei Dir HideEULAPage auf true steht, der Lizenzvertrag aber laut Deinem Post dennoch angezeigt wird, läuft da grundsätzlich irgendwas falsch. Zu den weiteren Punkten, die bei Dir noch fehlen, hier: https://docs.microsoft.com/en-us/windows-hardware/customize/desktop/unattend/microsoft-windows-shell-setup-oobe

Nö. Die Aussage war lediglich: Keines dieser Systeme muss in Besitz eines Accounts (Name + Passwort) sein, das Mitglied in DA ist. Dass ein Management-System in Tier0 auch ein Tier0-System ist, ist unbestritten.

Wenn Du auf die Konfiguration des Servers keinen Einfluss hast, kannst Du es vermutlich nicht verhindern. Du müsstest ja quasi einstellen, dass der Benutzer (der sich authentifiziert) Mails nur an eine Adresse senden darf (z.B. an seine eigene). Dann kann aber jemand, der im Besitz der Zugangsdaten ist, auch per IMAP in dieses Postfach reinschauen... Mir würden da ein paar krude Bastellösungen einfallen, aber das möchte ich hier nicht ausbreiten.

Hast Du da auch einen Beleg zu? Wenn ich mich noch richtig erinnere, fehlte die RDS-Rolle im Technical Preview. Daraufhin bloggte Ryan Mangan, dass Multisession Win10 jetzt die Zukunft von RDS wäre. Ryans Blog ist aber kein Indikator für die Strategie von Microsoft, und ein Technical Preview ist nur ein sehr grober Indikator für die zukünftigen Features. Im RTM war RDS komplett drin.

Ja, aber dieser SMTP sollte, zumindest mit den Anmeldedaten, nicht weitersenden. Denk Spamschleuder.