Re: How to disable ctrl-alt-del in a screen saver application

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance



I thought so. Assuming that your company has a domain, and that these are
Windows machines, the problem can be easily solved without you writing any
software at all (hardly). First, we need to analyze the problem, break it
down into smaller pieces, and see how they can be fit together.

Okay, first, again, I'm going to assume that your company network is set up
with an Active Directory domain. If not, it should be. If it is, then each
of these computers can be joined to the domain as computers, without any
user association involved. Users and computers are entirely different types
of domain members. Active Directory has the ability to organize these
accounts into sub-groupings, similar to folders in a file system. All of
these computers can be put into the same group and treated in the same way.

Next, each company user should have a domain user account. If they don't,
again, they should. This way, security for all users is handled through a
single Active Directory domain, nice and simple (r).

Once this is accomplished, the users would simply log in to the Active
Directory domain on whatever computer they happen to use. This solves the
issue of locking down the entire computer. Any Screen Saver can be set up to
lock the workstation it is on when it kicks on, and of course, configured as
to the interval of time it waits to kick on. Once the workstation is locked,
any user can log on to it, but will log off the previous user from the
desktop session as a result.

Next we have the issue of the web application with its own security and user
accounts. Each user in the SQL Server database is a domain user (or should
be). They would log on to the machine with their domain user account, but to
the web application with their SQL Server account. So, the web application,
which is aware of both the domain and the SQL Server, is the perfect bridge
between the 2. And, depending on the details, you might not even need
separate user accounts (unless you wanted more granular access in the web
application than to the web site).

The ideal situation would be to migrate the user accounts in the SQL Server
database to domain users, but that isn't entirely necessary. What would be
good would be to implement user authentication at the web site level using
IIS. There are several ways to go, depending on how accessible you want your
app to be to people in different locations. If the computers that access the
web app are on the domain, you can use Windows Integrated Authentication on
the web server, which would eliminate the need for the user to log in twice.
Once logged in to the domain on the workstation, the user's credentials are
automatically passed (encrypted) to the web server, which either grants or
denies them access.

Once inside the web app, if they need more granular access, they can log in
using their SQL Server login, which could enable them to have access to
different portions of the web application depending upon their login user
account. Here's a good article on the relationship between ASP.Net
authentication and IIS authentication, with some recommendations regarding
what model is best to use under what circumstances:

http://msdn2.microsoft.com/en-us/library/ms978378.aspx

As for the logging, that can be done either by the web application, or by
the domain.

I hope you understand where I'm coming from. Active Directory, Windows, and
a domain provide most of what you need, and with greater security (including
encryption over the network). The only remaining part is the melding
together of your web app with the domain security.

--
HTH,

Kevin Spencer
Microsoft MVP
Software Composer
http://unclechutney.blogspot.com

In case of Minimalism, break Philip Glass.

"mgdev" <mgdev@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:0C33D2D7-434B-469F-B155-BF1F4DC6FF78@xxxxxxxxxxxxxxxx
No problem.

I have an enterprise level web application that users use thruought the
company. This web application uses its own security and stores the
information into a SQL Server database.

Thruought the company there are a lot of workstations that are not
specificlly assigned to any person. People come and go as needed to use
these machines. These machines are used to access the above web
application
among other things (printers, etc...). Due to the diversity of the
environment these machines are setup as different workgroups and are not
tied
to any domain/active directory. Every user that uses these machines has a
user account in the enterprise web application.

What we now want to do is to be able to know who, when, and where people
are
logging into these computers. This information needs to be logged into
the
above SQL Server and be accessable through the enterprise web application.
This solution will also be used to deny access to the local machines for
users that don't have a valid user account. In other words when a user
walks
away from the machine it needs to be locked down. Then a user with a
valid
web site user account should be able to access the machine by keying in
their
web site username and password.

My solution to this problem is to build a web service at the web site that
contains a call to validate a username and password. Then to build a
Windows
based application to install at the client that will lock down the
computer
after a period of no activity and require a username and password to
access
the machine. The local application will call the web service to validate
the
user account.

I've built a sample of a screen saver using VS2005 and VB.net. I have set
it up to be activiated by Windows as a screen saver and it works great.
The
only problem is that the user can bypass my security by using Windows
commands like ctrl-alt-del, Win-E, or alt-tab.

This appears to be a small problem at the end of a long road but as you
said, it may be easier to back up and take a different approach.


.



Relevant Pages

  • Re: Font hell - please help
    ... you may have to reconstruct your user account. ... >> In fact, every update of KDE stuff of any kind, I always do that. ... I can browse the Windows machines no problem, ...
    (alt.os.linux.suse)
  • Re: Q: Named pipes and Windows (integrated) authentication
    ... >Mixed or SQL Server security modes. ... The objective was to use Windows ... The two machines are also in the same workgroup.<<Lou. ... Lou>>The Administrator account I was referring to is the client ...
    (microsoft.public.sqlserver.connect)
  • Re: Not associated with a trusted SQL Server connection - Windows
    ... I checked the user accounts on the SQL server and I ... > Using Windows authentication in SQL server DOES NOT mean that as long as you ... and SQL Server accept who you are as your user account claims. ... > include authentication and authorization. ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: SQL_Server_does_not_exist_or_access_denied
    ... When this happens yes I can ping by name and by number. ... open windows are being over one another for all the open windows... ... > SQL Server authentication, and have you tried both (e.g. maybe the domain ... > Can other machines connect to the SQL Server machine during this time ...
    (microsoft.public.sqlserver.connect)
  • Re: Not associated with a trusted SQL Server connection - Windows
    ... Using Windows authentication in SQL server DOES NOT mean that as long as you ... and SQL Server accept who you are as your user account claims. ...
    (microsoft.public.dotnet.framework.adonet)