locked
Change Password in UAG SP1 RRS feed

  • Question

  • Hi All. When trying to change an expired password at the initial logon page, URL responds with an "You have attempted to access a restricted URL" error message. The illegal path is PortalHomePage/validatechangepassword.asp and the RuleSet confirms that the path is not good. However, that path is good for the InternalSite, not for the Portal. Seems that the operation to validate the password is miscalling the Portal instead of the IbternalSite. I am running UAG SP1.

    Regards


    // Raúl - I love this game
    Wednesday, November 10, 2010 1:28 PM

Answers

  • Just to update the forum:

     

    Based on Raul's description and Fiddler traces, I've reproduce the issue on the RC1 build (build 1575) of SP1.

     

    I've checked the same scenario on a much newer SP1 build and I can say that the issue does not reproduce on this build, and passwords can be changed successfully.

     

    Regards,


    -Ran
    • Proposed as answer by MrShannon Wednesday, November 17, 2010 4:05 AM
    • Marked as answer by Erez Benari Wednesday, November 24, 2010 5:53 PM
    Monday, November 15, 2010 5:43 PM

All replies

  • I get the same problem, need a fix for this.       change password works OK from the 'Credential Management' link once your in the portal.
    Wednesday, November 10, 2010 1:47 PM
  • Yes, you are right. If the password change is user-initiated from wihin the session, it works fine. But if the user muts "change password at next logon" it doesn´t. I guess that changing the Portal RuleSet to allow that path will not work as the binaries (the asp file itself) are not located in the PortalHomePage folder so it would probably fall into a 404 error file not found

    Regards


    // Raúl - I love this game
    Wednesday, November 10, 2010 2:31 PM
  • Hola Raúl,

    I've just tried this and it works as expected for me.

    What puzzles me is how could the URL become /PortalHomePage/ValidateChangePassword.asp, since at the point you are entering your new credentials, the browser displays /InternalSite/LoginChangePassword.asp, and the “action” of this page (meaning the URL to which the credentials are POSTed) is ValidateChangePassword.asp . So, when you click on Submit, what should happen (and what I see happening) is that the browser prefixes ValidateChangePassword.asp with the path in its address bar, which is, as I said /InternalSite/, therefore the URL to which the credentials are sent becomes /InternalSite/ValidateChangePassword.asp and all works well.

    Can you maybe provide here some exact repro steps, and some more details if there is anything special in your configuration (some customization of authentication pages, etc.)?

    Thanks,

     


    -Ran
    Wednesday, November 10, 2010 3:47 PM
  • Hi Ran. That was my first thougt and then I took a Fidler trace to see where the path is changed from Internal to Portal. And for my surprise, I have noticed that the form submit to validatechangepassword.asp is sent from /PortalHomePage, so the current Url is not Internal. I cna send you the fiddler trace if you like. The only customization I can think of is that I had changed the initial application to be SharePoint 2010 instead of portal. I did change to Portal again but the behavior is the same. Anyway, the portal is not a production one, it is only for demos, lab and so on, so it may include some personalization but I need to double check the CustomUpdate folders

    Regards


    // Raúl - I love this game
    Wednesday, November 10, 2010 4:07 PM
  • Raúl,

    Yes, please do send that Fiddler trace to me, since I am still unable to repro, even when setting a SharePoint 2010 application as the initial app.

    Regards,


    -Ran
    Wednesday, November 10, 2010 6:00 PM
  • OK. I will send you a private mail with the traces (plenty of usernames and passwords :) and a screenshot of the portal where you can see the PortalHomePage in the login page In few minutes Thanks a lot
    // Raúl - I love this game
    Wednesday, November 10, 2010 6:09 PM
  • Just to update the forum:

     

    Based on Raul's description and Fiddler traces, I've reproduce the issue on the RC1 build (build 1575) of SP1.

     

    I've checked the same scenario on a much newer SP1 build and I can say that the issue does not reproduce on this build, and passwords can be changed successfully.

     

    Regards,


    -Ran
    • Proposed as answer by MrShannon Wednesday, November 17, 2010 4:05 AM
    • Marked as answer by Erez Benari Wednesday, November 24, 2010 5:53 PM
    Monday, November 15, 2010 5:43 PM
  • Just to update the forum:

     

    Based on Raul's description and Fiddler traces, I've reproduce the issue on the RC1 build (build 1575) of SP1.

     

    I've checked the same scenario on a much newer SP1 build and I can say that the issue does not reproduce on this build, and passwords can be changed successfully.

     

    Regards,


    -Ran


    Cool :)

    I like problems I will never see! ;)


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

    • Proposed as answer by Andy Welch Wednesday, November 17, 2010 9:28 AM
    Monday, November 15, 2010 5:54 PM
  • I've now updated from UAG SP1 to the SP1 release version (build 4.0.1752.10000) and still get the same "You have attempted to access a restricted URL" when changing an expired password so it looks as though SP1 has not resolved the issue.

    the fix mentioned in the link below by editing loginchangepassword.asp seems still works with SP1.

    http://social.technet.microsoft.com/Forums/en/forefrontedgeiag/thread/e79428ee-57af-471b-80cd-f4f0c79dc9bc

     

    Andy


    Andy
    Tuesday, December 7, 2010 4:14 PM
  • I've now updated from UAG SP1 to the SP1 release version (build 4.0.1752.10000) and still get the same "You have attempted to access a restricted URL" when changing an expired password so it looks as though SP1 has not resolved the issue.

    the fix mentioned in the link below by editing loginchangepassword.asp seems still works with SP1.

    http://social.technet.microsoft.com/Forums/en/forefrontedgeiag/thread/e79428ee-57af-471b-80cd-f4f0c79dc9bc

     

    Andy


    Andy
    Ran?

    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Tuesday, December 7, 2010 11:43 PM
  • Jason/Ran

    any update on this please - will this be resolve in a future update to UAG without manual modification to the loginchangepassword.asp file?

    thanks

    Andy

     

    • Edited by Andy Welch Wednesday, September 14, 2011 2:59 PM
    Wednesday, September 14, 2011 2:59 PM
  • Hi, Bringing this thread alive in 2012! After manually changing the asp file, it worked for a while. But now it seems to be broken again. I have a user that has the `change password at next logon` flag set. After changing the password the following error appears: ´You have attempted to access a restricted URL. The URL contains an invalid parameter.´ before changing the loginchangepassword.asp it was: The URL contains an invalid path. Anyone can tell me how to resolve this? The follwing is the faulty url: https://domain/InternalSite/InternalError.asp?site_name=werk&secure=1&error_code=20&policy_id= best regards, Ruud Boersma
    MSCE
    Monday, January 9, 2012 10:50 AM
  • This issue is now fixed in UAG Service Pack 1 Update 1 Rollup 1.   no more need to manually change the ASP file!

    http://support.microsoft.com/kb/2655012

    http://support.microsoft.com/kb/2647899


    Andy

    • Proposed as answer by Andy Welch Wednesday, February 8, 2012 12:03 AM
    Wednesday, February 8, 2012 12:03 AM