As a former programmer, using Active Directory for permissions, it’s greatest asset is it’s greatest detraction: you’re trapped into the Microsoft ecosystem for system credentials. The assets were that Microsoft’s Windows platform provided a way to store the credentials that your application will run under, in Services or IIS identity and that password was encoded (or better yet I learned last year, using system accounts, the password for Service accounts were auto-generated). This meant your configuration files never contained the credentials to access the remote service you are trying to access, but only contained the location. This primarily only worked with remote services made by Microsoft.
Actually…
When I was a younger programmer, I rarely concerned myself with system permissions granted to my application, b/c I was usually only involved in creating a proprietary application permissions, or whatever application privileges were needed granted, were usually fulfilled by my programmer group/role permissions.
And you didn’t realize that different privileges were used in production, until the first deployment test. And then you also had to worry that the application didn’t have access to resources it wasn’t supposed to, b/c as a programmer, you had access to almost everything, to effectively do your job. It was often overlooked until after you told your boss you were done.
So if you accessed SQL server in your application, your application might be publicly accessible. But you want to lock down what the application can access on the server that it was deployed to, or even other network resources secured by Windows Active Directory, you told the Windows Service, or IIS worker process to run as that identity. It would secure the password, and when it started your application, it would run as that user. When the application tried to access files on the Windows Network, only the files that that user would have access to would Windows allow access to. When the application tried to access SQL server, SQL server will ask Windows Active Directory who this person is, and if he is one of the Active Directory users assigned to SQL Server, then SQL server will check internally if this user has access, to the operation to the data it was requesting.
Alternative application design may be a application that has private authentication database implemented in a proprietary method, Windows still needs to grant bulk access rights to the application to every file and Microsoft product database that it needs access to, but it will be up to the application to identify the user accessing it and segment the resources available to the user, that Windows has granted to the application. So if your application wasn’t set the correct Windows permission, obviously the application’s private user store will not have access to resources managed through Windows (presumably thru Windows API calls, via the platform that your application was built on).
Another way an application can be implemented, is as a client-server desktop app, and then when the program starts when the logged in user double clicks in, the application runs as the logged in user. And whatever Microsoft database and file that this user has access to, the application has “inherited” those permissions. So you can see how this has the potential to simply permission, and access control.
Since Active Directory users are all centralized to the domain (as opposed to each computer system has it’s own local user database), the SQL server has the same list of users and passwords, as the server that your application has access to. To disable the application, you only need to disable the user. And the application won’t run. Theoretically, any instance of application currently running should lose access to files it has, and it should lose access to the database, provided the permissions aren’t cached in some fashion. You can check yourself, if your operational requirements fits what your application using Active Directory, as it’s primary method of shutting down an application and resources it has access to.
There are other advantages invisible to the user b/c there is one Active Directory database, however Windows Server domain distributes copies to all domain controllers, it has some redundancy and distributed horizontal scaling in it’s design.
“admin” user is not a default created by Windows Server
Window’s default user is named “Administrator”. My Powershell script creates a user in Active Directory named “admin”.
This is the reason why my Powershell script(link below) that starts a Windows Server domain, adds a “admin” user. B/c, during login process, if a user doesn’t exist in the local Windows database, it will automatically try to login to the domain with it, if you did not provide the domain prefix or suffix. While the “Administrator” user exists in both local and AD databases, and to login using domain database, you need to explicitly add the domain prefix/suffix to the Administrator username. A lot less typing just logging in with “admin”.
They also say it is best practice to disable or rename the default Administrator user, but unless you making corporate policy, I suggest you just be a lemming and do what they tell you, and copy their reasons for it, until it becomes a stupid idea.
User access to Active Directory in most Windows products for enterprise, is seamless. Windows 10/11 Educational/Enterprise has modules built to join the computer/OS to a Active Directory user database in a domain controller, after which the computer has limited access to some Windows Network services, and the user now has option to login to the domain. I’m not sure, but I think all versions of Windows can access network files via SMB by logging in with the correct credentials to the network resource, even if the network resource was controlled to domain permissions (this is b/c you’re always giving the remote credentials to the system you are accessing, and it checks against the database it is assigned to check). When you login to a computer joined to a domain, it still FIRST tries to login against the local database first. This is problematic only for the default Administrator user, as a user with this name exists by default in every installation of Windows, and is one of the first users in Active Directory. You actually need to indicate you are logging to the domain, by suffixing or prefixing the Administrator user with the domain name.
But this simplification now comes at a cost, as you need a copy of Windows to develop your application against, to verify using Active Directory’s subsystem to provide either system permissions, or user access. And depending on how integrated your application is, with the Windows architecture, porting it to other platforms may be more difficult. One interesting and loosely coupled example of integration method I saw last year at BCIT, is where “Cisco Unified Communications Manager” has a private user/administrator database, but integrated it to Windows Active Directory by accessing it’s LDAP API to sync users in a Windows Active Directory OU to the Cisco private CUCM user (think administrator or operator, not VoIP phone users) database for it’s telephony solution servers. And I can’t think of a critical reason why this is necessary, except as automation of centralized user access.
If you want to build a homelab with application deployed on several physical tiers, that has Windows AD as it’s centralized permission source, I have built a Powershell script that can build a Windows Active Directory environment out on Hyper-V
If this seems interesting for you, I wrote a Powershell script that will create a simulation of a Multi-site Windows domain in Hyper-V. You just need your own copy of Windows Server 2022 ISO. My class provided an evaluation copy. You might need to find your own copy, and registration key. But Hyper-V is available in Windows 10 Pro, Enterprise, and Education editions of Windows 10/11.
It is set to create 4 sites with 2 domain controllers (DC) each site, and a router using Windows’ Routing Services. This requires minimum of 32GB of RAM to have all VM running. You can alter the script to create only 1 DC per site, to save memory. Or change the arguments, to create less sites. To try out Active Directory, you really only need 2 DC’s, to observe to domain creation vs domain joining process, note the dependence on DNS services and to observe replication of the Active Directory(AD) database between them. Configuring a different site, simply allows you to adjust the replication schedule between DC’s organized by subnets, which are located in more remote and over less bandwidth network connections. But in operation, you only need 1 site and 1 DC, to operate a Active Directory services.
One of my last assignments in a Windows course, inspired me to automate creation of Windows domain in a Powershell script. It is in the Github below. A video explains the script.
Github:
https://github.com/studio-1b/Powershell-Examples-to-Create-AD-Sites-in-HyperV
Video explaining how to use the script:
Video of nearly uncut process of running the script(I had to edit out the registration key), so you can check what I did to run the script. But no comments or explanations in it :
Other reading material:
https://jumpcloud.com/blog/active-directory-purpose