Step by Step – Configuring ADLDS User Profile Synchronization in SharePoint 2010

Note: Download artifacts discussed in this article from Here.

First of all, bad news – SharePoint 2010 doesn’t support importing user profiles from the ADLDS (Active Directory Light Directory Services) out of box. Even though ADLDS has been widely considered as best practices to host SharePoint 2010 extranet user accounts, it is odd that SharePoint 2010 doesn’t support user profile sync from ADLDS out of the box. What I have seen and heard that even SharePoint 2013 FIM & User Profile Sync doesn’t support ADLDS user import out of the box either. I haven’t tested these steps in SharePoint 2013 but it would be still relevant in SharePoint 2013 time frame as well.

Now, Good news – Well, great news is Microsoft hasn’t closed all the doors for us. You can export ADLDS users in Lightweight Directory Interchange Format (LDIF) file and synchronize both users and group information from LDIF file in SharePoint 2010 User Profile store using User Profile Sync Service.

TechNet has great starting point if you want to configure user profile sync from any LDAP directories not supported by SharePoint out of box using FIM & User Profile Sync service. The problem with the TechNet article is its not complete, it’s vague, and assumes many things like security, permissions, tools required etc. and doesn’t provide detailed step by step details for end-to-end process. That’s where this article comes in.

This article will provide detailed step by step instructions on how to configure profile synchronization using LDIF file export from ADLDS in SharePoint 2010 to import users in SharePoint User Profile System. If you are looking for detailed step by step guide with lots of screenshots, you can download step by step PDF guide and supported files demonstrating same steps discussed in this article from my SkyDrive account.

Step 1 – Configure Pre-requisites

  • Ensure that Farm is running either the Standard or Enterprise version of SharePoint Server 2010 and you have run the farm configuration wizard. Profile Synchronization does not work on a single-server installation of SharePoint Server 2010.
  • Ensure that an instance of the User Profile service application exists and is started.
  • Ensure that User Profile Synchronization Service and FIM have been provisioned on the server where you plan to synchronize profile information from an LDIF file. Please note that there is no need for AD Synchronization configured for the ADLDS Profile Imports. Plan to use Spencer Harbar’s Rational guide on User Profile Synchronization for this configuration.
  • Ensure that ADLDS instance has already provisioned and ADLDS users are already created. This article is extension of one of my previous article where I have documented step by step process of how to install and configure ADLDS, populate ADLDS users, and configure form based authentication with ADLDS in SharePoint 2010. Plan to use my guide for ADLDS configuration.

Step 2 – Create a Management Agent for ADLDS using SharePoint Server Synchronization Services Manager

  • Download this config file from Microsoft to use as a starting point –, I have also attached this config file from Microsoft in Zip file in my SkyDrive location.
  • Open the synchronization service manager by browsing to C:\Program Files\Microsoft Office Servers\14.0\Synchronization Service\UIShell and double clicking the miisclient.exe.
  • Once open, click the “Management Agents” tab near the top. Under actions, click “Import Management Agent” and select the config file you just downloaded from Microsoft.

1-Import Config File

  • On the Create Management Agent page type a name in the Name field. The name must begin with “MOSSLDAP-” and ends with “-LDIFMA”, for example, MOSSLDAP-NIKSADLDS-LDIFMA. Optionally, type a description. Click Next.


  • On the Configure Attribute page of the wizard, delete all the attributes. Add five new attributes by clicking “New” => userPrincipalName, sn, givenName, displayName, and mail, and Click the “Set Anchor…” button and check the checkbox as seen below to use the distinguished name (dn) as the anchor attribute.

3-Custom Attributes

4-Set Anchor

  • Now click next to progress to the next section of the wizard, “Map Object Types”.  Delete the group entry so all you’re left with is the user Object class as seen below.

5-User Object

  • Click Next to move to the Define Object Types section and click edit to get the screen below to make sure userPrincipalName is required field during import.

6-Required Property

  • Click next repeatedly to progress through the wizard until you get to the Configure Attribute Flow section as seen below.
    • Delete Group object.
    • Expand the User object and select Metaverse Attributes that are not listed below and click the New/Edit/Delete or edit button one by one to update mappings as following screen.
    • Please ensure that userPrincipalName is mapped to the sAMAccountName. This will populate AccountName in SharePoint User Profile. If you need any other ADLDS attribute (e.g. mail), map that attribute to the sAMAccountName for some reasons, this is where you will make change. In this example, we have configured userPrincipalName as required field earlier and we will use userPrincipalName to map sAMAccountName.
    • Additionally configure all other attributes to map additional ADLDS user object properties to Sharepoint user profiles. E.g.
      • sn (Datasource attribute) – sn (Metaverse attribute) for lastname
      • givenname (Datasource attribute) – givenname (Metaverse attribute) for firstname
      • displayname (Datasource attribute) – displayname (Metaverse attribute) for full name
      • mail (Datasource attribute) – mail (Metaverse attribute) for workemail

7-Mapping fo Attributes

  • Click Next few more times to complete the wizard. This completes the management agent configuration for ADLDS
  • Next, you need to create and ldif export file, use the instructions below to create the file.  Once the file has been created you can start a profile synchronization from central admin.

Step 3 – Enable LDIFDE Utility to Create LDIF Export

  • To enable command line export of AD LDS data you need access to the LDIFDE utility add the AD LDS Snap-Ins and Command-Line Tools feature in Windows.  Please note that this is only necessary if you are not running the AD LDS on the same machine. Enabling AD LDS will already install this feature.

8-LDAP Utility

Step 4 – Prepare for LDIF Export and run Test drive

  • You need to ensure that you have proper rights to AD LDS for LDIF export to work. At minimum, you would need read rights.  Add the service account to the Reader Role in AD LDS under you plan to run the LDIFDE utility.  This is done by adding the user to the member attribute in the Reader role object in AD LDS as seen below in the ADSI Edit tool.  Add Two Accounts as a reader => Account you login to the server run LDIF command in future steps in this document and Account which runs User Profile Sync Service. Visit your central admin and make note of User Profile Sync Account. In my VM, both accounts are => Niks\Administrator. If your Service runs under different account and you login to the server to run LDIF with different account, add both accounts as reader.

9-Permission in ADLDS

  • You need to also ensure both accounts – Account You login to the server to run LDIF command in future steps in this document and Account which runs User Profile Sync Service – Niks\Administrator has proper rights to access to the directory created for the AD LDS connector => C:\Program Files\Microsoft Office Servers\14.0\Synchronization Service\MaData. If your Service runs under different account and you login to run LDIF with different account, configure both accounts’ security with full access.

10-Permission for LDIFMA

  • Once the LDIFDE utility has been installed, your service accounts have read access to the AD LDS and proper directory rights to import and export, you can run the following command from a command window from the command line to test the export-import of the ADLDS (ldifde.exe is in the system32 folder and is mapped as a local variable so you can run from any directory). Please note that do not change the file output name unless you change the connector’s configuration as the connector is preconfigured to look for a file named import.ldif in the connector’s directory.

ldifde -f “C:\Users\Administrator\Desktop\ADLDS\import.ldif” -s “SP2010VM.niks.local:52983” -d “CN=WPSCN,O=NIKSADLDS,C=LOCAL” -r “(objectClass=user)” -l “dn,changetype,displayName,userPrincipalName,mail,givenName,sn”

The command switches are described below (for more info on ldifde.exe see here): -f – this is the output directory, -s – this is the server and port to talk to your AD LDS instance, -d – this defines the scope to export (the top level container you want to export), -r – this is a filter to only allow user objects out (this may be different depending on your AD LDS schema implementation), and -l – this is a list of attributes you want exported (note that the objectClass is missing; more on that below)

  • To test the LDIF export, let’s visit ADLDS source to check how many users are in the LDAP directory. As shown below, there are 3 Users in the ADLDS

11-ADLDS Users

  • Run ldifde command to test the export, it will create the import.ldif in the export path specified in command.

12-Run the Export

  • You can validate that exported “import.ldif” file contains 3 ADLDS User Objects

13-Exported Import file

Step 5 – Create LDIF Export

  • Now, you are ready for LDIF export for SharePoint User Profile Sync. Once the file has been created you can start full user profile synchronization from central admin to import LDIF exported users in the SharePoint User Profile store.
  • By default AD LDS maps multiple object classes to your user objects. e.g. user object, inetOrgPerson etc.  To handle the multiple object classes in the import connector for SharePoint is quite complicated. It’s easier for us to simply use power shell to inject the missing objectClass attribute required by the User Profile Sync Service.
  • Run the power shell script below to create the import file in the AD LDS connector directory => C:\Program Files\Microsoft Office Servers\14.0\Synchronization Service\MaData and inject the missing objectClass attribute. You will need to update the file paths to match your configuration.  The tmp and stg paths are temporary file names and can be anything unique that doesn’t conflict with the profile synchronization connector:

$exportPath = "C:\Program Files\Microsoft Office Servers\14.0\Synchronization Service\MaData\MOSSLDAP-NIKSADLDS-LDIFMA\"

$tmpPath = $exportPath + "NikAdLdsExport-temp.ldif"

$stgPath = $exportPath + "NikAdLdsExport-staging.ldif"

$finalPath = $exportPath + "import.ldif"

ldifde -f "$tmpPath" -s "SP2010VM.niks.local:52983" -d "CN=WPSCN,O=NIKSADLDS,C=LOCAL" -r "(objectClass=user)" -l "dn,changetype,displayName,userPrincipalName,mail,givenName,sn"

if(Test-Path $stgPath ) { Remove-Item $stgPath }

#read the file created by the export 1000 lines at a time and ouput to a staging file

#if the line starts with the 'changetype:' then append the 'objectClass: user' line

(Get-Content $tmpPath -r 1000) |

foreach-object { `

Add-Content $stgPath "$_"; `

if($_ -like 'changetype:*') { Add-Content $stgPath "objectClass: user" } `


Move-Item $stgPath $finalPath -force

if(Test-Path $tmpPath ) { Remove-Item $tmpPath }

14-Powershell Script

  • Run Powershell script and it should create “import.ldif” in C:\Program Files\Microsoft Office Servers\14.0\Synchronization Service\MaData\MOSSLDAP-NIKSADLDS-LDIFMA. This is where User Profile Service will pick up user objects during next User Profile Sync job and import user profiles into SharePoint.

15-Import file in PROD

  • Notice import file contains objectClass. This is injected by PowerShell Script and required by User Profile Sync to import user profiles in SharePoint.

16-Final Import File

Step 6 – Run User Profile Synchronization to import ADLDS User Profiles

  • Run Full Profile Sync from SharePoint User Profile Administration Page to pick up users from C:\Program Files\Microsoft Office Servers\14.0\Synchronization Service\MaData\MOSSLDAP-NIKSADLDS-LDIFMA directory.
  • You should be able to click on Manage User Profiles to view the profiles imported.  To search enter “LDAP” to look up ADLDS user profiles. All 3 ADLDS User should show up.

17-User Profiles

Automate the Export

Last but not least step, in real world production environment, you probably wanted to automate the ADLDS profile synchronization process. One way to do it is automating ADLDS LDIF export using Windows Task Scheduler. Plan to run ADLDS LDIF export job at least 1-2 hours prior to User Profile Sync job kicks off to ensure all the ADLDS profile updates are synced to the SharePoint User Profiles.

Additional Resources

  • Synchronizing SharePoint profiles data from LDS – Excellent article explaining limitations of importing ADLDS using this approach and possible resolution to ensure user profiles are linked up with individual users logging into SharePoint using configured Trusted Identity Provider otherwise you have to manually map logged in user with ADLDS identity, In our case we had built HTTP Module to intercept incoming user to map logged in user to User Profile identity once user is authenticated through ADLDS provider using FBA –
  • Trusted Identity Providers & User Profile Synchronization for ADFS 2.0, it’s still relevant to ADLDS scenarios as well, this is explained in above link as well –
This entry was posted in Uncategorized. Bookmark the permalink.

17 Responses to Step by Step – Configuring ADLDS User Profile Synchronization in SharePoint 2010

  1. Is there an article on how to do this for MOSS 2007 and AD?

    • Nik Patel says:

      No, this is how you would do ADLDS in SharePoint 2010 and SharePoint 2013.. MOSS 2007 was direct AD import and it was really easy.. I am sure there are various articles out there..

  2. Hi,
    Ive done as you said in the article above.
    The problem I have is that once the Import.ldif is created and placed in the MaData location, I run the User Profile Import.
    The Import detects the users (after the sync has run it says 3 additions in the ADLDS-LDIFMA section of the import document),

    But I am still unable to search for the users in the UPS even though the import says its successful.

    Any ideas?

  3. Its ok. I have resolved this. silly mistake …
    You have to log in as that user for that user to appear in the UPS.

    The issue I have now is that the Fields are not mapped correctly.

    i.e. the Name property in the UPS is showing the Email address set in ADLDS for some reason.

    And the users First and Second name are not appearing at all in the UPS… Only the Account Name and Name, and both are appearing as email address?

    Any ideas?

    • Nik Patel says:

      Hi, I am really sorry, Not able to reply earliar. Being slammed here as I started my work at client..

      As far as mapping proper properties from ADLDS to SharePoint User Profiles, please check mapping property section on Configure Attributes flow step in LDIFMA file. That should decide which ADLDS property goes to which SharePoint User Profile property..

  4. Hi Nik,

    Many thanks for your reply.
    I have opened up the UI shell and modified the properties of the ‘Configure Attribute Flow’ step, but the issue persists.
    The userPrincipalName has a Metaverse Attribute of sAMAccountName
    displayName ——->displayName Type is Direct.
    givenName ——–> givenName Type is Direct
    mail ———————-> mail Type is Direct

    When the export ldif file, the file is created in the correct location, the file specifies all the values correctly, the user successfully imports in UPS, but the attributes just don’t match up.

    The Account Name in SharePoint is shown as ;:0#.f|fabrikammember|
    and the name is

    And they are the only fields imported… it appears that name and the Account Name is showing the mail for some weird reason as is the account name.

    Is there a setting in the web.config that needs modifying?

    because the mail attribute is what the users uses to sign into SharePoint 2013?


  5. Hi.
    Please could you send me example of the web.config?

    Also, I can sign into SharePoint without any problem with the mail attribute.
    The issue is just with the ADLS attributes not matching up with the SharePoint attributes.

    I have successfully populated the attributes in ADLS. When I export the users from ADLS, it produces the following LDIF file with the following users, indicating that the ADLS part is all filled in correctly.

    dn: CN=John Smith, CN=Users, CN=SharePoint, DC=Fabrikam, DC=local
    changetype : add
    objectClass : user
    displayName : John Smith
    userPrincipalName : John Smith
    givenName : John Smith
    mail :

    so the information is being pulled out of ADLS correctly, but sharepoint is unable to map these fields with the fields as below

    The userPrincipalName has a Metaverse Attribute of sAMAccountName
    displayName ——->displayName Type is Direct.
    givenName ——–> givenName Type is Direct
    mail ———————-> mail Type is Direct

    Any more ideas?
    I really need to get this to work asap please.

    Many thanks Nik

    • Nik Patel says:

      Hi, Sorry again.. Sounds like we work on different world clock..

      Can you send me what you have in your SharePoint User Profiles for John Smith in your example?

      Here is what it should look like..
      If you are logging in and authenticating with ADLDS using mail – your userid is
      If you trace incoming claims.. your claims will be for FBA… as ;:0#.f|ldapmember|, where ldapmember is your LDAP Membership in web.config file

      As far as SharePoint User Profiles, if you import user profiles from ADLDS in my method and if your userPrincipalName in ADLDS needs to be and map userPrincipalName in Metaverse as sAMAccountName. this would ensure Account Name in SharePoint User Profile would be something like Btw.. it may not be ;:0#.f|ldapmember|, Your goal should be matching both claims ID with SharePoint User Profile Account Name, You can use Powershell in ADLDS export file to ensure your account name is properly formatted.. This would link everything when users logs in.

      Let me know if this helps..

    • Nik Patel says:

      In our case, we didn’t care whether incoming user id and claims matches User Profiles account name because we didn’t have to provision my sites. If you are planning to provision my sites, you must ensure both incoming claims user id and User Profile account name are same (e.g. ;:0#.f|ldapmember|

      Also, do check out this link… it’s for ADFS but still relevant for ADLDS.. I didn’t go this far but this article may help you to fill gap.. Having said that, I should proof it out this one as well for complete closed loop.. and

  6. Hi Nik,

    I have noticed the following error appearing in the Event Logs
    The extensible extension returned an unsupported error.
    The stack trace is:

    “System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> Microsoft.Office.Server.UserProfiles.UserNotFoundException: A user with the specified SID could not be found in the domain. Check the spelling of the account name ‘JohnSmith’ and try again. —> System.ComponentModel.Win32Exception: No mapping between account names and security IDs was done
    at Microsoft.Office.Server.Utilities.Win32.AdvApi.LookupAccountName(String lpSystemName, String lpAccountName, IntPtr Sid, Int32& cbSid, StringBuilder ReferencedDomainName, Int32& cchReferencedDomainName, SID_NAME_USE& peUse)
    at Microsoft.Office.Server.UserProfiles.UserProfileGlobal.GetSidFromAccount(String strAccountName, SID_NAME_USE[] IntendedAccountType, SID_NAME_USE& sidUse)
    — End of inner exception stack trace —
    at Microsoft.Office.Server.UserProfiles.UserProfileGlobal.GetSidFromAccount(String strAccountName, SID_NAME_USE[] IntendedAccountType, SID_NAME_USE& sidUse)
    at Microsoft.Office.Server.UserProfiles.UserProfileGlobal.GetSidFromAccount(String strAccountName)
    at Microsoft.Office.Server.UserProfiles.UserProfileGlobal.GetSidFromAccount(UserProfileApplicationProxy proxy, Guid partitionID, String strAccountName, Boolean isWindowsAccount)
    at Microsoft.Office.Server.UserProfiles.UserProfile.set_SID()
    at Microsoft.Office.Server.UserProfiles.UserProfile..ctor(UserProfileManager objManager, String strAccountName, Hashtable properties)
    at Microsoft.Office.Server.UserProfiles.UserProfileManager.CreateProfileWithBulkProperties(Int64 importExportId, String strAccountName, Hashtable properties)
    at Microsoft.Office.Server.UserProfiles.ProfileImportExportService.UpdateWithProfileChangeData(Int64 importExportId, ProfileChangeData[] profileChangeData)
    — End of inner exception stack trace —
    at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
    at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
    at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
    at Microsoft.Office.Server.WebServiceDirectProxy.WebMethodInfo.Invoke(Object webServiceInstance, Object[] args)
    at Microsoft.Office.Server.WebServiceDirectProxy.Invoke(String methodName, Object[] args)
    at Microsoft.Office.Server.UserProfiles.ManagementAgent.ProfileImportExportDirect.UpdateWithProfileChangeData(Int64 importExportId, ProfileChangeData[] profileChangeData)
    at Microsoft.Office.Server.UserProfiles.ManagementAgent.ProfileImportExportExtension.Microsoft.MetadirectoryServices.IMAExtensibleCallExport.ExportEntry(ModificationType modificationType, String[] changedAttributes, CSEntry csentry)
    Forefront Identity Manager 4.0.2450.47”

    Can you spot anything obvious I have to do… It appears the user details are not even attempting to import because a user with the specified SID could not be found in the domain?

    Any ideas?

  7. Hi Nik.

    Thanks for your reply. Yes, im am based in the UK
    This is really annoying me.

    When I create a new user in ADLDS, I log into SharePoint, and I can successfully search for that user using the people picker (p.s I search for it using the email attribute). Once the ADLDS user is added into a SharePoint security group, That user can log into SharePoint. e.g. As soon as logs into SharePoint, an entry is created for that user in the user profile.
    The entry that is created in the UPS looks like as below.

    AccountName : i:o#.f|fabrikammember|
    First Name :
    Last Name :
    Name :

    All other UPS fields are empty.

    In ADLDS, the user John Smith has the following attributes.
    cn : John Smith
    displayName : John Smith
    distinguisedName ; CN=John Smith, CN=Users, CN=SharePoint, DC=Fabrikam, DC=Local
    givenName : John Smith
    mail :
    msDS-UserAccountDisabled : False
    name : John Smith
    sn : John Smith
    userPrincipalName : (I previously had this as John Smith)

    The Mappins in the miisclient are
    ————————-> distinguisedName
    userPrincipalName —–>sAMAccountName
    ———–> sps-oBJECTeXSISTS
    mail ——————————> mail

    When I run the powershell script, it creates a import.ldif file the MOSSLDAP-ADLDS-LDIFMA folder, and John Smiths entry looks like

    dn: CN=John Smith,CN=Users,CN=SharePoint,DC=Fabrikam,DC=Local
    changetype :add
    objectClass: user
    displayName : John Smith
    userPrincipalName :
    givenName : John Smith
    sn : John Smith
    mail :

    When I run the profile synch, the following error Is logged in the event logs.

    “System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> Microsoft.Office.Server.UserProfiles.UserNotFoundException: A user with the specified SID could not be found in the domain. Check the spelling of the account name ‘JohnSmith’ and try again. —> System.ComponentModel.Win32Exception: No mapping between account names and security IDs was done.

    So it appears, the users are not even attempting to import into the UPS because a specified SID could not be found.

    I don’t understand why it is doing this. Do I have to export additional fields from ADLDS into SharePoint, such as a ID?
    Failing this, are you able to give me a time to call you, (if possible) so you can look at my servers. I have two separate servers, for SharePoint 2013 and ADLDS?

    Many thanks.

    • Nik Patel says:

      Aha.. That makes sense..

      Let me explain where you can look into.. It seems like you have configured ADLDS correctly as a Form Based Claims provider. You are able to lookup user in people picker and login successfully. When you login successfully, SharePoint creates users information locally in that site collection.. it’s User Information List.. What you are seeing is user in User Information List, not in User Profiles… this is hidden list at the site collection level. site collection keeps local cache of all user information.. These user profiles you are mentioned might be stored in /_catalogs/users/simple.aspx, not in User Profile System.

      If you visit User Profile Application in central admin, I bet there are no User Profiles. SharePoint can’t create User Profile automatically unless you have written some custom code. It seems like the steps I have shown in this article are not correctly configured and you are having User Profile Import issues. I will check it out if I have documentation on importing users with email but process is pretty much same. Are you sure users in ADLDS have correct properties configured for FIM to access information? Check out if ADLDS users are not locked or User Profile Sync account has access to the ADLDS store.

      Your goal is ensure both incoming user log id should be same as User Profile Account Name property.. This will ensure you have complete closed loop to create my sites.


    • Nik Patel says:

      Let me what I said above is true, if yes, we can dig into more.. I will boot up my VM and send you more info if I can…

  8. Hi Nik. Thanks for the prompt reply.

    When I log into the UPS in SharePoint, I can see user profiles for John Smith, and all other ADLS users. But the information in SharePoint is only showing the account name and name, but the account name and name is showing as

    AccountName : i:o#.f|fabrikammember| and the name is showing as
    Name :

    Im not sure why these profiles are getting created in the UPS, but as soon as the user logs into SharePoint, the user is created in the UPS.

    I was hoping that when the import run, the correct information would override it somehow. Im not sure.

    All I know is that
    a) the user information for that user is not mapping correctly in UPS
    b) When I run an import, and error is logged . “A user with the specified SID could not be found in the domain”

    The ALDS users not defnantly not locked. Which properties do I have to check in ADLS to ensure FIM to access the information?
    I have added the UPS services and import account into the readers group in ADLDS, so I assume the ups account has the correct permissions to adlds.


Leave a Reply to Nik Patel Cancel reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s