No, it has nothing to do with perl installed, it should be compiled in.Clayton Hicklin wrote:
On Tue, Sep 16, 2008 at 4:05 PM, André Warnier <aw@xxxxxxxxxx> wrote:
Clayton Hicklin wrote:Same error. I wonder, does my Apache need access to a PCRE implementation
On Tue, Sep 16, 2008 at 3:35 PM, André Warnier <aw@xxxxxxxxxx> wrote:PCRE" stuff.
Clayton Hicklin wrote:
On Tue, Sep 16, 2008 at 3:11 PM, André Warnier <aw@xxxxxxxxxx> wrote:work
Clayton Hicklin wrote:#!/usr/bin/perl -w
On Tue, Sep 16, 2008 at 2:40 PM, Clayton Hicklin <chicklin@xxxxxxxxx>The regex does not compile, according to the Apache error log. The
wrote:RequestHeader edit REMOTE_USER ^(?:[^\\]+\\)(.+)$ $1
"So what I believe in this case, is that the LDAP module might,
possibly,
rely on the "REMOTE_USER" header that IE is sometimes sending when
theSo, it looks like I need mod_setenvif, right? Could anybody write a
user
is authenticated in the domain. And that one indeed would probably
contain
the domain and user. If that is the case, then a simple manipulation
of
the
HTTP headers of the request, using standard Apache modules, might be
enough
to get just the user."
I agree, I believe that is exactly what is happening. I can verify
that
the REMOTE_USER server variable is set to 'domain\user' using PHP
(echo
$_SERVER['REMOTE_USER']). I didn't realize that you could manipulate
headers with Apache. I will definitely look into this as it sounds
like
that is what I need. Thanks.
Clayton
On Tue, Sep 16, 2008 at 2:32 PM, André Warnier <aw@xxxxxxxxxx>
wrote:
Clayton Hicklin wrote:
On Tue, Sep 16, 2008 at 1:28 PM, André Warnier <aw@xxxxxxxxxx>
wrote:Clayton Hicklin
Clayton Hicklin wrote:
[...]Your first communication was a bit summarised, so I did not know to
Clayton,
which
extent you knew the underlying tidbits, from there my fist answer.
I am currently in the middle of the same kind of problematic. I have
created an SSO solution that works at the Tomcat level, in a
particular
context, and and I am interested in a solution at the Apache level,
just
like you.
In the process of creating the Tomcat-level solution, I have learned
quite
a bit about how IE (and servers) work in that respect, and my
questions/opinions are guided by that.
I didn't mean to imply that the authentication fails "in" IE. I
realize it
is at the server. My issue is that I would like a seamless usertrying.
experience. IE is passing 'domain\user' due to "Windows Integrated
Authentication" being turned on and it would be nice if those
credentials
could be used to authenticate without popping up the login dialog.
That is what should indeed happen, if the server supports the
related
authentication, meaning the authentication "type" that IE is
This
works using the mod_auth_sspi module (which uses NTLM) but not with
LDAP
authentication.specify an attribute to search for the username that is passed to
Which module are you using for this LDAP authentication ?
The reason is that with LDAP authentication, you have to
Apache.
In the case of Active Directory, this attribute is sAMAccountName.what is happening ? (I am not saying it is false, I just mean that I
This
attribute stores the username of the Windows user. The problem is
that
IE
passes 'domain\user' (not just 'user') on it's first attempt at
authentication.
That's where I am not so sure. What makes you sure that this is
indeed
have a
doubt and would be interested in whether you have really verified
this,
and
how).
This obviously fails which causes the login dialog to pop
up. You can then just type in your username and password and
everything
works fine.the module you are using. It would be relatively surprising if it
I think the ultimate solution would be to modify the Apache LDAP
module
to
accept a parameter that would optionally strip out the domain
portion
of
the
credentials that IE passes.
Yes, that kind of what you need, unless that parameter already
exists
in
didn't.
But even if it isn't available, there might be another solution,
stay
with
me.
That way, we could use IE + APACHE + Active
Directory (LDAP) for a seamless SSO solution. I think this would
be
pretty
common in most corporate environments, which is where this is beingisn't
implemented.
One nore thing I want to add here, is a brief summary of how web
authentication works, just in case there is a part in there that
clear
to you, and because there is a particular step that may play a role.
0) we imagine that, at the beginning, the browser is just opened,
and
knows nothing yet of the URL or the server on which it resides.
1) browser sends a request to server for a particular URL. Because
the
browser at this stage does not know that this URL requires any
authentication, the request is sent without any authentication.
2) the server receives this request. It consults its configuration,
and
sees that this URL requires some form of authentication and/or
access
control. It thus verifies if the request contains this kind of
authentication. If yes, the request goes through and we're done.
3) The request does not contain an authentication (or not one of the
accepted type). So the server sends back to the browser a response
"401
Authorization required", along with the type of authentication
required
(NTLM, Basic, Digest are 3 possible, supported by IE), and along (if
Basic
or Digest) with a "realm" (the protected "area" name on the server).
4) the browser receives the 401 response. It looks at the
"authentication
type" required, and, *if it can handle that* (which may depend on
its
settings, security zone etc..) it proceeds to try that kind of
authentication. (If the browser cannot handle that particular type
of
authentication requested by the server, it may check if it has a
"fallback
type" that it can try. If it doesn't have such a fall-back, I do not
know
really what happens, but I guess some kind of error at the browser
side.)
5) once the browser has "put in the bag" the required pieces for the
authentication (as requested by the server, or its fallback type),
it
re-sends the same original request to the server, but this time it
adds
an
"Authorization:" header with the appropriate content.
Now, depending on the case, a back-and-forth dialog *may* take place
between the server and the browser. For instance, with IE and NTLM
authentication, there are 3 such exchanges before the server and
browser
are
satisfied, and the browser has the right content to send in its
"Authorization:" header.
I am only pointing this all out so that it would be clearer that it
is
important to know, for instance, *which* kind of authentication the
LDAP
module is telling IE (in the 401 message) that is required.
Unless this LDAP module can handle an NTLM-type 3-step dialog with
IE
(like the mod_auth_sspi module can), then probably what the module
sends
is
a response which requires a "Basic" authentication.
Does IE then automatically send whatever IE thinks the domain\userid
is
,
as a "Authorization: Basic xxxxxxxxxxxxxxxxxx" header containing the
user-id
and user password ?
It seems a bit far-fetched that IE would send the user's password
over
the
network, just Base64-encoded.
So what I believe in this case, is that the LDAP module might,
possibly,
rely on the "REMOTE_USER" header that IE is sometimes sending when
the
user
is authenticated in the domain. And that one indeed would probably
contain
the domain and user. If that is the case, then a simple
manipulation
of
the
HTTP headers of the request, using standard Apache modules, might be
enough
to get just the user.
That was a long message, but in the end the answer may be simple.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server
Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
" from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
--
chicklin@xxxxxxxxx
Sorry about top-posting on that last message (stupid Gmail :).
quick
directive that would look at REMOTE_USER to see if there is a
backslash
("\"), and if there is, set the same variable to everything following
the
backslash? I think this would solve my problem. I would rather use
mod_authnz_ldap that mod_auth_sspi as it is included with Apache and
is
well-supported.
I would try the following, but it's mod_headers, not mod_setenvif :
the regexp should mean (if really it's a perl regexp) :
- for the first () group, match but do not capture
- match (potentially) from the beginning, anything before the backslash
and
the backslash itself, if any such things.
- then match whatever is left, and capture it as $1
then replace this all by $1
(the fancy maybe-match stuff is just in case you *don't* get a domain
sometimes)
That's what I'm trying to do anyway, regexpes are painful (but nice).
Please let us know if the whole solution works in the end.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server
Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
" from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
Andre,
manual
says Apache uses PCRE, btw. I will see if I can figure out where the
error
is.
Strange :
use strict;
my $RU = "domain\\user";
$RU =~ m/^(?:[^\\]+\\)(.+)$/;
my $user = $1;
print "1) User : $user\n";
$RU = "user";
$RU =~ m/^(?:[^\\]+\\)(.+)$/;
$user = $1;
print "2) User : $user\n";
exit;
output :
1) User : user
2) User : user
Maybe under Apache, it escapes the backslashes automatically by itself ?
Try :
^(?:[^\]+\)(.+)$
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server
Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
" from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
It keeps saying "regex could not compile" even though I can get it to
in the regex tester. Weird.
I think it might not like my (?:...) construct. That's probably "extended
Let's try another one :
RequestHeader edit REMOTE_USER ^([^\\]+\\)?(.+)$ $2
(hoping that $1 gets set even to '' if there is no domain)
(and yes, the "replacement part" is now $2)
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
" from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
(i.e. PERL) or is that compiled in? Maybe that's the problem.
But the current on-line documentation for mod_headers has this paragraph :
edit
If this request header exists, its value is transformed according to a regular _expression_ search-and-replace. The value argument is a regular _expression_, and the replacement is a replacement string, which may contain backreferences. Available in version 2.2.4 and later.
So, maybe your version does not quite make the cut ?
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
" from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|