Hi,

We recently setup a 2 way trust between 2 of our domains. We needed this change to be reflected in SharePoint, so I have modified UPS to cater this. The newly added UPS connection has been able to find/locate and add the new users into our new domain using the Profile Synchronisation service. I then ran a crawl and made sure the people scope was the same as the UPS user count. (Which it was)

What I am struggling with now is the authentication of the newly added users. I am trying to hit the SharePoint web app (intranet site) but it doesn't seem to be authenticating the account. I receive the username and password box on repeat. Also noticed that users were not populated in the Site Collection user list but I believe from memory these users are only added once they hit the web app successfully?

I have also added the intranet site to trusted sites and still nothing.

So, is there a step or something I have missed out on here??? Or could it be a security group setting or something similar when the 2 way trust was conducted? I didn't setup the 2 way trust as I'm just the SharePoint monkey but if there is something security group related between the two domains that could be the cause of this issue it would be good to know so i can pass it on.

Many thanks

• Edited by Luca Sanchez Wednesday, March 13, 2013 3:36 AM

Hi Trevor,

No the particular web app in question on the new domain is NTLM

DNS is configured on the new domain to cater for the web app address. I dont think it is setup old on the older domain actually

No I cant Trevor, the new added users aren't in the site collection as yet hence why i asked the below in the initial thread

Also noticed that users were not populated in the Site Collection user list but I believe from memory these users are only added once they hit the web app successfully?

As for the previous question in relation to the DNS settings .. i asked our network guys and they mentioned something about utilising the DNS forwarding feature.

You have to add them via the People Picker before they'll have access to the site.  Are you able to find the users via the People Picker on the target site?

DNS forwarders are fine, as long as it is configured properly.

This can be caused by a few different issues.  You may have a People Picker property set on the Web Application/Site Collection which restricts access to a particular OU (or in some cases, domain).

It could also be a port issue.  The SharePoint servers need access to specific ports.  I built a tool to help test this.  You should run this from the SharePoint server(s):

http://peoplepicker.codeplex.com/

It could also be a port issue.  The SharePoint servers need access to specific ports.  I built a tool to help test this.  You should run this from the SharePoint server(s):

http://peoplepicker.codeplex.co

"A referral was returned from the server" is at least a problem, if not the problem.  You should instead see a list of "CN=<name>,..." in there.

This typically happens when you ask for an object that the target directory doesn't host, but knows where to find it.

By default, SharePoint won't do referral chasing.

http://support.microsoft.com/kb/967612

Interesting, ok I think I put the wrong credentials using the dom/user and password lol. I will sort that out, my bad

I ran the following command in the interim and found the property is actually set to no

stsadm.exe -o getproperty -pn Peoplepicker-searchadforests -url <Address>

Presume I would need to run the setproperty command with the password?

That property is only used for Web Applications and is only typically used in one-way trust scenarios.  The UPS won't use that property.

To set the password needed for that property, you would use:

stsadm -o setapppassword -password Somepasswordvalue

Ok so I am seriously confused now haha. I do need to use that stsadm command to set the password or not? I have read it shouldnt be done for a 2 way trust but there are examples of it in here where people have had to do it?

Sorry to be a pain Trev but could you just point out what steps i need to do to resolve this.

Thanks again

• Edited by Luca Sanchez Tuesday, March 12, 2013 12:57 AM

So you have to run:

stsadm -o setapppassword -password Somevalue

In order to secure the username/password used in:

stsadm -o setproperty -pn peoplepicker-searchadforests -pv "forest:localforest.com;remoteforest.com,username,userspassword" -Url http://webAppUrl

But you should not have to do that for a two-way trust.  I've seen it solve some people's problems as well, but those should be rather unique or incorrectly configured to require this solution.

Thanks for that. Will give it a shot and post back.

FYI though. I ran your port tester app again and received the results as expected under the LDAP test but i used the Local Forest LDAP details and user details. Previously I tried to connect to the Remote Forest with the details and that's where it fell over.

Sorry for my ignorance but which account and what forest should I be looking up here? Just to be sure :)

Once again, thanks ..

In the command above?

localforest.com == the forest the SharePoint server resides in.

remoteforest.com == the forest you've established  a two-way trust with, then a username and password from that forest (note do not specify the domain with the username (e.g. dom\user), just the username).

• Edited by Luca Sanchez Wednesday, March 13, 2013 12:49 AM

Sorry to bring this up again Trev .. but ive been researching the whole thing and can see its a bit of a widely spread issue! It's really doing my head in now :(

I noticed running your port tester with my local forest details that port 137, 138 and 139 are not connecting. These I believe are the RPC ports. It hasnt connected to 749 and 750 either but I am not using kerb so I dont think I need to worry about it?

Do I need to add all of these ports in the windows firewall to allow access for the people picker? If so, are they outbound rules?

• Edited by Luca Sanchez Wednesday, March 13, 2013 1:32 AM

Yep, those would be RPC ports.  These are only outbound connections, however.  With the default configuration, the Windows Firewall shouldn't impact the results.

You should be OK with that configuration.  Next step may be to run a NetMon trace on the SharePoint Server making the People Picker call.

Yep, those would be RPC ports.  These are only outbound connections, however.  With the default configuration, the Windows Firewall shouldn't impact the results.

You should be OK with that configuration.  Next step may be to run a NetMon trace on the SharePoint Server making the People Picker

You would run NetMon 3.4 on the SharePoint server while a client accessed SharePoint and attempted to resolve a user from the remote domain in the People Picker.

If you'd like, I can help you via email with the results of the page.  On my blog link below, you can send me an email via the Contact page.

Just have to commend Trevor on helping me with this issue offline. I pretty much drained him with every possible scenario possible as to why this wasnt working for me but he pointed me in the right direction every step of the way.

The simple answer was the SP service account required 'Allow to Autenticate' on the DC it was trying to communicate with. Was receiving a tonne of Kerberos errors and he replicated the scenario in his environment to assist. Cant thank him enough!!!

• Marked as answer by Luca Sanchez Wednesday, March 20, 2013 5:27 AM