ESCde Blog - Wissen rund um die IT
Kategorien
- ASP.NET 1
- Active Directory 41
- Administration Tools 1
- Allgemein 60
- Backup 4
- ChatBots 5
- Configuration Manager 3
- DNS 1
- Data Protection Manager 1
- Deployment 24
- Endpoint Protection 1
- Exchange Server 62
- Gruppenrichtlinien 4
- Hyper-V 18
- Intune 1
- Konferenz 1
- Künstliche Intelligenz 7
- Linux 3
- Microsoft Office 11
- Microsoft Teams 1
- Office 365 11
- Office Web App Server 1
- Powershell 21
- Remote Desktop Server 1
- Remote Server 1
- SQL Server 8
- Sharepoint Server 12
- Sicherheit 1
- System Center 10
- Training 1
- Verschlüsselung 2
- Virtual Machine Manager 1
- Visual Studio 1
- WSUS 7
- Windows 10 12
- Windows 8 9
- Windows Azure 4
- Windows Client 1
- Windows Server 24
- Windows Server 2012 7
- Windows Server 2012R2 15
- Windows Server 2016 7
- Windows Server 2019 2
- Windows Server 2022 1
- Zertifikate 4
LDAP Anfragen in PowerShell mit dem DirectorySearcher
Oft kommt es vor, dass Informationen über viele Nutzer im Active Directory abgefragt werden sollen. Dies ist beispielsweise nötig, um per Skript die Nutzer einer bestimmten OU abzufragen, oder um Active Directory Attribute für alle Nutzer zu setzen. Das .Net Framework bietet hierzu die Klasse „DirectorySearcher“, welche in allen .Net Sprachen, wie z.B. C# oder PowerShell verwendet werden kann.
Temporäres deaktivieren eines Accounts
Ich möchte diesen Blogbeitrag einer organisatorischen Hürde widmen, die in einer Exchange-Umgebung immer mal wieder auftritt. Konkret geht es um jene Benutzer in der Domäne, welche temporär deaktiviert und deren E-Mail-Account nicht endgültig gelöscht werden soll.
Hierzu ein Beispiel: Mitarbeiter A besitzt ein Domänen-Konto mit einer Mailbox auf dem Exchange-Server. Seine Mailbox enthält benutzerspezifische Einstellungen, wie zum Beispiel speziell gesetzte Berechtigungen und ein erhöhtes Quota-Limit. Dieser Mitarbeiter wird nun aufgrund eines längeren Auslandsaufenthalts freigestellt. Der Mitarbeiter hat seine Rückkehr zur Firma angekündigt, jedoch nannte er keinen festen Termin.
Der zuständige Personalverantwortliche beauftragt die Administratoren sich mit folgender Fragestellung auseinanderzusetzen:
„Wie gestalten wir die Zugriffsrechte auf die Domäne für den Mitarbeiter?“
Group Managed Service Accounts
In meinem letzten Blogeintrag habe ich die Notwendigkeit und die Nutzung von den, mit Windows Server 2008 R2 eingeführten, Managed Service Accounts erklärt. In diesem Beitrag zeige ich die Weiterentwicklung dieser Accounts.
Migration DHCP Server Role von 2012 R2 nach 2016
Heute erkläre ich kurz, wie man die DHCP-Rolle von einem Windows Server 2012 R2 nach 2016 migriert. Geändert hat sich hier seit den letzten Serverversionen nichts. Diejenigen unter euch, die bereits in früheren Versionen die DHCP-Rolle migriert haben, sollten also mit dem Verfahren vertraut sein.
SYSVOL Replikation nach Replikationsfehler wieder anstoßen
Nach einem Systemausfall stellen Sie fest, dass keine DFS-Replikation mehr zwischen Ihren Domain Controllern stattfindet. Im Event Viewer finden Sie hierzu die Warnung 2213, welche angibt, dass die Replikation für ein bestimmtes Volume beendet wurde, da eine DFSR-JET Datenbank nicht ordnungsgemäß heruntergefahren wurde. In den meisten Fällen lässt sich dieses Problem, wie in der Warnung beschrieben, über den Aufruf der WMI-Methode ResumeReplication lösen. Doch wie geht man vor, wenn die Replikation länger als die im Parameter MaxOfflineTimeInDays festgelegte Maximaldauer unterbrochen wurde?
In-Place Upgrade Teil 2: Umsetzung in der Umgebung - Keine Hexerei!
Wie ich bereits im ersten Teil dieser Reihe erläutert hatte, ist ein In-Place Upgrade keine Hexerei und läuft erstaunlich reibungslos. Während meines Tests traten keinerlei Probleme auf, jedoch kann sich dies von System zu System unterscheiden.
Nun möchte ich damit weitermachen, welche Schritte nach der im ersten Teil beschriebenen Vorarbeit noch nötig sind um ein komplettes Upgrade auf einem Domain Controller durchzuführen.
Managed Service Accounts
Ständig braucht man Sie, meistens werden Sie falsch verwendet oder völlig vernachlässigt. Die Rede ist von Service Accounts. Bei nahezu jeder Installation werden Service Accounts verwendet. In vielen Fällen benutzen Administratoren dafür Domänenaccounts. Häufig mit Domänenadministratorrechten und richten alle Accounts mit dem gleichen Passwort ein. Oftmals werden diese Accounts darüber hinaus so konfiguriert, dass diese von der Passwortänderungspolicy ausgenommen sind. Dieses Vorgehen stellt offensichtlich ein enormes Sicherheitsrisiko dar.
IADsUser::ChangePassword() schlägt seit Kurzem fehl
Seit dem 09. Oktober 2016 kann es vorkommen, dass Skripte oder Webseiten, welche Passwortänderungen für Benutzer durchführen, nicht mehr funktionieren. Dies kann aus der Verwendung der IADsUser::ChangePassword()-Methode in Verbindung mit dem ADSI WinNT Providerund dem Sicherheitsupdate KB3167679 vom 09.08.2016 resultieren. Mit dem Update wurden bestimmte Fallbacks bei der Authentifizierungsaushandlung deaktiviert, um unter anderem Downgradeangriffe zu verhindern. Der ADSI WinNT Provider verwendet unter bestimmten Umständen eine nun verbotene Authentifizierungsstrategie und resultiert ab nun in einem Fehler mit dem Errorcode: -2147023631 (ERROR_DOWNGRADE_DETECTED)
Migration eines Domain Controllers von 2008R2 auf 2012R2 – Teil 6 HerabstufenEntfernenNachbereitung
Zuletzt muss nun der alte DC entfernt werden. Die Schritte, welche hierfür notwendig sind, werden in diesem Teil der Blogeintragsreihe vorgestellt.
Migration eines Domain Controllers von 2008R2 auf 2012R2 – Teil 5 FSMO-Rollen
In diesem Blogbeitrag verschieben wir die FSMO-Rollen von dem alten 2008 R2 DC zu dem neuen 2012 R2 DC.