Getting Access denied when nav to the Shared Service instance
- I created a Shared Service on my server a few days ago using the local administrator account. I have since created a separate Windows account (belongs to the Administrators group) for myself to use. I'm able to do everything in the Central Administration site but accessing this instance of Shared Serviced created a few days ago. What specific access rights does it need? My windows account is in the Farm Administrators group too.
Antworten
- Try adding the second admin to the site collection admins of the SSP admin site. That should help.
Alle Antworten
Bob,
Log into Shared Services using the same account you used to create the SSP a few days ago with. There is a permissions seperation between Shared Services and the Central Administration. You simply need to add your account you want to access with.
Hope this helps
I'm having the same problem. 2 Domain admins, both in MOSS 2007's Farm Administrators group, but only one (the one first used to install/config MOSS) can open the default SSP's admin page. I was even able to make a test domain user, add it to the domain admins group and the farm administrators group then use it successfully to get to the SSP admin page. But my other admin's account still can't, and its the only thing on the server and in MOSS he can't do.
We who are having this problem can already tell there is a separation somewhere. What we need to know is not that a separation exists, since that is clear, but we need to know WHERE it is. WHERE do I go, WHAT do I do specifically to overcome it?
ArieMichal
Hey friend im just trying to help here so please keep the tone down. :)
Did you add you other Administrator to the SSP portal?
- Try adding the second admin to the site collection admins of the SSP admin site. That should help.
- I, too, have had this problem.
My only way of solving it so far is to create a new SSP and then re-assign the other sites to the new SSP. The busted SSP can then be removed via IIS.
I know that this will have some implications as to content that was already created in other sites but it is the only way for me to move forward.
What I am learning is that the Shared Services is a special site. Without adequate documentation I'm flying blind.
MOSS 2007 is a huge improvement over previous versions but still has a way to go before it is a manageable product.
I would love to see MS do a better job of streamlining the Admin user, SSP admin, with a set of defaults or recommendation via EXAMPLEs. kiral wrote: Try adding the second admin to the site collection admins of the SSP admin site. That should help. Exactly! Thanks a lot, kiral.
Ole Thomsen
- Thanks a lot Kiral. That fixed the problem for me. It really makes sense since a new top level site wouldn't know what accounts need to be in the admin group other than the account creating it.
Has anyone run across this situation:
I cannot logon to Shared Services with the account used to install it, or any other account?
How can I tell which account created it? I just want to verify that I am using the right account to access it.
Thanks,
Matt
Thanks so much Kiral. I had this same issue and your fix worked perfectly. This stuff isn't very intuitive.
- You can find out the account by looking at your App Pool for your SSP. Try logging in with that account
I am facing this issue with accessing newly created SSP and never had issue like this.
I can't access the admin site of SSP with any of accounts (set up user, farm admin , ssp pool and ssp service) used to setup but can access settings page like /_layouts/settings.aspx or searchsspsettings.aspx. SSP setup user has full control and added farm admin as well with full control. But nothing happened and still can'taccess the ssp admin site
If I change the Authentication provider to Enable anonymous access, I can see admin site for one or two clicks. I configured it on many server but never had this issue. Only difference with this is SQL Server is running under local system accout.
But no result.
Thanks,
I wrote a blog Give a user access to SSP that should help all of you with permissions. For the person having problem logging in with any account you could try the blog link to from that post Become Administrator of the Entire Web Application and give yourselft access to the whole web application.
Shane - SharePoint Help
I've got a similar issue. I can't access the SSP admin site at the base url, I get access denied. If I put in
http://servername/ssp/admin/_layouts/settings.aspx I can access all settings. I added additional users. Still no luck accessing main http://servername/ssp/admin. The new users can access the settings.aspx page directly.
We are having this same problem. We are not able to access the Shared Services Provider site with the account I just used to create it, the sp farm account, ssp-app account, or ssp-service account. I have tried the above suggestions including adding the accounts as full application administrators, as farm administrators, and as site administrators through the _layouts/settings.aspx page which we can also get to directly. We have loaded MOSS many times in the last few weeks in our lab and come across this issue ALOT. Any other suggestions would be greatly appreciated. Thanks.
Edit:
I finally found the answer, it was just much further down the google tree than I normally go.
It appears to be a bug where sharepoint builds the app pool but insists on running it with the ssp service account instead of the app account that gets entered and won't let you change it. I created a new app pool by hand with the correct account and moved my ssp data to it as suggested here http://faraz-khan.blogspot.com/2007/06/moss-2007-cannot-login-into-ssp.html .
It worked like a charm! Hope this helps.
- Als Antwort vorgeschlagenJeremy Thake Donnerstag, 21. August 2008 02:07
- The bottom line is (As stated here and links referenced here) that you should not name your SSP the same as the Application Pool for the Administration site of the SSP.
What I concluded and is not obvious from the documentation is that there are two (2) application pools associated with the SSP: One, is created automatically by the SSP creation process and it is named exactly like the SSP. This AppPool is configured to run with the SSP_SVC account we provide. The second is the AppPool that will be associated with the Administration Application (site) for the SSP.
If this was made clear from the beginning, we might not be tempted to name the SSP and the Admin site's AppPool the same. Instead, I now might name things like this:
SSP Name: MOSS_SSP_01
AppPool Name: MOSS_SSP_01_Admin (this tells me it's the AppPool for the admin site of the SSP_01)
I hope this helps.- Als Antwort vorgeschlagenFernando Vargas Montag, 6. Oktober 2008 16:35
- The post by kiral - Posted on Friday, February 09, 2007 5:28:30 AM worked for me. But it's easy to get confused. When you go to assign a site collection administrator, note that you can choose another web application. You need to choose the one associated with your Shared Services Provider site. Each web application can support multiple site collections. Each site collection may have both a primary and secondary site collection administrator. So, if you go to Central Admin, Application Management, Site Collection Administrators, and see your account as the secondary site collection administrator, you might be confused and think your account is assigned access to the shared svcs provider. But look carefully at the drop-down "Site Collections" and explore a bit further.
- BearbeitetDavid K Allen Montag, 29. Dezember 2008 20:11clarify context
- Have been going around in circles on this one. In the end the problem was not related to any account or application pool privileges, but rather to a 'loopback security check'.Have blogged about it here.Apologies if this post shows up several times, as I am posting it as a response to several other similar threads on technet.
I have the same problem, i tried all posibles solutions, but the problem i can't resolve.
I found a solution log me with firefox, with Internet Explorer i Can´t but firefox i don't have problem.
leon- Als Antwort vorgeschlagenchristopher Howell Donnerstag, 3. September 2009 15:06
- The SSP is a totaly diffrent security matrix than the Central admin and this is by sharepoit design. When a SSP is created only the account that it was created with has access to the SSP. Log in to the SSP and go to site actions> site Settings > SIte collection administrators and add your users in theie. This then allows those users to log in ot the SSP with the regular account.
In a large scale portal you will not necissarily have the farm administrators and the SSP administrators as the same group. - This is an old thread but I thought I would post an answer here for those searching. Most of the posts have all the typical things to try and they will msot likely work. However, we ran into this issue today and after checking all the usual suspects without success I thought of another scenario.
We are working with a staging environment for a larger MOSS deployment. Since the staging servers were setup exactly like the production farm the same URL was used for everything http://customersite. Later this was changed due to DNS confusion so that the staging site (non-admin stuff) runs at http://customerstaging. I noticed the SSP admin URL was still using the old URL and, sure enough this was trying to hit production.
So I went into Alternate Access Mapping in Central Admin/Operations (under the Global Configuration section) and changed the SSP (and all others) to the new URL - voila we have access again. Don't forget to check IIS host header names as well.
Madrona
