Authentication by the Server

[david]

Hello!

I am attempting to discover the remote user for an INTRAnet site, but cannot
see how to do this cleanly. It seems so simple, too... (IIS is NOT being
used)

ALL I need is the user ID that logged in; when they log into their
workstation, that is good enough for this intranet set, and I am willing to
believe who they say they are. I would like them to be automatically logged
into the site using their ID (this part is simple, assuming, of course, I
actually had the ID). For this application, I do not need to know, nor even
care about, their password.

But the problem comes when I try to GET the remote user ID. I realize that
in theory I can use something an Apache module (like mod_auth_sspi), but
these authenticate against the web server, which in this case is in the DMZ
and ignorant of all other users. Simply getting the user name with PHP
returns the user name that PHP is running as, which is exactly what I do not
want.

I saw a brilliant hack that dug the user name out of NetBios in PHP, but
naturally, NetBios is turned off.

There seems to be ways to do this with .htaccess, but the users are stored
in Active Directory. The goal here is that once the user is added to the AD,
then they should have access to the intranet. I can actually handle the
security settings from within the intranet via LDAP. That works like a
champ. But it works because at that point I know the User ID. I want to
figure out what the user ID is in the first place. So, using .htaccess is
not really an acceptable solution.

One suggestion made was to start IE with a .bat file that passes the user
name as a parameter (i.e.; iexporer
http://mysite.mydomain.com/login.php?login=%LOGINNAME% but this makes the
user use a certain browser and click a certain link/icon.) I would like the
server to be able to cope with this all by itself.

It seems that no matter what direction I go, the door is closed. What is
really frustrating is that it IIS does this out of the box! Switching to IIS
is not an option.

Thank you for any pointers!
david

The environment is:
Server: Apache/2.0.48 (Win32) mod_perl/1.99_12 Perl/v5.8.3 mod_ssl/2.0.48
OpenSSL/0.9.7c. Clients are Windows Workstations. Server is Windows 2000.

[Mike Discenza]

"david" <someone> wrote:

Hello!

I am attempting to discover the remote user for an INTRAnet site, but
cannot see how to do this cleanly. It seems so simple, too... (IIS is NOT
being used)

ALL I need is the user ID that logged in; when they log into their
workstation, that is good enough for this intranet set, and I am willing
to believe who they say they are. I would like them to be automatically
logged into the site using their ID (this part is simple, assuming, of
course, I actually had the ID). For this application, I do not need to
know, nor even care about, their password.

But the problem comes when I try to GET the remote user ID. I realize that
in theory I can use something an Apache module (like mod_auth_sspi), but
these authenticate against the web server, which in this case is in the
DMZ and ignorant of all other users. Simply getting the user name with PHP
returns the user name that PHP is running as, which is exactly what I do
not want.

I saw a brilliant hack that dug the user name out of NetBios in PHP, but
naturally, NetBios is turned off.

There seems to be ways to do this with .htaccess, but the users are stored
in Active Directory. The goal here is that once the user is added to the
AD, then they should have access to the intranet. I can actually handle
the security settings from within the intranet via LDAP. That works like a
champ. But it works because at that point I know the User ID. I want to
figure out what the user ID is in the first place. So, using .htaccess is
not really an acceptable solution.

One suggestion made was to start IE with a .bat file that passes the user
name as a parameter (i.e.; iexporer
http://mysite.mydomain.com/login.php?login=%LOGINNAME% but this makes the
user use a certain browser and click a certain link/icon.) I would like
the server to be able to cope with this all by itself.

It seems that no matter what direction I go, the door is closed. What is
really frustrating is that it IIS does this out of the box! Switching to
IIS is not an option.

Thank you for any pointers!
david

The environment is:
Server: Apache/2.0.48 (Win32) mod_perl/1.99_12 Perl/v5.8.3 mod_ssl/2.0.48
OpenSSL/0.9.7c. Clients are Windows Workstations. Server is Windows 2000.

A couple of questions first, before anything else.

Security? Say a person is at their desk and walks off to go to the bathroom
and doesn't lock their workstation. What is to stop a malicious co-worker
from jumping on their machine and doing something on the 'intranet' that
could get the potty-breaking worker fired? If you're automagically logging
the person is, the answer is nothing.

What in the world is your INTRANET doing in the DMZ?!! In my, sometimes
warped, way of thinking that site should be behind at least one firewall
with no access from the outside world. There may be a legit reason for
this, but it raises some concerns for me.

Now for a couple of answers to the question:

How about a session cookie approach. Have the person log in, register a
session cookie, and they're set. Since you have AD this shouldn't be that
hard to do. So what if is another time they have to log in -- you can sell
this approach as a security precaution.

Another approach, also using cookies, would be to register a cookie that
expires in a month or so. But, this would raise a concern with me, again
the malicious co-worker thing.

Even these suggestions are flawed and wouldn't work where I work. We have
several people that share workstations, so registering a session cookie or
an expiring one would not be practical.

I think the way our intranet group designed the site is about the best
approach. You login, a session is started. If you are inactive for 60
minutes you're automatically logged out.

Honestly, I think you're wasting your time with looking for and SSO type
solution. Code something that works with AD and makes the person log in
and be done with it.

[david]

Mike:

Thank you for your comments. They are much appreciated.

I can answer a couple of your questions, first off.

Have you ever heard the lyrics that go "I fought the law and the law won?".
Regarding your SSO comments, I could not agree more. Unfortunately, however,
management has deemed that a SSO, despite the inherient security flaws, is
the way that it will be done. Personally, I am dead set against it, but in
the case, it does not matter because it has been decreed to be a Good Thing.
We will not talk about the wildly varying security levels within the
intranet.

As for the DMZ, this too is necessity. The intranet is available from the
outside world (but outsiders do not get the benefit of the SSO). The DMZ is
probably the best location for this. But I am open to suggestions, bearing
in mind that it must be available to insiders and outsiders.

I have thought about the cookie thing. Is that specific to the user or the
workstation?

I already use sessions, and keep the session alive until the browser window
is closed (again, this flies in the face of seemingly good security. Then
again, it is the way it is by preference.) I already go against AD, so that
is not a problem. I just want to automatically discover the User ID (login
value), which just didn't seem that hard. At first.

My hands are also tied on the SSO. I have no choice. My entire goal here is
to (against seemingly common sense, but sometimes what corporate America
wants, corporate America gets, because they pay the bills at the end of the
day, and food on my table has always been attractive to me) provide an SSO.
I have already already waged the battle as to whether or not this is a good
idea, and, sadly, lost.

Thanks so much, Mike!
david

ALL I need is the user ID that logged in; when they log into their
workstation, that is good enough for this intranet set, and I am willing
to believe who they say they are. I would like them to be automatically
logged into the site using their ID (this part is simple, assuming, of
course, I actually had the ID). For this application, I do not need to
know, nor even care about, their password.

But the problem comes when I try to GET the remote user ID. I realize that in theory I can use something an Apache module (like mod_auth_sspi), but
these authenticate against the web server, which in this case is in the
DMZ and ignorant of all other users. Simply getting the user name with PHP returns the user name that PHP is running as, which is exactly what I do
not want.

It seems that no matter what direction I go, the door is closed. What is
really frustrating is that it IIS does this out of the box! Switching to
IIS is not an option.

Thank you for any pointers!
david

A couple of questions first, before anything else.

Security? Say a person is at their desk and walks off to go to the bathroom and doesn't lock their workstation. What is to stop a malicious co-worker
from jumping on their machine and doing something on the 'intranet' that
could get the potty-breaking worker fired? If you're automagically logging the person is, the answer is nothing.

What in the world is your INTRANET doing in the DMZ?!! In my, sometimes
warped, way of thinking that site should be behind at least one firewall
with no access from the outside world. There may be a legit reason for
this, but it raises some concerns for me.

Now for a couple of answers to the question:

How about a session cookie approach. Have the person log in, register a
session cookie, and they're set. Since you have AD this shouldn't be that
hard to do. So what if is another time they have to log in -- you can sell this approach as a security precaution.

Another approach, also using cookies, would be to register a cookie that
expires in a month or so. But, this would raise a concern with me, again
the malicious co-worker thing.

Even these suggestions are flawed and wouldn't work where I work. We have
several people that share workstations, so registering a session cookie or
an expiring one would not be practical.

I think the way our intranet group designed the site is about the best
approach. You login, a session is started. If you are inactive for 60
minutes you're automatically logged out.

Honestly, I think you're wasting your time with looking for and SSO type
solution. Code something that works with AD and makes the person log in
and be done with it.

[Mike Discenza]

I hate having to do what I know is just wrong. Our intranet is available to
outside people as well, in a sense. You can get to it from outside the
company, but only if you VPN into the network first. In our case this is
the best set up since we do have some sensitive data on ours. I'm sure you
do too.

Don't you have a network security person or group around there. Often, when
the higher-ups start looking into doing some oddball thing that we (me and
the members of the group I'm in) know is wrong, we'll calf-rope one of them
and drag them in front of these higher ups to explain the potential
security flaws and what might happen if one of them is taken advantage of.

The cookie is specific to the workstation, which ties a person to the
machine. Having one that sticks around for a month or so could be a
dangerous thing, as dangerous as the SSO approach.

"david" <someone> wrote:

Mike:

Thank you for your comments. They are much appreciated.

I can answer a couple of your questions, first off.

Have you ever heard the lyrics that go "I fought the law and the law
won?". Regarding your SSO comments, I could not agree more. Unfortunately,
however, management has deemed that a SSO, despite the inherient security
flaws, is the way that it will be done. Personally, I am dead set against
it, but in the case, it does not matter because it has been decreed to be
a Good Thing. We will not talk about the wildly varying security levels
within the intranet.

As for the DMZ, this too is necessity. The intranet is available from the
outside world (but outsiders do not get the benefit of the SSO). The DMZ
is probably the best location for this. But I am open to suggestions,
bearing in mind that it must be available to insiders and outsiders.

I have thought about the cookie thing. Is that specific to the user or the
workstation?

I already use sessions, and keep the session alive until the browser
window is closed (again, this flies in the face of seemingly good
security. Then again, it is the way it is by preference.) I already go
against AD, so that is not a problem. I just want to automatically
discover the User ID (login value), which just didn't seem that hard. At
first.

My hands are also tied on the SSO. I have no choice. My entire goal here
is to (against seemingly common sense, but sometimes what corporate
America wants, corporate America gets, because they pay the bills at the
end of the day, and food on my table has always been attractive to me)
provide an SSO. I have already already waged the battle as to whether or
not this is a good idea, and, sadly, lost.

Thanks so much, Mike!
david

>
> ALL I need is the user ID that logged in; when they log into their
> workstation, that is good enough for this intranet set, and I am
> willing to believe who they say they are. I would like them to be
> automatically logged into the site using their ID (this part is simple,
> assuming, of course, I actually had the ID). For this application, I do
> not need to know, nor even care about, their password.
>
> But the problem comes when I try to GET the remote user ID. I realize that > in theory I can use something an Apache module (like mod_auth_sspi),
> but these authenticate against the web server, which in this case is in
> the DMZ and ignorant of all other users. Simply getting the user name
> with PHP > returns the user name that PHP is running as, which is exactly what I
> do not want.
> >
> It seems that no matter what direction I go, the door is closed. What
> is really frustrating is that it IIS does this out of the box!
> Switching to IIS is not an option.
>
> Thank you for any pointers!
> david

A couple of questions first, before anything else.

Security? Say a person is at their desk and walks off to go to the

bathroom

and doesn't lock their workstation. What is to stop a malicious
co-worker from jumping on their machine and doing something on the
'intranet' that
could get the potty-breaking worker fired? If you're automagically

logging

the person is, the answer is nothing.

What in the world is your INTRANET doing in the DMZ?!! In my, sometimes
warped, way of thinking that site should be behind at least one firewall
with no access from the outside world. There may be a legit reason for
this, but it raises some concerns for me.

Now for a couple of answers to the question:

How about a session cookie approach. Have the person log in, register a
session cookie, and they're set. Since you have AD this shouldn't be
that
hard to do. So what if is another time they have to log in -- you can

sell

this approach as a security precaution.

Another approach, also using cookies, would be to register a cookie that
expires in a month or so. But, this would raise a concern with me, again
the malicious co-worker thing.

Even these suggestions are flawed and wouldn't work where I work. We
have several people that share workstations, so registering a session
cookie or an expiring one would not be practical.

I think the way our intranet group designed the site is about the best
approach. You login, a session is started. If you are inactive for 60
minutes you're automatically logged out.

Honestly, I think you're wasting your time with looking for and SSO type
solution. Code something that works with AD and makes the person log in
and be done with it.