I am trying to create an FTP site in IIS, which will contain folders based on IIS isolated users.
I don't want these user to be Windows Users.
I have read many different forums which all provided the same steps, such as
http://www.iis.net/learn/publish/using-the-ftp-service/configure-ftp-with-iis-manager-authentication-in-iis-7
But for some reason the users i'm creating are not able to log in. I get Access Denied. Although at some points i removed all firewalls and added every kind of permission on the folders and such.
I tried the above suggested steps for 100 times.
Could anyone might suggest something that i might be missing?
Related
At some point over the weekend most users lost access to Outlook (they were unable to sync) and to some shared folders. The users that kept their workstations logged in during that time still had access to both Outlook and the shared folders.
If added to a "domain administrators" group, the users have access to both Outlook and the shared folders. Obviously this is not a solution, even in the short term, but it is a symptom of the problem.
I don't think someone deliberately changed a setting in the server. I do believe this to be a wrong setting somewhere. We currently have a Windows 2003 SBS as an Exchange server, domain controller and primary DNS.
We've been having issues with the DNS servers. Sometimes we need to add a shared folder by ip. Other times it is added by name.domain.local, and sometimes by just their name. Although I think the current problem is not related, I mention this for context.
After a lot of research i found it to be an issue with the CAL´s, the licenses somehow reset to default values and that was preventing users from accessing outlook and share folders.
After stopping "license logging" service, using the info contained in autolicstr.cpa and passing it to licstr.cpa, then restarting the service...the licences were restored and everyone had access again.
I followed these two questions:
IIS 7.5 App Pool Identity permission not assigned to folder, but application still can write to its folder?
IIS AppPoolIdentity and file system write access permissions
To try to understand how it is possible to isolate IIS ApplicationPoolIdentity users although they are members of the Users group that has read access practically everywhere.
I think that should be more secure that the App Pool\myapp could only read the contents of the site (or read/write its virtual directory), but what is the best practice to do that without removing the Users group ACL from everywhere?? my Windows server defaults has the "users" group on the volumes acl with read access and inherits to all folders...
This question is also answered in the answer you linked to, by Kev. You should preferably set up your web root on a separate non-system drive. There you can remove the Users group from the top level and grant rights to the home folder of each site to the respective application pool identities only.
AMit - that still doesn't solve the issue that his web app can read practically any file on the c:/ drive. But it's even worse than that. The web app can WRITE to the c:/ drive. Because the users group has permission to do so...
It's a fundamental security flaw in Microsoft's design. I've been searching for a solution myself and yet to find one.
Putting the web site on a different partition is security through obscurity... Which is basically no security at all - rather the mere hope that they don't find...
We have both internal and external users on Windows SharePoint Services 3.0. We are using Windows Integrated authentication and have all users, both internal and external, in the same domain. We are allowing all users access to the application by adding the Domain Users group. The issue is that there are certain sites that need to be secure from the external users, but because they are in the same domain they have access. We have removed the Domain Users group from some sites and then explicitly assigned permissions to a dedicated group in Active Directory, but we have around 100 sites that we need to do this for and it would become an administrative nightmare to do this for all 100 sites.
I've done some searching and it looks like we might be able to accomplish this using zones, but when we tried last week we broke the entire application. Does anyone have any ideas?
The other option is to move the WSS server into a different domain and give the external users accounts in that domain so that we could keep them separate, but I wanted to see if there was a better way to do this.
Work on creating automation that creates and maintains Active Directory security groups that contain lists of internal or external users. Surely there is an attribute or two that distinguishes between these different types of users.
While you are at it, update your user provisioning process to make sure that when you create accounts, they get stuck in one group or another.
It would seem to be relatively simple to automate the process of changing your security using a powershell script?
An example of a script like that is here
I'm creating a website in IIS 7.5 (with Windows 7) that needs to be able to create further websites. I've written code that uses Microsoft.Web.Administration to create the website programmatically, and this works fine when I run it as administrator.
Now I'm trying to use the same code in the context of my web application. It fails with the error
Error: Cannot read configuration file due to insufficient permissions
for the file redirection.config (which I understand is located in %WinDir%/System32/inetsrv/config).
I've tried creating a new apppool for this specific website, running under the IIS AppPool[AppPoolName] identity. I've then tried to grant that identity permission to edit the IIS config using
ManagementAuthorization.Grant(#"IIS AppPool\MyAppPool", "Default Web Site", false);
but I still get the same error.
What else should I try?
This probably isn't the wisest approach from a security viewpoint. If this site is hijacked then your attackers will be able to interfere with those files (to no good purpose) or even just delete them.
The way we approached this was to separate website creation tasks into a windows service running with the correct rights to perform these activities. In this service is a remoting end point (although these days you'd probably want to use WCF).
We then created a proxy assembly that is signed and registered in the GAC (it would also need to be marked with the APTCA attribute if you're running at less than Full Trust). This assembly passes on the relevant calls to the remoting endpoint in the windows service from the admin web app/service.
This allows us to run the admin site at least privilege and in partial trust mode. The scope of what can be done by way of site admin tasks is narrowed somewhat by whatever functionality is exposed in the windows service application.
This is a technique known as sandboxing.
I've found a way to do it, but I would very much like to hear expert opinion on whether this is a wise thing to do.
I granted Modify and Write permissions for the IIS AppPool\MyAppPool account to %WinDir%/System32/inetsrv/config and the three .config files inside it.
Doing some more tinkering with development on VS2008/Vista/IIS7, I'm wondering at a few things regarding the Network Service account. It had no issues running my website until I attempted to set up the Sql Role Membership Provider, which creates a local database in the App_Data folder. Somewhere in there, Network Service ran out of the permissions needed to auhenticate my client.
I solved the problem by changing the app pool to run under my admin account (and later by granting Network Service admin permissions for now), but I'm curious as to what permissions Network Service is missing as I'd ultimately like to keep it (and my sites) out of the admin group. Any ideas?
Also, where's a good place to go debug this stuff? EventLogs have nothing useful, so I'm not sure where else would be a good place to find out when an account tries to do something and is denied. Maybe I just don't have the logs configured properly?
Thanks!
Oddly enough, it looks like gving Network Service write access to the folder containing the mdb file wasn't enough. It apparently wants read access to everything under the "Documents\Visual Studio 2008 directory" as well (the site is hosted from within that directory). Seems ok now. Thanks ProcessMonitor!