We are sometimes asked for a deeper explanation as to how our software works and the operating system interfaces or APIs on which we rely. Our software architecture is fairly simple when compared with other Web applications. All of our software is written in C# using Microsoft Visual Studio. We rely on Microsoft's .NET Framework for many of the web, Windows, LDAP, and Internet Information Server (IIS) API's that we leverage. We also use AJAX controls from Telerik and some open source JQuery tools. Our software installer uses Wix.
All client-> server communication is handled via HTTP or HTTPS from most any modern Web browser. (IE 10 or later, Chrome, or Firefox.) For an intranet application only, HTTP is usually sufficient. However, if you are publishing any of our applications to the Internet, then we recommend using HTTPS instead. Client-to-server authentication is handled by either a logon form (basic authentication) or via Integrated Windows Authentication.
On the IIS Server, our applications are just another virtual directory/virtual application on your Web server, so if the Web server is enabled for HTTPS then our application will leverage HTTPS. We do require Windows Server, though, since some of the ASP.NET components are not available on Windows desktop clients or on Windows Web Server edition or on Server Core builds. We leverage the Microsoft .NET Framework v4.0 / v4.5 and ASP.NET components of IIS. Our applications run under an IIS Application Pool and typically require that the App Pool be configured with the Network Service identity.
On the server, we have work processes that run inside of an IIS Application pool. HTTP requests come in to the IIS server, we read those requests and then send the requests or updates on to a Windows Active Directory domain controller using LDAP. IIS Server -> Active Directory communication is standard LDAP v3 functional calls and we authenticate to the Active Directory using Kerberos. (The IIS server *must* be a domain member.) We do not support LDAPS. We have had a few customers ask about this option. For us, this is just a simple check-box when compiling our code, but we found supporting LDAPS installations to be exceedingly complex since we were often called in to support certificate errors and certificate authority problems in our customer’s environments. If you require encryption between the IIS server and Active Directory, we recommend you enable IPSec instead.
All updates to the Active Directory are performed in the context of a proxy account (we sometimes refer to it as a “service” account even though we don’t really have a service running anywhere. Read our TechNote on the Service-Proxy Account.
We are also asked if the IIS Server on which our applicatoins are installed should be installed in a perimeter or DMZ network. We recommend against this due to the fact that the IIS server must be a domain member. Domain members require quite a few TCP and UDP ports be opened to internal systems which can possibly compromise security.
On the server, we use a series of configuration files that use XML formatting to localize the software, to enable features, and set options for fields and drop-down lists. These are found in the .\Settings folder for each application. We recommend using a good text editor like Notepad++ when editing these files. And, always keep a recent backup copy.