
Robinho1986
-
Gesamte Inhalte
223 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von Robinho1986
-
-
vor 17 Minuten schrieb testperson:
Okay, wir reden nicht über "SecPol", wir reden über Conditonal Access Policies.
Ist der Sync User in der "AllUser_NoLicence"? Falls ja, würde ich ihn aus dem dynamischen Filter ausschließen und testen.
Ansonsten mit "What If" oder den Sign In Logs einmal prüfen, ob es tatsächlich an dieser Policy scheitert.
Ok danke, gucke ich mir an. Und ja, er ist nicht Mitglied der Gruppe.
-
vor 33 Minuten schrieb testperson:
Hi,
wo hast du denn hier eine "SecPol" erstellt bzw. was verstehst du hier gerade unter "SecPol"? Und wie steht es um den "On-Premises Directory Synchronization Service Account"?
Gruß
Jan
Allen Usern ohne Lizenz wird der Zugriff auf jegliche Ressource verweigert. Bei AUSSCHLIEßEN ist der Sync-User ausgeschlossen. Sobald die Regel aktiviert wird, kann der Sync-User nicht mehr syncen.
Vielleicht gibt es auch einen besseren Weg?
-
Hallo zusammen,
ich stehe vor folgender Herausforderung. Aktuell besteht eine AD <-> Azure Synchronisation und wir migrieren unseren Exchange Server in Exchange Online.
Viele synchronisierte User haben eine Lizenz, leider haben viele User aber auch keine Lizenz.
Lizenzlose User würde ich gerne per SecPol in Gänze erstmal aussperren. Ich habe mir eine dynamische Gruppe gebaut, die alle User enthält, die KEINE Lizenz haben.
Mit dieser Gruppe habe ich dann eine SecPol erstellt, die diesen User den Zugriff auf ALLE Ressourcen verbietet. Zusätzlich wird in dieser Pol eine Gruppe ausgeschlossen, die Tenant-Admins enthält.
In der Theorie funktioniert dies auch, leider bricht dann trotz Ausschluss die Synchronisation per Azure Connect ab, weil der User keinen Zugriff mehr hat (Obwohl er definitiv bei dieser Secpo ausgeschlossen wird!)
Hat jemand eine Idee oder vielleicht Verbesserungsvorschläge?
Vielen Dank im Voraus!
-
Hallo zusammen,
aktuell sind wir fleißig dabei einige Lenovo Tiny PCs per Autopilot zu deployen. Alle Geräte sind vom gleichen Hersteller und Typ.
Allerdings ist es im Moment so, dass von heute auf morgen ein Deployen nicht mehr möglich ist. Geräte lassen sich zwar im Autopilot registrieren,
beim eigentlichen Prozess kommt es allerdings zu einer Fehlermeldung 0x8000705b4.
TPM Chip löschen
Entfernen des Gerätes aus Autopilot
brachten bisher keinen Erfolg.
Hat vielleicht noch jemand einen Tipp?
Vielen Dank im Voraus!
-
Gerade eben schrieb Nobbyaushb:
Ganz überlesen - ihr verwendet die MDM von intune?
Dann kann ich leider nicht weiterhelfen, ich habe eine andere MDM im Einsatz
ja genau, danke trotzdem. Vielleicht hat noch jemand weitere Ideen? :)
-
mit der nativen APP im Arbeitskontext?
-
Morgen zusammen,
gibt es eine Möglichkeit, dass Kontakte aus Exchange Online mit den lokalen Kontakten auf einem Smartphpne (IPhone / Android) gesynct werden?
Sprich aus dem Arbeitsprofil heraus. Wir haben das Problem, dass Anwender nicht per Freisprechanlage auf die Kontakte es Arbeitsprofils zugreifen können.
Umgekehrt funktioniert dies ebenfalls nicht. Ich finde keine adäquate Lösung für dieses Problem.
Vielleicht habt Ihr ein paar Tipps für mich, vielen Dank!
-
Gerade eben schrieb testperson:
Hi,
was kostet denn der Betrieb der lokalen Printserver vs. was kostet das längere Warten auf den Ausdruck? ;)
Gruß
Jan
ich weiß, auf diese Diskussion werde ich es wohl ankommen lassen müssen. Zentral redundante Server sollten wohl genügen.
-
vor 5 Minuten schrieb BOfH_666:
Wow.
das ist hier leider ein ganz ganz großes Problem für die Anwender
-
pro Standort ca. 20 Drucker und ca. 50 Clients. VPN Anbindung mit genügend Bandbreite ist in die Hauptverwaltung gegeben. Dennoch dauert der Druck ca. 10 Sekunden länger, wenn alles zentral über den Hauptstandort läuft.
-
vor 18 Minuten schrieb Squire:
wieviele Clients hast Du vor Ort? Software Verteilung im Einsatz? Wie schaut das Umfeld aus ... Virtualisierung?
Kostenlos ... ne Linux Büchse mit CUPS und entsprechenden Samba Share ... Kostenlos aber muss auch gewartet werden
im Schnitt 20 Drucker und 50 Clients, Softwareverteilung wird gerade auf INTUNE umgestellt.
-
Morgen zusammen,
gerne würde ich diverse Windows Server an Außenstandorten abschaffen, diese werden lediglich aufgrund des installierten Print Service Dienstes am Leben gehalten.
Gibt es vernünftige kostenlose Alternativen?
Filialdruck ist keine Alternative, diese Option funktioniert nicht optimal.
Kurzer Brainstorm sollte helfen :)
Danke lg!
-
Am 18.3.2024 um 12:44 schrieb testperson:
Hi,
du würdest vermutlich in die Dokumentation gucken, wenn diese (vollumfänglich) vorhanden wäre. ;) Dann nutze die Gegebenheiten jetzt und dokumentiert alles.
Gruß
Jan
korrekt. Danke nochmal für alle Eure Infos, mit dem Input kann ich definitiv starten!
Eine Frage zu einem konkreten Beispiel hätte ich dennoch. Es existiert ein Berechtigungskonzept auf einem Fileserver, soweit so gut.
Dennoch ist in jedem Ordner die Gruppe der Domänenadmins mit Vollzugriff eingetragen, Besitzer ist der lokale Admin des Servers.
Würdet Ihr das ändern?
-
Am 13.3.2024 um 10:58 schrieb NilsK:
Moin,
fangen wir doch mal vorne an - wie groß ist denn das Netzwerk überhaupt? Jede Maßnahme muss ja auch angemessen sein.
Gruß, Nils
Hallo,
wir reden von ca. 70 Windows VMs und ca. 500 Mitarbeitern.
vor 16 Stunden schrieb toao:Hi Robinho1986,
zum Thema "Wo wird der Domain-Admin genutzt" ein paar potentielle Anwendungsbereiche:
- Scheduled Tasks- Local Services
- IIS Application Pool
- Scripts, batches
- Tools, Applications
Richtig, dass alles solltest Du versuchen mit einem Script abzufragen. Zusätzlich könntest Du auch etwas über die nachfolgenden Windows EventIDs (auf den Domain Controllern) herausbekommen (auch mit ins Script einarbeiten):
Kerberos:
4768: A Kerberos authentication ticket (TGT) was requested.
4769: A Kerberos service ticket was requested.
4770: A Kerberos service ticket was renewed.
NTLM:
4779: The computer attempted to validate the credentials for an account.
*Bitte prüfe ob das Auditing zumindestens für die oben genannte EventID's, bei Euch entsprechend eingerichtet ist.
Du erhälst in allen EventIDs zwar nicht den genauen Prozess, Service serviert, jedoch die IP-Adresse(Hostname) des Endsystems. Quasi ein Anfang um weitere Nachforschungen durchzuführen.
Sobald es ans eingemachte geht, den Domain-Admins gegen einen Service-Account zu tauschen, bitte favorisiere als Service-Account immer einen MSA/GMSA (object class ms-DS-Group-Managed-Service-Account) wo immer es geht und nicht einen Service-Account auf Basis der object class: user.
Je nach Größe des Unternehmens, kannst Du damit sicherlich ersteinmal ordentlich zu tun haben.
Das Tiering- und Delegation Model würde ich sagen ist nie verkehrt. Da müsst Ihr schauen welche Kapazitäten ihr habt das parallel laufen zulassen , wie versiert Ihr mit der Delegierung von Berechtigungen im AD seid und einiges mehr. Da kann man sich schnell verlieren und soetwas muss sorgfältig geplant und durchgeführt werden.
Viel Erfolg beim Aufspühren der Nutzung des Domänen-Admins in den nächsten Tagen und Wochen :)
Toao
Vielen Dank für die ausführliche Antwort. Ich habe schon vermutet, dass es kein Tool oder Patentrezept geben wird. Ich denke das wichtigste ist, erstmal anzufangen.
Jeder Schritt wird einen Mehrwert an Sicherheit bringen. Wir werden uns nun erstmal einen Schlachtplan entwerfen.
-
Hallo zusammen,
ich stehe vor der Herausforderung in einer gewachsenen Domänenstruktur die Sicherheit im Bezug auf einen bekannten Domänen-Admin zu erhöhen.
Vermutlich sind viele Anwendungen / Dienste vor geraumer Zeit mit genau diesem implementiert worden. Aktuell stellen wir uns die Frage, wie wir am besten vorgehen und was das Ziel sein sollte.
Folgend meine Ideen und Gedanken:
1. Grundsätzlich sollte die Domänenadmin-Gruppe NUR den Domänenadmin enthalten
2. Im besten Falle kann ich per Skript und Co. alle Dienste auslesen und erkennen, worin der User enthalten ist
3. Sukzessive stellen wir alle Applikationen auf eigene entsprechend berechtige User um
4. Die Einführung eines TIER Modells sollte das Ziel sein?!
5. LAPS haben wir bereits eingeführt
Hat jemand Erfahrungen bei dieser Thematik und kann eventuell gute Tipps und Ideen dazu beitragen?
Vielen lieben Dank im Voraus!
-
Thema hat sich erledigt!
-
Morgen zusammen,
aktuell setzen wir 2x Server 2019 als Domänencontroller ein und Firewalls von PaloAlto.
Bei diesen haben wir das Transport Protocol von WIM auf WINRM HTTPS umgestellt.
Seitdem haben wir erhebliche Performance-Probleme auf den Domänencontrollern.
Diese sind zu 100% ausgelastet, den größten Teil nehmen folgende Dienste ein.
Ich nehme an, dass die Anzahl der Anfragen einfach zu hoch ist, gibt es vielleicht jemanden, der diese Problematik kennt und vlt. auf die Schnelle eine Idee zur Optimierung hat?
Wie immer, vielen Dank im Voraus! Weitere Infos kann ich gerne nachliefern.
-
Zur Info, die Migration hat super geklappt. Einige Fehler konnte ich im Vorfeld in der Testumgebung schon sehen und im produktiven Betrieb direkt lösen.
Werde mich als nächsten wohl mit dem Thema KB5008380—Authentication updates (CVE-2021-42287) auseinandersetzen müssen.
Danke für die Unterstützung!
-
1
-
-
vor 3 Minuten schrieb NorbertFe:
Genau das wäre sicherlich die sauberste Lösung, die beide Anforderungen (Namen/IP und Verfügbarkeit/Redundanz) vernünftig zu geringen Kosten erfüllt.
Blöde Frage zu der Lösung:
Damit ist also folgendes gemeint:
DC3 Server 2019 installieren und als DC hochstufen
DC2 vollständig aus der Domäne entfernen
DC2 als Server 2019 wieder installieren und als DC hochstufen mit altem Namen und IP
DC1 vollständig aus der Domäne entfernen
DC1 als Server 2019 wieder installieren und als DC hochstufen mit altem Namen und IP
DC3 vollständig aus der Domäne entfernen
Ich nehme an mit aktualisieren meint man kein IN-Place Upgrade? xD
-
nochmal danke für die angeregte Diskussion. Hier ist es so, dass viele Geräte die IPs für DNS hart eingetragen haben.
Ich habe aktuell die Systeme in einer Testumgebung und werde es nun einmal durchspielen.
Mir wäre wichtig, dass es am Ende zwei DCs mit den aktuellen IPs gibt.
Zu diesem Ziel führen scheinbar viele Wege.
-
Ich glaube ich habe mich etwas falsch ausgedrückt. Ich versuche es nochmal.
Aktuell laufen 2x DCs 2012 R2. In der Theorie könnte ich vor der Migration einen davon bereits komplett aus der Domäne entfernen, sodass nur noch ein Server 2012 R2 läuft. Dann würde ich einen neuen Server 2019 installieren in die Domäne aufnehmen und die Rollen verschieben. Sobald der neue Server 2019 läuft, würde ich dann einen weiteren 2019er aufsetzen.
Ein In-Place Upgrade würde ich nicht durchführen.
-
Danke für die Rückmeldungen! Eine Frage habe ich noch.
Aktuell laufen 2x DCs 2012 R2. Macht es Sinn den zweiten, welcher NICHT die FSMO Rollen beherbergt, vorher komplett aus der Domäne zu entfernen und dann den einzelnen zu migrieren. Anschließend würde ich dann wieder einen zweiten redundanten DC aufsetzen.
-
Gerne würde ich eine Domäne mit 2x Server 2012 R2 auf Server 2019 / 2022 aktualisieren.
Die Schritte die eine Migration erfordern sind mir bekannt. Allerdings befindet sich in der aktuellen Domäne noch ein Exchange Server 2016 und ich versuch aktuell zu ergründen, welche Hürden da auf mich zukommen werden, gerade in Hinblick auf heraufstufen der Funktionsebenen und Co.
Habe schon gesehen, dass Server 2022 mit on prem Exchange 2016 nicht supported wird!
Exchange Server supportability matrix | Microsoft Docs
Würde von daher erstmal auf Server 2019 gehen. Gibt es denn Dinge, die ich bei der Migration der Domäne in Hinblick auf Exchange 2016 beachten muss?!
Das Ganze werde ich natürlich vorab in einer Lab-Umgebung durchspielen mit exportierten produktiv Servern.
Vielen Dank vorab!
-
Morgen zusammen,
aktuell haben wir ADBA auf einem Server 2012 R2 laufen mit entsprechender Aktivierung. Gerne würde ich Server 2022 aktivieren und ich meine gelesen zu haben, das geht nicht mehr mit ADBA auf Server 2012 R2.
Leider habe ich mich mit diesem Theme nie beschäftigt. Wie wäre an dieser Stelle das beste Vorgehen?
ADBA paralell auf einem neueren Server aufsetzen?
ADBA von 2012 R2 zu 2016 oder neuer migrieren?
Vielleicht kann mir jemand ein paar nützliche Tipps geben, vielen Dank im Voraus!
SecPolicy - Blockzugriff für alle User ohne Lizenz
in MS Azure Forum
Geschrieben
User ohne Lizenz haben sie ein Postfach on prem. Die synchronisierten User können sich aber anmelden bei M365 (vermutlich nichts machen, aber dennoch b***d) und das ohne MFA. Sollte ich für die MFA erzwingen, könnte jeder "Böse" das auch einrichten, wenn er das PW hat. Stecke irgendwie in der Zwickmühle.