We have a website whose users supply HTML links to a virtual directory on the website. (Think www.website.com/dir1; dir1 is actually a virtual directory to a different server.) The server that the virtual directory links to requires authentication, however the username and password needed is constant.
Whenever a user tries to access a page that draws a resource from that virtual directory, the webpage asks for authentication. We don't want the user to have to enter in the authentication info every time they enter the site. We have no control over the server that is the source of the virtual directory, but have total control over the virtual directory's settings.
How can we set up the virtual directory so that a webpage that accesses the virtual directory automatically supplies the authentication info?
Please let me know if there's more info you need!
Unfortunately there isn't a way for you to transfer your authentication from one server to another, unless you share your session information. Do a google search for session state server for more information on this.
However, this may not be what you want.
Your only other options are to completely open up the resources on the 2nd server, or set up the directory on the other server as another virtual directory on the first server. This way everything is authenticated from the 1st server.
Related
I'm trying to create a custom master page template in a SharePoint Online environment. I'm using the Design manager to upload the design files. I've mapped the network drive like the page described and can open and view the files, but I cannot upload files to the location. Every time I try I get the following error:
Error 0x800700E0: Access Denied. Before opening files in this
location, you must first add the website to your trusted sites list,
browse to the website, and select the option to login automatically.
I've added the site to the trusted sites list, as well as selected the option to login automatically. The WebClient service is also running.
How can I upload files to this location?
The only explanation I can think of is that I am logged into windows on a Microsoft account, and I use a different Microsoft account for SharePoint. I can map the network drive fine, but when I try and map it with the option "Connect using different credentials", and I use my SharePoint Online account, I get the same access denied error.
Thanks
Check permissions for the document library/folder in which you're trying to write files. Folders like _Layout which resides at root level sometimes do not allow access of write. Global administrators have full access to these folders but tenant or site collection administrators may not have its access.... For example try opening this link in browser https://yoursharepointsite.com/_layouts/15/fonts this is where font files are like Arial.ttf or Comic sans.ttf So if you want to add new font to your sharepoint online themes you'll have to add files here.
Do this open SP Designer -> open main site -> browse left side menu for your folder and try copying something. If you can copy files there you should be able to copy through your mapped drive.
Also when you mapped drive in Windows Explorer didn't it ask for credentials, where you had to give in your Office365 login email then it can't be an issue of your windows credentials messing up with anything.
In this circumstance, it was actually the Trusted Sites that I had added. I added 'mysite.sharepoint.com' as well as '*.sharepoint.com' to my trusted sites. As soon as I also added: '*.lync.com', '*.microsoftonline.com' and "*.outlook.com", I had no problems writing to the directory
The question in brief: How can I set up WebDav so that unauthenticated users can download files with a URL, but can't access a list or make changes to the share?
The long version:
I'm new to WebDav. I'd like to replicate the Dropbox/public folder functionality. That allows any user with the correct URL to download a file, but no unauthenticated user can access a list of the files in the subdirectory or make any changes to the public folder.
I'd like to be able to send my client a URL to a file for download without exposing the whole contents of the share and, importantly, without requiring the client to have a user id and password.
The WebDav directory should also not be alterable or viewable by anyone who doesn't have a user id and password.
The WebDav directory is isolated on my server and I can alter .htaccess files.
I have a sharepoint site hosted on windows server 2008 r2 and iis7.
the sharepoint site is hosted on port 80.
when I browse the site by typing the IP of the machine I receive a login window asking for credentials to connect the Machine. after providing credentials another login window asks for credentials to connect to the sharepoint site.
my question is that when a user logs in to a sharepoint site he uses the credentials specified in the active directory, so why in my case I recieve the login window twice ?
thanks
I've seen this before but rough guess:
When a SharePoint site has a reference to a resource held inside another site (not necessarily SharePoint).
e.g.
http://mysharepoint/
contains perhaps an image with the url http://someothersite/images/someimage.gif.
Not necessarily an image, it would be any resource.
Best way to check could be to view source and check to see if there are any urls pointing to outside the site.
Also check for urls starting with https: .
Hope this helps.
Another thought:
Since you're accessing the site through the IP address, maybe its treating your IP address site (http://192.168.1.1) seperately to the actual host headed sharepoint site (http://actualsharepointsite). Therefore the first authentication prompt is for the IP address host headed site and the second is for the actual host header of the sharepoint site.
To eliminate this, I would try (if you have access to these areas):
a) Logon to the actual box, and browse the site on the actual server using its proper host header (might need host file entry and proxy bypass setup depending on your environment). See how many times you're prompted for login details.
or b) In Central Admin, try to setup Alternate Access Mapping from the IP Address url to the actual host headed url.
Sorry if this doesn't help..
I set up a new virtual directory in IIS under the Default FTP Site. I already have other virtual directories, and I'm able to access them with my user account, which is a domain admin. I created an account named FTPuser, gave it full permissions to the virtual directory, but I can't open the site. When I log in, I get a Success Audit event in Event Viewer, so my account is being authenticated. But the site doesn't appear, I just get the login box again.
I ran Process Monitor and saw different behavior between the two login scenarios. When I login to the same FTP site with my admin account, I get a SUCCESS result in Procmon when trying to access the folder that is specified as the home directory for my Default Web Site. But I get an ACCESS DENIED message when trying to connect as the FTPuser. Above that in the log, it also shows a NO SUCH DEVICE error trying to connect to the IPC$ share on that drive (the one containing the home directory).
When I look at the permissions, both accounts seem to have Full Control on the relevant directories. Can anyone point me in the right direction as to what is going on here?
Thanks.
I have an issue with SharePoint search.
The situation
The server is installed with
SharePoint on a farm with 2 servers.
A new app pool is created and that app pool is using a domain account called moss_service.
moss_service is set to be in the administrator group in both server.
moss_service is also set to be the db_creator in the content database.
When I checked it initially, the search's default content access account is using another different account, I changed that to be using moss_service account.
I didn't do IIS reset because this is a production server, they dont want frequent iis reset.
Strangely, checking the services.msc under "office sharepoint server search" the account is still using an old one. (and apparently it's only running on 1 server, the other server is not running) I then change that to the following:
domain\moss_service with the password.
and then I rerun the crawl.
How do I diagnose the issue
Basically everytime I change something I restart the crawl and then check the event viewer. Multiple things come out but the following is the major ones:
The start address cannot be
crawled. The password for the content
access account cannot be decrypted
because it was stored with different
credentials. Re-type the password for
the account used to crawl this
content. (0x80042406)
Performance monitoring cannot be
initialized for the gatherer object,
because the counters are not loaded or
the shared memory object cannot be
opened. This only affects availability
of the perfmon counters. Restart the
computer.
Access is denied. Check that the
Default Content Access Account has
access to this content, or add a crawl
rule to crawl this content.
(0x80041205)
Crawl Logs Result
The crawl log is showing this:
The password for the content access account cannot be decrypted because it was stored with different credentials. Re-type the password for the account used to crawl this content.
I tried changing it again at service.mstsc and the rerun the full crawl again but then it doesn't work. I have tried entering it using the following way:
moss_service#domain.local
and
domain\moss_service
My Questions are:
How do I fix this?
Is this the right way to setup the
search?
Does the search account has to be
using a different domain account?
Seemed like one fix complicates the
other, how do I set this right?
Is it worth it to upgrade to sp2?
Google this you will get answer " Access is denied. Check that the Default Content Access Account has access to this content, or add a crawl rule to crawl this content. "
Alex, I think you need to completely reconfigure the search services. Keep in mind that the search crawler should be an account with least privileges (not your application service account!). Also, the indexer only runs on one server and whether the search crawler runs on one or more machines is another configuration issue. Also, some settings changes (like changing the crawled File Types) even require the search engine to be restarted.
The start address cannot be crawled. The password for the content
access account cannot be decrypted because it was stored with
different credentials. Re-type the password for the account used to
crawl this content.
For this error,
Open the Sharepoint administration
Click on "Application Management"
Click on "Manage service applications"
Click on "Search Service Application"
Click on the current value for "Default content access account" and re-enter the user's password, or update to another admin user.