Win XP integrated authentication

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

We are developing a WinForms application which needs to user Windows
integrated application authentication. This means that there is no separate
user name/password for the application. The user should be able to access the
application with his windows security context.

Am proposing a design, by which the as and when the user invokes the
application the application will check for the 'windowsIdentity' and perform
a 'IsAuthenticated' check and allow the user to access the application.

Also there is another requirement that the solution should support 'Fast
user switching'. Similar to Windows XP's 'Switch user' feature.

The problem is I can't use this feature is disabled with Win XP systems
which are part of a domain. I cannot upgrade to Windows Vista to get this
feature enabled.

Is there any other way I can implement Fast user switching and at the same
time using windows integrated authentication?

We don't want to go for application to handle windows user name/passwords,
as we feel it is not secure to do so. Also by making the application handling
user name/password, the whole purpose of having windows integrated
authentication will get negated.

Thanks in advance
 
A few suggestions, you can tell which user is logged-on by way of environment
variables, or from the 'volatile environment' section of the registry. The
environment variables are best as the system won't normally let a user change
their default values once the desktop is running. (Type 'set' to see a list)

To tell if this user is genuine, and has entered a correct password, there
are DLL calls to do this, but a simpler approach on a LAN is to check for
access-rights to a server share. If the user has no rights we assume he
didn't log on, or has somehow reset his password, in which case access to
the program is refused.

(In fact, if the program code is in this share there is no need to do any
specific checks as it won't be accessible anyway if the user hasn't
authenticated in a way that satisifies the network. )

Suggest you avoid Fast User Switching unless you really have no alternative.
It leads to all kinds of confusion, and sometimes loss of data when a user
fails to realise he's left unsaved work in a hidden session. Most users
think "Switch User" means "Change User" and not "Log two on at once." This is
probably why MS decided to only allow it on home systems.
 
Dharan said:
We are developing a WinForms application which needs to user Windows
integrated application authentication. This means that there is no separate
user name/password for the application. The user should be able to access the
application with his windows security context.

Am proposing a design, by which the as and when the user invokes the
application the application will check for the 'windowsIdentity' and perform
a 'IsAuthenticated' check and allow the user to access the application.
Click to expand...

It sounds as if you intend for the authentication check to be included in the
program that the user is running. This isn't secure; the user could, for
example, run the program under a debugger and bypass the security check.

If the software has client and server components, authentication should always
be at the server component. You might, for example, use Windows pipes and set
the permissions on the server end of the pipe to only allow authorised users to
connect.

If the software doesn't have a server component, you need to secure the
underlying data the program is manipulating so that it can't be accessed by
unauthorised users - in which case the program doesn't need to do any
authentication. If an unauthorised user tries to run it it simply won't work.

In general terms, what does the program do and how is it structured?

Harry.
 
Ours is a client server application. My concern is even if the authentication
is happening in the server, as you said , a hacker can skip the code which
calls the server side authentication component.

My idea is to inherit windows security context and implement application
based authorization to authorise the application.

What do you think?
 
Dharan said:
Ours is a client server application. My concern is even if the authentication
is happening in the server, as you said , a hacker can skip the code which
calls the server side authentication component.
Click to expand...

Typically the server should be designed to refuse to serve a client which has
not properly authenticated itself. This is the only secure design.

How do the client and server talk to one another? If this hasn't been decided,
you might want to consider using named pipes. When the server end of the named
pipe is created, the server program can assign permissions to it; for instance,
it can be configured so that only members of a particular Windows group can
connect to it.

In this design, provided the proper permissions have been set, neither the
client software nor the server software will need to do anything else. When the
client software connects to the named pipe the current user's credentials will
be automatically used to establish the connection. If the user doesn't have
permission, Windows will automatically reject the connection; the server
software doesn't need to check.

Harry.
 
Back
Top