2

Our current situation:

  • our farm contains two DCs, one SP 2010 and one EX 2010 server
  • the SharePoint is running fine
  • the User-Profile-Synchronization-service is up and running, AD-imports are done well

What we'd like to do:

  • export user-object-data into the AD (f.e. thumbnailPhoto)

What we've done:

  • we added all permission-requirements to the syncing system-user-account (write objects, create objects, replicate directory and pre-win2000-access)

What happens:

The export of objects fails on admin-accounts. An investigation with the "Synchronization Service Manager on SP" (miisclient.exe) shows a "completed-export-err" during the "DS_EXPORT". A dig in tells us "Error: permission-issue", the permissions are not sufficient.

What do we need to do, to set the AD-permissions of the sync-account up, to be able to write attributes of our administrative-user-accounts?

Florian Neumann
  • 123
  • 7
  • I had a similar problem with BES a while back, turned out to be an inheritance issue - I ended up using ADSIedit to enable inheritance of permissions to the affected admin accounts, and that cleared it up. – HopelessN00b Jun 20 '12 at 10:37
  • Uhm.. i'm pretty sure i enabled inheritance but you may be right.. I'll try to test that in the next few hours. Thanks.. :) – Florian Neumann Jun 20 '12 at 11:18
  • Are you able to sync your Admin-accounts (exporting stuff to their AD-objects)? – Florian Neumann Jun 20 '12 at 12:23
  • Did you modify the scheme-configuration to allow inheritance and if so, which scheme did you modify? – Florian Neumann Jun 20 '12 at 12:31
  • No schema modification. Open ADSIedit, "Domain" node, navigate to whatever user, right click for properties, go to the Security tab, and in the pop up, you should be at the Permissions tab. Right below the lsiting of permissions, there should be a tickbox and some text that says "Inherit from parent the permission entries that apply to child objects. Include these with entries explicitly defined here." Tick the box. (At least, that's what solved my problem. You also need to set the object's "admincount" attribute to 0 in the attribute editor tab, or the changes might revert. YMMV.) – HopelessN00b Jun 20 '12 at 12:52
  • We already checked inheritance at our first approach. Admin-objects aren't affected by non-admin-users. There's where inheritance ends. – Florian Neumann Jun 21 '12 at 11:42

1 Answers1

0

For now we decided to solve the "problem" with a workaround, by adding extra user-accounts for each administrator.

Why we're doing that? At first, i'd like to pint out, that i have some pain with adding extra administrative permissions to the export-service-account. It seems to be a bad idea to grant this account such great power over the active-directory, to even manipulate admin-accounts in general. Another way could have been to adjust the "administrative flags" which seem to prohibit changes on admin-objects in general (unless an admin is the manipulator). I guess this also a bad idea, since this would grant the service full power to admin-accounts too and we might affect additional services, which rely on these flags for proper functionality.

Since we made this decision now we have to migrate the farm-status to the "new" situation. This is not that trivial, that's why i'd like to share our current workflow, for the case somebody has to do the same:

Creating additional user-accounts for an admin in a SharePoint/Exchange-Farm (if you were working with administrative accounts before)

This solution aims at transferring the admin-username to a new and normal user-object.

  1. Add filter-rules to your user-profile-synchronization-connection (sorry - translated from German), which avoid the synchronization of the "new" admin-accounts. It seems to be a good idea, to rely this ruleset on the attribute adminCount being greater or similar to 1.
  2. Rename the admin-account and login-name to a "new" naming-scheme for admins.
  3. Create a new user-object following the preferred naming-scheme for users.
  4. Disconnect the exchange-mailbox of the administrator. Be careful to not delete the belonging AD-account incidentially by removing the mailbox!
  5. Create a new exchange-mailbox for the new user (i advise to do this only if the mailbox wasn't in use before). Alternatively you might try to reconnect the admin-mailbox to the new user. Which didn't work in our installation so far.
  6. Check the correct synchronization-status of the specific profile within the user-profile-synchronization-service, you probably have to delete the "old" user-profile of the admin, to let the profile-service correctly reconnect to the new user.
  7. Do not forget to assure the correct authorization-levels in the SharePoint websites.
Florian Neumann
  • 123
  • 7