The whole idea here, AFAIK, is that authentication and authorization tasks should normally occur before the web-page code ever gets control in the first place.   In other words, “if you’re not authorized, you never get a chance to get here, period.”   (And so, if you do get this far, Apache already knows a good bit about you.)

Although Perl obviously does provide support for the low-level NTLM interfaces, AFAIK these are intended to be used when “the user has already passed a series of cursory examinations” (i.e. he is an employee of this company... therefore, he has managed to show-up at this internal web site), and now we want to know more details (i.e. is he the CEO or not? should we call him “sir?”).

You’ll specify the “cursory examinations” (which might well be very rigorous, indeed...) using the appropriate Apache configuration directives for the virtual-host or the location(s) within that host.   You can do a lot with these, and you should determine to do everything that you can in this way.

In any corporate setting, you definitely want to set up your intra-net websites such that: “no one who is not authorized to be here cannot get here, period.”   You want to abdicate that entire decision, “courtesy of Apache or IIS as the case may be,” entirely to the pre-existing (NT...) security infrastructure.   Then, if necessary, you want to use interfaces such as these to make “enhanced capability” (i.e. CEO...) determinations ... knowing (with confidence!) that you have no need to prove that the user belongs here.

This is, of course, radically different from “the great unwashed Internet-at-large,” where any old dammed fool can just show up unannounced.