cj_berlin

Hi,

das sollte nach wie vor funktionieren: https://lizardsystems.com/terminal-services-manager/articles/how-to-grant-shadow-access-rights-for-users-without-grant-full-admins-rights-in-rds-servers/

vor einer Stunde schrieb Cryer:

 

Service-Account: Account zur Anbindung und Authentifizierung externer Dienste gegenüber AD. Anmeldung an PCs damit nicht möglich.

Funktionsaccount: Kann nur an Computen verwendet werden, bei denen der Account hinterlegt wurde. Bei allen anderen Geräten wird die Anmeldung verweigert.

Siehst Du, und für Windows-Menschen ist ein Service-Account einer, unter dem ein Dienst ausgeführt wird 😊

Drum frage ich ja.

vor einer Stunde schrieb testperson:

Die User RDS Cals können ja nicht getrackt werden, da der eine Mensch sich ja durchaus mit 7 (User) Accounts anmelden kann, was von einer User RDS CAL gedeckt ist.

Ha! Diese Auslegung hatte ich noch nicht gehört, und sie würde ja total einleuchten, wenn man Microsoft vernünftiges Handeln unterstellt.

ABER. Nach demselben Prinzip könnten auch Device CALs nicht getrackt werden, denn ein Computer kann 7 OS-Instanzen installiert haben, die nichts voneinander wissen

vor einer Stunde schrieb testperson:

das wäre "return": about Return - PowerShell | Microsoft Learn

...wobei return als LETZTE Anweisung innerhalb einer Funktion vollkommen optional ist, sprich,

$rueckgabeWert

ist äquivalent zu

return $rueckgabeWert

Erst wenn return dazu verwendet wird, in einem bestimmten Zweig aus der Funktion auszusteigen, entfaltet es eine wirkliche Wirkung.

In Klassen sieht es wieder anders aus  

Dies nur als "unnützes Wissen zum Freitag".

Ich weiß nicht, was ein "Funktionsaccount" in Deiner Welt ist  Vielleicht. Aber genau das suchst Du doch, oder?

Moin,

im User-Account kannst Du nur die Workstations hinterlegen, von denen aus es sich anmelden darf, und Zeiten. Wenn das DokuWiki (ich nehme an, auf Linux) damit klar kommt, ist das Problem schon gelöst.

Für alles andere gibt es Policies ("loklae Anmeldung verweigern", "Anmeldung über remotedesktopdienste verweigern" usw.) womit Du den Member-Maschinen mitteilen kannst, dass dieses Acount sich NICHT dort interaktiv anmelden darf.

vor 33 Minuten schrieb testperson:

 

(Um den Empfang zu kappen, würde ich einfach die MX Records löschen.)

Das würde aber dazu führen, dass alle SMTP-Anfragen an den Server gehen würden, zu dem sich der FQDN der Domäne auflöst. Normalerweise nicht schlimm, muss man aber im Hinterkopf haben, falls doch.

Ich habe in meinen aktiven Labs nur zwei 2019er, beides Domain Controller, beide in EN-US. BEide haben zwar lange gerödelt, waren dann aber fertig. Aber natürlich VMs (ESX + Hyper-V), das ist nicht repräsentativ.

Nur hat @daabm die technologische Basis für diese Ansicht  Das ist der Unterschied sowohl zum BSI als auch zu 100% der Kunden von @Nobbyaushb.

vor 31 Minuten schrieb daabm:

Ehm - warum hängt Ihr Euch grad immer am "Befüllen" des Attributs auf? Es geht um das "Auslesen"...

Ich glaube, der Konsens im Thread ist, dass das verwendete Attribut nicht durch "äußere Umstände" befüllt wurde, sondern gezielt zweckentfremdet wird, um die benötigte Info zu speichern...

Moin,

vor 9 Minuten schrieb NorbertFe:

Get-clientaccessservices | fl *uri*

 

Service, Einzahl  

Nur mal als Schuss ins Blaue:

• hat der Einzel-Server exakt den gleichen Build wie die DAG-Member?
• auf welchem Server wohnt das Postfach von dem Account, mit welchem Du die ECP-Webseite aufrufst?

vor 1 Minute schrieb NorbertFe:

Sehr wahrscheinlich gar keine. Denn wenn das Auswirkungen in deiner Umgebung produziert, heißt es, dass da noch ziemlich alte Systeme beteiligt sind. Und die würdest du ja sicherlich kennen, oder? ;)

Das ist erst mal funktional, und da stimme ich @NorbertFe zu. Allerdings, wie immer, wenn man Kryptographie einschaltet, die vorher ausgeschaltet war, wird es zu einem etwas höheren CPU-Verbrauch führen als vorher  

Hier zum Beispiel ein Snippet, das das Mail-Attribut eruiert, in der Annahme, dass es nur eine Domäne im Forest gibt:

$ds = New-Object System.DirectoryServices.DirectorySearcher
$ds.Filter = "(&(objectClass=user)(sAMAccountName=$($env:USERNAME)))"
$null = $ds.PropertiesToLoad.Add("mail")
$user = $ds.FindOne()
$user.Properties["mail"][0]

Dafür benutzt man System.DirectoryServices, das ist in PowerShell unter Windows immer verfügbar.

Gerade eben schrieb NorbertFe:

Natürlich nicht. ;) Und ich bezweifle auch, dass es schon praxisrelevante Anzahlen von Umgebungen ohne NTLM gibt. ;)

Für diejenigen, die dort arbeiten, ist 1x doch durchaus eine praxisrelevante Zahl  

Aber klar, natürlich gibt es nur sehr wenige. Daher finde ich die Diskussion um jahrelang nicht gerollte Passwörter immer so spannend...

Moin,

Users von Shared Mailboxes sind normalerweise deaktiviert  Alle anderen: Least Privilege plus entweder Group Policy oder Authentication Policy.

vor 1 Minute schrieb NorbertFe:

Wir sind aktuell bei 14 Zeichen Länge und 10 History sowie 120 Tage maximales Kennwortalter und aktivierte Komplexität. Wir überlegen gerade, ob wir von den 120 Tagen hochgehen auf 365 und dafür 16 Zeichen erzwingen.

 

Also habt ihr NTLM schon abgeschaltet, so dass Pass-the-Hash nicht mehr ohne weiteres funktioniert? 

vor 6 Stunden schrieb Dayworker:

Nein, wir gehen auf einen nicht DC, öffnen dort die Ereignisanzeige, dann öffnen Protokoll eines anderen Computers. Dann öffnet er die Logs zum Anklicken, aber auf as Systemlog z.B. kommt dann Zugriff verweigert. 

Das hat in meiner Erfahrung mit "Event Log Readers" zu 100% funktioniert. Firewall?

Geht es um den Zugriff per PowerShell? Da gibt es zusätzliche Problemfelder.

vor 3 Stunden schrieb NorbertFe:

 

Hallo,

 

MS hat gerade mal ein Update der Roadmap veröffentlicht:

Und so sieht diese Roadmap grafisch aus:

Moin,

Tip #1: Die Verwendung von RODC noch einmal überlegen. Ist es *wirklich* ein Standort mit schlechter physischer Sicherheit, wo der DC physikalisch entwendet werden könnte? Falls nicht, ist RODC dort falsch.

Tip #2: DNS auf einem Member-Server installieren, wenn es schon nicht in AD integriert sein soll. Oder halt sogar auf einem Workgroup-Server.

Redest Du von diesem Thread oder von dem Zustand der Welt?

imap.something ist mit Sicherheit kein Posteingangsserver, auch wenn es in Outlook so heißt  Da müsste der Server hin, auf den der MX zeigte, bevor Du ihn auf Exchange umgestellt hast.

vor 3 Minuten schrieb Cryer:

Das ich damit keine Verbindung ins Geschäft aufbauen oder von unterwegs auf meine private NAS zugreifen kann.

VPN outbound zu einer IPv4-Adresse: Kann ich nicht bestätigen. Ich habe einen 1&1-Anschluss mit einer DSLite-IPv4 und bisher keine Probleme gehabt. Meine Kunden und Arbeitgeber hatten sowohl SSL-VPN als auch IKEv2, beides ging.

vor 25 Minuten schrieb RalphT:

Denn mit der eigentlichen Replikation hat dieses hier doch nichts zu tun.

Kommt darauf an, was für Dich die "eigentliche" Replikation ist. Das hat mit der AD-Replikation vielleicht nichts zu tun, dafür aber mit der DFS-Replikation, denn die SYSVOL-Inhalte kommen nicht "mit der Macht" auf die anderen Domain Controller.

Mit welchem DC Dein GP Editor verbunden ist, kannst Du direkt im Editor sehen: