locked
Exchange 2013 - OWA Password Expired - Requiring DOMAIN\Username RRS feed

  • Question

  • Hello,

    We have recently upgraded from Exchange 2010 to Exchange 2013 CU2. When a user's password expires and they login to OWA, the system allows them to change the password. However, Exchange 2013 OWA requires them to use the format 'DOMAIN\username' and it will not except just the username or username@domain.com.  This was not an issue in Exchange 2010. 

    Is there a way to resolve this issue?

    Thank you

    Wednesday, July 31, 2013 3:34 PM

Answers

  • Hello,

    I test it before. Exchange 2013 owa uses the format DOMAIN\username after allowing users with expired passwords to change their password.

    When changing passwords, users can't use a UPN.

    If you have any feedback on our support, please click here


    Cara Chen
    TechNet Community Support

    • Marked as answer by cara chen Wednesday, August 7, 2013 1:56 PM
    Thursday, August 1, 2013 2:59 AM

All replies

  • Hello,

    I test it before. Exchange 2013 owa uses the format DOMAIN\username after allowing users with expired passwords to change their password.

    When changing passwords, users can't use a UPN.

    If you have any feedback on our support, please click here


    Cara Chen
    TechNet Community Support

    • Marked as answer by cara chen Wednesday, August 7, 2013 1:56 PM
    Thursday, August 1, 2013 2:59 AM
  • There has to be a way to change this. Anyone?
    Thursday, August 1, 2013 3:29 PM
  • Hello,

    Based on my experience, there seems no way to change this.

    And there is no related article to explain we can use UPN when changing passwords.

    If you have any feedback on our support, please click here


    Cara Chen
    TechNet Community Support

    Friday, August 2, 2013 8:59 AM
  • This is a big problem.  We have the logon format set to username only with the default domain set for OWA, but when a user's password expires it takes them to the change password page and fills in just their username - they have no idea what "domain" is or that they need to add it before their username.  This should be fixed to follow the logon format of OWA.
    Tuesday, August 13, 2013 8:53 PM
  • I found a way to default the domain:

    Browse to:

    C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\<latestversion>\scripts\premium\

    Make a backup copy of fexppw.js, then look for this section:

            // UPN authentication isn't supported, don't fill in the username
            // if it's an email address
            //
            if (rg && rg[3].indexOf('@') == -1)
            {
                // Fill in username, set focus to password
                //
                gbid("username").value = rg[3];
                gbid("oldPwd").focus();
            }

    Change the username value setting code to this:

    gbid("username").value = "YOURDOMAIN\\" + rg[3];

    ----------------

    You'll probably have to redo this each time there's a major update in the latest version folder for owa.

    This assumes you're not using UPN format (username@domain).  That would require a little more string manipulation.
    • Edited by Robert Tuck Tuesday, August 13, 2013 9:07 PM
    • Proposed as answer by Boobs8 Monday, December 2, 2013 5:04 AM
    Tuesday, August 13, 2013 9:06 PM
  • This is not working for me?  Could the syntax I'm putting in be wrong, when I try this its still does not fill in the domain information for me.

    thanks 

    Friday, August 23, 2013 2:12 PM
  • Were you in the latest version folder?

    C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\<latestversion>\scripts\premium\

    Can you copy the section of code you edited in the fexppw.js file here?

    There's just one change, to modify this:

              gbid("username").value = rg[3];

    to be this:

              gbid("username").value = "YOURDOMAIN\\" + rg[3];

    Friday, August 23, 2013 4:00 PM
  • This is how I have the code and all it injects in is the username without the domain\. Yes even changed it on all versions to just make sure I wasn't in the wrong location.  I do have CU2 if that matters at all on all my Exchange 2013 boxes.

     gbid("username").value = rps\\ + rg[3];

    I tried it with the "rps\\" and then it breaks the change your password login screen because all it does is flash for a second and bring right back to the normal login screen without taking you the change your password page.

    thanks 


    • Edited by BrettSmith Friday, August 23, 2013 4:34 PM
    Friday, August 23, 2013 4:31 PM
  • Hmm...I'm on CU2 as well.  It should work within double quotes.

    The spot you're changing is within the "initExpPw" function, right?

    Is OWA set to use form-based authentication using UPN usernames?  That would cause it to skip that section of code.  We have ours set to User name only with the domain defaulted.  This is found in the authentication section for OWA under Servers, Virtual Directories in the EAC.



    • Edited by Robert Tuck Friday, August 23, 2013 4:47 PM
    Friday, August 23, 2013 4:46 PM
  • Yes its the section under "initExpPW".  No Im set to Forms-based with the User Name Only option checked and I'm just using the "\" for the logon domain because that's the only way to get the Password Change screen to show up.

    I do restart IIS after I make my changes each time to make sure its not something stuck in IIS.  

    Friday, August 23, 2013 5:00 PM
  • At this point I would just be happy if I could just get it to inject the domain name RPS\ in the username for are end users automatically, I could care less about it putting in there username automatically.  Is there an easy way to do that?

    thanks 

    Friday, August 23, 2013 7:18 PM
  • This worked perfectly for me!!! Our users now have our domain\username populated using this trick. Thank you Robert!

    Now if OWA will just bring back the "Download All Attachemnts" button, My users won't have much left to complain about!

    Wednesday, October 16, 2013 8:56 PM
  • thanks mate, applied to 4 cas servers without any issues.  I can remove my large text warning for users to enter it manually now.
    Monday, December 2, 2013 5:05 AM
  • It really works. One small glitch: need to issue IIRESET command to make changes to take effect. Without it OWA just states that the user name or password is incorrect.
    Wednesday, January 22, 2014 11:36 AM
  • Does it work with CU3?

    Is there difference between:

    gbid("username").value = "YOURDOMAIN.local\\" + rg[3];

    and

    gbid("username").value = "YOURDOMAIN\\" + rg[3];?

    ?

    Thanks!


    flavio

    Sunday, February 9, 2014 9:58 AM
  • It definitely works with CU2. I didn't install CU3 because I'm waiting for SP1.

    I believe you needn't specify your domain FQDN unless you have multidomain forest with mailboxes in different domains. Exchange must be able to find the user account in the AD, nothing above it.

    Monday, February 10, 2014 3:44 AM
  • Hi,

    I did a test and worked with CU3 but I noticed that will only work when Form authentication is enabled. If Windows authentication is enabled, it won't work. If someone knows how to make it work with Windows Authentication, please share how to do that. 

    Thanks!


    flavio

    Thursday, February 13, 2014 2:18 PM
  • I am trying to get this to work on CU3. If I do it in the Current\scripts\premium I can log in. But then the domain is not added to the user name on the reset form.

    I have form based authentication set.

    I have restarted IIS.

    The default domain is set for the log on page, so the user only has to enter username and not the domain.

    If I enter the domain\username at the log on screen it inserts domain\username in the reset password screen. But this has to be done every time when logging on so defeats the point.

    Is there another setting somewhere I am missing?
    Friday, February 28, 2014 1:56 AM
  • I believe you've modified an incorrect file. Beside "current" folder, usually there are several folders with numeric names (representing Exchange versions). You should modify the file in the folder with the most current version number.

    For example, I've modified the fexppw.js file in the following folder (I have CU2):

    C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\15.0.620\scripts\premium

    Friday, February 28, 2014 4:03 AM
  • I did try that first, but it seemed to break the page. I will try again and get back to you. I may have made a mistake...
    Sunday, March 2, 2014 3:20 PM
  • So I tried that again, but it just comes back with incorrect username or password every time.

    I know it is correct because as soon as I log on to a server, it prompts me to change the password.

    Any ideas....

    Tuesday, March 4, 2014 11:56 PM
  • Basically, the modifications discussed in this thread are intended to automatically insert the correct combination "domain\name" into the login field of the password change form, and nothing more. They don't influence the logic of how the password change request itself is internally processed.  Ensure that when you're redirected to that form, you have a correct combination in this field. If so, your problem is not related to the modifications.
    Wednesday, March 5, 2014 3:54 AM
  • When I don't make the change, it does redirect to the form, but it just puts the users name, and then prompts for the domain/username, which annoys the users.

    When I make the change it doesn't redirect to the page at all and it just says incorrect user name or password. But when I log on to a machine or PC it does accept the username and password and prompts me to change it when it has expired.

    Hope that makes sense

    Wednesday, March 5, 2014 5:27 PM
  • I believe you do something in a wrong way. I confirm that this method works on SP1 as well. Please check carefully what you're doing.

    One more time:

    • Open foler C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\XXX\scripts\premium , where XXX is the current Exchange build number (take the folder with the biggest XXX if there are several of them).
    • Open fexppw.js in Notepad.
    • Replace

          gbid("username").value = rg[3];

    with

          gbid("username").value = "YOURDOMAIN\\" + rg[3];

    • Save the file and restart IIS with iireset command.

    Clear your web browser cash before testing the changes and restart the web browser itself..


    Thursday, March 6, 2014 4:55 AM
  • Perhaps this can help you.

    Just installed SP1 on Exchange 2013 CU3.

    I started with YOURDOMAIN.local, after that I removed ".local".

    It still works.

    Regards,

    Wednesday, March 12, 2014 7:17 PM
  • I restored the file and then made the change again.

    This time I did the reset in command line rather than is the iis console.

    But I can confirm it does work!

    Thanks for your help

    Friday, March 21, 2014 12:51 AM
  • Hi,

    I have the same problem.

    I have installed the Exchange 2013 with SP1 (Version 15.0 ‎(Build 847.32)‎) on a Windows 2012 R2 Standard

    I have modified the file :

    D:\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\15.0.847\scripts\premium\fexppw.js

    ->             gbid("username").value = "MYDOMAIN\\" + rg[3];

    I have make a iisreset.

    But the Change Password windows don't accept the UPN. It's always asked for the Domain\Username

    If someone as an idea ?

    Tuesday, April 15, 2014 7:29 AM
  • But the Change Password windows don't accept the UPN. It's always asked for the Domain\Username

    Of course. The modification you've made transforms the name you enter by addding "Domain\" in front of it. If you enter user@domain.local, it's converted into DOMAIN\user@domain.local which is obviously an incorrect name.

    In addition, you must manually enable using UPN logon names in OWA. See http://www.techieshelp.com/exchange-2013-change-owa-log-on-options/ for more details.


    Evgeniy Lotosh
    MSCE: Server infractructire, MCSE: Messaging

    Tuesday, April 15, 2014 8:33 AM
  • I have configured UPN on OWA sign in.

    The sign in with UPN working fine.

    But If I change password for users and I would like that users must change password on next logon. it's don't work.

    The user sing-in in OWA with UPN and after redirect to the change password window.

    In the username field, if the user enter email address, They have the error message : username or password is not correct.

    Normaly, this post is exactly I want. to add the DOMAIN before the email address.

    because the DOMAINNAME\user@domain.local works but I don't want that users enter the DOMAINNAME and know only for sign in email address

    Tuesday, April 15, 2014 9:22 AM
  • What you're doing is wrong from the very beginning.

    The method of modifying the OWA files can be used only for changing the OWA behavior in the situation when a user enters their standard logon name without any prefixes or suffixes. In this situation Exchange doesn't know what domain name it should use, so our task is to give it a hint.

    If you use a UPN logon name to access the OWA interface, the name already contains the domain name. No additional hints for Exchange are required. You needn't modify OWA files at all.

    By the way, I waguely recall that the password changing functionality in Exchange 2013 doesn't work with UPN names at all. I can't confirm it, though, so I may be wrong.


    Evgeniy Lotosh
    MSCE: Server infractructire, MCSE: Messaging

    Tuesday, April 15, 2014 9:35 AM
  • I am in the same boat as you Mr. Tuck.  Thank you for this entry.  This was a big help in streamlining the user experience.
    Monday, June 30, 2014 3:19 PM
  • Thank you.

    Tuesday, October 21, 2014 12:56 PM
  • Hi,

    I've tested it with Exchange 2013 updated to CU8 and it allows to use UPN for expired password change.

    Once you've set to Use UPN for OWA auth method, it asking for "email address" instead of "Domain\Username" in expired password change dialogue =)

    Friday, May 29, 2015 10:51 AM
  • Not the best way. It's far beyond the ability of an average user to understand what the system wants in this scenario. It's always advisable to keep things as simple as possible.

    Evgeniy Lotosh
    MCSE: Server infractructire, MCSE: Messaging

    Saturday, May 30, 2015 6:11 AM