We have a one-way trust between our SharePoint domain and an external domain. We would like to have users from the external domain be able to access our SharePoint portal. We also want tobe able to search for those externalusers in the people picker.I read about the stsadm commandpeoplepicker-searchadforests. Would this be the solution to the two issues I mentioned or do I need to also import the profiles from the external domain?? Any help is greatly appreciated. Thanks

John-Great question. You are definately on the right track. There is a "gotcha" waiting for you right around the corner though.You are correct that you will need to import the users from the external domain. The "gotcha" is that in order to set up the import - the trust will have to be a 2-way trust at the time the import is configured. Once the import is configured you can drop the trust back to a one-way trust.At this point - you will need to use thepeoplepicker-searchadforests command so that the people-picker will see the users in the external domain.Hope this help-Jeff DeVerterRackspacewww.social-point.com

So what happensif I just use the peoplepicker-searchadforests command without importing the profiles from the external domain?

JohnXO, what do you plan to do with those user profiles internally? Won't they get in the way when your internal users go to add permissions or choose users in People Pickers and they see a whole slew of people that don't have access to the internal side of SharePoint? Your external users are going to access your SharePoint environment by you putting WFEs in the external domain. You don't want them to come inside your domain, because that would require a 2-way trust all the time (or one-way the wrong way). If you put WFEs in the external domain with a one-way trust where the external domain trusts internal, then you could keep your external users only in the external domain, but your internal users would be able to interact with them. You could extend a web application if you plan to expose your internal data/sites, or you could create a separate web app only exposed externally that both internal and external users can get to.SharePoint Architect || My Blog

Clayton,I might have used the word "externally" loosely here. What I meant by external here was the "other" domain and not the domain used by SharePoint.Lets call the SharePoint domain Domain A, and the other domain Domain B. There already exists a one-way trust between them. Now sometimes we get requests from people in Domain B wishing to access certain SharePoint sites in Domain A. In order for that to happen now, we are creating for those users actual Domain A active directory accounts in order for themto access SharePoint. We want to get away from that and instead have those users continue using their day-to-day Domain B active directory accounts to access our SharePoint site.What are my (best) options in a one-way trust as is now??Thanks Clayton

Then A has to trust B, and then your B users can be given permissions to sites in A. No one in A will be able to do anything in B.SharePoint Architect || My Blog

So if A trusts B, I would then need to import the profiles from B into SharePoint inorder for those users to access SharePoint sites, is that correct?

They should be recognized by SharePoint before doing a profile import and will be added to the profile database when called up with a People Picker as long as the domain is trusted.SharePoint Architect || My Blog

I am still confused between a regular profile import and the people picker command.If I simply run peoplepicker-searchadforests on my SharePoint WFE, would that provide me with access to the Domain B users where I can begin adding some of those users to SharePoint sites? Or do I need to also do a full import of the profiles????

Clayton Cobb mentioned that, you need not to import the profile from one-way-trusted domain. The people picker control would search the user in AD and it is a security matter and do not related with Profile Import. Hope the information can be helpful. -lambertSincerely, Lambert Qin | Microsoft TechNet Managed Forum Support Posting is provided "AS IS" with no warranties, and confers no rights.

Ok, people picker is the easy part... its the Profile import that i'm more interested in. if one does not have control over setting the trust level between forests what other options are there? Current configuration is a one way trust, security works, but profile import fails as it can not contact DCs. any help would be appreciated :-) thanks, -m

Hey Jeff, I'm confused. We only have a one way trust set up and was able to successfully import the profiles, however we cannot get the users to show up in the people picker even setting the peoplepicker -searchadforests property. A is our SharePoint Farm B is our corporate domain A trusts B B does not trust A In the SharePoint Farm (domain A) I imported the users profiles for B by creating a custom import and specifying credentials for an account in B. The load went fine.. all 5000 user profiles from B are in A. Now... how do I get those profiles to show up in the people picker? Do I need to somehow pass credentials for B when doing: stsadm.exe -o setproperty -pn peoplepicker -searchadforests etc.... Definitely not my area of expertise, any help is much appreciated.

Sorry to jump in but we're having the same issue: our SharePoint Farm is in domain A wich has an external trust to our Corporate domain B A externally trusts B B does not trust A In the SharePoint Farm (domain A) I imported the users profiles from B by creating a custom import and specifying credentials for an account in B. Worked. when I run stsadm.exe -o setproperty -pn peoplepicker -searchadforests -url http://localhost the command prompt returns command successful but I still cannot resolve external domain users from the people picker. As a further side note we also have SQL 2008 R2 RS (Native Mode) running on the same box and are able to add external users from domain B with no problem. They can access SQL Report Manager externally so the trust is working just not resolving in ShrePoint peoplepicker. Any ideas are greatly appreciated, Perry Neal

Mark & Perry - I had same issue and had been working with MSFT guys and they had pointed out an article as shown in below. The MSDN article states that if the customer has more than one domain, there is need of "TWO-WAY forest trust" between the two domains. http://msdn.microsoft.com/en-us/library/ee384252.aspx If the customer has more than one domain, verify that the SharePoint and Reporting Services service accounts and the user accounts accessing SharePoint are in domains that have a two-way trust between them. If there is only a one-way trust, there will be problems authenticating users and resources from both domains. Smith

Thanks for the quick response. Problem is this is actually running in the gov world and a 2 way trust will never happen... Never. As another side note I did have this working prior on Win Sev 2003 (different subnet but same domain by accident not design... it just always worked from first install) Then when we moved to a more secure Win Ser 2008 the same one way trust now only resolves SQL RS. I'll have to keep troubleshooting with the AD and network folks. Maybe a GPO or Firewall issue stoping the read from external AD resource. Any ideas on how to make this work with the one way external trust is again greatly appreciated. Thanks, Perry Neal After playing around I was able to create a import connection to the external owe-way trust using the default settings in SSP users and porfiles. After importing the external trust profiles, I selected the add all athenticated users to the root site members list (NT AUTHORITY\authenticated users) also adding to each site needed. Then each external user was able to log into the sites from the external domain with there external domain username and password after which I noticed cooresponding users profiles were automatically added to the site. While this solution is not pretty IT WORKS FOR NOW! (Note: after all the users were added we removed the NT AUTHORITY\authenticated users from the sites)

Hi, The NT AUTHORITY\authenticated users seems like an elegant and correct solution to this problem. Why would you then remove that group from the sites? It seems like having it there would just let you add new users as they become available; otherwise, if you add new users to the external domain, you'd have to do this set up again and again. Also, I've seen a lot of discussion about importing profiles. How is that done?

Hello Clayton, From reading your post here maybe I am going about this all wrong. My SharePoint server is and has always been on the same internal network as my user domain. Now we want to allow "trusted" external users (our subcontractors) access to a couple of sites on our farm. I had been using ECTS to accomplish this but Per someone elses advice I created a second domain for the external users so I placed the 2008 domain controller (with a DNS role as well) in an external network. From there I added forwarders to the DNS in each domain and setup a 1-way trust where the external domain trusts the internal domain only. I configured the custom import in shared services which imported my two test users from the external domain but have had absolutely no luck with the peoplepicker-searchadforests after setting the stsadm setapppassword. The 2008 DC I placed in the second domain is not a WFE. Any suggestions / guidance would be greatly appreciated!Dave Schafer

I have this situation almost to a 'T', except that a one way trust is working between a WSS 2007 server in an external domain with a one way trust to the internal domain. We're running a new instance of Sharepoint Foundation against a 2003 AD server that is authenticating across the DMZ on a one way trust. Users can be added via the people picker on a working WSS server, but 'peoplepicker -searchadforests' has not produced a positive result on our 2008 server running Sharepoint foundation. Any help would be appreciated!

Hello, I am having the same problem as dataman, and currently have an open ticket with Microsoft regarding the peoplepicker stsadm command not resolving the user from the remote domain. I have actually been forwarded over to Enterprise Support from the Sharepoint team. Baffling to me that this works correctly in all earlier versions, and the account we are using to specify the stsadm command is able to query the remote domain locally from the server and add any user from the remote domain. Has anyone been able to import users from a remote domain into a site collection easily?

Hello, I am having the same problem as dataman, and currently have an open ticket with Microsoft regarding the peoplepicker stsadm command not resolving the user from the remote domain. I have actually been forwarded over to Enterprise Support from the Sharepoint team. Baffling to me that this works correctly in all earlier versions, and the account we are using to specify the stsadm command is able to query the remote domain locally from the server and add any user from the remote domain. Has anyone been able to import users from a remote domain into a site collection easily?