I have a SharePoint 2013 server for development purposes, that runs on Win 2012. The problem is that after a period of time the anonymous authentication changes by itself.
In IIS, select the server name, than from the right panel under IIS double click Authentication. From the page that opens right click Anonymous Authentication and select Edit from the context menu.
Than will pop-up a credentials selector window.
The correct value should be first option: Specific user (IUSR account) but the option select is the second one: Application pool identity.
If I change it back to Specific user and select IUSR, after a while is back to Application pool identity.
Any ideas how can I investigate what app/software is messing up with my settings?
Have you looked at the IIS event logs or security logs?
Related
Windows Standard 2012 R2
SharePoint Foundation 2013
SQL Server 2014
I have a SharePoint Application page that is throwing the above error when clicking on any Button on the page. I even added a button with nothing in the method and still get the above error.
Note that I am NOT challenged when accessing the Application page initially and am NOT challenged when clicking the button. None of the code in the original method gets executed. In fact, it appears that the page cycle is never processed. I have logging in the method, the page_load even and in the page_unload event and nothing is logged.
The site is configured for claims authentication and I have verified that my account, application service account are both in Owners and both are admins on the box. Application Service account has SYSadmin on the SQL server (also located on the same box).
I changed SharePoint to allow access requests and to send me an email for those requests. Now the page shows:
The website declined to show this webpage
HTTP 403
Most likely causes:
•This website requires you to log in.
Any suggestions?
One more thing: this is a one-page application. There are no redirects, etc. within the page/application.
Thanks,
John
Turns out this was a permissions issue for the application service account. Never could find out specifically where but reverted to a previous service account and it works now.
I am trying to create a service which does following:
Logging in as a user with specified username/password
Running an application on the desktop of logged in user of step 1
Note: before step 1, user is not logged on. (something like right after machine is rebooted)
The expected result is, the user should be able to see the UI of launched app at step 2 if user logged onto the desktop with the user account logged on at step
I found this article, but this code will launch the app on current desktop (let's say, currently logged on as userA. Using username/password of userB, the app is still be launched on userA desktop, but using userB's account).
https://support.microsoft.com/en-ca/help/165194/createprocessasuser-windowstations-and-desktops
Please let me know what's the correct way to achieve my goal.
IDE: Visual Studio 2015 C++ on Windows.
Let me answer to my question.
The bottom line is:
I cannot launch a process on a desktop of not-logged-on user by programmatically logging in.
Reason:
Calling certain function such as LogOnUser, I can login and access to resources related to user's account.
However, the logon session is different from a Session which will be created when user logs on from login screen.
Because of security reason, once a process is launched, we cannot move the process to another Session. So, UI will never be able to show on the desktop after the user logs on from login screen.
Alternative solution:
Use auto-logon
Redesign app, and split UI and its data. So, a process with data can run as service, and UI can launch later on a desktop.
The details explanation of how Windows Session, Window Station, and Desktop works:
https://brianbondy.com/blog/100/understanding-windows-at-a-deeper-level-sessions-window-stations-and-desktops
Thank you very much for Harry Johnston for detailed explanation in the comment.
I finally created my first App for Office, and talked IT into deploying it into our on-premise SharePoint App Catalog. Is there any way, in SharePoint 2013, to hide/bypass the security dialog for people who are visiting the page for the first time?
Here's the dialog box I'm talking about,
There is no way to disable this dialog; the end user must click "Start" in order to trust the app. This dialog will not reappear once the user has trusted the app for the first time.
I am working on SharePoint 2013 server on premise. Surprisingly, I am not able to log in at SharePoint 2013 site on server side, when it is allowing me to log in on the same site with the same credentials on local machine.
What may be the issue?
Adding backhostConnectionNames should help.
Click Start, click Run, type regedit, and then click OK.
In Registry Editor, locate and then click the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
Right-click MSV1_0, point to New, and then click Multi-String Value.
Type BackConnectionHostNames, and then press ENTER.
Right-click BackConnectionHostNames, and then click Modify.
In the Value data box, type the host name or the host names for the sites that are on the local computer, and then click OK.
I don't remember if IIS reset is necessary.
On this page, it talks about Windows NT, 2000, XP and 2003. Fortunately, I have a Windows 7 machine.
The very first line says:
In User Manager for Domains, create a local user for the ColdFusion
service to log in as.
I don't see a "User Manager for Domains", so do they mean just "Add a new user"?
If it DOES mean that, can I use my own user account as the ColdFusion user, or should I specifically create a new account just for ColdFusion?
If you are creating a domain account it has to be created ON the domain - using user manager for domains connected to your domain controllers. If that's what you need then a sys admin has to help.
If you are doing a "local" user on a windows 7 I always end up hunting around for the right view of user manager before I get it right :) Here are the steps that I use:
Search from start and open the "user accounts" cpl.
Click on "Manage User Accounts"
Click on the "advanced" tab
Click on the "advanced" buttton.
This takes me to the mmc-like view of users that I'm accustomed to where I can add a user, change membership, set passwords etc.
Hope this helps :)
You can use your own username or you can create one for CF to run as. Creating a user to run CF as probably more closely replicates your production environment ( an assumption ) so if production for example writes to a UNC path the coldfusion user must have acces. You could
Mimic this locally.
You can use either an account local to the OS where ColdFusion is running, or a domain account if the OS is joined to a domain. In your case, you can just create a local user on your Windows 7 OS and run the ColdFusion Application Service as that user. The user account will need access to ColdFusion's installation folder, as well as read access to the webroot.
The whole idea is to run the ColdFusion service as a user with the minimum privileges necessary to handle requests and prevent access to other resources in the event of a data breach or remote code execution (e.g. someone exploits an upload form and manages to get their own CF code to run on your server; it's not pretty but can be somewhat restricted by running the CF service under a user account with restricted access).
As someone else mentioned, if CF needs access to other network resources, the user account will need to be granted access to those resources as well (either by using a domain account or having a local account with the same username and password on the remote system).
Just did this on Windows 2008 R2 with CF 10. The trick was to change the ownership of the c:\windows and c:\windows\system32 directories as outlined here.
change ownership from trustedInstaller