NilsK

Moin, da ADMX-Dateien nur die Verwaltungsoberfläche steuern, aber nicht die Funktion der GPOs, würde ich kein komplexes Versionssystem erfinden, sondern immer die neuesten Versionen einsetzen. Gruß, Nils

Moin, ja, du hast Recht, der Prozess ist sozusagen umgekehrt. Der Client ändert das Kennwort. Der Punkt, den ich meine: Das Ändern des Computerkennworts geschieht nicht durch das AD ohne Kontakt zum Client. Viele vermuten das. Daher kann ein Client nicht durch ein "automatisch geändertes Kennwort" aus der Domäne fallen, wenn er zu lange keinen Kontakt zum AD hat. Gruß, Nils

Moin, abgesehen davon, ändert sich das Computerkennwort nur, wenn dies gemeinsam von dem Client und dem DC gemacht wird. Der DC ändert das nicht "in Abwesenheit", das wäre auch nutzlos. Wenn das regelmäßig auftritt, vermute ich, dass was anderes im Busch ist. Wie lautet die Fehlermeldung denn genau? In welcher Situation tritt sie auf, was passiert vor- und nachher? Was sagt das Eventlog? Gruß, Nils

Moin, So altes Zeug wird keiner mehr kaufen. Windows 7 ist in einem halben Jahr aus dem Support. Bücher kann man auch ins Altpapier tun. Gruß, Nils

Moin, dann nehme ich mal an, dass sich nicht nur der Bildschirm abschaltet, sondern der Rechner in einen Sparmodus geht. Gruß, Nils

Moin, was passiert denn eigentlich genau? Im Betreff steht "Absturz", aber jetzt klingt es eher so, als würde nur die Kommunikation mit dem Dienst abreißen. Bitte beschreib mal genauer. Gruß, Nils

Moin, nachgucken kannst du im Eventlog. Da sollte sich was dazu finden. Schau dir alles an, was zeitlich in der Nähe liegt. Gruß, Nils

Moin, ich stimme zu - Diskussion per PN ist nicht der Sinn eines Forums. Was heißt dies genau? Gruß, Nils

Moin, *lol* das ist in der Tat witzig. Wobei "Grotesk" einfach ein traditioneller Name für nüchterne, serifenlose Schriften ist. https://de.wikipedia.org/wiki/Grotesk_(Schrift) Gruß, Nils

Moin, lass dir auf beiden Seiten den Verzeichnisbaum als Text in eine Datei schreiben. Dann nimm ein Vergleichstool, so kannst du identifizieren, was doppelt ist. Gruß, Nils

Moin, bei Kennwörtern ist faktisch nur die Länge entscheidend. Wie viele Zeichen genau, ist Glaubenssache, aber 8 Zeichen gelten schon seit Jahren als zu kurz für ernst gemeinte Angriffe, insbesondere bei hochprivilegierten Konten. Meine Ansicht dazu ist: alles unter 20 Zeichen ist zu kurz für einen Account, der Schlimmes anrichten kann. Hier helfen Kennwortsätze. Das mit dem Sperren würde ich lassen - das ist eine Krücke, die wenig hilft, aber viel schadet. [DOS-Angriff für jedermann: AD-Konten sperren | faq-o-matic.net] https://www.faq-o-matic.net/2013/08/07/dos-angriff-fr-jedermann-ad-konten-sperren/ Und gleich noch ein Tool für lange Kennwörter, die man gut tippen kann (es gibt noch ca. 1000 andere solche Tools): [Bessere Kennwörter erzeugen und merken | faq-o-matic.net] https://www.faq-o-matic.net/2017/07/26/bessere-kennwrter-erzeugen-und-merken/ Gruß, Nils

Moin, [Video-Tutorial: Active Directory Object Recovery | faq-o-matic.net] https://www.faq-o-matic.net/2009/09/07/video-tutorial-active-directory-object-recovery/ Gruß, Nils

Moin, die Kennwörter werden ja nicht ausgelesen. Nur das neu gewählte Kennwort wandert einmal durch den Filter, bevor das AD es als neues Kennwort akzeptiert. Danach ist es nicht mehr auslesbar. Durch einen anderen als den eingebauten Filter ändert sich an dem Prinzip nichts - oder anders: Der Vorgang geschieht jetzt auch schon. Gruß, Nils

Moin, in Outlook unter iOS gegen ein O365-System ist das schon lange so. Dort sieht man es ach "direkt", ohne ein anderes Tab öffnen zu müssen. Auf dem PC hab ich noch nie danach gesehen. Gruß, Nils

Moin, bitte gewöhne dir an, solche Informationen gleich zu liefern und nicht erst weit hinten im Thread. Da es in deinen Problemen um Exchange und Authentifizierung geht, ist sowas von Belang. Gruß, Nils

Moin, da ihr bereits einen 2016-DC in Betrieb habt, habe ich die Exchange-Frage nicht beleuchtet. In eurer quasi ungepatchten Konstellation habt ihr das Risiko (und eine nicht supportete Umgebung) bereits seit der Integration des 2016-DCs, es entsteht nicht erst in dem Moment, in dem ihr den alten DC rausnehmt. Gruß, Niös

Moin, nein, die Reihenfolge ist egal. Zu beachten ist nichts Besonderes, wenn die restliche Infrastruktur (insbesondere DNS) korrekt ist. Sollte es sich bei dem DC, der entfernt werden soll, um den ersten jemals installierten handlen, ist es ratsam, das EFS-Zertifikat mit dem Private Key zu exportieren. Auch wenn es nicht mehr gültig ist, kann es sein, dass man es später noch mal zum Entschlüsseln alter Dateien braucht. Gruß, Nils

Moin, um das Schema zu aktualisieren, muss man Mitglied der Gruppe Schema-Admins sein. Ob der betreffende Account in der Root Domain oder in einer Subdomain beheimatet ist, ist dabei egal. Kann das Schema-Update wegen mangelnder Berechtigungen nicht stattfinden, wird einen die AD-Installation darüber informieren. Auch wenn es technisch möglich ist, eine Subdomain vor der Root Domain zu aktualisieren, ist es gerade wegen solcher Zusammenhänge i.d.R. nicht sinnvoll. Gruß, Nils

Moin, könnte man denken. In der Cloud habe ich eine abgeschaltete VM, falls ich die noch nicht gelöscht habe. Und meine Frau hat ihre Mailbox bei einem Cloud-Provider. Die fünf Webseiten, die ich betreue, laufen als Shared Hosting mit Ökostrom. Das war's im Wesentlichen. Zugegeben: Wäre ich Freiberufler, nutzte ich vielleicht ein wenig mehr, aber auch dann bräuchte ich es nur punktuell. Ich will hier auch niemanden angreifen, aber ich finde die Tendenz der Diskussion gerade etwas ... ergänzungsbedürftig. Gruß, Nils

Moin, hm. Und wofür braucht ihr das? Steht dem ein reeller Nutzen entgegen? Mein 4-Personen-Haushalt wird vom Energieversorger schon seit Jahren als weit unterdurchschnittlich eingestuft (trotz zwei Teenie-Töchtern - aber Smartphones brauchen für Insta und Youtube halt nicht viel Strom). Ich brauche einfach privat keine IT, schon gar keine, die durchlaufen würde. Geek hin oder her, aber irgendwann ist es ja auch eine Frage der Verantwortung. Gruß, Nils

Moin, JEA wäre durchaus geeignet, denn man könnte, wie in dem Beispiel zutreffend angegeben, passende Filter definieren und so einschränken, welche Mitglieder in die Gruppe dürfen. Aber: das hat einen Preis, nämlich erheblichen Aufwand für Entwicklung und Test. Da die Diskussion allerdings in eine seltsame Richtung geht, mache ich hier Schluss. Gruß, Nils

Moin magheinz, danke für deinen wertvollen Beitrag. Richtig wäre "Klugschei*ß*modus". Und falls die spitzen Klammern an SGML-Tags erinnern sollen, sind sie falsch gesetzt, weil ohne Abschluss. Gruß, Nils

Moin, das entspricht vom Prinzip her dem Ansatz 1. Ist auch ungefähr so aufwändig. Gruß, Nils

Moin, das AD sieht es nicht vor, per Berechtigung nur selektiv Mitglieder zu einer Gruppe hinzuzufügen. Wenn das wirklich erforderlich ist, müsste man also mit einem Workaround arbeiten. Aus Erfahrung stelle ich aber in Frage, ob das Erfordernis wirklich so wichtig ist. Zwei mögliche Ansätze sind schon genannt worden: ein Frontend bzw. ein anderes Tool, das nur die erlaubten Objekte auswählbar macht. Das allein reicht aber nicht - das Tool müsste, wenn es Sinn haben soll, über einen separaten (Service-) Account auf das AD zugreifen und der User dürfte gar keine Schreibrechte auf die Zielgruppen haben. Effektiv würde man also ein separates Berechtigungssystem bauen. Die auswähbaren Objekte selbst per AD-Berechtigungen einschränken. Das ist denkbar - wäre aber zum einen ein erheblicher Eingriff in die AD-Berechtigungen (und könnte dazu führen, dass Microsoft es nicht mehr supportet) und würde zum anderen bedeuten. dass der betreffenden User die versteckten Objekte überhaupt nicht mehr sehen und benutzen kann. Da das AD für so ein Szenario nicht gebaut wurde, würde ich, wie gesagt, genau prüfen, ob das wirklich erforderlich ist. Gruß, Nils

Moin, da es um MS SQL geht, sind hier natürlich auch SQL-CALs erforderlich. Auch hier geht es um tatsächlich zugreifende "Menschen", nicht um den verwendeten Account. Gruß, Nils