Jump to content

Apex

Members
  • Gesamte Inhalte

    98
  • Registriert seit

  • Letzter Besuch

Reputation in der Community

11 Neutral

Über Apex

  • Rang
    Junior Member
  1. Danke, genau diese Kombination hat zum Ziel geführt...
  2. Hallo mit Windows 8.1 und Windows Server 2012 kamen zwei neue Security Identifiers hinzu: S-1-5-113 für NT AUTHORITY\Local account und S-1-5-114 für NT AUTHORITY\Local account and member of Administrators group: https://blogs.technet.microsoft.com/secguide/2014/09/02/blocking-remote-use-of-local-accounts/ Soweit so gut, jetzt will ich NT AUTHORITY\Local account im Rahmen einer GPO verwenden und z.B. "Deny log on through Remote Desktop Services" für diese SID setzen. In der GPMC kann ich das aber nicht auflösen, auch wenn als Typ Built-in security principals ausgewählt ist. Warum ist das so und wie kann man den Bezeichner bei Windows Server 2016 korrekt auflösen/eintragen...? Danke
  3. alternative login ID

    Hallo wird auch ADFS genutzt oder rein Azure AD, AD DS und Azure AD Connect?
  4. Mag sein, nur bringen mir die Aussagen im Gegenzug aktuell immer noch nicht sehr viel. Die DNS Einträge sind nicht kritisch, auch das wurde mir so mitgeteilt. Diese Aussage kann ich teilen, da es tatsächlich um die Benutzer-Einträge im AD geht, also um personenbezogene Daten. Die Rechner und Server nutzen ein Namensschema, das nichts damit zu tun hat und eher auf die Funktion des Rechners abzielt. Den einen Tip nehme ich gern, aber meine konkrete Frage: "Habe ich Nachteile bei einem Einsatz eines nicht-AD-integrierten DNS Servers" wurde nicht abschließend beantwortet. Geht es tatsächlich nur um die Replikation, die mir fehlt? Die muss ich manuell konfigurieren: OK, geschenkt.
  5. Die Anforderung, die an mich herangetragen wurde ist, dass an einem abgesetzten Standort ein DNS Server aufgebaut werden soll, da die Namensauflösung "zu lange" dauert. Dort an diesem Standort soll/darf aber kein vollwertiger Domänencontroller aufgebaut werden. Meine Frage ist, hier wäre eine Antwort wirklich toll, was habe ich für Nachteile dadurch, dass ich einen DNS Server betreibe, der nicht AD-integriert ist? Danke
  6. Wie ist das gemeint? Eben keine. Er macht ja nur DNS und stellt kein AD bereit, ist kein DC. Darum geht es ja.
  7. Ich bin von der Anforderung auch nicht begeistert. Der DNS Server (ohne AD) soll in eine Zone, in der keine personenbezogenen Daten erwünscht sind. Dieser soll rein zur Namensauflösung genutzt werden und die Geschwindigkeit erhöhen der Anfragen bezogen auf Latenz und Antwortgeschwindigkeit. Das mit der Synchronisierung, die normalerweise das AD über Replikation erledigt, ist ein guter Punkt. Danke dafür
  8. Hallo es wird der Einsatz eines DNS Servers überlegt, der nicht AD integriert ist in einer normalen AD Domäne. Die übrigen DNS Server sind AD integriert und laufen so, wie das üblich ist. Hintergrund ist, dass der DNS Server ohne personenbezogene Daten (AD) laufen soll. Ich kann mich erinnern aus der Zeit als man noch oft Bind in Verbindung mit AD Domänen verwendet hat, dass es dabei Nachteile gibt einen Windows DNS Server standalone zu betreiben. Mit welchen Nachteilen muss ich rechnen, wenn ich einen der DNS Server so betreiben soll? Danke
  9. Hi das sollte einfach machbar sein: Start > Ausführen > gpedit.msc In dem Zweig hier: User Configuration -> Administrative Templates -> Desktop -> Desktop die Einstellung "Desktop Wallpaper" anpassen. have fun
  10. Danke, bei der Microsoft Cloud Deutschland scheint es nicht so zu sein, allerdings bei dem globalen Azure. Dort habe ich die Sourcen gefunden unter: C:\Windows\WinSxS Den Pfad aus dem Artikel (C:\Windows\sxs) gibt es so nicht...
  11. Hallo das was ich gefunden habe ist nicht gerade hübsch: https://michaelcollier.wordpress.com/2017/05/03/copy-managed-images/ https://www.obungi.com/2017/07/21/how-to-copy-an-azure-vm-from-region-a-to-region-b/ Das Vorgehen: Man braucht neben dem Image die VM und das ganze als Skript ist nicht gerade schlank Bin offen für elegante Lösungen oder Ideen
  12. Hallo aktuell zerschelle ich an einem Azure-Thema, das mich überrascht: Wenn man ein Image (Abbild) erstellt von einer Windows VM, wie üblich via sysprep behandelt, so ist das auch in Azure möglich und es gibt dafür ein Feature namens Image/"Bilder". Soweit so gut und bekannt. Nur ist ein so erstelltes Image nur bezogen und beschränkt auf eine Region, das heisst ich erstelle ein Image einer VM in West Europe, dann kann ich damit nur VMs in West Europe erstellen. Will ich VMs aus diesem Image in anderen Regionen erstellen, müsste ich den Vorgang manuell jeweils wiederholen, was fehleranfällig ist oder das Image herunterladen und wieder hochladen. Soll heissen: Es gibt keine einfache und praktische Möglichkeit dieses Image auch in anderen Regionen zu hosten. Gibt es eine elegante Möglichkeit ein so erstelltes Image in anderen Regionen bereitzustellen? Ich stelle mir ein In-Azure-Copy vor oder einen anderen Mechanismus, den ich nach dem Capture ausführe... Danke
  13. Nochmal zur Erläuterung: Ich teste in einer isolierten Domäne (1 DC) ca. 20 bis 25 mal eine Anbindung einer Software gegen AD/LDAP. Das hier LDAPS verwendet wird ist nur der Transportweg und für das Vorhaben uninteressant: Ich teste nichts in Richtung Verschlüsselung, Schlüssellängen, Encryption Types etc. Es geht wirklich nur um die AD Anbindung an einen DC in einer Testumgebung, die ca. 2 Tage Bestand hat. Für das Vorhaben finde ich die Methode ausreichend. Wenn die zwei Skripte anderen helfen, dann bin ich schon zufrieden.
  14. Nicht mal für eine Test- oder Entwicklungsumgebung? Das für produktive Umgebung eine vertrauenswürdige CA oder eine eigene PKI der beste Weg ist, sollte klar sein.
  15. Ja, das hätte was. Nur habe ich keine. Wenn ich mir das Prozedere so ansehe, das zum Erfolg geführt hat, dann ändere ich das voraussichtlich bald... Der Artikel hat leider nicht zum Erfolg geführt im Zusammenhang mit LDAPS. Das hier hat dann geklappt, nach vielen Fehlversuchen: https://blog.jayway.com/2014/09/03/creating-self-signed-certificates-with-makecert-exe-for-development/ Die Kurzfassung: - Benötigt werden die beiden ausführbaren Dateien makecert.exe und pvk2pfx.exe aus dem Microsoft Windows SDK for Windows 7 and .NET Framework 4 - Mit makecert.exe ein root certificate (Root CA/Wurzelzertifikat) erstellen, um weitere Zertifikate erstellen zu können: makecert.exe ^ -n "CN=CARoot" ^ -r ^ -pe ^ -a sha256 ^ -len 4096 ^ -cy authority ^ -sv CARoot.pvk ^ CARoot.cer pvk2pfx.exe ^ -pvk CARoot.pvk ^ -spc CARoot.cer ^ -pfx CARoot.pfx ^ -po Test123 Den gewünschten Namen für die Root CA eingeben und in eine .BAT/.CMD einfügen und ausführen. Es werden 3 Dateien erzeugt in verschiedenen Formaten. - Mit makecert.exe im zweiten Schritt ein Zertifikat für die Server Authentifizierung erstellen: makecert.exe ^ -n "CN=fqdn.domaenencontroller.de" ^ -iv CARoot.pvk ^ -ic CARoot.cer ^ -pe ^ -a sha256 ^ -len 4096 ^ -b 01/01/2018 ^ -e 01/01/2028 ^ -sky exchange ^ -eku 1.3.6.1.5.5.7.3.1 ^ -sv %1.pvk ^ %1.cer pvk2pfx.exe ^ -pvk %1.pvk ^ -spc %1.cer ^ -pfx %1.pfx ^ -po Test123 Den FQDN des Domänencontrollers eingeben und in eine .BAT/.CMD einfügen und ausführen. Es werden 3 Dateien erzeugt in verschiedenen Formaten. Wichtig ist die OID 1.3.6.1.5.5.7.3.1 und die Angabe der CA Root-Datei, die im ersten Schritt erzeugt wurde. Das wars: Im letzten Schritt die beiden Zertifikate an die passende(n) Stellen importieren: Das Wurzelzertifikat muss in der Zertifikatsverwaltung (MMC>Certificates) in den Zweig Trusted Root Certification Authorities. Das Zertifikat selbst unter Certificates (Local Computer/Personal/Certificates) sowie unter Certificates - Service (Active Directory Domain Services) unter NTDS\Personal importieren. Dann eine kurze Prüfung mittels ldp.exe durchführen und mit Port 636 verbinden, wenn das klappt und der AD DS antwortet hat man es geschafft. Ich hoffe das hilft jemanden weiter, mir haben 99% aller Anleitungen leider nicht geholfen außer der von Elizabeth Andrews (siehe Link oben).
×