cj_berlin

Wenn das ein halbwegs ordentlich programmiertes Produkt mit einem halbwegs ordentlichen Installer ist, ist die Software nach der Installation für alle angemeldeten Benutzer verfügbar.

Moin,

welches ist denn "die Software"? Ich mache in letzten Jahren (wieder) relativ viel MDT, und "die Software", nachdem sie unter dem Administrator-Account installiert wurde, steht in der Regel allen anderen Benutzern ebenfalls zur Verfügung. Das würde man ja auch sonst so machen, bei einem Rechner, der bereits im Betrieb ist: Wird neue Software benötigt, wird sie mit administrativen Rechten für alle installiert...

Da sehe ich schon die Schlagzeile: "DSBs steigen deutschlandweit auf Linux um, um den Druck auf Microsoft zu erhöhen"  

Moin,

Windows speichert da gar nichts. Jeder Browser pflegt die Autocomplete-Daten für sich.

"Einfaches Adressbuch zur Nutzung im Netzwerk" ist sehr schwammig. Was soll denn mit den Adressen geschehen?

Moin,

was steht denn (beispielhaft) in $Name und $Path ?

vor 16 Minuten schrieb spooner:

Weil das Problem ist ja trotzdem, das wenn die VM gehackt/infiziert wird, dass es dann auf den Host übergehen kann.

"VM escape" ist eine extrem rare Geschichte und meist nur unter Laborbedingungen reproduzierbar. Nimmt man diesen Angriffsvektor aber als konkrete Gefährdung an, folgt daraus, dass auch der Host, auf dem die DMZ läuft, mit seinem Management-Interface nicht im LAN stehen darf (und somit auch nicht Mitglied des produktiven AD ist). Der nächste logische Schritt ist dann, dass auch für die Verwaltung dieses Hosts eine Admin-Workstation verwendet werden muss, die im DMZ-Management-Netz steht und nicht im LAN.

Jetzt muss man sich aber die viel profanere Frage stellen: Wenn Du eine Edge-VM on-prem hostest, muss sie vermutlich mit irgendwelchen Systemen im LAN kommunizieren und sich gegenüber diesen direkt authentifizieren, Sonst könnte man sie ja für schmales Geld in irgendein Shared Hosting stecken. Ist das nicht eine viel konkretere Gefährdung als die theoretische Möglichkeit, dass jemand die VM nicht nur übernimmt, sondern auch daraus ausbricht?

Wenn das die Erklärung für den Eintrag im AD ist, ja.

Moin, 

wenn der Key, z. B. im KMS, Enterprise ist, wird eine Pro-Installation zu Enterprise und umgekehrt. 

vor 32 Minuten schrieb stefan4711:

Was mich viel mehr beunruhigt, ist die Tatsache, dass die  Egebnisse mit dieswm Cmdlet anscheinend nicht stimmig sind.

Du ziehst doch Daten aus dem AD. In diesem kannst Du ja auch mit den GUI-Tools nachschauen, welche Werte bei welchen Objekten in welchen Attributen stehen. Das AD weiß übrigens nicht, welches Betriebssystem auf dem Rechner Deines Kollegen jetzt installiert ist. Dort steht nur, welches Betriebssystem unter diesem Namen dem AD beigetreten ist.

Wenn das Cmdlet andere Werte liefert als dsa.msc., dann sind die Ergebnisse nicht stimmig. 

Moin,

alles, was Du mit Select-Object auswählen möchtest und was keine Standard-Property ist, musst Du natürlich zuerst in Get-ADComputer zu den -Properties hinzufügen, damit das auch aus dem AD geholt wird  

vor 2 Stunden schrieb NorbertFe:

Wenn man die alle immer lesen und verstehen wollte, dürfte man nix anderes mehr tun. :/

Das ist aber für den Cloud-Admin der eigentliche Preis dafür, dass er sich nicht mehr mit Servern herumschlagen muss.

Moin,

das wird davon abhängen, wie Deine DMZ gestrickt ist. Meistens sind das separate Switche und separate Beine auf den Routern. In diesem Fall einfach eine zusätzliche Netzwerkkarte im Host und einen zusätzlichen vSwitch. Und das wäre absolut eine "sinnvolle Lösung"  

Nein, im Default trägt Exchange jeden neuen Termin "blassgrau-transparent" ein. Wenn der Nutzer bestätigt, sind sie gebucht, wenn er ablehnt, werden sie gelöscht.

Und wenn Exchange das nicht macht, kann Outlook das auch  Da gibt es die entsprechende Option, die man dann auch setzen muss.

Aber es gibt User, für die diese Geschichte praktisch Teil ihrer Arbeitsweise geworden ist...

Im allerletzten Screenshot, ist rot markiert.

vor 4 Minuten schrieb shooan:

Nein das geht leider auch nicht. Da dazu ja ein Outlook offen sein muss.

Nein. Wenn Du "vom Server beantworten" und nicht "beantworten" wählst, muss Outlook nicht laufen. Allerdings müssen automatische Antworten für alle Remote-Domains erlaubt sein.

Aber Exchange Rules Pro oder ein ähnliches Third Party-Produkt ist in der Regel jeden Cent wert

vor 58 Minuten schrieb rakli:

Da sich die Benutzeranmeldung "Prä-Windows 2000"  und UPN unterscheidet, wäre es elegant die Werte in Azure direkt abzufragen.

Das verstehe ich nicht ganz. Der sAMAccountName wird im Azure AD nicht verwendet, da jede Azure AD-Anwendung ja als erstes das Verzeichnis identifizieren muss, gegen das der Anmeldename zu validieren ist. Somit bekommst Du aus dem Graph (wie oben beschrieben oder mit dem AzureAD Preview-Modul) den sAMAccountName des synchronisierten on-prem-Accounts.

Moin,

mit einer Transportregel geht es nicht, wohl aber mit einer Postfachregel. Da gibt es die Action "Diese vom Server mit einer Nachricht beantworten".

Das einfache Ticket-System von Atlassian ist Jira. Nimmt man die Atlassian-Produkte aus der Cloud, so gibt es in Microsoft Docs sogar einen Integrationsleitfaden für Azure AD. 

Das war der Ingenieur  Aber als Physiker kann ich das nur bestätigen. 

Moin,

sorry, falls es oben schon erwähnt wurde: Hat der User, den Du suchst, das UPN-Attribut tatsächlich belegt? Man kann nämlich durchaus User ohne UPN erzeugen. Für Kerberos wird dann zwar der implizite UPN (sAMAccountName@Default.Suffix.Der.Doma.In) verwendet, beim Suchen wird der User aber nicht gefunden.

Moin,

aus Deiner Ausführung ist noch nicht klar, ob die Bedrohungslage ("wie anfällig ist die konkrete Infrastruktur in der konkreten Branche/Umsatzklasse am konkreten Standort für zukünftige Angriffe?") oder der Bereitschaftsgrad ("wie robust sind die IT-Management-Prozesse und die IT-Infrastruktur darunter gegenüber möglichen Sicherheitsvorfällen?") gemessen werden soll. Ob die Kennzahl das eine, das andere oder die Kombination daraus abbilden soll, entscheidet darüber, welche Einzelindikatoren in welcher Gewichtung zu verwenden sind.

Moin,

standardmäßig ist es so ("darf", "möglich" usw. sind technisch, nicht organisatorisch zu verstehen!):

• niemand (mit Ausnahme des Besitzers) darf in den Kalender einer Ressource direkt schreiben
• Buchung der Ressource ist nur durch eine Buchungsanfrage möglich. Die Anfrage wird von der Ressource abgelehnt, wenn mehr als X% der Termin-Instanzen mit bereits gebuchten Terminen kollidieren. Es kann eingestellt werden, ob die Ressource freie Termine sofort bestätigt oder an den Moderator weitergibt, der sie dann bestätigt oder ablehnt.
• Es können Benutzergruppen ("In-Policy") die kollidierende Termine überbuchen dürfen. Der ursprüngliche Termin wird dabei von der Ressource aber nicht abgelehnt.

Insofern dürfte der von Dir geschilderte Fall mit Standard-Einstellungen nicht vorkommen. Wenn Du Benutzern das Schreibrecht auf den Kalender der Ressource gibst, können sie eben dort schreiben, löschen usw. Nimm ihnen die Rechte weg, und das Problem ist gelöst.

Dann fehlt Dir jetzt eine schließende Klammer am Ende

For the record: es ist tatsächlich möglich, einen User anzulegen, dessen sAMAccountName ^ ist  Das werde ich mir jetzt beim Kunden immer wünschen  

Was bedeutet ein Hütchen denn in LDAP?

Und ja, bei den Klammern muss ja immer die Anzahl der Öffnenden gleich der Anzahl der Schließenden sein...