NilsK

Moin, ein Zertifikat erscheint nicht einfach von selbst, das muss irgendwo herkommen. Aus deiner Beschreibung lässt sich kaum ablesen, wie das auf die Rechner kommen könnte. Was ich aber nicht verstanden habe: Hast du die Domäne auch gelöscht und komplett neu eingerichtet? Oder nur die Server plattgemacht? So ein Fall dürfte in der Praxis kaum auftreten, daher würde ich an deiner Stelle keine weitere Energie in die Forschung stecken, sondern die ganze Umgebung komplett neu machen. Der Zeitaufwand dürfte geringer sein. Gruß, Nils

Moin, ein AD-Konto sperrt sich nicht einfach so, sondern nur, wenn jemand versucht, sich mit einem falschen Kennwort anzumelden. Als erstes könntest du also mal rausfinden, bei wie vielen Fehlanmeldungen diese Schwelle in eurer Domäne liegt. Da deiner Beschreibung nach die "ordentliche" Anmeldung funktioniert, der Chef also sein richtiges Kennwort kennt und eingibt, kommen typischerweise nur andere Prozesse in Frage, die mit einem falschen Kennwort eine Anmeldung versuchen. Das ist meist ein ehemaliges Kennwort, was Norbert mit "veralteten Credentials" meint (Credentials = Anmeldeinformationen). Meist sind solche Prozesse Dienste oder Anwendungen, die mit dem Konto des betreffenden Users konfiguriert sind, oder Tasks ("Geplante Aufgaben"), in denen das falsche Kennwort hinterlegt ist. Sowas bekommt man nur heraus, wenn man sich den betreffenden Rechner genauer ansieht. Gruß, Nils

Moin, du kannst das auch für eine passende Gruppe auf "Enroll" (nicht Autoenroll - der Unterschied ist die manuelle vs. automatische Genehmigung) setzen und den Assistenten nehmen. Wenn der mit der CA kommunizieren kann und die richtige Vorlage mit den richtigen Daten anfordert, braucht es ja nicht den Aufwand mit dem CSR. Wichtig ist vor allem, dass du solche Zertifikatsanforderungen immer prüfst und manuell freigibst, sonst kannst du dir den Zirkus gleich ganz sparen. Gruß, Nils

Moin, wenn der Ping mehrere Sekunden zur Ausführung braucht, dann klemmt die Namensauflösung. Vermutlich ist nicht der richtige DNS-Server beim Client eingetragen bzw, mindestens einer, der den Namen nicht auflösen kann. Gruß, Nils

Moin, sieht aus, als sei der eigentliche Zugriff OK. Nun könnte die Liste abgelaufen oder anderweitig ungültig sein. Oder der Dateiname ist nicht der, der im Zertifikat angegeben ist. Gruß, Nils

Moin, solche Zertifikatsvorlagen nie auf Autoenroll stellen. Du gibst damit die Kontrolle ab, wer ein Zertifikat für welchen Namen erhält. Effektiv hast du jetzt dafür gesorgt, dass jeder, der das Autoenroll-Recht hat, ein Zertifikat für einen beliebigen Computernamen anfordern kann, ohne dass dies geprüft wird. Das willst du nicht - Ruck-zuck hat jemand ein Zertifikat auf den Namen eures Mailservers für sich ausgestellt und kann sich als dieser ausgeben, ohne dass Clients eine Chance haben, das zu bemerken. Gruß, Nils PS: Es gibt schon Gründe, warum man eine PKI sorgfältig entwerfen sollte ...

Moin, das Veröffentlichen von Zertifikaten im AD wird weithin missverstanden. Das ist für fast keinen Einsatzzweck interessant; die einzige einigermaßen "übliche" Situation ist interne Mailverschlüsselung: Ein interner User, der einem anderen internen User eine verschlüsselte Mail senden will, kann per AD-Lookup dessen Zertifikat erhalten und muss es nicht erst anfordern (was voraussetzt, dass der Mail-Client das tut). Mehr passiert da nicht, es ist ein reines Datenfeld ohne weitere Logik. Das Zertifikat wird nicht für Logons verwendet, es gibt keine Sperrprozesse, und es wird auch nicht auf den Client übertragen, an dem der User arbeitet. Es gibt auch keine Verbindung von dem AD-Feld zur CA. Die CRL zu verarbeiten ist, wie Norbert schon sagt, Sache des Clients. Die meisten Clients tun das und akzeptieren ein Zertifikat nicht, wenn sie die CRL nicht finden oder diese abgelaufen ist. Das kann eine Stolperstelle in einer PKI sein. Und: Der Client sucht erst dann eine neue CRL, wenn seine lokale Kopie abgelaufen ist - da kommt die CRL-Lifetime ins Spiel, die das Sperren von Zertifikaten für "harte" Sicherheitsanforderungen eigentlich uninteressant macht (weswegen man es aber nicht weglassen darf, es darf nur nicht die einzige Maßnahme sein). Gruß, Nils

Moin, äh - aber per Autoenrollment bekommt doch das Zertifikat den Servernamen, keinen anpassbaren. Oder was genau ist da jetzt die Anforderung? Die certsrv-Webseite ist Uralttechnik und kann nur sehr wenige Zertifikatstypen ausstellen. Im Regelfall sollte man die nicht mehr verwenden. Was manuelle Requests angeht: [Windows-PKI: Computerzertifikat manuell anfordern | faq-o-matic.net] https://www.faq-o-matic.net/2017/09/13/windows-pki-computerzertifikat-manuell-anfordern/ Gruß, Nils

Moin, ich werfe mal Marks Vorschlag in die Runde: [Drucker verteilen und bereitstellen - Gruppenrichtlinien by Mark Heitbrink] https://www.gruppenrichtlinien.de/artikel/drucker-verteilen-und-bereitstellen/ Gruß, Nils

Moin, du musst dafür eine eigene Zertifikatsvorlage erzeugen, die den Namen nicht aus dem AD generiert. Folgender Artikel dürfte passen: https://blog.alschneiter.com/2014/04/28/how-to-deploy-remote-desktop-services-2012-r2-certificates-unsing-internal-ca/ Gruß, Nils

Moin, das Zertifikat zu sperren, ist nur ein wichtiger Schritt, wesentlicher in solchen Szenarien ist das Sperren des Accounts. Nur dann verliert der User wirklich sofort den Zugriff. Bis das gesperrte Zertifikat in der Sperrliste steht und diese neu auf den Clients bzw. dem VPN-Endpunkt ankommt, kann es durchaus Tage oder Wochen dauern. Das richtige Zertifikat zu finden und zu sperren, kann eine Herausforderung sein. Da hilft es, wenn man den Gesamtprozess im Griff hat und es für jeden User und Zweck nur ein Zertifikat gibt, nicht mehrere parallel, was in vielen Umgebungen Usus ist. "Versehentlich" ausgestellte oder ersetzte Zertifikate sollte man immer sofort sperren. Ebenso sind aussagekräftige Namen bei den Vorlagen hilfreich. Auch hilft es, abgelaufene Zertifikate aus der Datenbank zu entfernen: https://gallery.technet.microsoft.com/scriptcenter/Script-to-delete-expired-8fcfcf48 Neben der MMC könnte man auch per PowerShell arbeiten, was je nach Prozess und Umgebungsstruktur den Vorgang beschleunigen kann. Dazu ist das Modul auf Github nützlich: https://github.com/Crypt32/PSPKI Gruß, Nils

Moin, sorry, aber für mich klingt das erst mal nach einem Tippfehler beim Kennwort. Oder der User ist im AD gesperrt/deaktiviert. Gruß, Nils

Moin, also, ich wüsste jemanden, der sich recht intensiv mit Windows-PKI befasst ... Aber vermutlich ist das nur ein Verständnisproblem. Die Vorlagen bei einer Enterprise-CA zwar im AD veröffentlicht, aber dadurch stehen sie noch nicht auf einem konkreten CA-Server zur Verfügung. Du musst die Vorlagen, die deine CA tatsächlich anbieten soll, zuerst dort aktivieren. Eine CA installiert man nicht auf einem DC. Die Empfehlung gilt schon seit bald 20 Jahren. Gruß, Nils PS. Es gibt neben einigen Leuten hier im Board, die das können ;) auch ein gutes Buch zum Thema bei Rheinwerk.

Moin, ja, natürlich. Es wird ja ein Dienst von einem Windows-Server genutzt. Dasselbe gilt auch, wenn der Außendienstler per ActiveSync mit seinem Smartphone zugreift. Gruß, Nils

Moin, auch wenn du sehr interessante Vermutungen über mich und meine Brille (ich habe keine) anstellst: Du verfolgst hier offenbar eine akademische Frage. Ein zu erreichendes operatives Ziel gibst du zumindest nicht an, du versteifst dich auf deine selbst gewählte Frage. Kann man machen, aber für mich hat das keine Relevanz. Mir ist nicht klar, wozu man einen Domänenuser mit lokalen Adminrechten ausstattet, wenn man gleichzeitig versucht, ihn so einzuschränken, als wäre er kein Domänenbenutzer. Klar, da kann man rein technisch einiges machen. Für mich fehlt aber der Nutzen, weswegen ich mich nicht weiter damit befasse. Wüsste ich, was das operative Ziel ist, könnte ich mir überlegen, wo ich die Grenzen des Ansatzes sehe oder ob mir Alternativen einfallen. Dass du mit dem Konzept einen Rechner wirklich malware-sicher bekommst, bezweifle ich dennoch energisch. Dein Konzept ist blind gegenüber anderen Lücken, die ein nicht abgedichtetes Windows in üblichen Betriebsweisen hat. Es kümmert sich eben nur um diese eine Frage. Daher mein Hinweis, dass man solche Dinge sicher in einem Gesamtkonzept brauchen kann, aber allein bringt es nach meiner Ansicht ausgesprochen wenig. Damit ist für mich hier Schluss. Gruß, Nils

Moin, sorry, hier im Forum kann ich dazu nichts Zielführendes tun. Gruß, Nils

Moin, hm, seltsam. In einem Forum sind die Möglichkeiten begrenzt - ich würde mir das Objekt und den Vorgang jetzt mal genau ansehen. Wie lautet die Fehlermeldung denn bei dem erfolglosen Anmeldeversuch per VPN? Gruß, Nils

Moin, es ist ausgesprochen unwahrscheinlich, dass es an dem Attribut liegt. Das wird beim Kopieren eines Users gar nicht übertragen. Dass der Wert darin seltsam aussieht, liegt einfach daran, dass es kein Textfeld ist, sondern ein Binärwert, den kann ein Text-GUI natürlich nicht besser anzeigen. Ist bei dem User evtl. die Primary Group geändert worden auf einen anderen Wert als "Domänen-Benutzer"? Gruß, Nils

Moin, steht der RODC in der Niederlassung physisch gesichert, d.h. in einem abschließbaren Serverraum oder ähnlich? Dann wäre ggf. ein normaler DC vorzuziehen, weil der eben alle Funktionen bietet, die man von einem DC braucht. Dass der Zugriff auf Freigaben nicht funktioniert, deutet auf abgelaufene Tokens bzw. Kerberos Tickets hin. Die Anmeldung an den PC funktioniert dann über Cached Credentials (wie bei einem Notebook auf Reisen), aber auf Netzwerkressourcen kann man dann nicht zugreifen. Daher die Vermutung, dass die RODC-Konfig an der Stelle nicht ausreicht. Die kann man natürlich noch mal en détail prüfen, aber wenn ein schreibbarer DC ausreichend sicher dort steht (was hoffentlich der Fall ist, denn auch einen Dateiserver möchte man ja nicht gestohlen bekommen), hat man damit evtl. weniger Aufwand. Schnellschuss: Ist der Dateiserver denn auch in der RODC-Replikationsgruppe enthalten? Gruß, Nils

Moin, erstens gibt es im AD keinen PDC. Zweitens: Warum ein RODC? Drittens: Sind die User des Standorts und deren Rechner in der RODC-Replikationsgruppe, damit sie sich auch tatsächlich an dem RODC anmelden können? Gruß, Nils

Moin, sehr gut, dafür ist es gedacht. Gruß, Nils

Moin, man könnte den Sperr-Teil aus meiner DOS-Lösung ;) dafür verwenden: [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/ Dort ist es der letzte Abschnitt im Code (LogonTask). %1 steht dort für den Usernamen, der angegriffen werden soll. %2 ist die Anzahl der Versuche. Gruß, Nils

Moin, grundsätzlich funktioniert Sysprep auch in der GA, aber aussagekräftig werden deine Tests wohl eher mit einem aktuellen Patchlevel sein. Oder was genau willst du jetzt wissen? Gruß, Nils

Moin, das ist korrekt so. Gruß, Nils

Moin, gerade in dem Szenario niemals lange Laufzeiten nehmen. Ich habe Kunden, die für VPN-Zertifikate max. 2 Wochen setzen. Das ist natürlich eine Frage der Abwägung, aber die muss eben informiert geschehen und die Sicherheit priorisieren. Beim Einsatz von Zertifikaten ist "es soll halt funktionieren" fast nie der richtige Ansatz. Gruß, Nils