Hi, we have a dual NIC ISA 2006 Standard with an Exchange 2003 single server setup. I have published OWA with FBA. It works fine but when i try to change the password after logging in to the FBA page a error occures displaying on page: "An error occurred while trying to change the password. Please contact technical support for your organization." It works if you access the "Change Password" option in OWA -->Options, but not on the owa logon screen!!
ISA Server is member of target domain, no AD or DNS problems, the eventlogs is empty. Ideas ? Regards, Henrik
Hi! Yes, we have enabled both "change password" and "display notification when password expires". The options do show up on the logon page and you get the option to type in the new password. But when we click "ok" it generates the above message.
I had a problem before where people couldn't change their passwords through their workstations only when the password expired could they change it. Someone changed the secuirty settings on AD to not allow users changing their passwords.
I'm geussing they can change their password on the local network? If not maybe it could be a the security issue on AD.
It really should work! I was testing the password change feature last week and it worked fine. Although, I have to say that it seemed a bit inconsistent. For example, I tried to change the Administrator's password and it would not work. Then I created a new user and that seemed to work. It even allowed me to create a new user, configure the acct to require a password change on first log on, and the password change notification showed in the FBA screen and the password change worked fine.
I've got ISA 2006 in a single NIC config. Using LDAPS published to two front-end server with the web farm function. Exchange back-end running on DC and have certsrv installed.
I've got forms based authentication with the option to change passwords. The single nic ISA is in a dmz installed on a domain controller with CSS and a DC. We are planning to add another ISA 2006 machine for NLB which will also have DC and CSS running.
Everything thing seems fine rpc over https is working and OWA and OMA. Haven't tried active-sync yet but sure it will work.
The LDAPS rule is using a normal user account to check the status of the account.
When the user tries to change his password it gets denied with the following: "The password supplied does not meet the minimum complexity requirements. Please try again"
The user is able to change his password on the desktop without anyproblems.
So, to fix this you had to install a CA and enable LDAPS on all of the domain controllers? Even though it was joined to the domain? The URL mentioned using LDAP to authenticate, I am use Active Directory.
ISA 2006 Standard / Domain member / LDAPS enabled to allow password. Before enabling LDAP authentication forms logon was fast(half second) after enabling LDAPS authentication same form logon take 15 seconds. Does this sound like a configuration problem or is this normal?
I have the same issue, I'm unable to change passwords at the ISA 2006 / OWA login screen due to "complexity issues". I was previously having trouble changing inside OWA but I added /IISADMPWD/* to the paths and made the appropriate IIS directories and registry changes on my Exchange servers.
We're using FBA with Active Directory so I don't have LDAPS to implement (or at least, I haven't enabled it). I double-checked that the listener is configured to allow password changing through ISA.
The one thing I see that could be getting in the way is our ISA server is joined to a different domain than our internal users log into (and of which Exchange is a part of). It's part of an extranet domain which has one-way trust established with the internal domain. This ISA server was originally intended for our Sharepoint extranet, but I added a third interface and am using it for Exchange also. The ISA server physically has interfaces in the extranet as well as the internal (and thus has rules for each), but it authenticates via the extranet Active Directory. The extranet domain controllers have a one-way trust established to my internal domain controllers. Is there anything else that would need to be configured to allow password changing in this type of a scenario?