Starting fromt he bottom up yes, NTNAME must match what OSUser() returns, so you will not be prompted for credentials (you may accessing with AJAX or IE, but not with Desktop for development). That leads me to think that you are not deploying for the time being in clients with AJAX or IE plugin, rather than the Desktop app.
To make tests, I strongly recommend to uncheck the "Strict Exclusion" what is that gets you locked out. Sorry for this bit of theory but I think it's worth taking into account. When you have a section access (fields ACCESS and NTNAME -or USERID and PASSWORD) you are not doing any reduction on the data, so QlikView will only ask for user and password so if you don't have a valid combination you won't be granted. That's ok.
But when you use a reduction field (checking that option in the Document Properties), section access works as if you select the value correspoding to the logging user, go to File menu, Reduce Data, Keep Possible Values. Try that unchecking reduction in the document properties just to check if everything works fine. My guess is that that reduction will leave some users with zero records. Strict Exclusion means that if for a valid combination of user and password (or valid NTNAME) there are no records (possible values) in the document, access to the document itself is denied, instead of showing an empty document.
What I'm missing is if that model of security was working fine with USERID and PASSWORD and it started to go wrong when you used NTNAME. Are you using both? It only makes sense when all users have either USERID or NTNAME, but not both. Actually, it may lead to locking users out. For example, you have NTNAME pointing to your DOMAIN\UserName, and some other lines pointing to USERID and PASSWORD. When you load this document from a different computer or session, they document will never open, as it doesn't mach your NTNAME. (Side note, working with NTNAME will make the document to take longer to load, since credentials must validate against the AD instead the document itself).
ADMIN access is valid when the document is opened for developing in Desktop, not using "Open in server", since all users accessing via clients (even using Desktop with "Open in server") are granted USER access, even when you have stated otherwise in Section Access. That's why you are granted always.
In short, if you only want user and password, uncheck the strict exclusion and even uncheck the "Initial Data Reduction". Users will be prompted, although all users will be able to see all information in the document.
Hope that helps.
Thanks for your response, and for verifying the NTNAME should equal the result of OSUser(). That was my assumption, but I couldn't find it explicitly in the Help file or forum.
I just figured out my issue, and it's frighteningly simple:
I needed to UPPER() my Reduction Field and the corresponding bridge field (back in Section Application). It turns out my NTNAME is just fine. You're exactly right though about Strict Exclusion being the specific piece that was locking me out of the application... when the Reduction Field case mismatch caused the filtering to return a NULL set.
Ugh... At least it was a simple fix.