SharePoint Logon & Resource AD Connections


People with a keen eye for identity management may have noticed that there are three types of Active Directory connections for profile synchronisation; normal “Active Directory”, “Active Directory Logon Data” and “Active Directory Resource”.

Here’s the different types of AD connections in the User Profile Service application:

clip_image002

You may be wondering what the difference is between them. The first one is a standard import connection; the other two are for when the login & resource accounts are stored in separate domains.

When Two Accounts Become One with msDS-SourceObjectDN

It’s possible to have x1 logical user spread over x2 domains/forests. In one domain you keep login objects and in the other domain you keep the user metadata (resource data); full-names, telephone numbers, addresses, etc and just link from the resource-data to the actual login object.

This is done with the Active Directory property “msDS-SourceObjectDN”. Why would you do this? Good question; it’s not common but some organisations like to separate out login/authentication data to user metadata – updates to both are not equally as important as you can imagine.

While it’s true you can secure a single domain to the same effect, it can be preferable to separate the security rules into entire different logical containers at the forest level. AD property msDS-SourceObjectDN is just a way of tying back together the two accounts for systems like SharePoint/Exchange/Lync to then merge at the application level.

It’s also common to have the resource account disabled too – we only want the resource account for its’ metadata but not to actually login with.

image

“Logon” domain is highly restricted/audited for updates; “resources” domain less so because it’s just for metadata.

 

SharePoint Usage of msDS-SourceObjectDN

So in my test I have two domains; “testusers.spm.local” (NetBIOS name “TESTUSERS”) where I have a user called “Bob” and “sps.spm.local” (NetBIOS name “SHAREPOINT”) where I have a login called “Bob”.

“SHAREPOINT\Bob” is how Bob will login, but all his personal data is in “TESTUSERS\Bob” (which is disabled). We want SharePoint to import it all into one profile.

First we need to link “SHAREPOINT\Bob” to the “TESTUSERS\Bob” object.

Link Resource Account to Login Account

To link the account you need to edit the property “msDS-SourceObjectDN” for resrouce account “TESTUSERS\Bob” with a link to the login object:

clip_image005

Use your tool of choice for this of course. ADSI Edit works just as well.

Just to prove this works, here’s the SHAREPOINT\Bob account:

clip_image007

…void of all data in the logon domain.

Create AD Connections in SharePoint User Profile Application

Next up we need to configure two AD connections in SharePoint UPA; one to each domain. Remember to select the right type of connection for each one. When you’re done it should look something like this:

clip_image009

Pay no attention to the “source” column – the SharePoint domain really is pointing to sps.spm.local and users to testusers.spm.local – I frankly don’t know why SharePoint shows it like that, although both domains are sub-domains in the same forest.

Run Profile Synchronisation

From SharePoint start a new full synchronisation and wait for it to finish. Once it’s done, in the FIM client you’ll be able to see the object:

clip_image011

…populated with all sorts of data. In SharePoint you’ll see:

clip_image013

It’s as if all the data comes from the SharePoint/logon domain, but it doesn’t.

 

Wrap-Up

This AD property doesn’t affect authorisation of the accounts; the security doesn’t change in any way. It’s purely for metadata.

It’s rare to really need to do this, but at least this clears up why the different types of connections exist. Credit to my good colleague & friend Jesus Fernandez Saez for the help in this!

 

Cheers,

// Sam Betts

Comments (3)

  1. Emmanuel ISSALY says:

    really nice find, as that configuration occurs quite often. If i follow right, it would lighten the load on the "USER" DCs, because properties would be pulled from ressource. The thing is, it needs a “msDS-SourceObjectDN” mapping for each user, which i'm not sure you'll be able to get from the customer's AD team 🙂

    That said, it is usually simplier to sync to the USER domain, as the incremental sync is not that heavy to bear.

  2. Yep that's right; the "users" domain would really only be used for metadata & not authentication.

  3. Chris says:

    what about peoplepicker? Disabled users will not available by design i guess.

Skip to main content