Freigeben über


Using FTP with Different Account Types

I was going through some of my notes the other day and I stumbled across the following chart that I thought I'd share. I put this chart together for a coworker that had asked me about some of the advantages and disadvantages when using different account types with FTP.

This list is obviously not all-inclusive, but it should give you some things to consider when choosing which types of accounts to use for your FTP users.

Account Type Advantages Disadvantages
Domain User Accounts (Used with FTP's Basic Authentication) Domain accounts allow for easier access and auditing for domain resources, like content on UNC shares. Domain accounts obviously have more access to your network's resources. For example, if the accounts are part of the local "Domain Users" group, they have access to everything that the group has access to.
Local User Accounts (Used with FTP's Basic Authentication) Local accounts are generally better than domain accounts when you are trying to limit access to your domain, and you can still audit their activity using Windows auditing. Local user accounts may still have access to local system resources. For example, if the accounts are part of the local "Users" group, they have access to everything that the group has access to.
IIS Manager Users (Used with FTP's built-in IisManagerAuth provider) You can manage the accounts from inside the IIS Manager. The accounts do not physically exist on the domain, or have access to anything outside of FTP on the local server. No password policy, and if you decide to allow remote manage through the IIS management service using IIS managers then you will have to consider what to do with the accounts that have already been granted access to manage sites. The steps that are required to use IIS Manager Users is documented in the Configure FTP with IIS 7 Manager Authentication walkthrough.
ASP.NET Membership Users (Used with FTP's built-in AspNetAuth provider) The accounts to not physically exist on the domain, or have access to anything outside of FTP on the local server. No password policy, and it is somewhat tricky to set up. That being said, the steps that are required to use ASP.NET Membership Users is documented in the Configuring FTP with .NET Membership Authentication walkthrough.
Custom FTP Authentication Provider (User-defined FTP custom authentication provider) The accounts exist in whatever store that you choose to implement, but generally-speaking the accounts should not physically exist on the domain, or have access to anything outside of FTP on the local server. For example, you could write a provider that uses a text file for usernames and passwords, or you could write a provider that pulls usernames and passwords from an LDAP server on your network. Requires creating the authentication provider and installing on each system where the authentication provider will be used. That being said, this is not difficult to do, and several walkthroughs have been written that show how to create custom authentication providers at Developing for FTP 7.5.

One last note - all of these account types will work with FTP's User Isolation, so you can restrict any of these user accounts to specific content areas within your FTP site.

Comments

  • Anonymous
    January 24, 2014
    Hi Robert,  I´ve a problem with ASP.NET Membership Users for FTP, here is my scenary: We have a web app that uses Oracle Membership Provider that works without a problem, but We need to add an FTP that uses the same users. So We followed this walkthrough that You wrote (www.iis.net/.../configuring-ftp-with-net-membership-authentication-in-iis-7) that worked great on IIS 7. But on IIS 8 it simply doesn´t work, the error shows: Default Membership Provider could not be found. So, is there a way to do this on IIS 8 ? The Web app works fine in both IIS 7 and 8. Thanks in advance.

  • Anonymous
    January 29, 2014
    I´ve solved my problem using your walkthrough www.iis.net/.../how-to-use-managed-code-c-to-create-a-simple-ftp-authentication-provider but cause I need to use the Oracle database users, I've implemented IFtpAuthenticationProvider like this: Return Membership.ValidateUser(userName, userPassword); But that gave me the same error: Default Membership Provider could not be found. But if I create an instance of the provider like this: MembershipProvider m = Membership.Providers("OracleMembershipProvider"); Return m.ValidateUser(userName, userPassword); Everything works as expected. Is IIS 8 loading the providers in a different way? I hope Microsoft could solve  this strange behaviour.