Hi Doug,
I appreciate the added details, and I'm not writing to disagee, but to clarify. If user ID_A logins in, he might not have full rights to the application. I understand that. Network security might be set up to allow access to the DBFs, but the user can't edit, say, the SecretCodes table. Why not make a group, SecrectCodesEditors, and put the folks allowed to edit in it. The rules object for the business object SecretCodes, checks to see if the User is a member of that group. In some instances, the reason not to do this type of thing is that the network admin guy and the application's guy just don't get along..., and it results in just what you were saying. You spent a lot of time that you could have spent on improving functionality of the app writing security code.
After writing my note yesterday, I did some research on IsMemberOfGroup code. (I actually haven't implemented security through groups, it just seems right to me.) I can find Novell ActiveX controls to discern the group membership of users, but I don't see it available for MS. I thought the Network object would have it. I guess the active direction stuff has it, but I don't see anything that would deal with this for straight NT server.

>The ideal scenario is to have one login. This has been discussed over and over, and is even a management directive for LAN/WAN access which involves multiple domains.
>
>There is a caveat though, because with applications and some databases, I have been unable to make them into a "one size fits all"
>
>Doing applications for the intelligence community involves compartmented information, and the most expedient way to control this is by setting up fairly elaborate security within my application, which is on top of the secure network login, and/or even a departmental login. The security regulations detail elaborate controls over who can see what, and who can alter or edit/update records. The application can even test for the userid that was used to login to the network and prevent that userid from being used for the particular application. Much of this has been flowing over to the corporate side as well, and there is still the requirement that the application control the disemmination of classified data (classified at several levels) regardless of the clearance level or discretion of the system admin or DBA. In some cases the actual data in each field is strongly encrypted and is decrypted only to certain users.
>In this scenario, the data cannot be browsed directly outside of the application.
>
>I am also starting to see a trend by public corporations toward protecting their HR and other sensitive proprietary data in a similar, if not yet as elaborate manner; as the demand grows to make everything,everywhere available to the executive's desktop..
>
>Of course, it is much easier and faster to develop applications that have little or no built-in security other than user level (i.e data entry/admin/read-only, etc.) relying instead on the network security. Personally I would prefer developing this way, and could spend more time and effort on the design and usability of my application. But in the end requirements differ from application to application, thus 'one size fits all" will not necessarily apply.