I have an intranet web page.When I entered to the web page,it ask me to log in. When I put my credentials he lets me in but when inside he asks me again and again and again. If I click another section it will ask me again too.
I have tried adding the web page to trusted sites,credential manager on windows. I think this is not case since I have a qa site and doesn,t happens.
This only happens to this site because I have more sites on the server and they work as expected.
I have multiple sub sites on the page I don't know if this maybe related.
How can I solve this?
Thank you in advance.
Refresh your browser cache/ passwords..
If the page you are trying to access has some code/webpart which tries to access a resource to which you dont have access, then it can give this issue.
Related
The problem
We're running IIS on Windows 8.1 with Update. We're at the Orchard CMS first time setup screen, and IIS is giving 401s for all static content. We have read the following to no avail:
IIS 7.5 no images css js showing
IIS 7.5 no images css js showing
The official Orchard deployment documentation
Based on those, this is what I have tried that doesn't work.
Turn on the IIS feature to Serve Static Content.
Give IIS_IUSRS permission to Read, write & execute.
Give the site's application pool permission to Read, write & execute.
What does work though is the nuclear option: to give Everyone the Read permission (unless we want to proceed with the Orchard setup; then we need to give Everyone even more permissions.) That leads me to believe that I must give permission to some principle with less scope than Everyone but more scope than both IIS_IUSRS and the application pool combined.
Who/what is that principle?
Pictures to show the problem
We receive a 401 on ..\Themes\SafeMode\Styles\site.css
The task manager confirms that the site is running as the orchard user.
The security properties of the ..\Themes\SafeMode\Styles\ directory gives Read permission to orchard.
Why does it only work when we give Read permission to Everyone?
I had a similar problem. Under authentication, I right clicked "Anonymous Authentication" and clicked "Edit". That shows a dialog giving you the ability to set the identity of the anonymous user. I set it to "Application pool identity" and that fixed the problem for me.
.
This may not be the most secure configuration though, but I'm on a dev server so I don't care.
Try turn on the Static Content and Directory Browsing features under Internet Information Services->World Wide Web Services->Common HTTP Features node.
In my case I had to set Read permission for IUSR user for the web site folder.
So, what I had to do to fix this problem was the following:
(and please understand, that this is not ASP or PHP script related, the server wouldn't even show basic simple .html files, yet would serve out PHP results all day long!)
Two fold…
Had to set the application pool for each site, under advanced settings, to use LocalSystem for it’s process
Under site, advanced settings, security, add the IUSR account to have read & list contents access, for the site… :-)
See any problems with doing that?
'cuz it's working....
Updating windows feature for WWW services/Common Http Features/static content by selecting Static Content checkbox fixed my IIS not service static content issue.
Open IIS -> go to advanced settings of selected website and open Physical Path Credentials -> Select specific user and enter your local user credentials. Open below screenshot for further visualising the things:
IIS Settings
I'm pretty much new to IIS and this is the problem that I'm trying to solve.
I have a legacy web app (complied so not easily changeable) that is running in IIS 7.
This web app displays images to the user of possibly sensitive personal data but if the user views the source the of the page then they are exposed to the url which is viewable directly through any browser.
What I think that I need to do is to remove the folder permissions (where the images live) to stop people directly browsing vewing them and then create another account that has the permissions to view this folder and then associate this newly created account with the application pool that is running the site.
So my questions are would this be the correct way of doing this? And if it is, how would I actually achieve (bearing in mind that I'm a complete novice in IIS and permissions).
Any help would be muchly appreciated.
Thanks,
Craig
I have a problem with my sharepoint site, when I go to the home page the log in box keeps popping up, I have to click about 3 to 4 times before it goes away, and it does that everytime I go to the home page, all the other pages does not do that.
Can any one please help me out here.
Thank you.
Is there anything on your homepage you do not have rights to? Like un-approved images?
Use a tool like Fiddler to see what is causing the authentication requests.
Add the sharepoint url to the Trusted Sites also try enabling "Automatic Logon" under the Local Intranet Zone security settings
cheers,
NK
I've got a SharePoint MOSS 2007 development setup on to which I installed the WSS infrastructure update. Now, whenever I try to access any site collection in my SharePoint farm using IE7 I get a username and password prompt. I enter valid credentials for my Site Collection admin account and I see the box again. This happens three times then after the third time I just see a blank page.
When I access the system through FireFox 3.0 I get the username and password screen but after putting the credentials in the first time, the site runs as normal.
I presume this is because IE is using NTLM whereas Firefox is using basic authentication, but I'm not sure how to resolve the issue.
Has anyone else experienced this or can anyone point me in the right direction?
Thanks in advance
- Russell
I've found the answer to this now. It was all to do with this issue...
http://support.microsoft.com/kb/896861
Before the infrastructure update just entering the FQDN (e.g. intranet.domain.local) for BackConnectionHostNames entry in Method one worked fine. After the infrastructure update I added just the hostname (e.g. intranet) to the BackConnectionHostNames entry and this fixed the issue! :-)
I had to turn off IE ESC to get this to stop. For some reason, it worked on all servers except one in our farm. Who knows. Hope this helps you get started.
I'm trying to get crawl to work on two separate farms I have but can't get it to work on either one. They both have two WFE's with an additional WFE configured as an Index server. There is one more server dedicated for Query and two clustered SQL 2005 back end servers for the database. I have unsuccessfully tried at least 50 different websites that I found with solutions from a search engine. I have configured (extended) my Web App to use http://servername:12345 as the default zone and http://abc.companyname.com as the custom and intranet zones. When I enter each of those into the content source and then try to run a crawl, I get a couple of errors in the crawl log:
http://servername:12345 returns:
"Could not connect to the server. Please make sure the site is accessible."
http://abc.companyname.com returns:
"Deleted by the gatherer. (The start address or content source that contained this item was deleted and hence this item was deleted.)"
However, I can click both URL's and the page is accessible.
Any ideas?
More info:
I wiped the slate clean, so to speak, and ran another crawl to provide an updated sample.
My content sources are as such:
http://servername:33333
http://sharepoint.portal.fake.com
sps3://servername:33333
My current crawl log errors are:
sps3://servername:33333
Error in PortalCrawl Web Service.
http://servername:33333/mysites
Content for this URL is excluded by the server because a no-index attribute.
http://servername:33333/mysites
Crawled
sts3://servername:33333/contentdbid={62a647a...
Crawled
sts3://servername:33333
Crawled
http://servername:33333
Crawled
http://sharepoint.portal.fake.com
The Crawler could not communicate with the server. Check that the server is available and that the firewall access is configured correctly.
I double checked for typos above and I don't see any so this should be an accurate reflection.
One thing to remember is that crawling SharePoint sites is different from crawling file shares or non-SharePoint websites.
A few other quick pointers:
the sps3: protocol is for crawling user profiles for People Search. You can disregard anything the crawler says about it until you're ready for user profiles.
your crawl account is supposed to have access to your entire farm. If you see permissions errors, find the KB article that tells you the how to reset your crawl account (it's a specific stsadm.exe command). If you're trying to crawl another farm's content, then you'll have to work something else out to grant your crawl account access. I think this is your biggest issue presently.
The crawler (running from the index server) will attempt to visit the public URL. I've had inter-server communication issues before; make sure all three servers can ping each other, and make sure the index server can reach the public URL (open IE on the index server and check it out). If you have problems, it's time to dirty up your index server's hosts file. This is something SharePoint does for you anyway, so don't feel too bad doing it. If you've set up anything aside from Integrated Windows Authentication, you'll have to work harder to get your crawler working.
Anyway, there's been a lot of back and forth in the responses, so I'm just shotgunning a bunch of suggestions out there, maybe one of them is on target.
I'm a little confused about your farm topology. A machine installed as a just a WFE cannot be an indexer. A machine installed as "complete" can be an indexer, query and/or a wfe...
Also, instead of changing the default content access account, you may want to add a crawl rule instead (once everything is up and running)
Can you see if anything helpful is in the %commonprogramfiles%/microsoft shared/web server extensions/12/logs on your indexer?
The log file may be a bit verbose, you can search for "started" or "full" and that will usually get you to the line in the log where your crawl started.
Also, on your sql machine, you may be able to get more information from the MSScrawlurlhistory table.
Can you create a content source for http://www.cnn.com and start a full crawl? Do you get the same error(s)?
Also, we may want to take this offline, let me know if you want to do that.
I'm not sure if there is a way to send private messages via stackoverflow though.
Most of your issues are related to Kerberos, it sounds like. If you don't have the infrastructure update applied, then Sharepoint will not be able to use kerberos auth to web sites w/ non default (80/443) ports. That's also why (I would bet) that you cannot access CA from server 5 when it's on server 4. If you don't have the SPNs set up correctly, then CA will only be accessible from the machine it is installed on. If you had installed Sharepoint using port 80 as the default url you'd be able to do the local sharepoint crawl without any hitches. But by design the local sharepoint sites crawl uses the default url to access the sharepoint sites. Check out http://codefrob.spaces.live.com/blog/cns!7C69E7B2271B08F6!363.entry for a little more detail on how to get Kerberos & Sharepoint to work well together.
In the Services on Server section check the properties for the search crawl account to make sure it is set up, and that it has permissions to access those sites.
Thanks for the new input!
So I came back from my weekend and I wanted to go through your pointers and try every one and then report back about how they didn't work and then post the results that I got. Funny thing happened, though.
I went to my Indexer (servername5) and I tried to connect to Central Admin and the main portal from Internet Explorer. Neither worked. So I went into IIS on ther Indexer to try to browse to the main portal from within IIS. That didn't work either and I received an error telling me that something else was using that port. So I saw my old website from the previous build and I deleted it from IIS along with the corresponding Application Pool. Then I started the App Pool for the web site from the new build and browsed to the website. Success. Then I browsed to the website from the browser on my own PC. Success again. Then I ran a crawl by the full URL, not the servername, like so:
http://sharepoint.portal.fake.com
Success again. It crawled the entire portal including the subsites just like I wanted. The "Items in index" populated quickly and I could tell I was rolling.
I still cannot access the Central Admin site hosted on servername4 from servername5. I'm not sure why not but I don't know that it matters much at this point.
Where does this leave me? What was the fix?
I'm still not sure. Maybe it was the rebuild. Maybe as soon as I rebuilt the server farm I had everything I needed to get it to work but it just wouldn't work because of the previous website still in IIS. (It's funny how sloppy a SharePoint un-install can be. Manual deletion of content databases, web sites, and application pools seem necessary and that probably shouldn't be the case.)
In any event, it's working now on my "test" farm so the key is to get it working on the production farm. I'm hopeful that it won't be so difficult after this experience.
Thanks for the help from everyone!