Tonight I ran into another example of why I do not like using Microsoft Windows for a server. I don't mean to bash Microsoft, but it just seems that anytime I try to follow an official standard, and then need to use that standard on a windows box, I find the standard doesn't apply. So much for following standards. Ok, that might be harsh seeing as tonight's instance is a case of standards applying, but applying TOO many standards to do such a simple job. Let me clarify...
I have developed a web application for a customer, and the application in question is critical to their business. This means I take extra effort not to disrupt the server the application runs on. Now, for security purposes, we did not add the server to the local domain - after all the server is accessible from the Internet, and it makes sense to add that extra precaution to protect the network data.
An enhancement has been made to the application to allow it to automatically create a directory structure when certain events happen. This process works great in the development environment. And even works well on the production server - until we try to do it the 'right' way. The directory structure being created needs to be in a sub-directory on a server inside the domain. This is where the snag comes in. The new routine honors the concept of UNC paths, but the domain is forcing authentication for the shared resource. This is as it should be. The simple answer, one would think is to add the local account on the web server to the permissions for the folder in question. But this does not work, because windows refuses to see any accounts not registered in it's domain or active directory. And this is where things go so horribly wrong.
You see, with the Linux boxes I manage, this is not an issue at all. I just say account X has permission to resource Y. The account in question could be a local shell account, or from an LDAP directory, or a SAMBA account (the same as a windows account). There are only a small number of steps needed to grant the permissions required. With windows, there are SO many more hoops to jump through.
The reason for this is because of choices Microsoft made in how it would handle authentication. Apparently every account that could be authenticated must be within the active directory tree. Active Directory is an interpretation and extension of the LDAP protocol. But it would appear there is no consideration for allowing access from authorized resources that are not in the active directory.
So, the fix, would seem to be either 1) add the web server to the domain - which I consider undesireable due to the public facing server, or 2) convert the web server into it's own domain, and then tell the local domain to trust the web domain. The option of just moving the target directory is not an option - the drive space involved, and the nature of the data to be stored there excludes it.
Such a simple task - have the web server create a directory automatically - thus results in modifications to the server, which means a reboot of a production server, which means down time for a critical application. It also means potential failure of the box due to the sometimes unstable nature of active directory (the unstable part is usually due to a bad setup though - not the AD code itself), and the same issue could potentially bring down the network until things get resolved. If all goes well, then this is needless concern. But it's been my experience that Murphy's Law prevails in this sort of thing, and I'd rather be prepared for the worst that can happen.
This is NOT something I want to tell my customer just because they want the web server to create a directory. (Admittedly, I may have missed an easier option, but my research thus far does not reveal one...) But what choice do I really have? Luckily, the customer identified the authentication problem themselves and understand that we are doing something that is not quite "normal". These guys are great - they are technically minded, and understand the issues involved. But they still expect me to find a solution through this mess.
That would explain why I'm up at 1:30am on Easter Sunday trying to make this work. Hmmm... I wonder if I can convince them to switch the web server to a Linux server... nah, I'd still have the same problem with accessing the directory on the other windows server... sighs.
For anyone interested, here's how I resolved the problem:
- Made the web server a domain controller and added it as a child domain to the first domain.
- Changed the pertinent web services to run under a specific user account, rather than the system account
- Granted appropriate permissions to the service account on the target share
This list looks short and concise, but does not really highlight the time and effort it took to accomplish those three steps. It turned out to be about a 2 1/2 hour job. Hindsight is always 20/20, and this routine should probably take no more than 20 minutes - excluding waiting for permissions to propagate to some very large directories. But even then, it should have been less than a 2 minute job to simply grant access.
There are some days when I don't like computers.