Permissions for GalSync User

Permissions for GalSync User

 A very common question in support concerning GalSync is what are the permissions needed for the GalSync User Account to make GalSync work.  I have documented this information below to help understand what is needed for GalSync to work.

The GalSync User account is the account specified on the “Connect to Active Directory Forest” tab in the GalSync Management Agent Properties.

Contents

Provisioning to Exchange 2007. 1

Provisioning to Exchange 2010. 1

Multiple Domain Controllers. 2

Permissions required for Source Container(s). 2

Permissions required for Target Container(s). 3

Additional Information. 3

 

Provisioning to Exchange 2007

The GalSync User must be a part of the Exchange Recipient Administrators group.  The GalSync user must be a part of this group, in order to run the Microsoft Exchange PowerShell CmdLet Update-Recipient.

NOTE: Information from the Update-Recipient Page.

To run the Update-Recipient cmdlet, the account you use must be delegated the following:

  • Exchange Recipient Administrator role

For more information about permissions, delegating roles, and the rights that are required to administer Exchange 2007, see Permission Considerations.


The Update-Recipient PowerShell CmdLet updates an exported mail-enabled contact object so that it can be seen in the GAL.

Software Requirements

è You must install Windows PowerShell v1.0

è You must have the Microsoft Exchange Server 2007 Management Tools Service Pack 1 or later (preferred Service Pack 3) installed on the Synchronization Service Engine machine). 

  • The reason for this is that the PowerShell CmdLet Update-Recipient is installed with Service Pack 1 or later.  This is a local call to Update-Recipient, which is the reason we need the Exchange 2007 Management Tools installed on the Synchronization Service Engine machine.

Provisioning to Exchange 2010

The GalSync User must be a part of the Organization Management Exchange Security Group.  Again, the GalSync user must be a part of this group, in order to work with the Microsoft Exchange PowerShell CmdLet Update-Recipient

Please note the requirement for Organization Management is an Exchange 2010 Required permission.  In order to Test PowerShell, or view the settings of the PowerShell VDIR in Microsoft Exchange 2010, you must be part of the Organization Management Exchange Security Group.  More information click here.

Provisioning to Exchange 2010, we now utilize WinRM and PowerShell v2.0 to update the mail-enabled contact objects that we export so that they can be seen in the GAL.

In order for us to remotely call the Update-Recipient CmdLet, we need to know where the Microsoft Exchange 2010 Client Access Server is located.  Review this article to help locate the Exchange 2010 Client Access Server.

Software Requirements

è Windows PowerShell v2.0 and WinRM (download knowledge base article)

  • In Windows Server 2008 R2 this is a Feature that you can install.

 

Multiple Domain Controllers

If you have multiple domain controllers in the forest that you are working with in the GalSync solution, then you need to ensure that the GalSync User account has the Replicate Directory Changes permissions.

If the GalSync User account does not have these permissions, then you will receive connection problems when creating a management agent, or when attempting to execute an import or an export to the forest in question. 

How to grant “Replicating Directory Changes” permission for the Microsoft Metadirectory Services ADMA account

Permissions required for Source Container(s)

A source container, are the containers (Organizational Units) to where the Mail-Box Enabled User object is located, or the Authoritative Mail-Enabled Contact Object.  GalSync writes an x500 address back to the source object for reply-ability purposes.  The GalSync User Account will need “Write ProxyAddresses” on the source objects.  Please find below the steps to grant “Write ProxyAddresses” permissions. 

*Note: We will use ADSIEDIT in order to make these changes.  ADSIEDIT is part of the Windows Support Tools.  You can find them on the Windows Server Setup CD under \support\tools, or you can download them from here.  Windows Server 2008, they are a feature that you can install.*

  1. Start > Run and type ADSIEDIT.MSC and then click ok
  2. Navigate to the first source container (source organizational Unit)
  3. Right click and select Properties
  4. Select Security
  5. If the GalSync User exists then move on to step #6.  If the GalSync User does not exist, then you will need to add it via the following steps:
    1. Click Add
    2. Enter the alias (sAMAccountName) of the GalSync User account, and click Check Names to allow the account to resolve.
    3. Click the Ok button
  6. Click the Advanced Button
  7. Select the GalSync User Account in the list of account names on the Advanced Tab
    1. Click the Edit button
    2. Click Properties
      1. Apply Onto: Child Objects Only (or All descentant objects if using 2008 or later)
      2. Ensure that Write proxyAddresses contains a check for Allow (it is about ¾ to 5/6 of the way down)
      3. Click Ok
    3. Click Ok and Ok again

*NOTE: This permission will be applied to every child object whose “Allow inheritable permissions from the parent to propagate to this object and all child objects”
option is selected. This is located in the user’s Advanced Security property sheet. Any user that does not have this selected will not have the permissions
granted to it.

Permissions required for Target Container(s)

In a GalSync solution, the Synchronization Service Engine uses the GalSync user account to create a mail-enabled contact object.  You could give the GalSync User account Full Control to this container (Organizational Unit).  However, if you need to control permissions, you can set the following permissions to allow GalSync to work successfully.

  1. Start > Run and type ADSIEDIT.MSC and then click ok
  2. Navigate to the target container (target organizational Unit)
  3. Right click and select Properties
  4. Select Security
  5. If the GalSync User exists then move on to step #6.  If the GalSync User does not exist, then you will need to add it via the following steps:
    1. Click Add
    2. Enter the alias (sAMAccountName) of the GalSync User account, and click Check Names to allow the account to resolve.
    3. Click the Ok button
  6. Click the Advanced Button
  7. Select the GalSync User Account in the list of account names on the Advanced Tab
    1. Click the Edit button and ensure that the following permissions are selected
    2. Apply onto: This Object and All Child Objects
      1. Create permissions
      2. Delete permissions
      3. Read all properties
      4. Write all properties
  8. Click Ok and Ok again

Additional Information

GalSync Resource Wiki

 

Leave a Comment
  • Please add 8 and 3 and type the answer here:
  • Post
Wiki - Revision Comment List(Revision Comment)
Sort by: Published Date | Most Recent | Most Useful
Comments
  • Tim Macaulay edited Revision 5. Comment: added a link to exchange documentation that talks about the organization management

  • Jeff Ingalls [MSFT] edited Revision 4. Comment: Updated Exchange 2010 security group name

  • Tim Macaulay edited Revision 2. Comment: added a note with a snippet from the Update-Recipient Page

Page 1 of 1 (3 items)
Wikis - Comment List
Sort by: Published Date | Most Recent | Most Useful
Posting comments is temporarily disabled until 10:00am PST on Saturday, December 14th. Thank you for your patience.
Comments
  • Good article Tim.

  • Tim Macaulay edited Revision 2. Comment: added a note with a snippet from the Update-Recipient Page

  • Jeff Ingalls [MSFT] edited Revision 4. Comment: Updated Exchange 2010 security group name

  • Tim Macaulay edited Revision 5. Comment: added a link to exchange documentation that talks about the organization management

Page 1 of 1 (4 items)