cj_berlin

Allerdings, und das meine ich ernst, muss mir jemand mal zeigen, WIE er diese Website heutzutage noch benutzt, basiert die Ausstellung von Zertifikaten doch auf ActiveX-Controls...

Klar, jeden Tag, wenn Du die BSI- oder CIS-Härtung anwendest, dann wird der letzte angemeldete Name nicht vorbelegt.

Das ist die ACL, die jedes Objekt von seiner Klasse im Schema mitgegeben bekommt, wenn es erstellt wird. Wenn Du dir ein neues Objekt anschaust und die Berechtigungen unter "Advanced" auflistest, dann gibt es halt Einträge, die nicht vererbt sind. Das sind diese

genau. das ist ja der Sinn von "übernommen" --> es ist dann "ihre eigene" Domain

Manche, die ich so kriege, kommen mit valider DKIM-Signatur.

Moin, RDS-Lizenzierung ist niemals "concurrent" und ist es nie gewesen, daher schrieb ich oben Ansonsten, was @Nobbyaushb und ich auch bereits angemerkt haben - vergiss die zwei gleichzeitigen Sitzungen. Die sind für die Verwaltung des Servers und der darauf installierten Anwendungen, NICHT für die Benutzung. Andererseits, wenn ein Device lizenziert wurde (nein, nicht MAC-Adresse, die RDS-Lizenzierung funktioniert anders), können sich von diesem Device beliebige - und beliebig viele - User anmelden, Admin oder nicht. Ich bin generell kein Fan von VPN, aber ALLES ist besser als RDP ungeschützt ins Internet zu stellen, also per dieser Definition auch VPN

"PAT" ist das, was sein Router als "NAT" anbietet.

Moin, seltsame Formatierung, Ist es ein Copy/Paste aus einem anderen Forum? Dann bitte auf Cross-Post hinweisen. Das Wichtigste vorab: Du willst NICHT Port 3389 per NAT ins Internet stellen. Es sei denn, alle zugreifenden Clients haben feste IPs, und Du erlaubst nur diese auf der Firewall Deines Routers. Aber eigentlich auch dann nicht. Tust Du es dennoch, wird Dein Server nur damit beschäftigt sein, falsche Anmeldungen abzuweisen, bis die erste nicht falsch ist, und dann ist es nicht mehr Dein Server. Ansonsten: Neben RDS-Rolle aktivieren, musst Du dem Server noch den zuständigen RDS-Lizenzserver und den Lizenzierungstyp mitteilen. Der Typ, falls Du kein AD hast, kann nur "per Device" sein, der Lizenzserver kann auf demselben Windows Server aktiviert sein, und dort musst Du die RDS CALs einspielen - so viele, wie es unterschiedliche Devices gibt, von denen aus Deine User zugreifen werden. Aber da gibt es eine Karenzzeit. Dass bereits jetzt immer noch zwei Sessions möglich sind, ist ein Hinweis darauf, dass - vielleicht, nur vielleicht? - Deine "User" alle lokale Admins auf dem Server sind. Das ist natürlich auch nicht zielführend. Die Gruppe der Remotedesktop-Benutzer existiert auch lokal.

Moin, Herunterfahren ist einfach - lokale Sicherheitsrichtlinie, Zuweisen der Benutzerrechte, das Recht zum Herunterfahren dem Konto entziehen. Sperren - oder auch abmelden - ist schwierig. Je nachdem, was auf diesen Maschinen gemacht wird, könnte der Kiosk-Modus eine Lösung sein, aber ich weiß nicht, wie da der aktuelle Stand ist. Nachtrag - Du könntest, wenn es sicherheitstechnisch vertretbar ist, den "Tagsüber-User" ohne Passwort fahren. Hindert ihn zwar nicht am Sperren, aber auch nicht den Nächsten am Entsperren.

Wenn Twitter nach Deutschland kommt, hat Elon die Adresse e@x.de Und die Leute von der iX haben 2-stellige Kürzel und somit 8-stellige e-Mail-Adressen. Nicht kürzer als Dein samAccountName, aber trotzdem ziemlich geil.

Leider nein. Bin vom 28.03. bis 11.04. weg

Ich bin im März kaum im Lande :-( Nächstes Mal dann...

Moin, Get-ADObject -Filter * -SearchBase "CN=MSA01,CN=Managed Service Accounts,DC=doma,DC=in" -SearchScope Base -Properties tokenGroups, msds-tokengroupnames Wichtig ist, dass SearchScope=Base ist, denn das sind berechnete Attribute Allerdings sind natürlich im Token auch verschachtelte Gruppenmitgliedschaften enthalten. Wenn Dich nur direkte interessieren, dann Get-ADObject -Identity "CN=MSA01,CN=Managed Service Accounts,DC=doma,DC=in" -Properties memberOf DANN verpasst Du aber natürlich wiederum die Primary Group, denn diese ist nur über die primaryGroupID den Mitgliedern zugeordnet...

Moin, wie ich oben bereits schrieb, hast Du (vermutlich, aus Deiner Schilderung) kein ADWS-Problem, sondern ein AD-Problem. ADWS läuft, aber das AD oder vielmehr der DC fällt ab und zu aus, udn ADWS meldet das mit der Fehlermeldung aus dem OP. Dein NTDS-Log muss knallrot sein bei dem Befund, auch DNS Server-Meldungen und einiges mehr. Ich habe so die Vermutung, dass wir im Rahmen des Forums die notwendige Diagnose nicht werden vornehmen können. Such Dir ein zweites Paar Augen, am besten jemanden, der solch ein AD-Troubleshooting schon mal gemacht hat. Der Src Root Domain Srv ist der DC, von dem dieser DC bei seiner Promotion die forestweiten Partitionen repliziert hat, also wenn die Domäne älter ist als 2008, wird da natürlich ein anderer Server drin stehen

Genau.

Moin, ultimativ lösen --> da muss man sich mit Deinem anderen Thread und Deinem AD beschäftigen. jetzt das AD PowerShell-Modul in Gang bringen --> versuch mal, das Ganze auf dem 2008er DC zu starten oder auf einer anderen Maschine, aber den 2008er DC im Parameter -Server anzugeben.

PowerShell 7 ist NICHT die neueste Version von PowerShell, es ist ein separates Produkt. Alle Built-In-Cmdlets von Windows Server-Rollen sind für Windows PowerShell 5.1 entwickelt, und wenn Du sie aus PowerShell 7 aufrufst, wird unter der Haube ein Kompatibilitätsmodus gefahren. Du musst Dein AD reparieren, dann wird auch ADWS funktionieren, und damit auch das PowerShell-Modul.

Moin, wenn Du auf einem Server 2016+ oder Windows 10+ bist, hast Du die neueste. Du hast ja das ADWS-Thema gepostet, das hängt damit zusammen,

Moin, was Du vorhast ist technisch möglich. Wenn der Forest nur eine Domäne hat und keine Vertrauensstellungen zu anderen Forests, ist der Gruppen-Scope weniger wichtig. Es gibt Feinheiten wie Token Size, aber generell kannst Du die Gruppen konvertieren, und es dürften dem keine Gruppenverschachtelungen im Wege stehen, denn auch mögliche Mitglieder sind identisch. Ich bin aus Erfahrung kein Freund von Mail-Enabled Security Groups, und wenn Hybrid oder Migration zu Exchange Online am Horizont ist, würde ich dringend davon abraten. Zumindest in der Koexistenzphase, wenn ein Teil der Postfächer on-prem und ein anderer Teil online ist, wird das unschön. Falls ihr diese Gruppen automatisiert, z.B. aus einem IAM-System bestückt, würde ich prüfen, ob's nicht möglich wäre, einfach ZWEI Gruppen pro Entitlement zu pflegen - eine Security-Gruppe für die Zuweisung und eine Verteilergruppe für den Mailversand. Was auch immer Du tust, stell sicher, dass die Gruppen im Sinne des Bei- und Austritts "geschlossen" sind, so dass die Mitgliedschaften nur administrativ gepflegt werden können und nicht durch die Benutzer selbst über Outlook.

Korrekt. Nützt auf dem RODC ohne Netz eh nix

ABER - für RODCs kannst Du ein Konto cachen, das Du dann im managedBy-Attribut des RODC Computer-Objekts hinterlegst. Dieser User kann dann den RODC administrieren.

ich meine auf einem schreibbaren Domain Controller lokal ohne Netzwerk mit einem Admin, der in Protected Users ist, anmelden.

Hier funktioniert's. Frisches Account angelegt, Domain Admins + Protected Users. Kabel von DC abgezogen, rebooted, lokale Anmeldung funktioniert. Aber natürlich nur lokal. RDP ist nicht lokal, und RDP schließt sich mit "kein Netzwerk" auch gegenseitig aus.

Moin, klar können sie sich lokal anmelden, wenn sie aus derselben Domäne sind. Der DC kennt ja deren Kennwörter...