Note that absolutely none of this is authoritative or directly based on relevant documentation. It is mostly what I found and figured out and guessed and (in some cases) made up. Some of it may be wrong or dangerous or lead to disaster or confusion. I am not taking responsibility here for anything, not even spelling. Read and digest at your own peril!

Some time ago I found an interesting document from 1999. The [Application Specification for Microsoft Windows 2000] is a document published by Microsoft that documents proper application design for Windows Server. I never found a newer version or replacement document. But even this old document gives an interesting insight into how enterprise applications should be developed. It is more least-privilege than today’s standard by far.

Its purpose was clear:

The Application Specification for Windows 2000 defines the technical requirements for applications to earn the “Certified for Microsoft Windows” logo. Applications may carry the “Certified for Microsoft Windows” logo, once they have passed compliance testing and have executed a logo license agreement with Microsoft. This logo lets your customers know that your application offers a high quality computing experience available on Windows.

Since the document is from 1999 it features a few oddities when seen from today’s point of view. Some are outdated, some can be translated into the current situation.

Among those are

  • Obviously references to exlusively Windows 2000 Server (and not newer versions)
  • Instructions for how to deal with 16-bit dependencies of 32-bit programs (today I suppose this is less relevant for 64-bit programs and 32-bit dependencies)
  • References to the Alpha CPU (as apparently Windows 2000 was developed for Alpha until Compaq withdrew support)
  • References to best practices that use APIs now deprecated (SHGetFolderPath())
  • A complete lack of anything about .NET or PowerShell (which did not exist yet)

But there are also points that were new then and are very current still today:

  • Active Directory
  • Win64 (then for Alpha, now very much alive on x64 and ARM64)
  • SSO (Single Sign-On was already something people tried to achieve, it’s still the new thing)
  • “Browser-Hosted Applications”
  • Terminal Services compatibility considerations

This specification is intended for vendors and corporate developers building multi- user applications that run on any of the Windows 2000 Server family of operating systems.

Chapter 5 covers security requirements.

In order for Client/Sever applications to provide secure access to resources and security for their interactions, the application must configure and run the client and server portions in the correct security contexts. This provides access to the resources needed in a secure manner and provides a secure communication channel between the client and the server

It mentions specifically what has apparently been forgotten in modern times:

If a service or service account password is compromised, then the scope of damage that can occur is limited to the capabilities of the account under which the service is running.

It defines the security requirements for certification:

  • Document services that require more than User level privileges to run
  • Win32 clients running in the context of a trusted domain account must support Single Sign-On

Wow. We are still far from that.

For each service account that requires more than User-level privileges, the following must be documented:
1) The specific system resources that normal Users do not have sufficient access to by default.
2) The specific User Rights that normal Users do not have by default in order for the service to run properly.
3) The minimum permissions to the resources identified in #1 that the service account must have in order to run properly.

Of course, today the answer many vendors give for 1, 2, and 3 is “our application has been designed to run with administrator rights”, comically extending the absurd into a farce.

(My April 1st post describes how to conform to such a design and how to run a server in [Enterprise Mode].)

Finally, the chapter ends with the clarification that certification does not require applications to run completely unprivileged or even with defined security requirements. But it does explain that the customer must be told about the situation he will face, giving him the three options of running the application with well-configured permissions, running the application with administrator rights and accept the risk, or buy an alternative product that does not have those problems.

I fear that a lot of today’s enterprise software for Windows would not be able to become certified for Windows Server 2000.

Next: Trusted Computing Base Privilege