I believe this is right. If a request goes through the rule engine and there is no rule to check if there is a username available, the properties will stay empty, even if a lookup into the list of known sessions would be able to fill the properties.
Maybe there is a way to cause MWG to look up the username, but do not attempt to redirect the user to the Auth Server. Maybe a rule that triggers Auth.Authenticate, but has "Continue" as an action will help, but I am not sure. Maybe someone else has already done a similar setup.
one of my colleagues asked me about this thread and I would like to clarify the authentication method you are using. In the post above it looks like you are using the authentication method we call "Direct Proxy Authentication", e.g. a client is sending a request, MWG is sending a 407, client is sending credentials etc.
As an alternative method we offer the utilization of the so called "Authentication Server", which is also a way to authenticate users, but a completely different approach. I believe I remember from one of the eMails we exchanged you mentioned you are using the "Authentication Server" method for providing authentication to your users. The "Authentication Server" uses redirects to send unauthenticated users to a service to authenticate at (also works transparently for the users, but technique is different).
Would you mind to clarify which authentication is in place on your MWG? If you are unsure, maybe you can add a screenshot of the current authentication rules. Just to make sure we are talking about the same things.
meanwhile Ive got another question
is it possible to authenticate users but if authentication failes allow them anyway?
thanks for sharing. We have a property "Authentication.Failed" which becomes true when a user tried to authenticate, but provided wrong credentials. You could try to add this to your rules.
I have not tried this as part of an authentication server authentication so far, but I believe it should work.
Just FYI, the idea
"Maybe a rule that triggers Auth.Authenticate, but has "Continue" as an action will help, but I am not sure."
should work according to our authentication masterminds. Maybe you want to try it if you are still interested.
this reply is regarding 2nd question yes?
I tried it and Im not sure about understanding it (it didn't work btw)
Authentication.Authenticate has its default action "Authenticate <Default>" and its doing redirection with HTTP response code 302.
When changing its action to "Continue" the browser stops showing dialog box for username/password but property "authentication.authenticate" still does redirection with 302 code which is probably hard coded in it.
if I want to authenticate users normally (those who has its AD account) I need to leave this Action to "Authenticate" but when authentication fails (after 3 times as I remember) its <Default> schema displays block page with "Authentication required" so Im not able to move forward to next rule.
which Authentication approach is recommended for which situations? The one using 302 redirects or when MWG asks directly the browser with 407 code? casue this redirections seems to be the MWG itself as headers show.
this one presets when action is "Authenticate"
this one shows the same rule with action continue and it seems that there is very strange loop cause
MWG redirects to itself, and when browser tries to get to this plugin it receives rediretion back to its original page
and after a while Firefox presets "The page isn't redirecting properly"
Message was edited by: pkonitz on 2/15/12 12:15:33 PM CET
OK my mistake,
I should change the action to continue in the first rule not with "Authentication.Authenticate <NTLM>" property
Are you in possession of any materials which document every possible value ofproperties which MWG uses?
Following your idea I wanted to simplify the authenticationin a such a way that
- First try Local user database
Then if authentication failed - stop trying (I tried to useFailureReason property but couldn’t find what values are allowed. I tried torecord it in my own log handler rules but from there, but no such property isavailable.
And I need maybe a confirmation.
Authentication.Authenticate (method) doesn’t trigger this process. Only theAction Authenticate ?
So for example to implement multiple layer authentication it would look sth like this
1) Try AD
Authentication.Authenticate<NTLM> equals false action:Continue
2) Try LOCALDATABASE
Authentication.IsAuthenticated equals false AND
Authentication.Authenticate<User Database> action: Continue
3) If not authenticated
Authentication.IsAuthenticated equals false action:Authenticate <Default>
First HTTP request is not authenticated so it skips 1,2 and goesdirectly to 3.
Authentication is triggered in step 3 (browser prompts for username and password)
Username and password are saved by MWG in some properties and used in rule 1 then if not successful in 2nd and so on.
1 of 1 people found this helpful
a couple of questions there. I will try to cover some of the questions :-)
1.) Direct Proxy Authentication (407) against Authentication Server (302)
Usually this depends on how your proxy is deployed. In an explicit proxy environment, e.g. users have their browsers pointed to MWG (manually or by proxy.pac) you want to use direct proxy authentication. Once the browser knows that it uses a proxy to get to the internet, it will be capable of accepting and answering the 407 responses. This is the easiest way to authenticate, without too much overhead.
From my experience, if there is any chance to use explicit proxy + direct proxy auth, do it. I recommend the authentication server only if necessary.
Using the authentication server is required when the browser is not aware of a proxy on its way to the internet. So if you do any kind of transparent redirect, such as the internal transparent bridge/router modes, WCCP, policy based routing on a gateway, L2 redirect, whatever, you will have to use authentication server.
In this case the browser is redirected to the authentication server when authentication is required. The authentication server looks like a normal web site to the browser, that requires authentication (http status code 401). So the browser thinks it authenticates against a web site and - if the web site is recognized as "trusted" or "internal" - the default browser settings allow the windows credentials to be used, so you won´t even see that you are authenticated.
- Use explicit proxy (a lot better to troubleshoot) and direct proxy auth if possible
- Only use the transparent modes + auth server if required
- Convince people to invest the additional efforts to switch to an explicit proxy environment, instead of just putting transparent MWGs into en existing environment, because it looks easier
Note: This is my personal opinion - of course all other implementations work well.
If you did troubleshooting for a while on various environments you will probably think similar :-)
2.) What triggers the authentication process
This is a little more complicated. Basically the authentication process (which is basically sending a 407 or a 302) is initiated by the Authenticate action. Authentication.Authenticate is used to look up existing credentials and compare them against a directory.
The credentials MWG got are stored into Auth.RawCredentials (if I remember correctly). For your example rules the "Auth.Authenticate" rules will take the credentials from the RawCredentials property, and sent them against the directory configured in the Auth.Authenticate property. If the directory accepts the credentials, the property becomes true. Otherwise it becomes false. So you assumption is correct - you check the known credentials against all the directories and - in case all directories said "no" - you call the Authenticate action. This will make sure the browser is asked to authenticate, and once authentication is done the process starts from the beginning.