Exchange Server 2010 : Ensuring Message Integrity (part 3) - Configuring Permissions on Active Directory Objects & Rights Management Services Federation

4. Configuring Permissions on Active Directory Objects

You can perform functions (for example, allowing one user to send on behalf of another) and alter Exchange Server 2010 behavior by configuring the permissions on Active Directory objects, such as user mailboxes, distribution groups, Send connectors, and Receive connectors.

4.1. Adding and Denying Active Directory Permissions

You can use the Add-ADPermission EMS cmdlet to add an Active Directory permission and the Remove-ADPermission EMS cmdlet to remove such a permission. For example, the following command grants Kim Akers the Send As permission to the Don Hall mailbox, allowing Kim to send mail as Don:

Add-ADPermission -Identity "Don Hall" -User "Kim Akers" -AccessRights ExtendedRight
-ExtendedRights "send as" | FL

					  

The command is piped into the PowerShell Format-List function so that its output can be seen in more detail. Figure 7 shows this output.

The identity parameter specifies the Active Directory object to which permissions are being granted (or from which they are being removed). It could, for example, identify a mailbox, a Receive connector, or a Send connector. If the Active Directory object has an owner, you can use the Owner parameter to identify this. The User parameter specifies the user or group to which the permissions are granted. The AccessRights parameter specifies the rights needed to perform the operation. Valid values include the following:

• CreateChild

• DeleteChild

• ListChildren

• Self

• ReadProperty

• WriteProperty

• DeleteTree

• ListObject

• ExtendedRight

• Delete

• ReadControl

• GenericExecute

• GenericWrite

• GenericRead

• WriteDacl

• WriteOwner

• GenericAll

• Synchronize

• AccessSystemSecurity

The AccessRights parameter can take the argument ExtendedRight as specified in the above list. You can specify the extended rights, such as Send As, ms-Exch-SMTP-Submit, ms-Exch-SMTP-Accept-Any-Recipient, and ms-Exch-Bypass-Anti-Spam, by using the ExtendedRights parameter. For example, the following command configures the Receive connector MyReceiveConnector to accept anonymous SMTP messages and bypass the spam filter:

Add-ADPermission "MyReceiveConnector" -User "NT AUTHORITY\ANONYMOUS LOGON" -AccessRights
ExtendedRight -ExtendedRights ms-Exch-SMTP-Submit,ms-Exch-SMTP-Accept-Any-Recipient,
ms-Exch-Bypass-Anti-Spam

					  

Note that the Receive connector MyReceiveConnector must exist on the server on which the command runs; otherwise, the command returns an error. Note also that you would not configure a Receive connector in this way unless you had another mechanism in place for blocking unsolicited email.

You can use the Deny switch to deny a permission to an Active Directory object. For example, the following command denies the Send As permission on the Don Hall mailbox to the user Kim Akers:

Add-ADPermission -Identity "Don Hall" -User "Kim Akers" -Deny -AccessRights
ExtendedRight -ExtendedRights "send as"

Note:

Bear in mind that denying a permission is not the same as removing it. If an Active Directory permission is removed, the user no longer has the permission granted through this mechanism but may have the permission because of, for example, membership of a distribution group that has been allocated that permission. If a permission is denied to a user, the user cannot be allocated this permission through a group membership. The Deny setting overrides any allocation of the denied permission by any other means.

You can remove a permission by using a command based on the Remove-ADPermission EMS cmdlet. For example, the following command removes the permissions that enable the Receive connector MyReceiveConnector to accept anonymous SMTP messages and bypass the spam filter:

Remove-ADPermission "MyReceiveConnector" -User "NT AUTHORITY\ANONYMOUS LOGON"
-AccessRights ExtendedRight -ExtendedRights ms-Exch-SMTP-Submit,ms-Exch-SMTP-Accept-Any
-Recipient,ms-Exch-Bypass-Anti-Spam

					  

Figure 8 shows the output from this command. You need to confirm your action unless you set the Confirm parameter to false in the command by using the syntax –Confirm:$false.

You can discover the Active Directory permissions that have been set on an object by using a command based on the Get-ADPermission EMS cmdlet. For example, the following command lists the permissions set on the Don Hall mailbox:

Get-ADPermission -Identity "Don Hall" | FL > C:\"Don Hall Permissions"

This command generates a large volume of information, and its output has therefore been redirected into a text file named “Don Hall Permissions.” Figure 9 shows a portion of this text file.

AD FS is a single sign-on (SSO) technology that is often described as a limited trust relationship. The AD FS service provides external support for the internal identity and access services that Active Directory Directory Services (AD DS) requires and extends the authority of your internal network to external networks. In other words, AD FS lets you use the credentials required to log on to your own organization to access information (both protected files and protected email) held in another organization that is part of the same federation. In this section, you learn how AD FS authenticates a user, how you install and configure the service, and how you manage the trusts and certificates it requires.

5.1. Understanding AD FS

AD FS allows users of external web-based applications (for example, OWA) to access and authenticate through a browser. It relies on the internal authentication store of the user’s own domain to authenticate a client and does not have a store of its own. It also relies on the original authentication that clients perform in their own networks and passes this authentication to web applications that are AD FS enabled. AD FS federates a user’s internal AD DS identity and submits it to external networks. Users need to authenticate only once.

For example, David Hamilton, Nancy Anderson, and Jeff Hay buy supplies for Wingtip Toys from World Wide Importers, an organization with which their company has a long-standing relationship. David, Nancy, and Jeff need to log on to web applications at World Wide Importers. Employees at World Wide Importers need to be able to add David, Nancy, and Jeff to distribution lists that otherwise contain only World Wide Importers employees and send David, Nancy, and Jeff email messages that have their content protected by an RMS template.

World Wide Importers have user name and password policies that are different from those at Wingtip Toys. If no federation mechanism were in place, David, Nancy, and Jeff would need to log on to the World Wide Importers domain as if they were employees and remember two sets of login names and passwords, which regularly change. AD FS allows Wingtip Toys and World Wide Importers to set up a partnership so that David, Nancy, and Jeff can log on to these web applications and decrypt protected World Wide Importers internal email messages using their Wingtip Toys credentials. They are not required to log in twice and remember two user names and two passwords in order to do their job.

Unlike forest trusts, AD FS does not use Lightweight Directory Application Protocol (LDAP) ports but rather the common HTTP ports, specifically port 443, so that all AD FS trust communications can be secured and encrypted. AD FS relies on Active Directory Certificate Services (AD CS) to manage certificates for each server in the AD FS implementation. AD FS can extend AD RMS deployment and provide federation services for intellectual property management between partners.

AD FS provides extensions to internal forests and enables your organization to create partnerships without needing to open any additional ports on its firewall. It relies on each partner’s internal AD DS directory to provide authentication for extranet or perimeter services. When a user attempts to authenticate to an application integrated to AD FS, the AD FS engine polls the internal directory for authentication data. Users who have access provided through the internal directory are granted access to the external application. This means that each partner needs to manage authentication data only in its internal network. The federation services of AD FS do all the rest.

5.2. Forming Business-to-Business Partnerships

You can use AD FS and RMS Federation to form business-to-business (B2B) partnerships. In this arrangement, partners can be account or resource organizations (or both). These can be described as follows:

• Account organizations Manage the accounts used to access shared resources and decrypt protected email messages in SSO scenarios. Account organizations join partnerships created by resource organizations and access resources (including email) in these organizations.

• Resource organizations Form the partnerships in SSO scenarios. An organization that has resources (such as a collaboration website) can use AD FS to simplify the authentication process to these resources by forming partnerships that account organizations then join. The organization that initially forms the partnership is deemed the resource organization because it hosts the shared resources in its perimeter network.

In the example given earlier, David, Nancy, and Jeff are logged on to the Wingtip Toys forest and can access web applications and protected email messages at World Wide Importers without needing to supply additional credentials. In this case, Wingtip Toys is the account organization (or account partner), and World Wide Importers is the resource organization (or resource partner).

AD FS uses claims, cookies, and certificates to implement a federated B2B partnership.

5.3. Using Claims in AD FS

A claim is a statement that the federation server makes about a user or client. Claims are stored as AD DS attributes that each partner in an AD FS relationship attaches to its user accounts. They can be based on several different values, such as user names, certificate keys, membership of security groups, and so on. Claims are included in the signed security token that AD FS sends to the web application and are used for authorization. They can be based on user identity (the identity claim type) or on security group membership (the group claim type). Claims can also be based on custom information (the custom claim type), such as a custom identification number (for example, employee number or bank account number).

5.4. Using Cookies in AD FS

User browsers hold cookies that are generated during web sessions authenticated through AD FS. AD FS uses authentication cookies, account partner cookies, and sign-out cookies. When a user is authenticated through AD FS, an authentication cookie is placed within the user’s browser to support SSO for additional authentications. This cookie includes all the claims for the user. It is a session cookie and is erased after the session is closed.

The AD FS process writes an account partner cookie when a client announces its account partner membership during authentication, so it does not need to perform partner discovery again the next time the client authenticates. An account partner cookie is long-lived and persistent.

Each time the federation service assigns a token, it adds the resource partner or target server linked to the token to a sign-out cookie. The authentication process uses sign-out cookies for various purposes, such as for cleanup operations at the end of a user session. A sign-out cookie is a session cookie and is erased after the session is closed.

5.5. Using Certificates in AD FS

AD FS communications must be encrypted at all times, and this requires several certificate types. The type of certificate required by the role depends on its purpose.

A federation server requires both a server authentication certificate and a token-signing certificate. In addition, the trust policy requires a verification certificate. The server authentication certificate is an SSL authentication certificate that is typically requested and installed through IIS Manager.

A token-signing certificate is made up of a private key and a public key pair. When a federation server generates a security token, it digitally signs the token with its token-signing certificate. A verification certificate is used during the verification process that takes place between servers when there is more than one federation server in a deployment. It contains only the public key of the token-signing certificate.

A federation service proxy requires a server authentication certificate to support SSL-encrypted communications with web clients. It also needs a client authentication certificate (known as a federation service proxy certificate) to authenticate the federation server during communications. Both private and public keys for this certificate are stored on the proxy. The public key is also stored on the federation server and in the trust policy. A web server hosting the AD FS web agent also requires a server authentication certificate to secure its communications with web clients, typically federation servers.

Note:

CERTIFICATES AND OUTWARD-FACING ROLES

Many AD FS roles are outward facing. Therefore, your certificates should be from a trusted CA. If you use Active Directory–generated certificates, you need to modify the Trusted CA store on each web client. AD FS relies on AD CS to manage these certificates.

5.6. AD FS Role Services

Federated identity is the process of authenticating a user’s credentials across multiple information technology systems and organizations. Identity federation enables users in one domain to securely access data or systems of another domain by using SSO. AD FS relies on the following role services to support identity federation:

• Federation Service A server running the federation service (a federation server) routes authentication requests to the appropriate source directory to generate security tokens for the user requesting access. Servers that share a trust policy use this service.

• Federation Service Proxy A federation server relies on a proxy server located in the perimeter network to obtain authentication requests from a user. The proxy collects authentication information from the user’s browser through the WS-Federation Passive Requestor Profile and passes it on to the federation service.

• Windows Token-Based Agent A Windows token-based agent converts an AD FS security token into an impersonation-level Windows NT access token that is recognized by applications that rely on Windows authentication rather than web-based authentication.

• Claims-Aware Agent A claims-aware agent on a web server initiates queries of security token claims to the federation service. Each claim is used to grant or deny access to a given application. For example, ASP.NET applications that examine the various claims contained in the user’s AD FS security token are claims-aware applications, as is AD RMS.
  

AD FS supports three configurations (or architectural designs) depending on the type of B2B partnership you need to establish. Each supports a particular partnership scenario. These architectural designs are as follows:

• Federated Web SSO This deployment scenario typically spans several firewalls. It links applications contained within an extranet in a resource organization to the internal directory stores of account organizations. The federation trust is the only trust used in this model. A federation trust is a one-way trust from the resource organization to the account organization(s).
  

• Web SSO This is deployed when all users of an extranet application are external. It allows users to authenticate using SSO to multiple web applications. It relies on multihomed web servers that are connected to both the internal and the external network and that are part of the AS DS domain. The Federation Service Proxy is also multihomed to provide access to both the external and the internal network.

• Federated Web SSO with Forest Trust In this model, a forest trust is established between an external forest in the perimeter network and an internal forest. A federation trust is also established between the resource federation server located within the perimeter and the account federation server located in the internal network. Internal users have access to the applications from both the internal network and the Internet, whereas external users have access to the applications only from the Internet.

The most common scenarios are Web SSO and Federated Web SSO. Ideally, all members of an identity federation deployment have their own AD DS directory and act as account organizations to simplify the deployment strategy.

5.8. AD FS Authentication

When an AD FS partnership is in place, users can log on transparently to external web applications included in the partnership. In a typical AD FS email scenario, a user receives and attempts to open a protected email message across an extranet. AD FS automatically provisions the user’s credentials and outlines the claims included in the user’s AD DS account attributes. Figure 10 illustrates the process.

A more detailed high-level description of the process is as follows:

5.9. Configuring AD FS

Servers in an AD FS relationship rely on certificates to create a chain of trust and ensure that all traffic transported over the relationship is encrypted at all times. To ensure that the chain of trust is valid and trusted in all locations, you can obtain certificates from a trusted third-party CA or through the creation of a linked implementation of AD CS that uses a trusted third-party CA as its root.

When you deploy AD FS, you need to configure AD FS–aware applications, trust policies between partner organizations, and claims for your users and groups. After you install and deploy AD FS, you need to carry out the following configuration tasks:

• Configure the web service on each AD FS server to use SSL/TLS encryption on the website that hosts the AD FS service.

• Configure IIS on servers that host claims-aware applications.

• Export certificates from each server and import them on the other servers in the relationship.

• Create and configure the claims-aware applications you are hosting.

• On the federation servers in both account and resource organizations, configure the trust policy, create claims for users, and configure the AD DS account store for identity federation. In a resource organization, you also then enable the claims-aware applications.

• Create the federation trust to enable identity federation by exporting the trust policy from the account organization and importing it into the resource organization, creating and configuring a claim mapping in the resource organization, and exporting the partner policy from the resource organization so that you can import it into the account organization.

Much of the configuration process involves certificate mapping from one server to another. You need to be able to access the certificate revocation lists (CRLs) for each certificate. CRLs indicate to a member of a trust chain whether a certificate is valid.

In AD FS, CRL checking is enabled by default. Typically, CRL checking is performed for security token signatures, but it is good practice to rely on it for all digital signatures.

Transport rules allow organizational message policies to be applied to email messages that pass through Hub and Edge transport servers. You use transport rules to manage communication within an organization and communication from the organization to the rest of the world. They can filter internal communication and perform actions based on message properties such as sender, receiver, message content, and classification.

Transport rules are made up of conditions, exceptions, and actions. It is possible that a message may meet the conditions of multiple transport rules. Conditions determine to which messages a transport rule is applied. Transport rules without any conditions are applied to all messages, unless those messages meet a configured exception. Conditions can include, for example, messages received from or sent to a specified mailbox or distribution list or received from or sent to users inside or users outside the organization.

You use exceptions to exempt messages that match a transport rule’s conditions from the transport rule’s actions. Unlike conditions, where every specified condition must be met for a rule to apply, only one exception condition must be met for the message to be exempted from the rule. Exceptions can include, for example, “except when messages are received from or sent to a specified mailbox or distribution list” or “except when received from or sent to users inside or users outside the organization.” You can also configure a transport rule to apply to all email messages except when any of the recipients in the To or Cc fields are in a list of specified mailboxes or in a specified distribution list.

Actions are applied to messages that meet transport rule conditions and where the action is not blocked by any exceptions. They can, for example, include logging an event with a specified message (used for debugging), applying a message classification, copying the message to a specified address (used for journaling), and setting the spam confidence level (SCL) to a specified value.

For example, the following command applies a message classification named ManagementCommunication to all messages sent by members of the distribution group Managers to one or more members of the group AllEmployees, except when the message title contains the words “Holiday Photos”:

New-TransportRule -Name "ManagerMessage" -FromMemberOf "Management"
-SentToMemberOf "AllEmployees" -ApplyClassification "ManagementCommunication"
-ExceptIfSubjectContainsWords "Holiday Photos"

					  

New-TransportRule -Name "Protect-Secrecy" -SubjectContainsWords "Top Secret"
-ApplyRightsProtectionTemplate "Do Not Forward"