cj_berlin

Moin,

die Domain-Funktionsebene konntest Du aber hochstufen?

Was passiert, wenn Du die Aktion nicht vom ADAC, sondern von Users & Computers (Domäne) bzw. Domains & Trusts (Forest) vornimmst?

Wie viele DCs sind insgesamt am Start? Leben alle noch? Funktioniert die Replikation?

Hoffentlich führt dieser Thread nicht dazu, dass Leute anfangen, ihre CAs auf Verdacht hin auf DCs zu installieren...  

Wobei natürlich, eine Issuing CA, die nur Smartcard-Zertifikate ausstellt, auf dem DC, und das Thema Revocation Lag bei SmartCards ist vom Tisch... Hmmm... 

Set-OWAVirtualDirectory -LogonFormat PrincipalName

vor 28 Minuten schrieb NilsK:

Daran ändert auch ein Online Responder nichts, weil auch der nur die CRL nutzt. 

 

Schon, aber man kann ihn anweisen, die CRL häufiger zu ziehen als sie abläuft:

Neu ausstellen muss man sie nach Sperrung eines Zertifikats natürlich manuell

Moin,

das sind *zwei* Anwendungsfälle:

1. wenn der User das Unternehmen verlässt, sperre sein Account im AD. Das wirkt sich auch auf die Smartcard-Authentifizierung aus.
2. wenn er seinen Key verliert und Du wirklich nur das Zertifikat zurückziehen möchtest, muss der Domain Controller davon erfahren. Es geht also nicht um den CRL Cache auf den Clients, sondern auf den Domain Controllern.

Moin,

zwei Punkte:

1. CALs werden entweder pro Gerät (Physik) oder pro Benutzer (Physik) benötigt, und nicht pro AD-Account oder irgendetwas anderes. Ob sich Herr Müller überhaupt gegen das AD authentifiziert, ist unerheblich - er greift auf Dienste eines Windows Server Version XY zu, und braucht daher CALs in mindestens dieser Version. Positiv dabei ist: Herr Müller braucht sie nicht pro Server, sondern kann mit einer 2019er CAL auf alle Server 2019, 2016, 2012, 2008 usw. derselben Organisation zugreifen. Und auch "Organisation" ist in diesem Fall kaufmännisch zu verstehen und nicht mit einem AD-Forest o.ä. zu verwechseln
2. Es gibt im Lizenzvertrag keinen "Mittelbaren Zugriff" auf Microsoft-Produkte. Wenn Herr Müllers MacBook auf eine Web-Applikation auf einem Linux-Server zugreift, der auf VMware ESXi virtualisiert ist, seine IP-Adresse aber von einem Windows DHCP-Server bekommt, braucht entweder Herr Müller oder sein Gerät eine CAL. So etwas wie ein Drucker braucht hingegen keine CAL, wenn er seine IP-Adresse von Windows-DHCP kriegt, sofern alle, die darauf drucken, eine User CAL haben.

vor 4 Minuten schrieb Nobbyaushb:

Für mindestens 90 bzw. 180 Tage ohne Key

 

Ich bin für 120  Aber auch danach passiert nix, außer, dass er warnt...

Bei mir hat das im GPO-Editor nicht funktioniert. Bei NTFS- oder Freigaberechten dagegen schon.

OK, also reden wir von dem gleichen, nur ich rechne in VMs und @lizenzdoc in Standard-Lizenzen  Und ja, je nachdem wie man Break Even definiert, ist 12 oder 13 VMs Break Even.

vor 1 Stunde schrieb lizenzdoc:

preislich wird es ab der 7. W-STD Lizenz günstiger DC zu kaufen!

 

Huch? https://www.microsoft.com/de-de/windows-server/pricing sagt: Standard = $972, also $486 pro VM, und DC = $6.155, somit 12,66x der Betrag. 

Wo ist der Fehler? Du bist der Profi

vor einer Stunde schrieb MS_Noob:

 

 

Also wenn man zum Beispiel 2 ESXI (2 Sockel je 14 Cores) mit je 4 VMs

Die VMs sind für den Teil, wo mit Cores gerechnet wird, völlig uninteressant, denn die Windows Server-Lizenzierung gilt für das Blech.

Die Anzahl VMs kommt dann ins Spiel, wenn Du entscheiden musst, ob Du Windows Server Datacenter brauchst oder mit Standard oder 2x Standard auskommst. *Dann* nimmst Du nämlich die maximale Anzahl Windows Sever-VMs, die zu irgendeinem Zeitpunkt theoretisch auf einem Host gleichzeitig laufen könnten. Liegt die Zahl über 12, ist Datacenter billiger. Liegt sie darunter, musst Du so oft Standard lizensieren, bis die doppelte Anzahl der Standard-Lizenzen über der Maximalzahl VMs liegt.

Gegenfrage: Was verwendest Du denn sonst?

vor 10 Minuten schrieb testperson:

Es werden immer (atmende) Menschen lizenziert und keine Accounts ("User").

 

...aber leider werden User *reportet* und nicht Menschen. Darüber muss man dann halt mit dem Auditor sprechen.

Mit 2019 werden User CALs übrigens auch getrackt, daher wird das Halbieren evtl. nicht zum Ziel führen.

Hmmm. Ich habe es gerade aus Spaß im Labor ausprobiert. Der Session Host erbt nicht das Zertifikat vom Deployment, dieses ist in keinem Store vorhanden:

Und dennoch wird bei der Verbindung...

...das Zertifikat des Deployments (und auch dessen Name) verwendet:

Die einzige Anpassung, die ich gemacht habe, ist:

aber das beseitigt *eigentlich* einen anderen Pop-Up.

Der RD-Listener am Broker hat allerdings sehr wohl das Wildcard-Zertifikat gebunden.

Na toll, jetzt kann ich keine Screenshots mehr posten.

Aber eine andere Idee: Hat Dein Wildcard-Zertifikat den Wildcard-String auch im SAN oder evtl. nur im Subject?

Nein, User CALs in eine nicht vertrauende Domain pumpen kann der RDS-Lizenzserver nicht. Das ist das, wovon ich vorhin schrieb: Du brauchst einen Lizenzserver pro Forest und das Lizenzpaket somit 2x installiert. 

vor einer Stunde schrieb WSUSPraxis:

Dann erscheint die Zertifikatsmeldung. Hier dann jeweils das Zertifikat des jeweiligen Session Host.

 

Dann ist irgendwas mit Deinem Deployment nicht so wie es sein soll. Normalerweise spielen die individuellen Zertifikate der Hosts keine Rolle. Hast Du evtl. eine GPO für die Infrastruktur-Server, die zufällig auch auf Deine Farm wirkt und wo die Zertifikatsvorlage für RDP-Zertifikate festgelegt wird? 

Kannst Du die Session Hosts einmal aus dem Deployment entfernen und wieder hinzufügen? Oder einfach schnell eine VM in eine neue Session Collection stecken und schauen, ob das Problem immer noch auftritt?

Das allererste Beispiel sollte es tun.

Am 14.12.2020 um 21:42 schrieb J1504:

 

 

ich bräuchte eine .bat datei 

Bestimmt nicht. Es gibt keine lebendigen Systeme mehr, die zwar .BAT, aber keine .CMD unterstützen  

Hier sind nette Beispiele für FTP-Skripte mit Windows-Bordmitteln: https://www.dostips.com/DtTipsFtpBatchScript.php

Moin,

die Texteingabe der SID sollte funktionieren.

...allerdings wird diese Konstellation in Bezug auf die RDS-CALs immer zu Gesprächsbedarf führen, denn diese werden rein technisch sowohl doppelt vorgehalten als auch doppelt ausgestellt. Aber wenn die Namenskonventionen in beiden Segmenten so sind, dass man glaubhaft machen kann, dass AD1\bondj007 und AD2\bondj007 ein und dieselbe physische Person sind, ist der Auditor dann meistens auch schnell beruhigt.

Moin,

erstens, auch ein SHA-256-Zertifikat hat auch ein SHA-1-Thumbprint.

zweitens, das Farm-Zertifikat wird nur dem Broker über das Deployment zugewiesen (hast Du ja schon gemacht). Es ist schließlich nicht vorgesehen, dass man direkt auf einen RDSH aus einer Farm zugreift. Und wenn, dann ist man Admin und weiß mit der etwaigen Warnung umzugehen.

Was genau funktioniert denn nicht? Wenn Du Pop-Ups kriegst, kann es einen anderen Grund haben, je nachdem, welche Pop-Ups das sind...

OK, ich habe mir das nochmal angeschaut. Leases bekommst Du weder mit DUMP noch mit EXPORT, beide liefern de facto nur die Config. Wenn er beim Import meckert, sind wahrscheinlich falsch aufgelöste Sonderzeichen Schuld. Du kannst es viel robuster per XML mit Export-DHCPServer und Import-DHCPServer machen.  Und da kannst Du, zumindest beim Export, auch die Leases mitnehmen, wenn Du sie für die Nachwelt dokumentiert haben möchtest  

Mit Windows Server? RRAS. Ich sehe kein Incentive, da mit einem Third Party-Produkt anzufangen...

Aaaalso, zwei Dinge:

1. Wenn der Scope 10.32.0.0/16 noch in der aktiven Konfiguration drin ist, kannst Du 10.32.0.0/24 oder 10.32.1.0/24 nicht hinzufügen, denn sie würden sich ja überlappen.
2. Wenn Du nur die Maske geändert hast, versuchst Du laut Deinem Post ja Elemente mit 10.32.1.x in das Subnetz 10.32.0.0/24 zu schieben, wo sie nicht mehr hingehören. Aber vielleicht habe ich den Punkt ja missverstanden.

Das Subnetz des Scope ändern geht nur über Löschen/Hinzufügen, die ausgeteilten Leases gehen dabei verloren. Was aber nicht schlimm ist, denn sie werden beim Refresh erneuert.

Moin,

und der VPN-Endpunkt läuft auch auf dem Server oder ist da vom RZ-Provider etwas vorgeschaltet? Im Prinzip geht das mit der Windows-Firewall: Den Zugriff für RDP auf diejenige IP einschränken, die Dein Client bei der VPN-Einwahl bekommt.