>>We see interest in AD increasingly driven by customer concern re security. The most recent request was for app administrators to require new passwords every 21 days with specified password length and character types, and not to be allowed to reuse the previous 14(?) passwords.
>>
>>Which is possible via code, but these needs tend to change and once you do it the first time, you're on the hook for each iteration.
>>
>>Link it to AD and the customer can manage such things themselves as they please, or call on MS rather than us if they decide the features aren't adequate. ;-)
>>
>>So, we now offer 3 login modes:
>>
>>1) Legacy mode- our own username/password hashing technique dating back to the 1990s.
>>2) AutoAD - which tries to log the user in as the current AD user. As long as they have app privs, no separate login needed and the app runs. Most useful where users have static workstations and always log into AD as themselves.
>>3) ADLogin- Login dialog with username and password checked against AD. Doesn't need to match the current AD user. Useful where there are shared/always on machines and potential for security breach if people have to log into the PC as themselves to access the app.
>>
>>It's easier than it looks- E.g. Sys(0) contains the current AD user and there are multiple techniques to check usernames and password against AD.
>
>What you are describing above is just a small part of my application User Security module. In my current application (without AD) each user is assigned to a User Group (the application allows the admin person to create any number of User Groups). Each User Group define the privileges (probably couple of hundred). Such as Allow edit This Table. Allow Delete from This Table. Allow This Procedure. Allow This Report (and every report can be set to Yes or No). And so on. So the challenge for me is to associate the AD user with the application User Group. Therefore, the entire User List with ability to assign to various User Groups has to be changed. The application than should allow admin person to add a user from AD to the application and then associate this user with the User Group. Not a trivial task.

For this I used to add a separate field in the users table for the AD Username. If the App username is different from the AD username, then they can fill in the AD Username there, if they don't want to change the App username for some reason.

When the user enters the AD username, lookup in the users table if found in ADUsername field. If not found, lookup in AppUsername field. This way we link to the local user account and the rest is done by checking the status and password in AD.

There is an option if it is allowed to enter the username in the login or not. If you cannot enter the Name, the AD Username is already prefilled and you must provide the password. Disadvantage (or advantage, depending on viewpoint) is, that if another user needs to login, he must log off Windows and login with his own account.

The user roles and access management stays in our software, because this is quite complex and has usually nothing to do with the domain administration.