...

and then worrying about drive N: being mapped to the right place by the time the server starts up, feed it:

\\FILERNAME\[WEBSHARE\]WWWROOT

instead. This can make life much easier down the line.

Where is the user authentication step done if I do this?

As I remember, a dialog box pops up when you do that, if the system doesn't already have your password cached.

I've no idea what happens if e.g. an NT service refers to a UNC name.

rasmus@bellglobal.com wrote:

Where is the user authentication step done if I [use UNC names]? All my shares have to have an associated username/password since I do not appear to be able to limit by ip who can access individual cifs shares.

You would have to bring this one up, wouldn't you! :-)

Authentication is actually a pretty complicated subject in the NT environment. The average user sitting at their console usually only gets exposed to a relatively small portion of what's going on under the surface. Most people just feed their machine a username and password, and that's where it ends for 'em, but in reality there's a whole cast of "security characters" inside your system, strutting and fretting their hour on the stage. There's processes and threads, security descriptors, security identifiers for users and groups, discretionary ACL's, system ACL's, local security authorities, passwords, access tokens, handles to access tokens.... the list goes on. Generally speaking, you have to be a little more aware of how some of this under-the-covers stuff meshes together when you are trying to figure out what a background process (usually called a "service" on NT) can and can't do.

Thankfully, in the case of your WEB server using a UNC name to access a filer, you just have to be aware of a couple of extra pieces of information. First, when an NT process uses a UNC name to access a network resource, a connection *is* made to the server share by the system on which that process is running. The connection that is made is just the same as a connection that would be made if you mapped a network drive, it's just that you, a human being, can't "see" it anywhere because it's simply being maintained inside the operating system. Second, in the NT networking environment, authentication happens when the connection to a share is made. When it is a background process that is causing that connection to be made, probably be feeding a UNC name into some Win32 system call, NT has to have a mechansim for authenticating that connection automagically, preferably without bugging the possibly non-existent user for a password. To cut a long story short, it has.

Just like UNIX processes, NT processes must run under the auspices of a user account. Every NT process is associated with an entity called a token, which is not exactly analogous to a UNIX UID, but that's a little beyond the scope of this discussion. A token is sorta-kinda like a ticket-to-ride (or not ride) in the NT security architecture, and a process can normally only obtain a token by "paying for it" at some stage along the process creation chain with a valid NT account name and password (processes can inherit their parents token, but can't change their token without having another account's name *and* password available to them). Windows NT services are usually no different. They can be a little different if they run under the auspices of the NT "system account", but I'd really rather not get into that because I don't completely understand it myself! :-)

If you invoke the "Services" applet in the Windows NT control panel, you'll be presented with a list of the installed services on your system. Somewhere among those should be your web server service. If you select it and hit the button entitled "Startup", you'll see a dialog that contains a couple of radion buttons that are collected together inside a "Log on as:" static control. One of the radio buttons tells NT to start the service under the guise of the system account, the other allows you to specifically tell it what user account you would like the service to run under. Notice that you have to supply the password for this account (twice!). That's because either the service or the process that starts the service will need that password in order to obtain a valid token for the service process to run under. I *think* the way that the NT service startup mechanism works is that it obtains a valid user token using the the Win32 LogonUser() system call, and then fires up the service process using the CreateProcessAsUser() function. I don't know that for sure, but if you take a look at the API that the system offers, and then you take a look at the stuff that is being asked for on the UI, you can't help but think "Hmmmm"! :-)

The bottom line is that the service will be fired up with a token that has been legitimately obtained by feeding an account name and password to NT's security subsystem. This token plays a key role in authenticating any network connections that the process may subsequently attempt to make (e.g. when it starts throwing UNC pathnames around), but the basic username/password thing has already been done at that point. The service has already payed for its ticket.

One final word.... assuming you are in a domain environment, don't forget to stipulate the account that you'd like your web server to run under as DOMAINNAME\ACCOUNTNAME in the dialogue, otherwise the ticket-to-ride obtained by the service will likely not be valid on buses that take routes beyond the confines of your local system. The service's token needs to be generated from a domain account.

Hey, you were the one that brought this up! :-)

Keith