Today's challenge was setting up a WSS 3.0 server in the testing lab. The testing lab has a separate AD forest that only has a one-way trust to the production forest. The requirement was to have the WSS 3.0 server be part of the LABTEST domain AND be able to add users from both PROD and LABTEST to the application. Now that seems simple enough since the server already sees both domains as evidenced by the logon drop down box showing both domains. However, as I found out that doesn't mean that the web app will see both as well...
Finding the right command to run was a relatively easy google search which sent me to technet. Getting the syntax right and figuring out how to use the command correctly, now that was the fun part. With the assistance of these two blogs I got it to work:
http://blogs.msdn.com/joelo/archive/2007/03/08/cross-forest-multi-forest-configuration-additional-info.aspx
http://blogs.msdn.com/sharepoint/archive/2006/03/15/552331.aspx
First, in several discussion groups I got differing answers over whether or not the Sharepoint Application Pool Identity needed to be set to "Network Service" or as a domain user account in the domain (in my case, the LAB domain). I used a domain user account myself but had to make changes to the DCOM because my pool wouldn't start. (Component Services - Computers -> My Computer -> COM+ Applications -> DCOM CONFIG -> IIS WAMREG -> Properties -> Security Tab -> Edit Launch and Activation and just give the domain user permissions).
Next it's time to go to a command prompt and go to C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN . Now don't do what I did and think that just because you don't have a full web farm that you can skip the first instruction
stsadm.exe -o setapppassword -password SomeRandomPassword
Literally, it doesn't matter what
The second command is a bit on the long side. The full syntax I ran (names and passwords have been changed for security purposes).
stsadm.exe -o setproperty -url http://WSSVM1 -pn "peoplepicker-searchadforests" -pv "forest:AD.PROD.COM,TrustUser,3t9sz9$b20pz;forest:LAB.LOCAL;domain:AD.PROD.COM,TrustUser,3t9sz9$b20pz;domain:LAB.LOCAL"
Where AD.PROD.COM is the FQDN of my forest and root domain and LAB.LOCAL is the FQDN of the forest and root domain. (keep in mind LAB.LOCAL is the domain that the WSS server is joined to. You'll notice that I had to use a domain user account in the Trusted domain in order to be able to search it since it's only a 1 way trust. Also, while digging I found on one of the forums that you DO need to include the domain the server is joined to as well as the domain you want to add to the search. I'm not really sure if it's necessary to include both the forest: and domain: for each but it works this way so I'm sticking to this method.
On a related note, there's also an alternative way to set this up that involves setting up shadowed, non-login accounts in the resource domain that map to the real users in the production domain. It's a bit more than I needed for this project but you might find it useful.
http://blogs.msdn.com/sharepoint/archive/2006/03/15/552331.aspx
Posts
7 comments:
Does this apply to the following situation. My wss3 only server and its separate sql backend are on main domain where most of it's users are. But there are users in another domain which the first domain only has a one way trust with. These other users are not able to get to the web page - even though we've added them to the website/application. From the security logs it looks like they are hitting iis/wss3 as anonymous, which we don't allow so hence are getting the webpage. So will running that stsadmin command allow them to get to the website ???
That sounds like a headache. When you added the users to the web application, where you able to do a Search for the users in the other domain or did you have to add them manually in? If you were able to search for users in the other domain in the address book from sharepoint then you don't need the people-picker changes.
We also have a one-way trust with another domain, where users of that domain need to access SharePoint which resides in an internal domain. What we are doing now, is creating AD accounts in the internal domain for those users to allow them access. We need to move away from that and simply begin to allow those users to use their existing domain credentials to login into SharePoint. Do we need to establish a two-way trust to acheive that or is there another way to do that?
Thanks,
Okay, if you don't want to do a two way trust, Then either a) the one way trust has to be set up to have your internal domain 'trusting' the other domain. (Right now I assume your internal domain is the 'trusted' one) or b) you have to create a user in the other domain to be used in the peoplepicker command above. (And even in option A you may still need this user to be created) One way or another, your sharepoint server in the internal domain has to be able to look up users in the other domain. To do that, it has to either use user credentials for the other domain, or it has to have a trust in place that allows it to query the other domain.
Once that's in place, then you run the peoplepicker command to tell the sharepoint server to query both domains.
Does anyone know the stsadm command to reset the poeple picker to default behavior? We're moving the WSS server from the old domain to the new domain where all the accounts are..
I vaguely remember seeing somewhere that you could set the -pv value to nothing and it should reset to normal. stsadm.exe -o setproperty -url http://WSSVM1 -pn "peoplepicker-searchadforests" -pv ""
As always, back up your environment before you try it. I'm not sure if the double quotes at the end are needed or not. When I check my other server which has never been changed, it shows the property as not being set which would imply to me that it's Null. stsadm -o getproperty -pn peoplepicker-searchadforests -url http://WSSVM1/sites/testsite
<Property Exist="No" />
I tried about 10 different variants of this but this one is spot on. As soon as I executed it could see the accounts on the trusted domain.
Bless you.
Post a Comment