micha42
-
Gesamte Inhalte
1.034 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von micha42
-
-
Am 4.5.2022 um 16:42 schrieb cj_berlin:
Was passiert denn, wenn Du bei einem betroffenen User das Häkchen setzt bei "Account supports AES256 encryption" bzw. msDS-SupportedEncryptionTypes auf 0x10?
Das konnte ich heute testen, ohne Erfolg.
Ende vom Lied: "Sie setzen mir jetzt das folgende Passwort: diktier,diktier"
Ich hab also in genau 365 Tagen das Problem nochmal.
Naja ich hab noch weitere 2 Konten mit dem Problem.
Jetzt aber Feierabend und langes Wochenende. Montag geht s weiter.
Das mit
klist tickets
werde ich dann testen wenn ich beim zweiten die Audienz habe.
Auch die Anregung von daabm wenn ich dann da an das Keyboard darf.
-
Erst mal vielen Dank für Deine Hilfe!
Das werde ich morgen so machen.
-
vor 13 Minuten schrieb cj_berlin:
Du kannst die effektive Einstellung auf dem Client auch in der Registry sehen: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters SupportedEncryptionTypes
Super-Tip
Aber damit kann ich leider nix anfangen 7ffffff0 bzw 2147483632
ich google mal
vor 1 Minute schrieb cj_berlin:Was passiert denn, wenn Du bei einem betroffenen User das Häkchen setzt bei "Account supports AES256 encryption" bzw. msDS-SupportedEncryptionTypes auf 0x10?
Ey das ist der GF! mit dem spiele ich nicht rum. (gezuckt hatte ich ja auch, aber der Haken ist bei keinem drin.
Ich bin unsicher, was das auslöst. Kann ich den Haken gefahrlos setzten?
-
hm
GPresult auf Remoterechner kämpfe ich halt gerade:
gpresult /S FQDN-Client /H c:\temp\gpresult2.html
INFO: The user does not have RSoP data.
Den Verdacht hatte ich ja auch, aber aktuell sehe ich dafür keine Gründe. Ja, ich weiß, ich sehe die Gründe nicht, weil ich nicht gucken kann, aber ich bin halt dran
am Client steht auch im AD:
msDS-SupportedEncryptionTypes= AES256 (usw)
-
Das GPRESULT beim Client bekämpfe ich jetzt umsonst.
Aber Du fragtest
- Was steht bei den betroffenen Usern im Attribut msDS-SupportedEncryptionTypes?
- Was steht bei den Domain Controllern in diesem Attribut?
Bei den usern steht 0 (bei allen usern, auch die, die keinen Fehler erzeugen)
Bei den DCs steht 0x10 = AES256_CTS_HMAC_SHA1_96 (wie n der GPO gefordert
-
GPresult. stimmt natürlich
Also auf den DCs
Client gucke ich gerade noch, kommt gleich
-
nein bitte keine philosophischen Diskussionen.
-
2
-
-
moin, mit dem Durcharbeiten der GPOs hab ich auch schon angefangen, aber die 172 GPOs sind teilweise etwas unübersichtlich und ich brauche da noch etwas. (wie gesagt - neu hier)
Das mit dem Kennwortwechsel sehen hier alle genau so, aber der externe Sicherheitsberater nicht. und nun rate mal wem der CISO gefolgt ist...
-
ja, beide sind auf 2012R2
(by the way, das hab nicht ich hochgestuft, ich bin hier erst seit Kurzem)
Die Fehlermeldung habe ich von einem Screenshot von einem Client, die installieren wir der Einfachheit halber dann doch in D.
Ja, Du hast Recht und der Tip ist goldrichtig, aber die DCs sind tatsächlich alle mit englischem OS installiert. In der Ereignisanzeige habe ich nichts gefunden.
Den Artikel, den Du verlinkt hast, (danke dafür) hatte ich auch gefunden, aber das hat -glaube ich- nichts mit meinem Problem zu tun.
Die Server sind ja auch nicht erst seit gestern im auf der Funktionsebene, daher haben die alle schon diverse Neustarts gehabt.
-
Funktionsebene ist 2012R2
Server haben Win 2016 (ein 2012R2 ist noch dabei)
-
Moin, die im Betreff stehende Fehlermeldung bekommen mehrere user bei uns.
Kurz zum Hintergrund. Wir wollen hier eine neue Passwortrichtlinie ausrollen und dann auch mal (endlich) den VIPs den Haken "Passwort läuft nie ab" wegnehmen.
Da wir das Max-Alter deutlich reduzieren (auf ein Jahr) haben wir alle user angeschrieben, die ein älteres PW haben.
Die haben dann alle (ok, fast alle) brav ihr PW geändert.
Einige bekommen leider Fehlermeldungen
Die haben teilweise ihr Passwort seit 2015 nicht geändert.
Wenn ich nun aber mit den usern das Passwort ändern will, bekomme ich die Meldung, mit der ich nichts anfangen kann.
Ich vermute es liegt an der Kommunikation zwischen Client und DC.
Client ist Win10, DC ist Win2016, keine Firewall dazwischen.
Leider sind das nun auch nicht die Konten von irgendwelchen usern mit denen ich das Stundenlang durchtesten kann, bis es geht.
Was ich schon probiert habe:
Passwort zurückgesetzt (mit und ohne den Haken für "muss PW bei der nächsten Anmeldung ändern")
Eventlog durchsucht (nix zu sehen)
Ich stehe auf dem Schlauch, hat Jemand eine Idee?
Michael
-
ja, da wird es drauf hinauslaufen, ich hatte nur den Ehrgeiz zu verstehen, warum nicht die Aktivierung in DFS ausreicht. Für mein Verständnis hätte es funktionieren müssen.
Immerhin sind die Freigaben vom Cluster ja nicht mal über den gleichen Pfad zu erreichen, also wird die Freigabe ja nur vom DFS genutzt. Die sollte dann in der eigenen Freigabe "angereichert werden" mit ABE.
Wenn hingegen schon im Servermanager ABE aktiviert ist, dann verstehe ich nicht, warum DFS das nicht "sehen" kann und die Warnung herausgibt, dass ABE besser aktiviert sein sollte.
Ja klar, die Lösung ist ABE in beiden Managern zu aktivieren. Es hätte ja eine Fehlkonfiguration sein können. Dem wollte ich auf den Grund gehen.
Danke für die Antworten!
Michael
-
OK, stimmt, ich muss genauer beschreiben:
Clusterfreigabe: Clusterfreigabename.Domain.net\Testfreigabe
DFS nimmt diese Freigabe auf und gibt das nochmal frei:
DFS-Freigabe: \\Domain\Namespace\Test
Wenn ich im Servermanager eine Einstellung mache, erscheint auf der Freigabe (rechte Maustaste / Open share) die Clusterfreigabe. Das heißt, wenn ich hier ABE aktiviere, dann ist die Freigabe, die ja lediglich von DFS aufgegriffen wird schon mal restringiert, ich kann also nur noch die Dateien sehen, auf die ich Leseberechtigung habe.
DAS funktioniert auch: Wenn ich auf die DFS-Freigabe gehe, die ja auf die Clusterfreigabe zugreift, dann sehe ich nur die Ordner, auf die ich berechtigt bin.
OK, wenn ich das nun aber umkonfiguriere, also auf Schicht1 (Cluster) ABE DEaktiviere und auf Schicht2 (DFS) aktiviere, kann ich alles sehen.
Ich stelle mir das aber in einem Schichtenmodell vor. Ich denke, dass der "Filter" ABE doch in jeder Schicht funktionieren sollte. Wenn ich also in DFS ABE aktiviere, sollte es doch egal sein, dass in einer vorherigen Schicht dies noch nicht passiert ist.
Und das ist es, was ich meinte mit "hätte ich nicht erwartet".
PS: Änderungen am DFS werden erst am nächsten Tag sichtbar, weshalb Tests hier etwas Zäh sind.
-
Hallo Board,
ich habe hier eine neue Stelle angetreten und finde eine sehr komplexe Fileserver-Struktur vor, die ich erst nach langem Forschen genau durchblickt habe. Aber leider noch nciht ganz.
Aktuell ist meine Frage zu Access-bases Enumeration.
Diese ist im Servermanager > Dateiservice > Shares aktiviert und funktioniert auch.
Im DFS ist sie nicht aktiviert. Das führt zu einer unschönen Fehlermeldung (eben, dass sie nicht aktiviert ist)
Ich wollte das gerne umdrehen und hab einen Test-Namespace aufgebaut und in diesem erstmal identisch die Einstellungen gesetzt.
-> ABE funktioniert
Dann habe ich im Servermanager ABE deaktiviert und im DFS aktiviert
-> ABE funktioniert nicht
>> damit habe ich nicht gerechnet. ist das normal? Ich finde diesbezüglich leider keine Info.
Kurz zu "komplexe Fileserverstruktur":
georedundanter Storage - Failovercluster mit Freigabe - Freigabe im DFS aufgenommen - DFS Freigabe für User
-
Naja, kommt auf die Umgebung an. Wir haben 280 user, die haben alle einen Rechner und viele für den Fernzugriff noch einen Virtuellen Desktop (Citrix)
Ich müsste mich also "eben kurz" auf ca. 500 Clients verbinden. Und wenn ich einen neuen Treiber einbinde "mal eben" nochmal.
Ja klar, das geht natürlich auch automatisiert, aber ich muss dann bei jedem neuen Treiber einen großen Aufwand betreiben.
Aktuell haben wir mit den Gruppenrichtlinien über die Point-and-Print-Einstellungen die Beschränkung, dass ausschließlich von unserem Printserver Treiber bezogen werden können.
Das Papier das ich oben erwähnt habe kommt von Microsoft. Das ist direkt nach dem Update veröffentlich worden, dass PrintNightmare schließen soll (tut es nicht, ich weiß). Ich habe nur noch keine verlässlichen Informationen gefunden, ob MS selbst nach dem Schließen der Lücke direkt einfach empfiehlt die Lücke wieder zu öffnen, ohne mal in einem Nebensatz auf die Gefahr hinzuweisen (das wäre m.E. grob fahrlässig)
-
Moin,
seit Montag verlangt Windows bei uns ein Admin-Passwort für einen Druckerinstallation vom Printserver.
Die Gruppenrichtlinien "Point and Print" sind korrekt gesetzt und haben bislang tadellos funktioniert.
Ich weiß noch nicht, welches Update uns das eingebrockt hat. Ich konnte es auf 3 eingrenzen.
(KB5005260, KB5005033 und KB5004331)
Welches auch immer Schuld hat ist ja eher unwichtig, die Einstellung wird bestimmt in späteren Updates auch immer wieder gesetzt werden.
Aber wichtiger ist ja eher: Wie kann ich das Problem lösen. Ich kann ja jetzt nicht rumrennen und überall das Passwort eingeben.
Mir ist klar, dass diese Einstellungen wegen PrintNightmare gesetzt wurden und dies nun eine halbe Reparatur ist, aber für den laufenden Betrieb muss ich halt gucken, wie ich das hier einstellen kann.
Grüße Micha
mit dem Reg-Key geht es jetzt ohne Admin-PW. Ich bin gerade noch am gucken, ob ich damit irgendwelche Sicherheitslücken wieder aufreiße.
-
Ich habe DPM2012-RU8, auf Win 2012. (hatte ich noch erwähnt, dass ich das gleiche Problem habe? Bei mir aber von einer Woche auf die andere. Davor hat es ein Jahr funktioniert)
-
stimmt, den halbsatz hab ich wohl zu schnell gelesen ...
-
Ich hab nochmal etwas gesucht, es muss leider doch nicht unbedingt an den Reporting-Servises liegen (kann aber).
Ich habe immer noch keine Lösung, aber einen Work-around: Du kommst auch anders an die Reports.
Auch wenn die MMC abstürzt kannst Du die Reports erreichen, wenn der Reportingservice richtig konfiguriert ist.
Du surfst auf Deinem Backupserver die folgende URL an:
http://backupserver/ReportServer (Backupserver musst Du ersetzen durch den Namen Deines Backupservers - logisch(sonst kommst Du ja auf meinen - unlogisch :D )))
-
Eine Lösung habe ich nicht, aber das wird mit den Reporting-Services zusammenhängen.
-
"This support does not include installing Virtual Machine Manager Console on Windows 10 operating system clients."
Ooops. Naja, bisher funktioniert das Ding.
Naja, das geht vorerst auch ohne. Ich nutze ohnehin nur die Konsole auf dem DPM-Server (die anderen Komponenten von SysCenter nutze ich nicht).
Aber mal im Ernst: wer auf seiner Admin-Maschine jetzt schon W10 installiert, is doch ... na sagen wir mal "experimentierfreudig".
-
Kundendaten einer Krankenkasse sind sicherheitstechnisch durchaus ein heisses Eisen.
Zweifelsohne. Zwar kommen die Daten Pseudonymisiert hier an (und die De-Pseudonymisierung können wir nicht durchführen), aber trotzdem machen wir hier ne Menge Aufwand um die Daten zu sichern. Das haben wir mittlerweile auch mehrfach bestätigt bekommen. Im Moment wird das Ganze sogar zertifiziert.
-
Wir sind bei einem Datenschutzaudit mit der Hammer-Methode durchgefallen (bzw mussten Besserung geloben). Das Audit kam von einem Kunden (Krankenkasse) und die haben auf die Methode "zertifizierter Dienstleister" bestanden. Seitdem bezahlen wir halt für die Entsorgung Geld.
Persönlich finde ich das schwachsinnig, aber wenn s den Kunden glücklich macht...
Man muss eben immer gucken: Kosten der Wiederherstellung vs. Wert der Daten
Wir haben mal eine Festplatte zum Datenretter gegeben, die lediglich formatiert und neu installiert war. 3000 DM (wenn ich mich recht erinnere)
Was mag es wohl kosten eine Festplatte zu "retten" die mit dem Hammer so weit bearbeitet wurde, dass der Lesekopf zerstört ist und die Scheiben krumm oder gebrochen sind. Also in meinem Netz sind keine Daten, die so viel wert sind.
-
hä?
der angeforderte Verschlüsselungstyp wird vom Kerberos-Domänencontroller nicht unterstützt
in Active Directory Forum
Geschrieben
Hallo MurdocX,
Das Ändern des PW an einem anderen Rechner konnte ich nicht testen (nicht soo willig der user)
In UserAccountControll steht: 0x200 = Normal_Account