My organisation uses MWG 220.127.116.11 which is hosted by an external service provider. The system is shared across several agencies which limits the way we can use some features.
For my organisation we primarily use NTLM authentication so it's transparent for our Windows computers that are on our Active Directory. This has worked well for a while, however we are becoming more device agnostic, so are having to cater to a wide range of devices. We don't want to lose the simplicity for Windows users, but need to get rid of the incessant credentials prompts on devices like iPads, iPhones, etc.
So what I have done is add a rule set above our NTLM authentication that produces a login form if you visit a fictional domain (in our case, auth.doe was chosen). If you successfully authenticate it adds relevant information to PDStorage with a 2 hour lifetime. This PDStorage is then checked in the main authentication rule set. I chose to change the normal webform template to use PDStorage due to some strange authentication quirks when using the IP Database and to also allow the end user to visit http://auth.doe/logout to clear out the PDStorage value. This is due to some devices being shared, and will prevent users being authenticated as the previous user. This is working all pretty well, except for a significant security concern...
When the Login Form (POST) page (the one that is created when you import the Time/IP authentication rule) is left as-is in the Default schema, it submits the form values correctly and the rules can process the request. However we don't want the page to stay in the Default schema, we want it under our own schema and to customise the page a bit. But if I edit the page at all, whether it be modifying the version in the original location or copy the code over to our schema, it no longer seems to be able to submit the form data. I have created a debug block page with a form that submits back to itself and outputs various header and parameter values, but the only ones that get through are Get variables, which are included in the URL of the page. I have gotten a proof of concept working by changing it over to use Get (with username and password base64 encoded), but we don't want that information logged or captured by anyone or anything.
Does anyone have any insights into why it might be doing this? I would definitely appreciate if anyone has any time to try reproduce the problem. I am happy to provide as much information as I can.
I was able to create a copy successfully. I actually used the Import/Export features in the template editor to ensure a template is not modified when being copied over to a different collection. After the copy I was able to modify the copied version, and still logging on (using the default Cookie Authentication with Login Page ruleset).
Can you share some information how you copied the template over from one schema to another one? Can you see there is a different in the template editor when comparing the original/copied version?
What exactly happens in the browser?
Thanks for your response and testing Andre.
I had opened an existing Login Page (POST) and copied the contents (html source) across to our schema. I will try an export later. However I forgot about part of the problem - I've been tinkering so much that I forgot what it looked like at the start. I feel a bit foolish about it.
When I import the rule set from the library or an XML file, the block page object works fine as expected, with credentials being processed. However if I go to edit that block object, I see that the Collection field is set to Default Schema, but the Template Name is blank. I had changed it to Login Page (POST) because that's what I wanted it to do. However it appears the Template Name might not be the right one. Can you tell me what yours is called? I looked at the XML and it says LoginPage. I can't see that on this system. I think it is coming down to a permissions issue. I have asked my colleague to take a look and they can't see the object either, and they have a Super Admin account. I have escalated it to our provider to see if they can look into it. If Super Admin can't view it though, then I wonder if it may become necessary to make a support call to McAfee.
Alternatively, would you be able to send me the contents of the template (html code) so that I can see what it is meant to look like? Or perhaps look at the Login Page (POST) page to see if it is any different?
on my MWG it looks this way:
I found that import/export a single template did not work pretty well because there are several dependencies. When I wanted to show my Login Page in the different Schema I saw a couple of errors. So what I did is I exported the complete Default Schema (all templates), created a new schema, imported the file, and removed all templates but the one I would like to use.
I am not really sure if I understood your part about importing. The Template Name being blank usually happens if you import a rule set which refers to a block setting, but the template the block setting is referring to does not exist. When you import something from the library that ships with the product, all templates should already be present (unless modified earlier). As far as I know the templates are not part of the rules in the library, but are existing by default.
Importing a rule set usually results in tempaltes not being there if they have not been existing before the import. They are not part of rule sets, which makes importing rule sets which rely on a custom error template pretty messy :-(
Maybe you can share some screenshots ti explain what the exact issue is about?
Additionally I would go ahead and try the export/import to get the tempalte into a new schema.
Thanks again for your thoughts on this.
I agree, when I import the rule set, the block rule shows the Schema but not the Template. However when the rule is hit by a client, it does show the login page! Which is why I'm thinking it's a permissions thing, because otherwise it shouldn't work at all, should it?
Here is a screenshot of what the rule looks like at that point:
Note that this rule DOES WORK at this point, even though it appears to be invalid. That's why I thought it might be a permissions issue - I can use the block page because the page actually exists, but I don't have permissions to view the Template so it's not even in the list of Templates.
If I change it to Login Page (POST) from within the default template, which in theory has access to the same schema files because it's still in the same schema, it stops working.
In regards to how I imported the template into our local schema, I loaded up the page from the Default schema, selected all of the code, and pasted it into a new template that lives under our schema. But that was a copy of the Login Page (POST) page that doesn't work in the Default schema either!
I'm still waiting on a call from our provider to let me know if they have visibility of that Template. In the mean time, are you able to tell me what the dependencies are for that Template?
Thanks again so much for your help with this. I really appreciate it.
EDIT: I can't do an export/import because I can't see the page that works. And we have a lot of info already in our schema which I don't want to risk breaking by doing a full schema import.Message was edited by: aussiewan on 3/28/12 5:17:10 PM CDT
the "template name" being empty usually occurs if the block action setting points to a template which does not exist. It is really strange that - when you browse - you see the expected response. Usually I would expect you see a "template missing" or similar error message. A permission problem may be possible but I have never seen this before and I also cannot really imaging where this permission problem could occur or what may have caused this.
Do you think you can send me the rule set? Maybe I can find something in the XML source. Are you sure that it is exactly the rule which has the block action setting from the screenshot which causes the login page to be displayed? Maybe there is another instance of a similar rule somewhere else? Actually that would not explain why picking a template in this block action changes things... very weird!
One more idea. In a schema there is a "fallback" template which is shown if no template was found. Maybe this template has (accidentally?) been adjusted to show the login page you are looking for? This would explain why it only works as long as you do not pick any other template from the drop-down.
Very confusing :-)
I have been doing most of my work in a dev/test environment. When I copied my working (with GET variables, so not ideal) into production, the Block pages I had created were showing the same symptom, ie the Schema was selected correctly but there was no Template selected. So I think you are right, the page just doesn't exist. But as you point out, it should then load a default template, which would normally not be the login page. I've asked for the default Template to be checked, to see what it is set to.
I think that rather than trying to work out the how/why, it would probably be much more contructive if I could get some tips on how to handle authentication via a webpage using POST, or at least not using GET. That would solve my problem. To get me to that point, a code sample, any dependencies and how to refer to those values in Rules would be awesome. But then, as you pointed out Andre, when you exported the page and reimported into a different schema, you found that it failed. Does anyone out there know what is going on with that? Is there a way to see dependencies of a page?
I have managed to get this working! I went back to the start and realised that the POST variables are not being sent back to the client, so my debug stuff would never show it! I created a user-defined variable, populated them with some information from the headers of the request to the server, and then output the variable on my debug page. The information was then available. The rule set I imported was looking at URL.Get(variable), when it should have been using Header.Get(variable). I still don't know why it was working before the template was set correctly - I never got a response from our provider about it either. But I know have a working system where users get prompted for credentials via the old NTLM method (which is automatically passed through on Windows machines that are bound to our Active Directory) unless the user has previously visited https://auth.doe and logged in with their credentials. This allows apps that don't handle proxy authentication request (407) to work, which in our case means iPads and iPhones with iCloud, FaceTime, Youtube, etc. Finally these devices should work the way Apple intended
Thanks Andre for your thoughts, testing and tips. I'm really not sure how to allocate correct and helpful answers... I guess this post is the only correct one, but the others have been very helpful.
while I do not yet understand what happened in your configuration I am glad to hear that you got it solved by yourself. Thank you for sharing the information! :-)
As an additional note - I wanted to have this work over HTTPS for basic security of the user credentials, however it appears that when you set it to HTTPS, even though it is MWG handling the secure session, it can no longer read the headers in the requests, so authentication fails. I will need to put this to management and see whether the risk is acceptable.
The only issues I have left are related to PDStorage.... one is the time it takes to sync the information across the cluster (which I need to get the settings checked for), and the other is related to the values getting populated in the wrong PDStorage object. I added radio buttons to the block page so that users could select to stay logged in for 2 hours or 8 hours. The rule set then reads that value and stores the login information in a different PDStorage object that has the appropriate time set on it. However, in my debug pages, whenever I set the value in one of the PDStorage objects, it appears in both. Here is the rule set:
My debug page shows me the contents of both the 2 hour and 8 hour PDStorage object contain the same information after logging with this method. I can provide a screen capture of that if you like, but it's only text, I don't think it's valuable.
Just so you know, this system is based on a Time/IP based login rule set that you posted elsewhere here on the MWG forums, so you have contributed a LOT to this project. Thanks so much for all of your help!
EDIT: Note that the records appear to populate both PDStorage objects even if I disable one of the rules - eg if I disable the selected rule which is for 8 hours, it will still populate that PDStorage object if I choose to login for 2 hours. If I choose to login for 8 hours, no PDStorage values are set.Message was edited by: aussiewan on 4/3/12 6:08:21 PM CDT