NilsK

Moin,
 
zumindest machst du in dem Fall nichts großartig verkehrt. Ich würde das bei der Anzahl, die du angibst, wohl auch übers GUI machen.
 
Gruß, Nils
 

Moin,
 
Das entspricht dem Sicherheits-Reiter bei einer Datei. Bei einer Gruppe legst du dort fest, wer auf diese Gruppe zugreifen darf, um sie zu administrieren. Das gilt für alle Objekte im AD.
 
Eigentlich geht es dabei nicht nur um die Administration, sondern man könnte darüber auch steuern, wem die jeweiligen Objekte überhaupt angezeigt werden. Das kann beliebig komplex werden. 
 
Gruß, Nils

Moin,
 
für Automatisierung innerhalb des SQL Servers ist der SQL Server Agent da. Für einfache Aufgaben ist der einigermaßen selbsterklärend.
 
Falls der nicht nutzbar ist, kann man SQL-Skripte mit sqlcmd.exe auch über den Windows-Taskplaner ausführen.
 
Gruß, Nils
 

Moin,
 
Der Default-Switch ist ein spezieller Switch mit NAT-Funktion, der VMs möglichst einfach ins Internet bringen soll. Das setzt voraus, dass diese ihre Adresse per DHCP beziehen.
 
Wenn das Prinzip für dein Szenario nicht passt, musst du dir einen separaten virtuellen Switch anlegen.
 
Gruß, Nils

Moin,
 
der saubere Weg: Definiere zwei Domänenlokale Gruppen "Organizer-Lesen" und "Organizer-Vollzugriff". Richte für diese Gruppen (und nur für diese) die Berechtigungen ein. Stecke den einen User in die Lesen-Gruppe und alle anderen in die Vollzugriff-Gruppe.
 
Für andere Ansätze müsste man wissen, wie die Applikation auf Leserechte testet. Vielleicht könnte man dann gezielter mit dem "Verweigern" arbeiten - wobei man das üblicherweise vermeiden will.
 
Gruß, Nils
 

Moin,
 
da würde ich @winmadness zustimmen. In dem beschriebenen Szenario sieht mir Beeftext nach einem Umweg aus - und nebenbei nach einem Sicherheitsrisiko (nur für eine Supportmail alle paar Wochen muss man keinen dauerhaften Keylogger einrichten).
 
Gruß, Nils
 

Moin,
 
vermutlich einer der Fälle, die nirgends ausdrücklich geregelt sind.
 
Technisch dürfte AAD Connect auch in diesem Szenario der günstigste Weg sein, weil es alles, was man braucht, schon enthält. Alternativ könnte man so einen Sync auch mit anderen Tools (ohne Windows) bauen, aber ich bezweifle, dass man da was Fertiges findet, und dann ist es unangemessen viel Arbeit.
 
Lizenzrechtlich wird man wohl über Mutmaßungen nicht hinauskommen - gerade in diesem Fall, wo an den A1-Lizenzen ja auch niemand richtig Geld verdient. Intuitiv würde ich der Vermutung von Franz anhängen: Der Windows-Server ist an den Aktivitäten der Anwender nicht beteiligt, sondern er sorgt nur im Hintergrund für einen eher sporadischen Datenaustausch, den man auch anders bewerkstelligen könnte. Kein User greift direkt oder indirekt auf den Windows-Server zu. Also vermutlich (!) keine CAL-Pflicht.
 
Eine Unklarheit bleibt, und ich fürchte, wie gesagt, die wird man nicht aufgelöst kriegen.
 
Gruß, Nils
 

Moin,
 
vermutlich meinst du, dass du den alten DC aus der Domäne entfernst? Das kann man tun, aber: sofern die Domäne mehr als 5-10 User hat, ist ein einziger DC nicht genug, man sollte dann mindestens zwei haben.
 
Zu deinen Problemen: Ich vermute, dass DNS nicht korrekt eingerichtet ist.
 
[Was muss ich beim DNS für Active Directory beachten? (Reloaded) | faq-o-matic.net]
https://www.faq-o-matic.net/2007/01/09/was-muss-ich-beim-dns-fuer-active-directory-beachten-reloaded/
 
Gruß, Nils
 

Moin,
 
... oder ausführlicher: nslookup macht das, was es soll. Aber nicht das, was du erwartest - und viele andere Admins.
 
[Wenn (und warum) nslookup unerwartete Ergebnisse zeigt | faq-o-matic.net]
https://www.faq-o-matic.net/2014/02/12/wenn-und-warum-nslookup-unerwartete-ergebnisse-zeigt/
 
Gruß, Nils
PS. Norbert, danke für den Trigger. 

Moin,
 
ja, das ist korrekt. Und es lässt sich nicht verhindern. Zertifikate sind nicht geeignet, um Hardware eindeutig zu identifizieren - solange diese  Zertifikate nicht mit der Hardware "fälschungssicher" und "untrennbar" verbunden sind. Letzteres ist das Prinzip eines TPM, das lässt sich aber durch nachträglich ausgestellte Zertifikate nicht nachbilden.
 
Anders, als viele oft annehmen, sind Zertifikate keine Garanten für Sicherheit. In den meisten praktischen Situationen sind sie sogar eher das Gegenteil.
 
Gruß, Nils
 

Moin,
 
musst du die Leases denn wieder zurück übertragen? In dein meisten Szenarien ist das völlig unnötig. Adresskonflikte sind unwahrscheinlich, weil der Windows-DHCP-Server standardmäßig vorher prüft, ob eine Adresse noch frei ist.
 
Gruß, Nils
 

Moin,
 
also ... wenn es wirklich "nur" monatlich sein soll und dahinter dann eine organisatorische Auswertung steht ... würde ich Automatisierung vermutlich für verzichtbar halten.
 
Nach dem, was ich dazu weiß, ist das entweder aufwändig oder kostet Geld. Siehe etwa:
[Microsoft 365 admin center: automate report collection - Rencore]
https://rencore.com/blog/microsoft-365-admin-centers-automate-report-collection/

Gruß, Nils
 

Moin,
 
sehe ich auch so. Das Missverständnis ist vermutlich: Einstellungen in verschiedenen Bereichen der Gruppenrichtlinien können durchaus "additiv" sein bzw. sind es in der Regel. Hier ergibt das Konzept der "Delta-Richtlinien" durchaus Sinn (übrigens ist das so eine Erfindung der Autoren, das ist kein allgemein üblicher Ausdruck). Einstellungen für denselben Eintrag sind aber in aller Regel nicht "additiv". In dem Beispiel, das wir hier diskutieren, geht es ja um genau einen Wert (nämlich die Angabe, wer ein bestimmtes Benutzerrecht erhält). Der wird durch die GPOs vollständig gesetzt. Die Komponente, die das umsetzt, geht nicht die einzelnen Teile des Werts durch und prüft, was es da nun wie zusammenbasteln müsste. Hier also "ganz oder gar nicht", wenn man so will.
 
Das ist möglicherweise in dem Buch nicht so ausdrücklich beschrieben. Sowas liegt dann daran, dass die Autoren selbst nicht auf diesen Gedanken bzw. auf diese Lesart gekommen sind. (Ansonsten kann man den Autoren durchaus vertrauen, Peter kenne ich sogar persönlich. Und dem Verlag natürlich auch. )
 
Gruß, Nils

Moin,
 
deine Frage ist nicht saublöd, aber im Detail nicht ganz verständlich. Was haben deine Befürchtungen mit der Namenskonvention zu tun?
 
Womit du Recht hast: Ja, das Konzept kann zu sehr vielen Gruppen führen. Im Umkehrschluss aber - wenn du so komplexe Strukturen hast, wirst du immer sehr viele Berechtigungseinträge haben. Wenn du dazu die Zahl der Gruppen klein hältst, hast du sehr viele sehr komplexe Berechtigungseinträge. Das beschriebene Konzept versucht hingegen, die tatsächlichen Berechtigungseinträge möglichst einfach zu halten und dafür die Zuweisung über die (vielen) Gruppen deutlich zu machen. 
 
Eine erwünschte Folge ist die Erkenntnis, die du geäußert hast: Komplexe Berechtigungsstrukturen sind das eigentliche Problem, weil die dazu führen, dass jede Form der Abbildung schnell aufwändig und u.U. auch unübersichtlich wird. Das ist der Grund, warum große Organisationen dort schnell dazu übergehen, die möglichen Berechtigungen einzuschränken und nicht alles, was technisch möglich ist, auch umzusetzen.
 
Spätestens da ist man dann auf der organisatorischen Ebene. Und das führt zu Erkenntnis 2, vor der sich die meisten IT-Abteilungen aber noch viel mehr sträuben: Die IT hängt mit der Organisation des Unternehmens zusammen. Um zu einer leistungsfähigen Abbildung zu kommen und den IT-Service passend zu organisieren, muss die IT mit den Fachabteilungen und der Orga reden.
 
Gruß, Nils
PS. "hab ich noch nie so gemacht" ist irgendwie kein Argument ... 

Moin,
 
rechne doch mal durch, ob die Netze selbst eindeutig sind, d.h. ob du die Anfangs- und Endadressen richtig identifiziert hast und keine Adresse mehr als einem Segment angehört. Wenn ja, wäre das erst mal korrekt. Natürlich können mehrere Netz-Segmente dieselbe Subnetmaske haben. Wichtig ist die Netz-Adresse, und zu der gibt die Maske ja nur die Länge an, aber nicht den Wert.
 
Vor wenigen Tagen haben wir hier im Board eine Methode gezeigt, wie man sich solche Subnet-Berechnungen visualisieren kann. Wenn man das tut, wird das Konzept der Masken schnell deutlich. Nutz mal die Boardsuche dazu.
 
EDIT: In der Praxis würde man durchaus die Netze deutlich voneinander trennen, wie du es in deinem "2. Ansatz" vorschlägst. Man würde auf jeden Fall vermeiden, mit so komplexen Masken zu arbeiten - da steigt ja keiner durch, ohne sich Stunden damit zu befassen. Also, wenn es irgendwie geht, würde man die Transfernetze d, e und f aus völlig anderen Nummernkreisen nehmen.
 
Das ist aber nicht die Aufgabenstellung. Dein Ausbilder will dir eine harte Nuss geben, um das Konzept des Subnetting zu verdeutlichen. Ansätze 2 und 3 scheiden im Rahmen dieser Aufgabe also aus. Die "minimale" Lösung ist die mit der Maskierung, dann können alle Netze aus dem Bereich 192.168.12.x kommen. Zumindest prinzipiell ist dein 1. Ansatz also passend. Ob er auch korrekt ist, müsste ich jetzt nachrechnen, aber das ist nicht meine Aufgabe. 
 
Gruß, Nils
 

Moin,
 
ich mache keinen Betrieb und muss keine Server verwalten, daher habe ich da keine belastbaren Praxiserfahrungen. Total Commander wird aber oft für sowas genannt. 
 
Eine andere Stelle, an der sich der Explorer hanebüchen verhält, habe ich hier beschrieben:
 
[Windows-Berechtigungen mit UAC verwalten | faq-o-matic.net]
https://www.faq-o-matic.net/2015/12/23/windows-berechtigungen-mit-uac-verwalten/
 
Gruß, Nils
 

Moin,
 
was heißt denn "die grundsätzlich mit Admin Rechten starten möchten" genau? Kommt eine UAC-Abfrage? Dann wirst du es nicht ändern können, weil es dann im Programm so vorgesehen ist.
 
Gruß, Nils
 

Moin,
 
solche Subnet-Betrachtungen kann man deutlich vereinfachen, wenn man die bitweisen Operationen weglässt und einfach "nach Optik" vergleicht.
Subnet-Masken haben (in binärer Schreibweise) immer zusammenhängende 1-Ketten, die ganz links beginnen immer, wenn in der Subnet-Maske eine 1 steht, gehört die entsprechende Stelle in der IP-Adresse (in binärer Schreibweise) zur Netzwerk-Adresse. Immer, wenn in der Subnet-Maske eine 0 steht, gehört die entsprechende Stelle in der IP-Adresse (in binärer Schreibweise) zur Host-Adresse. Man schreibt beides untereinander und vergleicht optisch. Kein Bedarf, im Kopf oder per Tool AND, XOR oder sonstwas durchzugehen, was für Menschen wenig intuitiv ist. Hier mal verdeutlicht mit "x" für 1 und "-" für 0:
IP 192.168.56.1 /20 1100 0000 1010 1000 0011 1000 0000 0001 xxxx xxxx xxxx xxxx xxxx ---- ---- ---- IP 192.168.50.1 /22 1100 0000 1010 1000 0011 0010 0000 0001 xxxx xxxx xxxx xxxx xxxx xx-- ---- ---- Aus Sicht des ersten Hosts (mit der IP-Adresse 192.168.56.1 /20) ist der zweite Host also im selben Netz. Er wird versuchen, ihn direkt ohne Router anzusprechen.
Aus Sicht des zweiten Hosts (mit der IP-Adresse 192.168.50.1 /22) ist der erste Host nicht im selben Netz. Er kann diesen also nicht direkt ansprechen, sondern müsste seinen Router dafür ansprechen. Je nachdem, wie dieser konfiguriert ist, klappt das dann oder auch nicht.
(Dieses Ergebnis kam oben in diesem Thread bereits vor.)
 
Deine XOR-Betrachtung verstehe ich nicht - sie ist, soweit ich sehe, fehlerhaft. Das liegt nach meinem Dafürhalten daran, dass Menschen nun mal mit XOR nicht intuitiv umgehen können. Mach es dir einfacher.
 
Gruß, Nils
 

Moin,
 
nimm es mir nicht übel - aber das erstaunt mich etwas. Aber sei's drum.
 
Vermutlich stolperst du über die "Installation" der Management-Tools. Die nimmt man auf einem Admin-PC vor. Nicht auf einem DC. (Den Artikel bei faq-o-matic.net habe ich jetzt noch mal angepasst, um das deutlicher zu machen.)
Von diesem Admin-PC aus machst du dann auch einmalig das Schema-Update, indem du dich dort einmalig mit einem Account anmeldest, der Schema-Admin ist.
 
Auf keinem der DCs läuft bei LAPS ein zusätzliches Stück Software. Nur auf den Clients, deren Kennwörtern per LAPS verwaltet wird, ist das der Fall, und da ist es eine GPO-Erweiterung. Auch auf dem Admin-PC läuft nicht dauerhaft irgendwas, sondern dort startest du nur bei Bedarf eins der Tools, um zu administrieren. Das ist alles.
 
Ganz ehrlich: Um LAPS sinnvoll zu betreiben, brauchst du mehr Sorgfalt bei der Vorbereitung und im Betrieb, als du bisher anscheinend aufgebracht hast.
 
Gruß, Nils
 

Moin,
 
in den meisten Szenarien ist es völlig egal, welche Zone verwendet wird, um einen DNS-Namen aufzulösen. Beide von dir vorgeschlagenen Wege würden für das genannte Szenario also funktionieren. (Sogar parallel - technisch spricht auch nichts dagegen, dass derselbe Client in mehr als einer DNS-Zone eingetragen ist.)
 
Such dir also aus, was anhand möglicher sonstiger Umstände am besten passt.
 
Gruß, Nils
 

Moin,
 
ein Angreifer müsste das vorbereiten. Er bräuchte dazu einen DNS-Server mit einer präparierten Domain, soweit ich das verstehe, und einen Client, der den Windows-DNS-Server anspricht (dieser dient ja nur als Werkzeug für den eigentlichen Angriff). In einem "normalen" internen Firmen-Netzwerk eher unwahrscheinlich, dass das gelingt - wer so einen Angriff plant, sucht sich leichtere Wege.
 
In einer Umgebung, die mit "unbekannten" Clients zu tun hat, kann das Problem aber durchaus bestehen. Unis etwa nutzen oft (auch) Windows-DNS und haben praktisch keine Kontrolle über die "internen" Clients. In dem Fall würde ich die RRL-Empfehlung auf jeden Fall umsetzen.
 
Gruß, Nils
 

Moin,
 
falls die "organisatorischen Gründe" auf die Struktur des Unternehmens zurückzuführen sind (und nicht auf die technischen Erfordernisse der IT-Administration), dann solltet ihr dies zum Anlass nehmen, nicht die Namen zu ändern, sondern gleich die ganze Struktur umzubauen. Das AD soll nicht das Organigramm abbilden, sondern es soll die IT-Administration unterstützen. Eine Struktur, die diesem Prinzip folgt, wird man so gut wie nie aus organisatorischen Gründen ändern müssen.
 
Zu deiner eigentlichen Frage: Du könntest mit der Technik, die in folgendem Artikel am Anfang genannt wird, versuchen, die tatsächlichen Abfragen zu identifizieren, die an das AD gestellt werden. Ob das funktioniert, weiß ich nicht, aber es sieht aus, als wäre es einen Versuch wert.
https://blogs.technet.microsoft.com/askpfeplat/2012/11/11/mcm-active-directory-indexing-for-the-masses/
 
Gruß, Nils
 

Moin,
 
es lässt sich aus der Ferne kaum einschätzen, was da quer hängt. Da der Netzwerkstack bei Installation von Hyper-V kräftig durchgerüttelt wird, ist es vermutlich am sinnvollsten, den Host einmal sauber neu zu installieren und große Sorgfalt auf das Einrichten der Netzwerkeinstellung zu legen. Da macht man gerade als Anfänger oft was verkehrt, weil die Sache leider etwas unübersichtlich ist.
 
Gruß, Nils
 

Moin,
 
ein RODC würde in dem Szenario doch gar keinen Sicherheitsvorteil ergeben. Die User melden sich, wie du sagst, per VPN an. Das VPN ist also deine Sicherheitsgrenze. Ab da sind die User im Netzwerk. Ob sie also auf einen RODC oder einen echten DC zugreifen, macht keinen Unterschied. Danach greifen sie ja ohnehin vermutlich auf "alle" Ressourcen zu.
 
RODCs wurden ursprünglich für genau einen Zweck entworfen: kleine Niederlassungen, die physisch nicht ausreichend gesichert sind, aber einen lokalen DC haben sollen. Der RODC steht dann also physisch in dieser Niederlassung. Wenn dort der DC gestohlen wird, soll nicht gleich das ganze Unternehmen kompromittiert sein.
 
Außerhalb dieses einen Szenarios gibt es - nach meiner Ansicht - keinen sinnvollen Einsatzzweck für einen RODC. Verschiedentlich wird ein RODC für andere Zwecke in Konzepten genannt, aber wenn man sich das genauer ansieht, passt es eigentlich nie. Es gibt keinen Sicherheitsvorteil, es werden praxisferne Annahmen getroffen oder jemand hat das einfach nicht verstanden.
 
Kein Angriff beabsichtigt, nur die Darstellung der Dinge aus meiner Sicht.
 
Gruß, Nils
 

Moin,
 
für die AD-Administration sollte man sich weder lokal noch per RDP auf einem DC anmelden. Dort sollten nur dann Anmeldesessions laufen, wenn der betreffende DC konfiguriert oder gewartet wird. Das ist selten der Fall, wenn überhaupt.
 
Dies hier hast du schon probiert?
https://www.petenetlive.com/KB/Article/0001448
 
Gruß, Nils