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
Getrenntes Offline Adressbücher (OAB) für verschiedene Gruppen von Nutzern
Sie haben in Ihrer Umgebung verschiedene Gruppen von Nutzern, in diesem konkreten Beispiel Studenten und Mitarbeiter. Da Sie nicht beiden dasselbe OAB zumuten oder zur Verfügung stellen möchten, erstellen Sie zwei gesonderte OABs und weisen der jeweiligen Gruppe das passende zu.
Genau solch ein Szenario beschreibe ich in diesem Beitrag und zeige Ihnen, wie man das alles recht zügig mit der Exchange Management Shell umsetzen kann. Die Voraussetzungen hierfür sind zum einen ein Microsoft Exchange Server 2010 SP2 oder höher und keine Scheu vor der PowerShell bzw. der Exchange Management Shell.
Eigene AD-Attribute - Änderungen mit Windows Server 2012
In meinen Blogeinträgen habe ich die Möglichkeiten vorgestellt, wie man eigene Attribute im AD erstellen kann, sie versteckt bzw. nur für wenige User sichtbar macht. Diese Lösung funktionierte bis Server 2008R2 problemlos. Mit Server 2012 gab es ein paar kleinere Änderungen am Verhalten des ADs, wodurch die Lösung so nicht mehr ganz praktikabel erscheint. Im Folgenden werde ich kurz die wichtigsten Änderungen auflisten und erklären, wie man auf das neue Verhalten reagieren muss.
Reconnect einer Mailbox + Archiv
Ab und zu kommt es vor, dass ein AD-User zur Fehlerbehebung neu angelegt werden muss. Alles kein großes Problem, mit wenigen Klicks ist der alte User durch einen neuen ersetzt und der Fehler ist beseitigt. Was passiert jedoch mit seinen Daten auf dem Exchange?
Eigene AD-Attribute Teil 2 - enable ADVANCED-FIND
Vor einiger Zeit habe ich in den Artikeln Attribute im AD verstecken und eigene Attribute erstellen [1] und AD-Attribute verstecken Teil 2 - Leserechte für Confidential Attributes [2] erklärt, wie eigene Attribute im AD erstellt, versteckt und bestimmten Benutzern wieder Leserechte gegeben werden können.Manchmal besteht allerdings der Wunsch, dass ein eigenes Attribut nicht vesteckt ist und mit der erweiterten Suche in ADUC gefunden werden kann.
AD-Attribute verstecken Teil 2 - Leserechte für Confidential Attributes
In einem vorangegangen Artikel Attribute im AD verstecken und eigene Attribute erstellen habe ich bereits erklärt, wie Attribute im AD durch die Markierung confidential versteckt werden können. Dadurch haben nur noch Administratoren Leserechte auf das Attribut.Nun gibt es manchmal die Situation, bei der man ausgewählten Benutzern bzw. Gruppen das Lesen erlauben möchte, ohne Sie gleich zu Administratoren zu machen.
Attribute im AD verstecken und eigene Attribute erstellen
In einer normalen AD-Umgebung kann jeder Benutzer Attribute aus dem AD auslesen. Dies ist allerdings nicht gerade wünschenswert, da so auch eventuell private Informationen allen Benutzern zugänglich sind. An Universitäten wäre zum Beispiel die Matrikelnummer ein solches schützenswertes Attribut.
Um das Verstecken eines solchen Attributs zu realisieren gibt es jetzt 2 Möglichkeiten:
Man nimmt ein bereits existierendes Attribut im AD und versteckt es, oder man erstellt sich ein eigenes Attribut Matrikelnummer. Hierbei ist zu beachten, dass so genannte „Base Schema Attributes“ gibt, die nicht versteckt werden können.