Alternatives for Account Management in FileZilla Server - ftp

For our FTP server, my company has installed FileZilla Server version 0.9.41 beta. The server is working well and we're pleased with it. My question involves account management - FileZilla Server includes an easy-to-use UI for managing user accounts, but I would prefer to handle user accounts with the rest of our customer info, like logins for the company website, notes of the last support issue, and so on. I don't see a way to configure FileZilla Server to accept a different account manager. Is there a plugin architecture that I can code against, or better, modules that I can install that would give me the flexibility I'm looking for? Ideally, I'd be able to configure FileZilla Server with a SQL connection string and CRUD queries, and then manage the account store myself.

There is a XML file called "FileZilla Server.xml" in your program directory. In this file you can edit all relevant options regarding settings and user management of the server.
Don't forget to reload the config with "/reload-config" afterwards.

Related

is it possible to implement kerberos authentication in azure web app?

We have an application which is hosted on the on-premises Windows server (IIS) server
now I created a windows server on azure and building a web app for it.where the application needs to authenticate the user by windows server (DC) using kerbrose protocol but I couldn't find any documentation regarding this from Microsoft's side
Is the above query possible to be implemented in the azure web app?
No, it's not possible. Windows Authentication is something for on-premise deployments. For Azure Web Sites Azure Active Directory is clearly the best option. Sync from AD to Azure Active Directory is also quite easy to setup.
If you still want to absolutely use Windows Auth and host your website on Azure, you can create Windows VM and host your website there. You then need to join the VM to your AD. To this, both VMs must be in the same network. So if your VM is on-premise you will need to create an site-to-site VPN.
For more information, follow this SO which also discussed about this.
If your intention is to join the VM hosting the website to a domain then as others have mentioned, this isn't possible.
However, doing Kerberos authentication itself within an Azure website isn't particularly difficult, but it does require manual implementation. Windows natively handles all of this for you on domain joined machines and and IIS exposes that functionality. Since you can't domain join you have to manually do all that heavy lifting and request and validate the tickets yourself.
This involves creating a service account in Active Directory and keeping the account password in sync. Once you have that you need to indicate to the browser that it needs to negotiate auth, which is done with the WWW-Authenticate: negotiate header on a 401 response. The client, if configured to send tickets, will send a ticket in the Authorization: Negotiate YII... request header on a subsequent response. At this point you need to shove that negotiate header and that original service account password into something that can validate Kerberos tickets. Windows SSPI will do this for you, but it's a pain. I built a library that'll do this for you: Kerberos.NET. YMMV with what works best for you.
All of that said, it may be more beneficial to switch over to a more modern authentication mechanism like OAuth/OpenIDConnect/SAML.
There are several ways depending on if you have to allow access to users who are associated with a on-premise Active Directory or not.
You should have a look at this service: https://learn.microsoft.com/en-us/azure/active-directory-domain-services/
It will offer an Active Directory within Azure where you can domain join your VM to and then using Kerberos as authentication protocol (should work the same way like on prem).
The other option would be to create a new Active Directory within your Virtual Network (via 1 or 2 small Windows Server VMs where you create the AD).
The good thing if you are using Active Directory Domain Services would be that you could extend it to your on-prem Active Directory by synchronizing or federating your on-prem AD.
There are more informations regarding these scenarios here:
https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-hybrid-identity
For a Azure App Service - Web App you would connect it to your Azure Active Directory (AAD) and use the hybrid identity model to allow users who originate from an on-prem AD access to it:
https://learn.microsoft.com/en-us/azure/app-service/configure-authentication-provider-aad
Hope this helps a bit, it is a rather complicated topic you are digging into.

Can my application server find out which Java hosting provider it lives in?

I'd like to have my Scala application server find out if it's running inside Heroku or CloudBees or Cloud Foundry or something else. Is there some standard way of finding out which Java hosting provider is currently in use? (if any)
Perhaps the hosting provider's firewall/load-balancer/whatever adds some standard HTTP header that the app server could check? Or perhaps it's possible to do hosting provider specific checks somehow, for the most popular hosting providers?
Background: The app server could then show helpful tips to the server admin that tells him/her how to view the server's log files. This would be useful during the initial setup of the server + database, because then the admin needs to find a certain magic password in the log file, which s/he then uses to get access to the admin interface web pages the very first time (before any admin user exists in the database, see this security question). — The installation would be more user-friendly, if the server could tell the admin exactly how to view the log files (which varies from hosting provider to hosting provider).
In the case of cloudbees there are several ways, none of which are guaranteed to be future proof (given changing containers).
Perhaps what is needed is a standard environment variable to make this doable.

User configuration for TeamCity and Plastic SCM

I'm currently 'playing' with Plastic and their (brand new) TeamCity integration plugin.
The plugin blurb says "When installing Team City on Windows systems, it normally uses the SYSTEM user account. We recommend changing the user that executes the Team City application."
The thing is, I can't work out what kind of user I should substitute: I would like to be able to access Plastic (on the server) using AD, but wouldn't that mean that TeamCity would also have to run with a network user in order to be able to access Plastic?
An alternative (for me accessing Plastic) would be user/password - but I can't make the TeamCity service run with user/password.
Am I missing something obvious, or is the paint just too wet?
I'm also using PlasticSCM and the Team city plugin, this is my configuration:
For the server: configure your PlasticSCM server with LDAP authentification and select "Active Directory" as the server type.
For the client: configure your PlasticSCM client with LDAP authentification, use your credentials and try the "Test connection" button.
The client setup will generate a "client.conf" file at "C:\Users\your_user\AppData\Local\plastic". This file is used by PlasticSCM client to authenticate with the PlasticSCM server.
So, if your TeamCity service is running with the administrator account you have to place this file in your Administrator "...\AppData\Local\plastic" directory. If you change your TeamCity service to be run with your system account you don't need to do anything, the file is in the right place.
You have another option (if you are still running the TeamCity plugin as Admin), place the "client.conf" file where your "cm.exe" file is. Because the "cm.exe" is going to try to find this file first on its own location and then in the current user "AppData\Local\plastic" directory. This option is only valid if you are the only user working with PlasticSCM in the machine.
Hope it helps!

Microsoft SQL Server on a VPS for hosting multiple client databases - Is this the right way to go?

Good morning,
I have found that many of my customers have MS Access already installed on their PCs. Although Access is very limited as a data store, I have found that it is great for deploying low-cost front-ends for entry level customers.
I want to start renting a VPS, so I can host customer databases using Microsoft SQL Server 2008, which they can access using a locally stored Access front-end. I do have a few questions though:
In order to access the remotely hosted databases, and use the security features, would the VPS need to be set up as a domain controller, using AD DS? If I am hosting multiple customer databases, this is not an option.
What I envisage is being able to set up a simple MS Access front end, to access a MS SQL Server database on my VPS. For security, I would want the database to use the Windows account on the client machine to authenticate, and also to provide basic data change tracking.
Is this possible? Or, will I need to set up a server for each client and have it configured as a domain controller, etc?
You can have many databases on the same server, so for each client you d not need to setup a separate domain controller. Only the connection strings will be different.
You can use SSL for establishing connection with the remote server to make the process more secure. You can also make a few web services to play with the data (CRUD operations), this would also make things more manageable.
take care :)

What is the best way to restrict access to a development website?

I have a site i am working on that i would like to display only to a few others for now. Is there anything wrong with setting up windows user names and using windows auth to prompt the user before getting into the development site?
There are several ways, with varying degrees of security:
Don't put it on the internet - put it on a private network, and use a VPN to access it
Restrict access with HTTP authentication (as you suggest). The downside to this is it can interfere with the actual site, if you are using HTTP auth, or some other type of authentication as part of the application.
Restrict access based on remote IP. Just allow the IPs of users you want to be able to access it.
Use a custom hostname. Have it on a public IP, but don't publish the hostname. This means make an entry in your HOSTS file (or configure your own DNS server, if possible) so that "blah.mysite.com" goes to the site, but that is not available on the internet. Obviously you'd only make the site accessible when using that hostname (and not the IP).
That depends on what you mean by "best": for example, do you mean "easiest" or "most secure"?
The best way might be to have it on a private network, which you attach to via VPN.
I do this frequently. I use Hamachi to allow them to access my dev box so they can see whats going on. they have access to it when they want , and/or when I allow. When they are done I evict them from my Hamachi network and change the password.
Hamachi is a software VPN. Heres a link to Hamachi - AKA LogMeIn
Hamachi
They have a free version which works quite well.
Of course, there's nothing wrong with Windows auth. There are couple of (not too big) drawbacks, though:
your website auth scheme is different from the final product.
you are giving them more access to the box they really need.
you automatically reimaging the machine and redeploying the website is more complex, as you have to automate the windows account creation.
I would suggest two alternatives:
to do whatever auth you plan on doing in the final website and make sure all pager require auth
do a token cookie based auth - send them a link that sets a particular token in a cookie and in your website code add quick check for that token before you even go to the regular user auth
If you aren't married to IIS, and you need developers to be able to change the content, I would consider Apache + SSL + WebDav (aka Web Folders). This will allow you to offer a secure sandbox where developers can change and view the content without having user accounts on the server.
This setup requires some knowledge of Apache so it only makes sense if you are already using Apache or if you frequently need to provide outsiders access to your web server.
First useful link I found on the topic: http://pascal.thivent.name/2007/08/howto-setup-apache-224-webdav-under.html
Why don't you just set up an NTFS user and assign it to the website (and remove anonymous access)

Resources