Marco31

Eintragen und bestätigen konnte ich diese ja auch, nur angewendet wurden sie nicht. Da waren ja dann die SceCLi 1202 Fehler... Werde das nächste Woche mal weiter testen, vielleicht funktioniert es ja jetzt nachdem ich (wie oben in dem Artikel beschrieben) alle Einträge mal geändert und gespeichert habe...

Ähem... ich habe die Einstellungen auf einem win10 1903 Rechner gemacht... die Templates sind auch alle aktuell. Oder habe ich da was falsch verstanden?

Und wie bekomme ich meine Passwörter nun grösser 14 Zeichen? ?

Ja, auf sowas kann man verzichten Die Einstellung "RequireLogonToChangePassword" wird aber auch jetzt noch im Winlogon geloggt. Ich muss aber gestehen dass ich mich nicht so recht traue, an der GPTTMP.INF rumzufummeln... Hat jemand von euch Passwörter länger 14 Zeichen über die DPP konfiguriert oder nur über "Fine Grained Password Policy"?

Also im Eventlog bekomme ich am DC SceCli Fehler 1202, 0x57. Und das seit dem Tag an dem ich die DPP geändert habe... Das ganze hört sich so an, als seien noch Uralte Reste in der DPP die hier Probleme machen: https://superuser.com/questions/1422880/scecli-0x57-password-policy-event-1202 Tatsächlich wir der im Artikel genannte Eintrag "RequireLogonToChangePassword" im Winlogon protokolliert: ---Sicherheitsrichtlinien werden konfiguriert... Die Verabeitung der Wiederherstellungswerte für 7 Einstellungen wird gestartet. Es besteht bereits ein Wiederherstellungswert für die Gruppenrichtlinieneinstellung <MinimumPasswordLength>. Es besteht bereits ein Wiederherstellungswert für die Gruppenrichtlinieneinstellung <PasswordHistorySize>. Es besteht bereits ein Wiederherstellungswert für die Gruppenrichtlinieneinstellung <MaximumPasswordAge>. Es besteht bereits ein Wiederherstellungswert für die Gruppenrichtlinieneinstellung <MinimumPasswordAge>. Es besteht bereits ein Wiederherstellungswert für die Gruppenrichtlinieneinstellung <PasswordComplexity>. Es besteht bereits ein Wiederherstellungswert für die Gruppenrichtlinieneinstellung <RequireLogonToChangePassword>. Es besteht bereits ein Wiederherstellungswert für die Gruppenrichtlinieneinstellung <ClearTextPassword>. Konfigurieren der Kennwortinformationen. Die Verabeitung der Wiederherstellungswerte für 3 Einstellungen wird gestartet. Es besteht bereits ein Wiederherstellungswert für die Gruppenrichtlinieneinstellung <LockoutBadCount>. Es besteht bereits ein Wiederherstellungswert für die Gruppenrichtlinieneinstellung <ResetLockoutCount>. Es besteht bereits ein Wiederherstellungswert für die Gruppenrichtlinieneinstellung <LockoutDuration>. Es besteht bereits ein Wiederherstellungswert für die Gruppenrichtlinieneinstellung <ForceLogoffWhenHourExpire>. Konfigurieren der Informationen der erzwungenen Abmeldung. Kleine Rückmeldung: Ich habe die Anweisungen aus der ersten Antwort des Artikels ausgeführt (alle Einstellungen anwählen, ändern, speichern, wieder auf richtigen Wert setzen, speichern) und ein gpupdate /force gemacht. Siehe da, net accounts /Domain zeigt jetzt die Werte an, die auch in der DPP stehen. Habe auch die maximale Kennwortlänge auf 14 gesetzt. Aber habe ich das richtig verstanden dass man über die DPP keine Passwortlänge größer 14 setzen kann??

Ja, so ist es, da DPP und net accounts /Domain unterscheiden sich. Zu Test 1: Das sieht unauffällig aus, da steht einer meiner beiden DC's (der Betriebsmaster) drin. Zu Test 2: Wo muss ich da genau hinschauen? Mit adsiedit bin ich jetzt nicht so wirklich vertraut. Weitere Probleme gibt es keine, zumindest keine die mir aufgefallen sind.

Folgendes ist definiert: RSoP sagt genau das was auch in der DPP definiert ist. Und hier nochmal net accounts /Domain:

Guten Morgen Also auf Root-Ebene sind ausser der DDP noch 8 weitere GPO's definiert, aber keine davon hat Kennwortrichtlinien definiert. Zweimal Terminalserver (Anmelden über Terminaldienste zulassen & SSO), zweimal Zertifikat-Verteilung, einmal Einstellung TimeService, zweimal SMBv1 Disable, einmal Logon as Batch Job. Alle aktiv auf Root Ebene.

Ok.... Da stehen die falschen (alten) Einstellungen drin.... Wie kann das denn sein?

Hallo Forum, ich habe hier ein Problem bei dem ich nicht ganz weiter weiß. Ich habe vor einiger Zeit ein paar Sachen an den Kennwortrichtlinien geändert (Länge des Passwortes und Maximales Kennwortalter). Das ganze habe ich in der Default Domain Policy geändert. Jetzt habe ich aber das Problem, dass die Passwörter weiterhin nach 30 Tagen und nicht wie in der Policy eingestellt nach 120 Tagen ablaufen. Ich kann mir das ganze nicht wirklich erklären, da ich keine andere GPO habe die Kennwortrichtlinien definiert... Hat jemand eine Idee wo das Problem liegen könnte?

Ja, werde ich wohl tun. Mal schauen was die zu dem Thema sagen. ?

Also noch nicht gefixed… Großes Kino... SMB1... Bei denen gehen die Uhren anscheinend noch anders...

Hallo Forum, ich habe ein Problem mit dem Backup meiner VCSA. Seit 6.7 gibt es ja die Möglichkeit, ein VCSA-Backup auf ein SMB Share zu sichern. Das möchte ich jetzt entsprechend einrichten. Leider bringt mich das ganze zum verzweifeln, da es nicht funktionieren will... Die VCSA kann nicht auf das SMB Share zugreifen. Hat das schon mal jemand hinbekommen? In früheren Versionen soll das ganze nur mit SMB1 funktioniert haben, das soll aber wohl jetzt auch mit SMB2 funktionieren. Auf jeden Fall ist meine VCSA auf dem aktuellsten Patch-Stand (6.7.0.40000) und SMB2 ist auf dem Backup-Ziel aktiviert. Zugriffsrechte am Ziel stimmen auch. Es ist mir gerade ein Rätsel...

Versuche mal das ganze über das Zertifikat zu machen. Die Dateien von Teamviewer sind signiert.

Bei Arcserve sind es meines Wissens 3 Jahre.

Du solltest die Datenträger nach dem Ablaufdatum nicht mehr unbedingt verwenden... Was nützt dir ein Backup wenn du im Fall der Fälle merkst dass der Datenträger im A.... ist? Sparen am Backup ist sparen an der falschen Stelle

Also ich bastel ja auch gerne mal, aber in der produktiven Umgebung ist das für mich ein No-Go. Außer Aufrüstung lass ich da Hardwaretechnisch die Finger von. Und wenn du aktuelle Hardware bei einem der drei besagten Großen kaufst wirst du sicherlich mindestens 5-6 Jahre Support erhalten. Das ist billiger als doppelt kaufen und auch streßfreier

Habe ich so gemacht, vielen Dank für die Hilfe!

Die Applikationen sind derzeit Client/Server-Anwendungen mit Programm & Daten am Server und installiertem Software-Client auf den Clients. Die Programme sind aber Terminalserver-fähig. Dasselbe gilt für das Betriebstagebuch. Verfügbarkeit ist nicht das große Thema; eine Ausfallzeit von 1-2 Tagen ist verkraftbar.

Hallo Forengemeinde, ich habe mal eine Frage zur "Best Practice" für die Veröffentlichung von Anwendungen über Terminalserver. Folgendes Szenario: Ich habe derzeit einen Anwendungsserver und zukünftig einen Server mit einem Betriebstagebuch. Ich würde gerne sowohl das Betriebstagebuch als auch ein paar Anwendungen des Anwendungsservers veröffentlichen. Es geht hier um ein kleines Netzwerk, maximal 8 Terminalserver-Benutzer und nur internen Zugriff. Jetzt meine Frage: Wie sollte man das am besten installieren? Einen neuen, separaten Server mit RD-Sitzungsbroker, RD-Lizensierung, WebAccess für RD und RD-Sitzungshost und die beiden anderen Server hinzufügen? Oder auf einem der beiden vorhandenen Server die 4 Rollen hinzufügen und den anderen Server hinzufügen? Wie würdet ihr das machen? Noch eine kurze Frage; um einen Server zu einer TS-"Farm" hinzuzufügen, genügt es da auf dem betroffenen Server die RD-Sitzungshost-Rolle zu installieren?

Mojito

Genau so ist es. Der Terminalserver soll nicht über das Internet erreichbar sein und ist von außen auch nicht auflösbar. Und wenn jemand von außen drauf soll/muss (irgendwann), dann nur über eine VPN. Ja, die Infrastruktur ist sehr überschaubar. Auf jeden Fall schon mal danke an alle!

Hallo Forengemeinde, ich habe eine Frage zur Bereitstellung von Programmen über Terminalserver. Benötige ich hier zwingend eine CA für Zertifikate oder kann man sowas auch ohne realisieren? Bisher haben wir keine CA und es besteht derzeit auch kein Bedarf...?

Hierzu noch eine kleine Frage; wie baut man sowas normalerweise auf? Den Terminalserver mit Verbindungsbroker und Web-Access auf einer separaten Maschine und einen Server, auf dem man die Anwendungen installiert hat und die Sitzungshost-Rolle installiert hat? Wie gesagt, bin nur am testen derzeit. Ich möchte damit eigentlich nur 4-5 Anwendungen mit überschaubarem Ressourcenbedarf als WebApp bereitstellen. Mit den Apps würden dann nicht mehr als 6 User arbeiten.

Ok, danke. Habe ich mir schon so gedacht.