>>>>Actually it is their IT team who is "pushing" for this change. The users could not care less. I think one aspect they (IT Security) like is that the password in AD is "forced" to be changed every so often (I think every quarter). Where is my app does not require a change of the password.
>>
>>For AD authentication I believe we used to rely on Rick Strahl's LogonUser function in Web Connect's wwapi.prg. From memory it used to need admin rights, though that requirement was relaxed in newer Windows. Worth checking out.
>>
>>My experience: these days it's common to see login pauses of over 30 seconds to re-establish profile on a busy LAN or WAN. Busy workers can't wait that long just to look something up, so shared always-logged-in PCs are becoming commonplace. Customers still want control over user access, so your scenario will be seen more frequently IMHO. If/when you get it going, it would be fantastic to post your working solution here.
>
>The most time-critical shared computer scenarios I've seen have been restaurant PoS. Some of those use smartcards or similar for staff. That does move authentication from the session to the app.
>If we're talking about AD authentication, whether username + (strong) password are checked by Windows or by an app, it still takes significant time for the user to enter.

on embolded: I'd still say it depends.
Scenario 1: pure cash register, 1 or a few more for whole restaurant. Here I'd argue for single task/kiosk similar setups, so no other process can disturb that function. In such a scenario the biz app might shell out to windows or biz specific auth, loading cash register program automatically for the new/reloaded user. App can stay ignorant of security details.

Scenario 2: multi purpose, to stay in restaurant domain for KISS - small tablet inside the table, used to display menu, let customer order or verify ID of customer who had ordered in advance via email or similar login. Customer comes in, verifies CustID which gets saved in a central server as tuple of
{restaurant, table, datetime, customer}. If service is not predefined, but on each visit will be assigned, service member either logs into app or signs on as current user and all other tasks are either web based reloads (web here might be local LAN) or system tasks.

Again, no need to place keys to the castle into the app domain.
Hanks example/appoach deemed more secure

I never hid paranoid streaks ;-)
thomas