cj_berlin

Moin,

Family Safety bezieht sich nur auf Microsoft-Konten privater Art (ehem. LiveID). Konten aus dem lokalen AD sind in der Cloud nicht bekannt und können nicht über den Cloud-Dienst Family Safety verwaltet werden.

vor 12 Minuten schrieb info@vision4d.de:

Da Username mir nur die 2-4 Buchstaben liefert ( hier wird sich noch mit WIN2000 Notation angemeldet) bringt mir das auch nicht viel.

1. selbst Windows NT konnte schon 15 Zeichen  

2. Und? Es kann zwei Michael_Mueller in eurer Umgebung geben, aber die werden trotzdem unterschiedliche sAMAccountName-Werte haben müssen.

vor einer Stunde schrieb NilsK:

[Ordnerumleitung – Denial of Service in Wartestellung | faq-o-matic.net]
https://www.faq-o-matic.net/2011/11/14/ordnerumleitung-denial-of-service-in-wartestellung/

Das stimmt, nichts in der IT ist vollständig problemfrei. Aber das im Artikel beschriebene Problem lässt sich bereits dadurch drastisch reduzieren, dass man %APPDATA% nicht umleitet. In dem vom TO beschriebenen Szenario geht es ja nicht um Roaming, sondern dadurch, den Usern die Möglichkeit zu geben, ihre Dateien über eine einheitliche Vorrichtung auf einem Fileserver abzulegen.

Moin,

für sowas gibt es mit Bordmitteln das Homedrive.  Dafür kann Windows %USERNAME% abbilden und andere Dinge, für die es Umgebungsvariablen gibt. Vielleicht arbeitest Du mit dem, was out of the box vorhanden ist, und erfindest nicht das Rad neu.

Besser, viel besser allerdings ist es, wenn Du es mit Laufwerkmappings sein lässt und beispielsweise mit Ordnerumleitungen arbeitest (auch da ist %USERNAME% Dein bester Freund). Dann hat der User das "Laufwerk" jederzeit im Explorer unter "Dokumente". Laufwerkmappings sind von vorvorgestern und bringen mehr Probleme mit sich als sie jemals zu lösen vermochten.

Moin,

siehe Abschnitt "GSSAPI" unter https://linux.die.net/man/5/ldap.conf . Allerdings ist es in Bezug auf ein mögliches Abhören von Credentials nicht sicherer als was ihr jetzt macht, nur in Bezug auf Replay. Ihr solltet daher überlegen, ob nicht die Zeit gekommen ist, euren DCs Zertifikate zu verpassen und auf LDAPS zu wechseln.

@NilsK wird gleich sagen, PKI ist böse, wenn man nicht weiß, was man tut, und er hat nicht unrecht. Andererseits, Credentials unverschlüsselt übertragen ist auch böse.

vor einer Stunde schrieb BOfH_666:

Falls es ein Script sein soll, wäre meine Empfehlung es mit PowerShell zu machen.

ich glaube, das meint er mit "PWS"  

Genau. Also ist in Deiner Applikation irgendwo eingestellt, dass die Verschlüsselung zu verwenden ist. Ich meine, in der neusten Version der OLEDB-Komponenten ist sie es per Default. Also musst Du es im Connection String deaktivieren, sofern Du Zugriff darauf hat.

Besser ist natürlich, wenn Du am Server ein Zertifikat einspielst, dem Deine Clients vertrauen, und Daten, wie Ende 2021 dringend geboten, verschlüsselt überträgst...

...aber wenn nachweislich kein Zertifikat am Server eingespielt, dürfte das scheitern.

vor 10 Stunden schrieb home:

Gestern musste ich mich einmal als Administrator (Domänen-Admin) anmelden, damit ich eine Software updaten konnte.

Moin,

das ist jetzt nicht auf Dein Problem bezogen, muss aber dennoch gesagt werden: Niemals *muss* sich ein Domain Admin an einer Workstation anmelden; es sei denn, es ist eine dedizierte und extrem gehärtete Privileged Access Workstation (PAW).

Zu Deinem Problem aber: Ich würde vermuten, dass eher die Installation der Updates als die blosse Anmeldung als Admin das verursacht hat. Es sei denn, jemand hat die Profile so verbogen, dass jeder User auf dasselbe Profilverzeichnis zeigt. Dann hat der Admin mit seinen Rechten Besitz von der Registry und den DPAPI-Schlüsseln nehmen können, der User konnte den Besitz aber nicht wieder "zurückerobern".

vor 5 Stunden schrieb Bumbum:

Es ist schwierig herauszufinden wie oft das passiert, da durch die immer mal wieder falsche Systemzeit auch die Zeitpunkte in der Ereignisanzeige falsch sind. Seit meinem Post heute früh ist es aber schon wieder passiert.

...aber das Debug Logging des Windows Time Service ist eine Textdatei und wird immer sequenziell geschrieben  Das solltest Du mal aktivieren, auf die höchste Stufe drehen und einen Tan lang mitlaufen lassen.

Moin,

keine (mir bekannte) Lösung wird lokale Benutzer provisionieren. View und XenDesktop können beide SAML, aber die haben ja auch einen Agenten, der diese Authentifizierung empfängt. Und dennoch wird vorausgesetzt, dass es diesen User schon gibt und dass er sich da anmelden kann.

Die von Dir angestrebte Lösung hat aber auch lizenzrechtliche Auswirkungen, die Du beleuchten solltest, bevor Du technisch weiter designst. Soll der Zugriff per User oder per Device lizenziert werden? Falls per Device, fallen jegliche Gateway-Lösungen vermutlich flach. Falls aber per User, wie sollen Lizenzen ausgestellt werden? Dafür muss der Server zwingend in einem AD sein, und die User aus diesem AD oder einem Forest, der diesem AD vertraut, kommen.

Achtung! Ein Ordered Dictionary ist keine Hashtable. Hier ein paar Unterschiede:

• OD hat keine der Methoden ContainsKey(), ContainsValue() und Clone(). 
• Und obgleich OD keine Methode Clone() hat, ist das Zuweisungsverhalten so, dass man sie gelegentlich bräuchte.
• Dafür hat OD die Methoden Insert() und RemoveAt(), die für HT keinen Sinn ergeben.

vor 32 Minuten schrieb Mase_:

 

Ich würde 10Zeilen und 2Spalten erwarten.

Dem ist leider nicht so - aber warum?

Naja, zwei Spalten hast Du schon, die hat eine Hashtable immer

Der Konstruktor einer Hashtable ist keine Zuweisung, daher kann man hier kein Array von Values zu einem Array von Keys gleicher Länge zuweisen.

Siehe auch hier: https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_hash_tables?view=powershell-7.2

Wenn das ganze wenigstens ein bisschen verschlüsselt sein soll, musst Du die Anmeldedaten so oder so in der Session des zugreifenden Users erfassen, dann kannst Du auch gleich den Windows Credential Manager nutzen und die Anmeldedaten einfach beim ersten Verbinden des Netzlaufwerks hinterlegen.

IGEL UMS:

https://kb.igel.com/securitysafety/en/isn-2021-11-ums-log4j-vulnerability-54086712.html

...da sollte man sich im Nachhinein aber schon fragen, warum ein Tier 0-System etwas "nachladen" darf  

vor 26 Minuten schrieb Marco31:

Eine Frage dazu; wenn ich mal die Anwender im lokalen Netzwerk als potenzielle Angreifer ausklammere, bin ich vor der Schwachstelle sicher wenn meine Applikationen nicht aus dem Internet erreichbar sind?

Nein, weil ein Angreifer die Lücke ausnutzen könnte, indem er einem User scheinbar harmlosen Code unterschiebt, der ein anfälliges Gerät anspricht. Klar, weniger wahrscheinlich und ungleich komplexer als ein direkter Angriff aus dem Internet, aber "sicher"? Nein.

Schau mal *in* die Registry, nicht nur auf die Rechte dort.

Oder lege den Task im Legacy-Modus mit AT an, dann helfen Dir Rechte im Dateisystem.

vor 56 Minuten schrieb TitusPullo:

Typisch Microsoft Rotz. An sowas kann man sich echt tagelang aufhalten.

Damit motivierst Du natürlich andere, Dir zu helfen  Vielleicht beschreibst Du mal, wie es auf anderen Plattformen geht, dass man einen Normaluser befähigt, einen Task mit Root-Rechten zu starten, denn nichts anderes versuchst Du hier. Und Spoiler: Mit Windows geht's.

Moin,

ein User ohne Adminrechte hat per Default nicht die Berechtigung, einen Scheduled Task zu starten, den er nicht selbst erstellt hat. Da musst Du nachhelfen (Permissions in C:\Windows\Tasks für AT-Tasks, Fummeln in der Registry unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks\ für moderne Tasks).

vor einer Stunde schrieb Sunny61:

für die MSFT-Remote-App Lizenzierung weiß ich das nicht, vermutlich werden die nicht freigegeben.

Die RDS-Lizenzierung ist Named User/Named Device. Da wird so schnell nichts freigegeben  

Moin,

was @NilsK gesagt hat, plus noch: Das ganze hört sich zwar nicht nach einer Umgebung mit mehreren Scopes an, aber falls der DHCP Server doch nicht im selben VLANs wie die Clients steht, müssen natürlich noch IP Helper und/oder DHCP Relays angepasst werden.

Für mobile Mitarbeiter haben die meisten Anbieter von "sicheren Mail-Apps" diese Funktionalität am Start. Wenn aber "beliebiger Zugriff" gemeint ist, wird es schwierig.

Nein, das ist ein Feature von Azure AD in Deinem Tenant.

Moin,

ad 1. ein Client-Zertifikat

ad 2. Nein. Ihr könnt dafür aber die Firmenhandies in Intune enrollen und Conditional Access benutzen, um nur Geräte im Status "company owned" zuzulassen.

Moin,

das geht mit "einfachen Bordmitteln" tatsächlich nicht und ist auch vom Hersteller nicht vorgesehen. Der Use Case ist aber keineswegs exotisch. Und, wie vermutet, ist für diesen Use Case Exchange nicht die Plattform der Wahl, aber das will ja keiner hören.

Eine sehr bekannte Handelskette hat jahrzehntelang deutschlandweit so gearbeitet (ein Postfach pro Filiale, alle Mitarbeiter haben Zugriff). Bis Outlook (und Exchange) 2010 ging es noch mit PRF-Dateien, die man per Skript pimpen konnte. Mit Outlook (und Exchange) 2016 haben sie dann festgestellt, dass man Outlook 2016 zwar dazu vergewaltigen kann, aber irgendwann Autodiscover greift und alle möglichen Artefakte anfangen. Wie sie das gelöst haben, weiß ich nicht mehr.