Exchange server 2013 Client Access Server - Part 1

Exchange server 2013 have only two roles. Mailbox server role & client access server role.

Blame it to RBAC!

                           

                             Blame it to RBAC  !

If you are working as an Administrator in an Exchange 2010 based environment and on one fine day you realized you are not able to execute certain command in your environment even after verifying syntax multiple times over Google...Blame it to RBAC guys !!!!

Introduction of DAG is the most technologically interesting  advancement in Microsoft Exchange Server 2010, the implementation of new permission model based on the concept of role based access control exerts the most pervasive influence on the most parts of product. RBAC is therefore the most important element for administrators to master !

Taken as a whole, RBAC is an approach to restrict access to system and data based on the need of administrators and users to do their job (that's why at one fine day, curious administrator like you all fell short of Cmdlet!)

RBAC is not new concept and it has been implemented in other operating systems and applications including HP-UX, Linux, Oracle, SAP R/3 etc.

Previous versions of Exchange uses Windows ACL to grant permissions to users and administrators. ACLs are effective way to manage permissions in environment which is well structured and does not tend to change much over the time. Exchange is little more dynamic and snaps thousands of hundreds of objects in its largest deployment. Tracking and updating ACL across such a dynamic environment for so many objects is real challenge and real world experience revealed that ACLs are often updated incorrectly, can be difficult to debug when things go wrong. Another issue is that the conventional model of creating, updating and setting permissions on objects often does not translate well into a task driven environment that exists within application such as Exchange where permissions have to support scenarios such as permitting help desk personnel to reset a user's password without being able to effect any other setting of the user's account.

The granularity available in RBAC  addresses this need !

It is impossible to understate influence of RBAC throughout Exchange 2010. It would require 300-page book to cover every aspect of RBAC in depth.

RBAC Basics :

To understand how RBAC defines and distributes roles, you will need to become familiar with a few new terms:

Management Role A management role, also referred to as a role, represents a grouping of

Exchange cmdlets that can be run by people who are assigned the role. These cmdlets are also referred to as management role entries.

Management Role Entry A management role entry, also known as a role entry, is the term used to refer to each Exchange cmdlet that is defined on a role. There is also a special type of role that allows your role entries to be able to execute PowerShell scripts or non-Exchange cmdlets.

Scope The scope defines the boundary of objects that a role can be applied to. By default, the scope of impact on roles is not very restrictive. However, you can create custom scopes that make the scope of impact for a role more restrictive, such as restricting a role to only an organization

Role Group A role group is a security group in Active Directory that defines who gets which

roles applied to them. Along with the specific roles, a role group can also define the scope to

which those roles are appliedal unit (OU) of recipients.

Role Assignment Policy A role assignment policy is similar to a role group, because it is a

representation of a collection of management roles. However, the role assignment policy is

used for distributing roles to end users, whereas the role group is used for assigning roles to

Exchange administrators.

Management Role Assignment Management role assignments, also known as role assignments, pulls everything together. RBAC defines who (the role group or user account)

has what permissions (the roles) and where (the scope) those permissions are in effect. The role assignment pulls this together by assigning a management role to a role group, a user account, or a role assignment policy. Each time a role is assigned to a unique role group, user account, or role assignment policy, a different role assignment is created. Each role assignment assigns only one role to one role group, user account, or role assignment policy.

Managing RBAC

You can manage RBAC either by using ECP or by using EMS. There is not really much you can do with RBAC using ECP and very soon you will turn to EMS to do wonders!

Below is the list of commands which can be used to manage RBAC through EMS

Component                      Cmdlet                                        Description

Management role

New-ManagementRole                  Creates a new role

Get-ManagementRole                    Gets the list of roles or the properties of a specific role

Remove-ManagementRole             Deletes a role

Management

role entry

Add-ManagementRoleEntry            Adds a role entry to an existing role

Get-ManagementRoleEntry             Retrieves the list of role entries on a role

Remove-ManagementRoleEntry      Removes a role entry from a role

Set-ManagementRoleEntry             Sets the parameters on an already defined role entry

Role group

Get-RoleGroup                             Gets the list of role groups or the

properties of a specific role group

New-RoleGroup                            Creates a new role group

Remove-RoleGroup                      Deletes a role group

Set-RoleGroup                             Changes the properties of the role group

Add-RoleGroupMember                 Adds an administrator to a role group

Get-RoleGroupMember                  Lists the members of a role group

Remove-RoleGroupMember            Removes an administrator from

a role group

Update-RoleGroupMember             Modifies the role group membership in bulk

Role assignment

policy

Get-RoleAssignmentPolicy              Retrieves the list of role assignment policies or retrieves the details of a specific role assignment policy

New-RoleAssignmentPolicy             Creates a new role assignment policy

Remove-RoleAssignmentPolicy        Deletes a role assignment policy

Set-RoleAssignmentPolicy              Configures the properties of a role

assignment policy, including whether the

policy is the default policy for the domain

Management role

assignment

Get-ManagementRoleAssignment    Retrieves the list of role assignments or the details of a specified role assignment

New-ManagementRoleAssignment   Creates a new role assignment

                          Remove-ManagementRoleAssignment           Deletes a role assignment

Set-ManagementRoleAssignment     Configures the properties of the role assignment, including the scope that the assignment uses.

The RBAC data is stored in Active Directory. Each management role has an associated object in Active Directory of the object type msExchRole.

The role objects are stored in the Configuration Naming Context inside the following container:  Services\Microsoft Exchange\Org Name\RBAC\Roles.

What could be one the trickest task for administrator is to choose what management role to assign to particular user based on the requirement of job role! It is always recommended to use built-in RBAC roles to fulfill your needs instead of creating any custom RBAC role group. Exchange has taken care of this and has many built-in RBAC role groups which are designed considering various needs of any organization. Let's look into it by an example.

Suppose you have an user Bhalu who needs to be able to import mailbox data and you don't know if any such built-in RBAC role is there in Exchange or not.

You can use wild card to search the required management role group as shown below

get-managementroleentry "*\import mailbox"  and you will be get an output as below

Name                               Role                                Parameters

----                                  ----                                  ----------

Import-Mailbox        Mailbox Import Export        {AllContentKeywords...

That's it ! now you know the name of ManagementRole which can fulfill Bhalu's need. Now is time for you to check what RoleEntries this role has and you can do it using below mentioned Cmdlet

get-ManagementRoleEntry "Mailbox Import Export\*" and the output looks like below

Name                               Role                                 Parameters

----                                  ----                                  ----------

Import-Mailbox        Mailbox Import Export                  {AllContentKeywords...

Get-Mailbox             Mailbox Import Export                  {Anr, Credential, D...

Export-Mailbox         Mailbox Import Export                  {AllContentKeywords...

As simple as that !

Unscoped Roles ( The exception ) :

Unscoped management roles are interesting because they allow you to create tailored roles for administrative purposes. This type of role does not have a parent ! and hence they are called as unscoped top level roles!

The basic idea behind a custom unscoped role is that it is a mechanism that allows administrators to grant access  to non-Exchange Cmdlets or Windows PowerShell scripts to management role groups, individual users or USGs. Granting access to the ability to perform  specific work without the need to grant access to particular role group or Cmdlet is another reason why you might create custom unscoped role.

For Example, You might want a helpdesk to be able to create mailboxes in some OU following a structured naming convention and populating mailbox properties in certain manner. You can do this by writing a script that encodes all the required business logic for this and grant access to helpdesk group to run the script. Now the helpdesk group members who receive this unscoped role can run the script however can not use 'New-mailbox' Cmdlet in any other way!

To begin, you have to delegate the ability to create unscoped roles to an account. This ability is not granted by default, even to accounts that hold Organization Management role. Which means, by default, no one has access/permissions to create these role groups !!!

Special Roles

The list of roles included in the Organization Management role group includes the following five special roles that have to be delegated before they can be used :

       ApplicationImpersonation: This is a special purpose role intended primarily for use by Service Accounts that need to take on the persona of an user to accomplish a task.

       Mailbox Import Export:  This role allows user to import or export data into or from a mailbox.

       Mailbox Search: This role allows an user to search mailbox contents. The role is assigned to the 'Discovery Management ' role group. However the group has no default members and needs to be populated before searches can be performed.

       Support Diagnostics: This role allows access to diagnostics Cmdlets such as 'Test-ReplicationHealth' that are intended for use by Microsoft or other support personnel to retrieve diagnostic information from  an Exchange server or organization. This role is not assigned to any user by default.

       Unscoped Role Management: This role permits unscoped roles to be created and managed. Unscoped roles are used to authorize access to custom scripts and Cmdlets. This role is not assigned to any user by default but it can be delegated by holders of the Organization Management role. 

I hope, this will give fairly basic idea about what RBAC is and how it works!

How Exchange Leverages Windows PowerShell

From an Exchange perspective, Windows PowerShell provides a way to perform tasks quickly and simply in variety of manners. Prior to Exchange 2007, there was no way for administrators to automate common tasks to meet need to their organization; essentially if exchange engineer didn't code something into product, it couldn’t be done.

Below figure illustrates the central role that Windows PowerShell now plays in the Exchange architecture and how it provides a central place to encapsulate Business Logic that underpins the Exchange Setup program, EMS, EMC and ECP.

       Figure: Windows PowerShell at the heart of Exchange

The options presented by EMC to work with mailboxes, connectors, servers and other objects invariably results in a call to one or more PowerShell cmdlets that actually do the work.

The critical point is that the four major administrative interfaces in Exchange all lead to the same place and execute same Business Logic. Apart from removing redundant and overlapping code, having single place to implement Business Logic allows Exchange Engineer to concentrate on implementing new functionality rather than redeveloping features separately and specifically for EMC, EMS or other setup programs. This approach allows Exchange to deliver more consistent environment and a comprehensive method to automate tasks to deal with mailboxes, connectors, databases and all other components that collectively make up and Exchange Environment.

                                                                       

The RTM release of Exchange 2010 includes 584 cmdlets that are added to EMS to join standard set of Windows PowerShell cmdlets, including cmdlets to work with system registry, file system, variables ( including environment variables) and so on. The number of cmdlets grows again to 619 in Exchange 2010 SP1.

You can determine exact number of cmdlets owned by Exchange with the following command:

Get-ExCommand | Measure-Object | Select Count

You can use below command to generate full list of Exchange cmdlets that your account can access:

Get-ExCommand > C:\ExCommand.Csv

By comparison, Exchange 2007 includes 394 cmdlets, 26 of which have been removed in Exchange 2010. The 216 new cmdlets provided in Exchange 2010 reflects the new functionality in the product, such as introduction of RBAC model, mailbox archives, Database availability group (DAG) along with expansion of existing functionality such as messaging records management.

# Remote PowerShell:

Windows PowerShell has been at the heart of Exchange since Exchange 2007. Exchange 2007 was the first major server product to embrace Windows PowerShell extensively. However lack of remote capability was more serious because it required installation of Windows PowerShell and its snap-ins for exchange on any workstation or server from which you wanted to perform management tasks.

Installing software is an acceptable requirement in environments where all the servers are under your control and within your own network, but it caused problems when you want to manage servers remotely. The Microsoft introduction of Online services where companies will be able to run their exchange environments inside large Microsoft datacenters means that remote management has taken a new importance.

Exchange 2010 includes many new feature designed to ease the transition to online services and remote PowerShell provides the fundamental building blocks for management.

Exchange 2010 extends the concept of remote management to support the remote execution of commands in a secure manner using HTTPS and a Kerberos-based encryption. Here is an interesting thing to know about Exchange 2010 sessions. In Exchange 2010, remote PowerShell is used for all EMS sessions. Which means, even if you are logged on the server and want to user EMS to change property of that server, EMS still creates a remote session to the local server to the work. The same applies to EMC. In effect, remote PowerShell replaces local PowerShell in Exchange 2010 for all server roles except Edge servers.

Removal of local PowerShell and the concentration on the combination of remote PowerShell with and RBAC as the basis for administrative control over Exchange components is a major change in the product.

The logic of replacing local PowerShell with remote model is simple. Just like then change in Exchange 2007 to force all messages to flow through the transport system so that single common place existed to apply features such as transport rules, remote PowerShell forces exchange administration to flow through RBAC so that the PowerShell session will only ever include set of cmdlets to do your job !

The logic of keeping local PowerShell on Edge servers is simple too. These are the isolated from the rest of the organization so they do not have access to remote RBAC roles. Anyone who logs on the Edge server as an administrator operates in the context of management of just that server and has complete control over that server. However, he can not affect any other server or object in the Exchange organization.

The need to support hosting platforms such as Microsoft Business Productivity Online Services (BPOS) was major influence on Exchange’s move to remote PowerShell.

Permissions granted through RBAC are evaluated at the time of session initialization. If you are assigned a new role then you have to create a new session with EMS, ECP or EMC before you can access the cmdlets made available through newly assigned role.

# Advantage of Remote PowerShell:

Microsoft does not make changes to product like Exchange unless they see some clear advantage. There are 3 potential advantages of remote PowerShell.

1 1.Separating client and server processing and using IIS as the mechanism to route the traffic allows communication through a well understood route that can flow across firewalls and so accommodate both Microsoft Online Services and enterprise customers that operate multiple active directory forest.

2 2.The ability for administrators to delegate the tasks to other users on the basis of well defined roles adds to overall system security and prevents inadvertent mistakes that can affect essential data.

   3. Remote capability means you can perform Exchange management tasks from a workstation connected to your network without installing Exchange management tools. Of course you still need to install Windows PowerShell and any prerequisites software such as WinRM, .Net Framework, but these components are more likely to be part of corporate build for administrator’s workstation.

EAS Lock Down - Part 1

     You have an Exchange 2010 environment and users are using activesync devices, now your organization decide to lock down the EAS and allow the access only for those user who have signed some sort of consent form.

Below is the method to achieve this through ECP.

Now the first thing you need to do is edit "Exchange ActiveSync Settings" and you can do it through ecp.
1) Login to the ecp
2) Select "Manage My Organization"
3) Go to "Phone & Voice" Tab.
4) Under "ActiveSync Access" you will have "Edit" option to edit "Exchange ActiveSync Settings".
5) You will then get a pop to edit the settings.
       So you will have three below self explanatory options (but still I'll add some detail to it ) :
              a) "Connection settings
              When a device that isn't managed by a rule or personal exemption connects to Exchange" :
                     Select the option "Quaratine - Let me decide to block or allow later" which will quarantine all the activesync devices

              b)  "Quarantine notification e-mails Select administrators to receive e-mail when a device is quarantined." :
                    Add the administrators details so that email is received by the administrators once device     gets quarantined. Personally I would recommended that you mention the administrators detail here, will explain why it's recommended.


             c) "Enter text to include in e-mails sent to users who have a device in quarantine, blocked, or in the process of being identified" :
                      Here you can enter any custom message that you want to provide in an email which is received by the users' who's ActiveSync device is quarantined or blocked.

             d) Click Save to accept the settings.


Refer below figures for more details :

Figure 1: Managing EAS Settings

Figure 2: Exchange ActiveSync Settings

Once the above setting is applied then all the users who are using activesync on their device will receive the email message saying that their device has been quarantined.

Administrator will also receive an email which would contain the users' activesync device details and direct ecp link for managing users' device.
Administrator then can click on the link given in the email to either block or allow the device from syncing the emails depending on if that user has signed the consent form or not.

     Besides from the email you will also get the list of quarantined devices  under "Quarantined Devices"(6) to manage the users' activesync devices. You can then select the desired user and allow or block the activesync access(6a) accordingly.
If in your organization you have more than 500 users then you will get random 500 activesync devices in the quarantined devices list, so you may or may not get the desired user in the list who has signed the consent form and you want to allow the activesync access for that user.

If you want to allow access only for users' who has signed the consent form and for only particular device (like iOS devices) then you should also check "Device Type" and "Model" while allowing or blocking the activesync access.