TMG 2010 – FBA, troubleshooting the change password feature

When we are publishing OWA, or every web service through TMG and we are willing to make use of FBA we have the chance to change our password through the FBA web form. However this step is not always as straightforward as it seems and there are some possible pitfalls in the configuration on the TMG or on the DC.

One error you might see in a case of an issue in the configuration is the following generic error:

In this article we want to provide some guidance how to troubleshoot these problems and also how to identify specific issues that can prevent the FBA changing password from working as it should.

Of course the first point when you see the error message is to check if the “complexity requirements” are really met and if the user who sees the error is the only one affected by this issue.

(Note that both Active Directory and an LDAP server use the LDAP protocol for communication)

· The connection to the LDAP server or Active Directory on the domain controller must be over secure LDAP (LDAPS). To use a secure LDAP connection, a server certificate must be installed on the domain controller. The common name on the certificate must match the fully qualified domain name (FQDN) that you specify for the authentication server.

· The Forefront TMG computer must have the root certificate of the certification authority (CA) that issues the server certificate in the Trusted Root Certification Authorities store for the local computer.

· When using LDAP authentication, you must create an LDAP server set containing the LDAP servers that will be used to authenticate users. Configure the following settings for the LDAP server set:

o Enable connecting to the LDAP server over a secure connection.

o Specify an FQDN for the LDAP server name. Ensure that the FQDN matches the common name specified on the server certificate installed on the LDAP server (domain controller).

o Disable querying of the global catalog (GC).

o Specify the domain in which user accounts can be identified and specify the details of an account that will be used to bind to the LDAP server and to query the credentials of logged-on users.

o An account is required to bind to the authentication server and verify user name and password status. In the case of domain authentication, this must be a domain account with privileges to make changes to Active Directory.

And we must check also if the http://support.microsoft.com/kb/957859 patch has been already installed (included in TMG RTM), and if you might need to run the script provided in this article.

If the above steps are fine we should move forward in our analysis and as first thing check if the “root certificate” we are using to establish the LDAPS connection is trusted everywhere (TMGs and DCs).

If this is the case but still we are not able to make it working we have to move forward in our analysis and check for any possible error in the ISA/TMG tracing. Due to the very detailed information which can be found in the tracing, this can only be analyzed by Microsoft personnel.

Recently I was working on a case, where above steps didn’t resolve the issue. In this article I want to share how we resolved the issue, which was caused by a permission error on AD in my case.

When analyzing the TMG tracing we found that TMG tried to gather the account properties and failed:

You can also use the TMG Diagnostic logging to verify if you are facing this issue. More information on how to use diagnostic logging can be found here.

When you filter for the specific connection, you should be able to see the error code 2147463155 in the logging. You can of course also just filter for the error code itself, after collecting the diagnostic logging:

Under this case it is a good idea having a look at the user permissions, of the account where you cannot change the password. It is necessary to add the permission to read the attribute UserAccountTask to every account which should be able to change the password via ISA/TMG.

This attribute is used to gather information regarding the password as for example if it is expired or if it matches the complexity requirements.

This task can be accomplished simply adding the “authenticated users” group to the security tab if it is missing under AD as per following screenshot with the following attributes enabled as per our default Windows Server 2008 R2 installation: