Dunkelmann
-
Gesamte Inhalte
1.863 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von Dunkelmann
-
-
Dort sollte stehen:
URL = "http://pki.meinedomain.net/CertEnroll/rootLlegalPolicy.txt"
Meine Frage lautet, ob es etwas nutzt, wenn ich das ändere? Oder muss ich etwas neu erstellen?
Moin,
die capolicy.inf wird zur Laufzeit nicht genutzt. Die Vorgaben werden nur bei der Installation der CA oder bei der Erneuerung des CA Zertifikats angewendet.
Die url der legal policy wird als Eigenschaft den ausgestellten Zertifikaten hinzugefügt. Wenn eine Anpassung erforderlich ist, sollten alle von der CA ausgestellten Zertifikate erneuert werden. Wenn es sich um die Root CA handelt, betrifft es auch das selbstsignierte Zertifikat der Root CA.
Ob das Anpassen für eure Organisation wirklich erforderlich ist, oder ob es sich um ein kosmetisches nice to have handelt, kann aus der Ferne nicht beurteil werden.
-
Moin,
wenn Du Dir was einfängst, dass sich Zugriff auf offline Backups verschaffen will, hast Du vermutlich andere Probleme als banale ransome ware.
Das war bestimmt der mexikanische Glotzfrosch - sehr selten!
... aus Süd Sri Lanka
-
1
-
-
Moin,
was hast Du wie 'hin und her' installiert?
Hast Du die CDP angepasst? Stimmt DNS? Liegt der CDP überhaupt auf einem Webserver?
Was passiert, wenn Du die url im Browser öffnest?
-
Moin,
das was ich bisher gelesen habe, erzeugt ein massives Gruseln. Dabei geht es nicht um Dich, sondern um die Anforderungen und den Mangel an Know How der sogenannten 'Admins'.
Subdomain für Gäste, MAC Filter/Authentifizierung usw.; wer so etwas vorschlägt hat das Thema 802.1x nicht verstanden.
Ohne einen fähigen und qualifizierten Tutor würde ich das Ganze vergessen und ein neues Thema suchen.
Falls Du dennoch am Ball bleiben willst, werfe ich mal ein paar Brocken in den Raum:
- WiFi Controller
- Captive Portal und Voucher
- 802.1x guest vlan
- PKI und NDES/SCEP
-
Moin,
es gibt von Brian Komar ein schönes Buch: PKI & Certificate Security
ISBN-10: 0735625166
ISBN-13: 978-0735625167 -
Beim Stacking werden mehr Komponenten in eine Failure-Domain aufgenommen, das ist bei HA eher unerwünscht.
Bei stand alone Switches gibt es mehrere Failure Domains aus jeweils einem Switch. Beim Stack nur eine, den Stack.
Ich meine eher das klassische Stacking, wie es bei Campus oder Access Switches eingesetzt wird. Ich denke nicht das der TO VSS oder ähnliches einsetzen möchte.
-
Moin,
bitte kein Stacking, wenn es um Hochverfügbarkeit geht. Entweder die Dinger können virtual LACP, virtual link trunking (oder wie auch immer das beim Hersteller heißen mag) oder man baut eine klassische Topologie mit STP und active/passive Teams bzw. Switch Independent an den Endgeräten.
-
Moin,
genau, das geht (leider) nicht.
-
Scheinbar dreht MS wieder an der Lizenzschraube. Kann man den Dokumenten glauben, sind für die nächste Server- und System Center Generation physische Cores zu lizenzieren.
Wobei es jeweils Stückelungen von 2 Cores geben soll und mindestens 8 Cores je Prozessor zu lizenzieren sein sollen (= 4 Lizenzen á 2 Cores).
-
Wir haben hier hochredundante Webserver ohne FT und das kostet bis auf die Hardware und die VMwarelizenz gar nix.
Hochredundante Webserver? Wow!
Fehlertoleranz richtig implementiert bedeutet fünf oder sechs Neunen garantierte Systemverfügbarkeit. Alles darunter ist Spielzeug.
-
Es gibt unter Anwendungs- und Dienstprotokolle ein Log "DPM Alerts". Event ID 3112 steht für eine erfolgreiche Wiederherstellung.
Bei der Menge an Dateien würde ich eher im PowerShell Skript ein 'out-file' mit den relevanten Parametern (welcher Pfad, welche Datei, welcher Backupstand, wohin, timestamp etc.) erzeugen und zur Nachkontrolle in die Abteilungen geben. Je nach Unternehmensgröße und/oder -art können solche Information ggf. Audit-/Compliance-relevant sein oder auch ein RPE* verhindern, falls Theorie und Praxis nicht Hand in Hand gehen.
----
*Resumee Producing Event, auf Deutsch auch Abmahnung genannt.
-
Mit geeignetem Budget (sechs- bis siebenstellig) guter Planung und qualifiziertem Personal für Implementierung und Betrieb.
-
Moin,
das Verhalten ist normal. Ein Cluster stellt nur Hochverfügbarkeit bereit. Wenn Du mehr möchtest benötigst Du Fehlertoleranz.
-
Dann wird es Zeit für Power Shell und einen Kasten Bier vom "talentierten" Kollegen
https://technet.microsoft.com/en-us/library/hh881588%28v=sc.20%29.aspx
https://technet.microsoft.com/en-us/library/hh881612%28v=sc.20%29.aspx
-
Moin,
Plattenauslastung und andere Systemwerte lassen sich mit den MS MPs recht einfach überwachen.
Bei Fremdanwendungen sieht es anders aus. Dafür muss man sich i.d.R. selbst etwas bauen. Das kann von einer einfachen Überwachung des running-state eines Dienstes bis hin zur Ermittlung von Latenzen eines Remote-Clients, Auswertung von Logfiles der Applikation usw. gehen. Benutzerdefinierte Überwachungen müssen bei Anwendungsupdates / -migrationen ggf. nachgepflegt werden, das ist in vielen Fällen kein Selbstläufer wie die fertigen MPs von MS und man sollte einen guten Draht zum Softwarehaus haben damit man nicht alles durch herumpröbeln herausfinden muss.
-
Natürlich geht das auch mit DPM. Es gibt unter Wiederherstellung sogar einen Punkt "Wiederherstellungspunkte suchen / Dateien und Ordner" ;)
-
Moin,
hat er wirklich nur die admx hinzugefügt oder auch gleich ein wenig in den Richtlinien rumgewerkelt?
-
Wie die man Benutzer verwalten möchte, muss man sich selber überlegen.
Wie oft ist eine interaktive Anmeldung an den Servern notwendig? Ist es notwendig, dass sich verschiedene Admins mit individuellen Kennungen anmelden, müssen zwangsläufig lokale Administratoren verwendet werden, kann der Datensfer ggf. per VMBus erfolgen und/oder sonstwie vollständig automatisiert werden, usw. usf.
Zum Patchen kann man sich einen WSUS in die DMZ packen. Ob als eigenständiger WSUS, Downstream, oder nur zum Genehmigen und Statistik sammeln ist wieder geschmackssache. Man kann die DMZ natürlich auch an den internen WSUS binden, direkt von MS Updates beziehen oder sogar den SCCM samt DCM verwenden.
Man kann sich auch mehrere Zonen bauen. Eine für inbound anonymous (öffentliche Webservices), inbound authenticated (owa), eine für outbound (proxy, DNS Forwarder), eine als Infrastruktur (AD, WSUS) für die anderen beiden.
Am Ende des Tages muss das Konstrukt natürlich benutzbar und verwaltbar bleiben.
-
1
-
-
Moin,
das hängt von Deinen konkreten Anforderungen (und natürlich vom Budget) ab. Für ein umfangreiches Szenario finden sich i.d.R. keine Best Practices, solche Lösungen sind zu individuell.
Eine eigene Domäne mit Hyper-V Cluster und z.bsp. shared JBOD als gemeinsamen Speicher kann man machen. Es geht aber auch flacher mit nur einem separaten VLAN. Dazwischen gibt es noch diverse Schattierungen.
Je nachdem, welche Dienste in der DMZ laufen sollen, kann die Verbindung zur internen Domäne komplett uneterbunden werden, per Vertrauensstellung erfolgen. Bei einigen Applikation kann ggf. auch ADFS oder Radius/NPS verwendet werden. Da geht es aber schon recht weit in Details, die sich in einem Forum kaum seriös behandeln lassen.
PS: Für Kennwörter gibt es jede Menge Kennwortdatenbanken. Z.Bsp. KeePass
-
Moin,
wenn Du die Webservices nicht möchtest, nimm 'certutil'.
-
Es gibt zusätzlich noch Einträge in der Datenbank.
MS schreibt dazu:
To safely remove the server from your RDS deployment, contact Microsoft Customer Support Services. For a complete list of Microsoft Customer Support Services telephone numbers and information about support costs, visit the following Microsoft website:
Important We do not recommend that you manually edit the database that is used by the RDS deployment.https://support.microsoft.com/en-us/kb/2925854
Falls Du es - auf eigene Verantwortung - selber probieren möchtest:
http://dave.harris.uno/unable-to-remove-deleted-session-hosts-from-rds2012-deployment/
-
Moin,
auf dem Broker gibt es einige lokale Sicherheitsgruppen mit Bezug zur RDS Konfiguration. In einer oder mehrerer dieser Gruppen - hab gerade zur Hand, welche genau - wird der tote Server noch als Mitglied hinterlegt sein.
Eventuell findest Du nach dem Löschen des Computerkontos aus dem AD auch nur noch eine SID, die nicht mehr aufgelöst werden kann.
-
Hi Dunkelmann,
ich habe das Farmzertifikat in den Bereitstellungseigenschaften der Sammlung konfiguriert. Dort gibt es drei Punkte :
- Remotedesktop-Verbindungsbroker - einmaliges Anmelden aktivieren
- Remotedesktop-Verbindungsbroker - Veröffentlichung
- Web Access für Remotedesktop
Bei allen dreien habe ich das Farmzertifikat rdsfarm.mydomain.com hinterlegt.
Hast Du auch den Client Access Name für den Broker angepasst?
Zudem habe ich auf dem Sessionhost rds02 das Farmzertifikat lokal in den Zertifikatsspeicher hinterlegt (unter Eigene Zertifikate) und den folgenden Befehle ausgeführt:
- gci cert:\LocalMachine\My | select FriendlyName, Thumbprint (zur Anzeige des Fingerabdruckes des Farmzertifikates)
- wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash="<Fingerabdruck des Farmzertifikates>"
Warum?
Kann mir jemand sagen, ob der WebAccess nicht über den Brokerdienst geht, sondern sich direkt mit den RDS Hosts verbinden will? Das wäre für mich zur Zeit die einzige mögliche Erklärung, auch wenn ich dann noch nicht weiß, wie ich das Problem lösen könnte, da beide Zugangsmöglichkeiten auf die Farm gewünscht sind.
Danke Mag
Aufrufe aus dem WebAccess gehen über den Broker.
Gib mal bitte die Ausgabe von 'Get-RDCertificate', 'Get-RDWorkspace' und ein 'certutil -dump' vom fraglichen Zertifikat.
-
Es gibt einen Unterschied zwischen preiswert und billig. Aktuell sind Kabel von equip im Einsatz und die Reklamationsquote geht gegen null.
Ginge es nach mir, ich gäbe ein paar Mark mehr aus.
Meine letzten Reichs-, Gold- und D-Mark behalte ich :cool:
Server 2012 R2 Remote Desktop Services
in Windows Server Forum
Geschrieben
Moin,
Der Ansatz ist grundsätzlich richtig.
Dem RDS Gateway ist es egal, ob RemoteApps oder ein Desktop veröffentlicht wird.
Sollte gemacht werden. Eventuell auch in Kombination mit dem Web Aplication Proxy (WAP) und ADFS
Vermutlich ja, sonst würde es ja funktionieren
Ryan hat auf seinem Blog eine ganze Reihe Artikel zum Thema:
http://ryanmangansitblog.com
Nicht ganz korrekt. Die Website oder Feed stellen nur Verbindungsinformationen für die Client bereit. Der Verbindungsaufbau zu den RDS Ressourcen erfolgt unabhängig.
Genauer: Es wird der Broker kontaktiert und beim Verbindungsaufbau, wird die angeforderte Ressource (Bspw. Name der Sammlung und RemoteApp) als Parameter mitgegeben. Der Broker leitet die Verbindung an einen passenden RDS Session Host um.
Im mstsc können die Parameter zu Sammlung etc. nicht angegeben werden, daher ist ein manueller Aufruf nicht repräsentativ.
Der Gateway ist keine Webanwendung, sondern ein Anwendungsgateway.