Exchange 2007 permissie delegatie
Exchange 2007 komt met een nieuw delegatiemodel gebaseerd op een aantal rollen. Op het eerste gezicht is dit dus niet veel anders dan Exchange 2003, maar toch zijn er een aantal significante wijzigingen.
Waren de permissies die behoorden tot de rollen in 2003 impliciet te delegeren via de Exchange system manager; de rollen in Exchange 2007 zijn, op de Server Administrator na, expliciet te zetten door een security enabled object lid te maken van een of meerdere Universal Groups in het root domain.
De rollen zijn als volgt:
Exchange Organization Administrator
Exchange View-Only Administrator
Exchange Recipient Administrator
Exchange Server Administrator
Zoals al gemeld zijn de eerste drie rollen terug te vinden als Universal Group in een nieuw aangemaakte OU, 'Microsoft Exchange Security Groups', in het root domain.
Organization Administrator
Zoals de naam al doet vermoeden is een organization administrator in staat om op organisatieniveau zaken te bewerken. Het gaat echter verder dan dat. Een Organization Administrator is in principe in staat om ALLES te wijzigen wat met Exchange 2007 te maken heeft. Hij heeft dus naast de rechten om organisatie brede eigenschappen aan te passen, ook rechten op elke Exchange server en de Exchange propery sets. In het dagelijks beheer is het dus niet verstandig om beheerders standaard Organization Administrator te maken. Dit zou in principe een rol moeten zijn die bij changes aangevraagd en geaudit moet worden.
View Only Administrator
Een view only administrator is in staat de configuratie van Exchange in de Configuration partitie van Active Directory uit te lezen. Hij heeft standaard echter geen rechten op een Exchange server en is daardoor niet zo View-Only als je zou denken. Zo kan je geen informatie over Client Access virtual folders (zoals OWA en ActiveSync) uitlezen en kan je ook de status van bijvoorbeeld de databases niet uitlezen. Om ook deze te kunnen uitlezen heb ik de volgende workaround gevonden. Let wel, dit is niet gebaseerd op officiele documentatie, maar is in mijn optiek redelijk secure. Voer het volgende uit:
1. Sta toegang tot de IIS metabase toe door een van de volgende commandos te draaien op de Exchange server:
%windir%\Microsoft.NET\Framework\v2.0.50727>aspnet_regiis -ga
Werkt alleen vanaf ASP.NET 2.0, dus in principe wel op elke Exchange 2007 server
cscript Metaacl.vbs "IIS://Localhost/W3SVC" RE
Metaacl moet je wel eerst HIER downloaden
2. Sta toegang tot het remote registry toe door Lees rechten te geven op de HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\ winreg key.
3. Sta voldoende DCOM permissions toe door een security enabled object lid te maken van de 'Distributed Com Users' local group op de Exchange server OF Access permissies toe te staan in component services. Dit gaat als volgt:
- Open de 'Component Services' snapin (comexp.msc) en selecteer Computers > My Computer > DCOM Config > IIS WAMREG admin service > Properties.
- Selecteer de Security tab en allow remote en local access en activation permissies.
Persoonlijk voel ik meer voor de laatste optie omdat deze alleen toegang biedt tot de IIS service en niet tot alle COM applicaties.
Recipient Administrator
De Recipient Administrator vind ik persoonlijk als rol echt een giller. Het staat toe dat over het gehele forest de Exchange property sets gewijzigd kunnen worden. Een Recipient Administrator kan dus standaard, zonder bijvoorbeeld aanvullende AD rechten als account operator, ALLE Exchange properties wijzigen en ook bijvoorbeeld mailboxen aanmaken op servers in andere domains.
Op zich heel leuk voor de wat kleinere organisaties, maar ik had persoonlijk liever gezien, dat men via bijvoorbeeld lidmaatschap van een andere groep een en ander nog wat kon beperken. Gelukkig is dit redelijk simpel te verwezenlijken, maar het blijft maatwerk, wat ik niet zo charmant vind. Wat je doet met de volgende procedure is een aantal nieuwe Security Groups aanmaken die je gaat gebruiken om rechten te delegeren op container niveau in Active Directory.
Voordat je begint, double en tripple-check de commando's voordat je begint!!!!
1. Meld aan met een Domain Admin Account op een Exchange server.
2. Maak de gewenste UNIVERSAL security groups aan.
3. Open de Exchange management shell en voer de volgende commando's uit:
Add-ADPermission –identity "ou=OUnaam,dc=bedrijf,dc=com" –user "domain\group" -AccessRights ReadProperty, WriteProperty -Properties Exchange-Information, Exchange-Personal-Information, legacyExchangeDN, displayName, adminDisplayName, displayNamePrintable, publicDelegates, garbageCollPeriod, textEncodedORAddress, showInAddressBook, proxyAddresses, mail
Add-ADPermission -identity "ou=OUnaam,dc=bedrijf,dc=com" –user "domain\group" -AccessRights GenericRead
Add-ADPermission -identity "ou=OUnaam,dc=bedrijf,dc=com" –user "domain\group" -AccessRights GenericAll –InheritanceType Descendents -InheritedObjectType msExchDynamicDistributionList
Add-ADPermission -identity "ou=OUnaam,dc=bedrijf,dc=com" –user "domain\group" -AccessRights CreateChild, DeleteChild -ChildObjectTypes msExchDynamicDistributionList
Add-ADPermission -Identity "CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=CompanyOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=company,DC=com" -User "domain\group" -InheritedObjectType ms-Exch-Exchange-Server -ExtendedRights ms-Exch-Recipient-Update-Access -InheritanceType Descendents
Add-ADPermission –identity "CN=Address Lists Container,CN=ExchOrganisatieNaam,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=bedrijf,DC=com" –user "<domain\group> " -AccessRights WriteProperty -Properties msExchLastAppliedRecipientFilter, msExchRecipientFilterFlags
Add-ADPermission –identity "CN=Recipient Policies,CN=ExchOrganisatieNaam,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=company,DC=com" –user "" -AccessRights WriteProperty -Properties msExchLastAppliedRecipientFilter, msExchRecipientFilterFlags
Vervang alles wat schuingedrukt is met de juiste waardes voor jouw organisatie. Je kan deze commando's gebruiken op elke domein- of OU container.
4. Voeg de beheerders accounts to aan de juiste Security Group.
Je hebt nu voldoende toegang verleend om exchange recipient management te doen op mailenabled objecten in een bepaalde container. Het enige wat nog steeds kan is een mailbox aanmaken op elke server. Ik ben er nog niet echt achter hoe je dat kan beperken, maar misschien komt dat nog.
Server Administrator
De server administrator is een impliciete rol, welke bestaat uit lidmaatschap van de 'Exchange View-Only Adminstrators' Universal Group, 'Administrators' local group op de betreffende server(s) en lees/schrijf rechten op het/de server object(en) in de configuration partitie in Active Directory. Let wel, zet deze rol niet zelf via raw editing tools, maar gebruik de Exchange tools.
De server administrator is in staat een individuele Exchange server te beheren.
Delegatie van rechten
Het delegeren van rechten is relatief simpel te doen via de Exchange Console. Selecteer de Organization Node en kies voor 'Add Exchange Administrator'
Je kan het ook doen via de Exchange Shell, maar ik gebruik dit zelden. Gebruik het volgende commando:
Add-ExchangeAdministrator -Identity -Role [-DomainController ] [-Scope ]
De scope parameter wordt alleen gebruikt bij de Server Administrator, waar je 1 of meerdere servers op kan geven
Property Sets
Bij de recipient administrator heb ik laten zien hoe je permissies delegeert op container niveau. Dit waren slechts een paar ACE's wat een heel verschil was met de manier waarop het in Exchange 2000|3 ging. De reden is dat met Exchange 2007 de properties (attributeSchema's) zijn gegroepeerd in property sets. Klinkt allemaal leuk, maar wat is nou een property set?
Simpel gezegd is een property set dus een groepering van attributen, op basis waarvan rechten gedelegeerd kunnen worden.
Als je op zoek gaat naar een propertyset als object in het schema zul je het niet terug vinden. Een propertyset wordt gedefinieerd door een controlAccessRight object aan te maken in CN=Extended-Rights,CN=Configuration,DC=bedrijf,DC=com en de rightsGuid te koppelen aan het attributeSecurityGUID property van een verzameling attributeSchema objecten in het Schema.
In het screenshot heb ik de attributen, behorend tot de 'Exchange Personal Information' property set opgehaald, om een en ander te visualiseren.
Zoals, eerder gemeld is dit, in vergelijking met Exchange 2000|3 een hele verbetering, doordat deze groepering niet bestond. Aan de andere kant is dit wel een erg zwakke implementatie. Het attributeSecurityGUID property op een attributeSchema object accepteert slechts 1 GUID octet, wat dus impliceert dat een attribuut slechts tot 1 property set kan behoren. Redelijk zwak in mijn optiek, maar beter iets dan niets. Dit is trouwens ook de reden dat wanneer je in ADSI gaat kijken naar de rechten delegatie voor bijvoorbeeld de Recipient Administrator, dat je attributen als Proxyaddresses en mail apart gespecificeerd ziet staan. Zij zijn namelijk al lid van de 'Public Information' property set.
Bronnen:
https://msexchangeteam.com/archive/2007/02/12/435171.aspx