Page tree
Skip to end of metadata
Go to start of metadata

Status

FunctionalityStable
Support statusLEGACY, unsupported
Support provided byN/A
Target systemsActive Directory


DEPRECATED and UNSUPPORTED

This connector is based on the .NET code developed by Sun Microsystems in 2000s. It is in fact just a special case of (now deprecated) .NET-based Active Directory Connector. This connector is DEPRECATED. It is likely that it will still work, but it is no longer developed, it is not maintained and it is not supported.

Please use the Poweshell support in the new LDAP-based Active Directory Connector instead.

Description

Connector usable for connecting to Active Directory and Microsoft Exchange. This is quite heavyweight connector and it works only in .NET connector server.

Exchange connector provides a superset of functionality of the Active Directory connector, see below.

Protocol

PowerShell + ADSI

Framework

ConnID 1.4.x (for 1.4.x.y versions), OpenICF 1.1.x (older versions)

Bundle name

Exchange.Connector

Connector name

Org.IdentityConnectors.Exchange.ExchangeConnector

Additional requirements

.NET Connector Server

Capabilities and Features

Provisioning

YES


Live Synchronization

?


Password

YES


Activation

YES


Script execution

YES


History

This is mostly the original Sun ICF AD connector. Some extensions and fixes were done by ForgeRock and Evolveum.

Versions

Version

Origin

Binary

Sources

Build Date

Description

1.4.1.20283Version built by EvolveumZIPgithub (Evolveum/openicf, branch master)Oct 22nd, 2014Experimental. Support for paged searches (VLV) for AD-fetched objects (users, orgs, groups).
1.4.1.20257Version built by EvolveumZIPgithubSep 9th, 2014A lot of new functionality (many object classes, flexible scripting and schema processing). Seems to be quite stable. Recommended.
1.4.0.20165Version built by EvolveumZIPgithubMay 31st, 2014Use this one in case of problems with 1.4.1.20257.

1.0.0.20108

Version built and partially tested by Evolveum

ZIP


Mar 2014

OBSOLETE. Use only with pre-3.0 versions of midPoint.

Documentation

Introduction

Exchange connector is able to provision Active Directory users, optionally with some Exchange-related artefacts. Specifically, currently supported kinds of users (recipient types in Microsoft terms) are shown in the following table. The first column contains Microsoft name for the recipient type, while the second one contains the respective value that should be put into RecipientType attribute (see below) to create specified kind of user.

Recipient typeRecipientType attribute valueMeaning
User mailboxUserMailboxActive Directory user with a mailbox in local Exchange organization.
Mail userMailUser

Active Directory user that has a mailbox outside the Exchange organization. Each mail user has an external email address. Messages sent to this user are forwarded to the external email address.

UserUserOrdinary Active Directory user without any Exchange-related information.

Support for provisioning other types of recipients (e.g. distribution groups) is planned for the future.

Permissions

To successfully manage accounts with Exchange access, the administrative user should be put into the "Organizational Management" group (located in "OU=Microsoft Exchange Security Groups, ...").

Also it seems that at least for Microsoft Exchange 2013 the Connector Server should be running as the same administrative user, not LOCAL_SYSTEM.

Comparison with Active Directory connector

Exchange connector is a superset of Active Directory connector. It is able to provision "pure" Active Directory users. However, there are two differences:

  1. Exchange connector requires Exchange installation to work, even if you do not plan to deal with any Exchange-specific objects.
  2. Exchange connector does not support UpdateAttributeValuesOp API interface, so adding and deleting attribute values (for both general AD attributes as well as Exchange-specific ones) is a bit less efficient in comparison with Active Directory connector, because these operations have to be emulated by Connector Server via GET-UPDATE operations pair. Direct replacing attribute values (UpdateOp API interface) is supported by both connectors.

Therefore, if you plan to use AD objects only, use AD connector. If you plan to use Exchange objects as well, use Exchange connector.

AspectActive Directory connectorExchange connector
Required softwareWindows ServerWindows Server with Exchange server (TODO: specify exactly which components of Exchange are needed)
Works with AD-only objects and attributesYESYES
Works with Exchange-specific objects and attributesNOYES
Supports efficient "attribute add/delete value" operationYESNO
StatusProduction qualityNear-production quality (still in development)

Please note that the distribution ZIP file for Exchange connector contains both connectors (two DLL's with supporting files), so when installing into Connector Server directory, it is sufficient to install this one file. On connector discovery, midPoint will show two connectors: Active Directory and Exchange. It is up to you whether you use AD or Exchange connector for working with any given resource.

Supported attributes

The connector supports all attributes supported by AD connector, along with the following Exchange ones. Descriptions are taken from Microsoft's site.

AttributeDescriptionAD counterpartNotes
RecipientTypeSpecifies the kind of user (see table above).msExchRecipientDisplayType, msExchRecipientTypeDetails

(warning) Beware that when changing the value from UserMailbox to any other one, the user's mailbox is deleted. Also when changing any value to User, all Exchange-related information from Active Directory user object are removed.

(info) When fetching data from the resource, two AD attributes are used to determine RecipientType: msExchRecipientDisplayType and msExchRecipientTypeDetails (see here). It is possible that in some cases, the mapping will be inaccurate. Please contact Evolveum support in such situations. For diagnostic purposes, values of these two attributes are provided (as read-only items) among account attributes fetched from the resource.

ExternalEmailAddressExternal email address to which all messages for a MailUser should be forwarded.targetAddress

This parameter is obligatory when creating a MailUser.

These addresses are used without "smtp:" prefix - pure "user@domain" form is needed.

EmailAddresses (multivalued)All addresses under which this user is known.proxyAddresses

In contrary to other email addresses used by this connector, this parameter uses SMTP:/smtp: prefixes for individual address. "SMTP:" prefix is used for specifying primary SMTP address, "smtp:" for non-primary ones. Only one address can be designated as primary.

It is not allowed to specify this attribute along with PrimarySmtpAddress attribute.

Usually, these addresses are computed by default, unless EmailAddressPolicyEnabled is set to false.

EmailAddressPolicyEnabledAre EmailAddresses updated automatically based on e-mail address policy?msExchPoliciesExcluded
PrimarySmtpAddressPrimary SMTP address.mailDo not set/modify along with EmailAddresses.
AliasThe part of address before "@" sign.mailNicknameThe alias can be a combination of characters separated by a period with no intervening spaces. Don't use special characters in the alias.
HiddenFromAddressListsEnabledSpecifies whether this mailbox is hidden from other address lists.msExchHideFromAddressLists
Database

Specifies the database that contains the mailbox object. You can use either GUID or database name.

homeMDB

If not specified, default database is used.

(warning) This attribute is not updatable. Any attempt to update it will fail. Mailboxes have to be moved explicitly using Exchange tools or dedicated PowerShell commands.

ForwardingSmtpAddressSpecifies a SMTP address where mail should be forwarded.msExchGenericForwardingAddressFor detailed explanation, see e.g. this document.
DeliverToMailboxAndForward

If set to TRUE, messages are delivered to the mailbox and to the forwarding address. If set to FALSE, messages are delivered only to the forwarding address.

deliverAndRedirect
CustomAttribute1..15Used to store any custom (additional) information.extensionAttribute1..15

Connector configuration

Connector configuration is the same as for Active Directory connector, with one attribute added: ExchangeUri. It shoud contain a URI pointing to place where to execute PowerShell commands used to manage Exchange accounts. An example: http://exchange.example.com/PowerShell/. As the host name, DO NOT use "localhost", because in that case the Kerberos authentication to that host will fail.

A sample configuration:

   <connectorConfiguration>
      <icfc:resultsHandlerConfiguration xmlns:icfc="http://midpoint.evolveum.com/xml/ns/public/connector/icf-1/connector-schema-2">
         <icfc:enableNormalizingResultsHandler>true</icfc:enableNormalizingResultsHandler>
         <icfc:enableFilteredResultsHandler>false</icfc:enableFilteredResultsHandler>
      </icfc:resultsHandlerConfiguration>
      <icfc:configurationProperties xmlns:icfc="http://midpoint.evolveum.com/xml/ns/public/connector/icf-1/connector-schema-2" 
                                    xmlns:ex="http://midpoint.evolveum.com/xml/ns/public/connector/icf-1/bundle/Exchange.Connector/Org.IdentityConnectors.Exchange.ExchangeConnector">
         <ex:ObjectClass>User</ex:ObjectClass>
         <ex:DirectoryAdminName>...</ex:DirectoryAdminName>
         <ex:DirectoryAdminPassword>...</ex:DirectoryAdminPassword>
         <ex:ExchangeUri>http://exserv1.abc.com/PowerShell/</ex:ExchangeUri>
         <ex:SyncDomainController>localhost</ex:SyncDomainController>
         <ex:CreateHomeDirectory>true</ex:CreateHomeDirectory>
         <ex:LDAPHostName>localhost</ex:LDAPHostName>
         <ex:SearchChildDomains>false</ex:SearchChildDomains>
         <ex:SyncGlobalCatalogServer>localhost</ex:SyncGlobalCatalogServer>
         <ex:Container>OU=TestOU,DC=abc,DC=com</ex:Container>
         <ex:DomainName>abc.com</ex:DomainName>
      </icfc:configurationProperties>
   </connectorConfiguration>

Some recommendations

  1. When creating mailboxes, the only attribute that is necessary to set, is RecipientType. Set it to UserMailbox and all other settings will be done via Exchange.
    For example, default addressing policies will be applied, and primary user mail address will be provided in PrimarySmtpAddress attribute (from where you can get it into midPoint via appropriate inbound mapping). Similarly, all addresses wil lbe present in EmailAddresses attribute.

  2. When creating external mail recipients, only two attributes to be set are RecipientType (set to MailUser) and ExternalEmailAddress.

  3. It is recommended to play for a while with the accounts on Resources->List resources->Accounts page and see how effect has changing RecipientType and setting some attributes on AD/Exchange user records.

  4. To prevent the execution of malicious scripts, PowerShell enforces an execution policy. By default, the execution policy is set to Restricted, which means that PowerShell scripts will not run.  If a script execution error occurs when you set RecipientType field in the connector configuration, set the executon policy to “RemoteSigned” in Powershell using the command below,

    Set-ExecutionPolicy RemoteSigned

    Source: http://security.stackexchange.com/questions/1801/how-is-powershells-remotesigned-execution-policy-different-from-allsigned (thanks to Arda for providing this recommendation).

Resource Examples

See Also

  • No labels