Domaenencontroller usw…

https://technet.microsoft.com/de-de/library/cc730749(v=ws.11).aspx

http://blog-schulenburg.de/index.php/kategorie-als-blog/72-fsmo-rollen-anzeigen-und-verschieben

https://www.windowspro.de/andreas-kroschel/defekten-domaenencontroller-entfernen

https://technet.microsoft.com/de-de/library/hh472163(v=ws.11).aspx

FSMO

https://de.wikipedia.org/wiki/FSMO

Flexible Single Master Operations (FSMO) oder operations masters (Betriebsmaster) sind spezielle Aufgaben, die Domain Controller innerhalb des Active Directorys der Firma Microsoft übernehmen. Die Aufgaben können auf verschiedene Server verteilt werden, jedoch darf keine dieser Rollen von mehreren Servern gleichzeitig übernommen werden.

Flexible Single Master Operations umfasst folgende ‚Rollen‘:

geloschten-ad-benutzer

http://blog.sauter-online.de/geloschten-ad-benutzer-wieder-herstellen/

https://www.administrator.de/wissen/gel%C3%B6schte-active-directory-objekte-wiederherstellen-123639.html

step-step-guide-migrate-active-directory

http://www.rebeladmin.com/2016/10/step-step-guide-migrate-active-directory-fsmo-roles-windows-server-2012-r2-windows-server-2016/

http://jackstromberg.com/2013/10/migrating-domain-controllers-from-server-2008-r2-to-server-2012-r2/

https://xenappblog.com/2016/windows-2016-migration/

http://jackstromberg.com/2013/10/migrating-domain-controllers-from-server-2008-r2-to-server-2012-r2/

step-by-step-active-directory-migration

https://blogs.technet.microsoft.com/canitpro/2014/05/27/step-by-step-active-directory-migration-from-windows-server-2008-r2-to-windows-server-2012-r2/

https://www.administrator.de/frage/dc-migration-server-2008r2-2016-317621.html

Zusammenführen von zwei AD-Strukturen,

Zusammenführen von zwei AD-Strukturen

http://www.nt4admins.de/themen/active-directory/artikel/zusammenfuehren-von-zwei-ad-strukturen-teil-1.html

http://wiki.butzhammer.de/Migration_/_Zusammenf%C3%BChrung_von_zwei_Dom%C3%A4nen

Configure Exchange 2010 to Route Messages for a Shared Address Space

https://technet.microsoft.com/en-us/library/bb676395.aspx

РУ.

http://sqrnotes.blogspot.de/2010/09/admt-32.html

http://gattosporco.blogspot.de/2013/09/blog-post.html

IT-Handbuch für Fachinformatiker von Sascha Kersken Der Ausbildungsbegleiter

AD Dokumentation

http://openbook.rheinwerk-verlag.de/it_handbuch/

https://www.edv-lehrgang.de/exchange-server-2010/

http://ifpaprojekt.pbworks.com/f/03_Bsp+Report+FACHINf_Datenbank.pdf

##programme:

https://www.heise.de/download/products/netzwerk/infrastruktur#?cat=netzwerk%2Finfrastruktur

http://www.markus-baersch.de/php/senddl.php?f=projektauftrag-anleitung

Hebel mit dem man in einem AD gegen Locky ansetzen

Applocker – der Hebel mit dem man in einem AD gegen Locky
ansetzen kann


Applocker – der Hebel mit dem man in einem AD gegen Locky ansetzen kann

Application-Locker (nicht
Application-Blocker, obwohl es das auch ganz gut treffen würde, weil es
geht ja letztlich darum, nicht erwünschte Programmdateien auszusperren.)

Wer
über ein AD mit Group-Policies verfügt, ist eigentlich fein raus. Man
muss es nur richtig machen. Eine automatisierte Softwareverteilung,
damit man den ganzen Krempel nicht von Hand und in unterschiedlichen
Versionen (aus verschiedenen Ordnern, Sammlungen, „gerade eben mal
runtergeladen“, …) installiert, ist auch hilfreich.

Laut
Golem.de *1 lädt das Office-Makro von Locky eine ladybi.exe herunter und
startet diese. Darin steckt der eigentliche Schadcode. Das ist der
Hebel, an dem man gegen Locky und andere ähnliche Programme ansetzen
kann.

Folgendes:

Man lege eine neue Computer-Policy an, die
auf alle Computer (PCs, Laptops, Terminalserver, virtuelle Desktops,
eben alles wo User Unsinn bauen können *2) im AD oder in der gewünschten
OU greift.

– Compute Configuration
— Policies
— Windows Settings
—- Security Settings
—– Application Control Policies
—— Applocker
——- Executeable Rules

Da
drin kann man nun Regeln definieren, welche Applikationen vom Benutzer
ausgeführt werden dürfen. Das können Allow und Deny Regeln sein, die
nach folgenden Regeln entschieden werden:
– Publisher, das heißt, in
der EXE-Datei muss ein Zertifikat des Softwareherstellers hinterlegt
sein. Ok, kann man fälschen, ist aber schon schwierig.
– Path. Hier
sollte man natürlich sinnvollerweise auf jeden Fall „c:\windows“,
„c:\programm files“ und „c:\program files (x86)“ als „allow“ (für
Everyone oder Domain Users) hinterlegen, sonst sägt man sich den Ast ab,
auf dem man sitzt. Man muss außerdem dafür sorgen, dass diese Ordner
vom Anwender nicht beschrieben werden können, aber das ist eigentlich
Standard in einer normalen Windows-Installation. Niemand meldet sich mit
Admin-Rechten zum normalen Arbeiten an, nichtmal Admins *4, sonst ist
eh alles für die Katz.
– File hash, dazu muss man alle Exe-Dateien,
die ausgeführt werden können sollen, mal „einsammeln“ und (also
„c:\oracle“ nach „*.exe“ durchsuchen und diese dann temporär in einen
Ordner kopieren und von dort) von diesem Policy-Assistenten einen Hash
errechnen lassen, der dann für jede dieser Exe-Dateien in der Policy
hinterlegt wird. (die temporären Kopien kann man danach wieder löschen,
es zählt dass der Dateiname mit seinem Hash in der Policy enthalten
ist!) Dann können diese Programme von jedem Laufwerk gestartet werden.
Man sollte halt nur nicht unbedingt ladybi.exe hashen…

Sobald
man Regeln in dieser Policy eingestellt hat, ist diese aktiv und man
kommt nicht mehr drumherum. Empfehlung: Unbedingt eine eigene Policy
dafür, nicht eine andere Policy dafür mißbrauchen. Denn wenn es eine
eigene Policy ist, kann man sie, fals man was falsch gemacht hat,
jederzeit ohne weitere Folgen einfach deaktivieren. Anfangs ist es gut,
einen PC (oder Server) zu haben, auf dem das Group-Policy-mmc läuft, der
nicht in der OU ist, auf den die Applocker-Policy nicht wirkt, aber
sobald man ein prinzipiell funktionierendes Regelwerk hat, ist dieser
Notanker nicht mehr nötig.

Evtl. nimmt man per „Restricted Users“
die Admins da raus, da ein Admin per Rechtsklick und „Run As Admin“ ein
Programm immer noch starten kann, oder der Admin kopiert das setup.exe
nach „c:\program files\install“ und startet es von dort.

So
praktizieren wir das hier schon seit Jahren (seit Win 7 Einführung und
nachdem diese Policy verstanden wurde! *3) in einer Umgebung mit etwa
1500 Plätzen. Locky ist hier kein Thema. Und ja, anfangs, wenn man einen
neuen Kollegen dazu bekommt, der sich ein Admintool installieren will,
der tut sich damit erstmal schwer, aber man gewöhnt sich dran.

*1 Siehe http://www.golem.de/news/krypto-trojaner-locky-mehr-als-5-000-infektionen-pro-stunde-in-deutschland-1602-119247.html
*2
Auf normale Server, wo User sich nicht aufschalten können, sondern nur
Admins, sollte man diese Policy nicht wirken lassen, damit macht man
sich nur das Leben schwer. Aber Paranoia ist in dem Fall auch nicht ganz
falsch, kommt auf die Umgebung und den Anspruch an.
*3 Erstmal in einer eigenen OU mit ein paar PCs in dieser OU testen, damit man versteht, wie das funktioniert!
*4
Administrative Sachen startet der Admin selbstverständlich mit „run as“
(shift rechte Maustaste auf das Program, und dann der separate
Admin-Account, der dann die speziellen AD-Berechtigungen und im
Dateisystem hat).

Wer es anders macht, dem ist leider nicht zu helfen.