Archive

Archive for the ‘authentication’ Category

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:

image

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.

Hence if we can meet the complexity requirements we should check the following steps:
http://technet.microsoft.com/en-us/library/cc984426.aspx

(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.

The “Configuring and Troubleshooting the Password Change Feature in ISA 2006” is also a very good place to continue troubleshooting.

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:

Info:CUserAccountTask:  User: domain\user, Operation: 1, Error code: 6, Internal (ADSI) error: HRESULT=8000500D

Where the error 8000500D is translated as:

# for hex 0x8000500d / decimal -2147463155
E_ADS_PROPERTY_NOT_FOUND

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:

image

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:

Read, Read account restrictions, Read exchange information, Read exchange personal information, Read general information, Read Group membership, Read logon information, Read personal information, Read phone and mail options, Read private information, Read public information, Read remote access information, Read RTCPropertySet, Read RTCUserProvisioningPropertySet, Read RTCUserSearchPropertySet, Read Terminal Server license Server, Read web information, Special permissions.

image

Of course we can perform the same action directly on the “users and computers” console (it is the same).

The above guidelines should help in troubleshooting some of the most common issues under FBA when we are willing to implement the changing password feature.
See you next time!

 

Author
Andrea Vescovo
Support Engineer
Microsoft CSS Forefront Edge Team

Technical Reviewer
Philipp Sand
Support Escalation Engineer
Microsoft CSS Forefront Edge Team

Categories: authentication, ISA, ISA 2006, ISA Server, TMG Tags:

New in SP2: Kerberos Authentication in Load Balanced Scenarios

October 12th, 2011 No comments

In TMG 2010 Service Pack 2, we did put our focus on bug fixing, in order to improve the overall experience with TMG 2010. However next to pure bug fixing, we also introduced some new features.

One of these new features introduces the possibility to allow Kerberos Authentication when connecting to TMG in a “High Availability” (HA) scenario.

Consider the scenario, where you have a TMG array of two or more nodes. Let’s call them Florence.contoso.com and Firenze.contso.com in this scenario. Both nodes are member of a Domain, and you require Proxy Authentication to authenticate your user for Forward Proxy Access. You enabled Load Balancing on the internal network, e.g. by enabling TMG Integrated NLB, the NLB VIP in your internal network resolves to SP2Array1.contoso.com in this example setup.

Why didn’t Kerberos authentication work in a HA scenario before?

In the given scenario your user could already use Kerberos to authenticate the proxy requests. They could only do this though, when using the FQDN of either one of the nodes, e.g. when using a WPAD file with both proxy FQDN included (see this article to find out how to configure FQDN in the WPAD file), or when connecting to only one node’s FQDN. It wasn’t possible to use Kerberos when connecting to the NLB virtual IP address or when installing a load balancer between the client and the TMG array to balance the requests. As Tom Shinder summarizes in the article CARP and High Availability – Not So Much, the setup using WPAD with multiple FQDNs included, provides some load balancing mechanisms like Client CARP, but it shouldn’t be considered as a HA scenario.

The reason for this limitation is directly connected to the Service Principal Names (SPN), which uniquely identifies an instance of a service. A web client (such as a browser) that uses Kerberos to authenticate against the proxy uses the proxy name as it knows it to construct the SPN for the client-to-proxy authentication. For Domain’s computer accounts, a respective SPN with the computer’s FQDN is created automatically when the computer is joined to the domain. This SPN is associated with the computer account so processes running as NETWORK SERVICE principal, such as TMG’s Firewall Service, can authenticate clients through Kerberos tickets referring to this SPN. In HA scenario all array members need to be able to authenticate such tickets because the client may connect to any array member. However, SPNs have to be registered on only one account. If you register the SPN on multiple accounts in your active directory, you will end up with duplicate SPNs, which can lead to quite unpredictable behavior in your AD. For further details here’s the MSDN description for SPNs:

A service principal name (SPN) is the name by which a client uniquely identifies an instance of a service. If you install multiple instances of a service on computers throughout a forest, each instance must have its own SPN. A given service instance can have multiple SPNs if there are multiple names that clients might use for authentication. For example, an SPN always includes the name of the host computer on which the service instance is running, so a service instance might register an SPN for each name or alias of its host. For more information about SPN format and composing a unique SPN, see Name Formats for Unique SPNs.

Before the Kerberos authentication service can use an SPN to authenticate a service, the SPN must be registered on the account object that the service instance uses to log on. A given SPN can be registered on only one account. For Win32 services, a service installer specifies the logon account when an instance of the service is installed. The installer then composes the SPNs and writes them as a property of the account object in Active Directory Domain Services. If the logon account of a service instance changes, the SPNs must be re-registered under the new account. For more information, see How a Service Registers its SPNs.

When a client wants to connect to a service, it locates an instance of the service, composes an SPN for that instance, connects to the service, and presents the SPN for the service to authenticate. For more information, see How Clients Compose a Service’s SPN.

http://msdn.microsoft.com/en-us/library/ms677949(v=VS.85).aspx

Before TMG SP2, the Firewall Service (the process hosting the Web Proxy and hence the one authenticating proxy clients) could only run under the NETWORK SERVICE account. Therefore it could authenticate only tickets that refer to SPNs associated with the respective computer account. If you considered to register the SPN for SP2Array1.contoso.com in this setup, you would need to register the SPN on each one of the array nodes computer accounts, which leads to duplicate SPNs in your AD and isn’t a valid configuration.

What did change in SP2 to allow Kerberos Authentication in HA scenarios?

In SP2 we introduced the possibility to configure the TMG Firewall Service to run in a context of a user account. With this new possibility it’s now possible to use Kerberos for HA scenarios, as you can register the SPN for the “HA-IP address” FQDN on the user account that is configured for Firewall Service.

How to configure Kerberos Authentication in TMG HA scenarios?

1. You need to configure a domain user account, which will be used as “TMG Firewall service account” in the future. In this example the Account name I use is TMGSP2KRB in Domain contoso.com

Recommendations for creating the user account to help protect your domain:

· The domain account that you use for the TMG Firewall service is not a member of any local or domain groups. However, since an account must be a member of at least one primary group, define a new placeholder group and use that as the primary group. Make sure that the placeholder group does not have any permission or user right on any domain resource.

· The domain account has no permissions or user rights on any domain resource.

· The domain account is used only for the TMG Firewall service and not for any other purpose within the domain.

Forefront TMG grants the domain account the minimal permissions required on the TMG array nodes when you configure it for the Firewall service and removes the permissions when you configure a different account. Hence, do not manually grant any permission for that user on the TMG array nodes.

2. You need to register at least the SPN for SP2Array1.contoso.com on this user account. You can register the SPN, using the setspn command line tool.

Here’s how to register the SPN for SP2Array1.contoso.com on the account TMGSP2KRB:

setspn –A http/SP2Array1.contoso.com TMGSP2KRB

In order to be able to use Kerberos when connecting to the FQDN of each individual node, we recommend to register the additional SPNs for each FQDN on the service account as well.

In the end you can use setspn –L TMGSP2KRB to list the SPNs which had been added to the user account. In this example scenario this will look similar to this:

clip_image002

3. With the account all setup, we can now open the TMG MMC of the array to complete the TMG configuration of this scenario.

Right-click the Array name and select properties:

clip_image004

Select the Credentials Tab to configure the service account:

clip_image006

Apply the settings. Please be aware, that the TMG Firewall Services needs to be restarted for this change to take effect. A proper prompt will be displayed when applying the configuration changes. It is also recommended to restart the TMG Admin console (MMC) in this case.

After successfully applying the change, you can open the Services.MSC to verify if the changes were applied successfully.

If applied successfully, you’ll notice, that the Microsoft Forefront TMG Firewall Service will Log On As contoso\TMGSP2KRB now:

clip_image008

When you configure Proxy Authentication now, and collect a network trace on one of your clients, the trace will look similar to this when you connect to your favorite technet blog Smiley

clip_image010

Notice that the client is using GSS-API Authorization which is the equivalent to Kerberos Authentication in Netmon 3.4.

If your client still tries to use NTLM, and the trace looks like this:

clip_image012

make sure that you Enabled Windows Integrated Authentication in the Advanced Internet Explorer Settings:

clip_image014

Without Integrated Windows Authentication the client will try to use NTLM instead of Kerberos. (Please don’t ask me why this setting had been named like this, as Kerberos and NTLM are both Integrated Windows Authentication types as far as I know J)

Author
Philipp Sand
Microsoft CSS Forefront Security Edge Team

Technical Reviewer
Oved Itzhak
Senior SDE TMG Product Group

Categories: authentication, Load Balancing, NLB, SP2, TMG Tags:

Random authentication prompts while accessing internet through ISA Server followed by ISA Server becoming unresponsive

January 13th, 2011 Comments off

Introduction

Consider a scenario where users behind ISA Server (internal network) start to receive random prompts for authentication while trying to access internet using ISA Server as proxy. The authentication prompt persists even after entering the credentials. To resolve the issue it is necessary to restart Firewall Service.

Although you probably heard or read about this scenario many times, the goal of this post is to give you a compiled version of the action plan and what to look for while analyzing the data.

Data Collection

Start by following the plan from this post (basics section), along with that make sure that binding order is also correct i.e. internal NIC is higher in order then the external. Wrong binding order can cause issues such as the one mentioned here. In addition to the data gathering specified previously, also collect the following data:

1. Use ISA Data Packager while doing repro of the issue.
2. Enable netLogon logging on the ISA server nodes, using command nltest /dbflag:0x2080ffff in the command prompt as per KB109626.
2. Set the Performance counters as specified in this post.

Data analysis

When start reviewing the perfmon data you want to check the counter ISA Server Firewall Packet Engine\Backlogged Packets. You will notice a trend similar to the perfmon screenshot showed in this post. This can happen due name resolution issue as explained in this TechNet Article.

Next data to analyze is the netlogon.log, which also can be done using the same approach as the following post. In other words, look for the following pattern:

08/21 12:00:00 [DOMAIN] Contoso: Domain thread started 08/21 12:00:00 [DOMAIN] Contoso: Domain thread started doing API timeout 08/21 12:00:00 [SESSION] Contoso: Contoso: NlTimeoutApiClientSession: Unbind from server \\ab-cd.Contoso.local (TCP) 0.

From above data it appeared we can conclude that the Domain Controller to which ISA server had the secure channel established with, did not responded in time manner, which triggered the NlTimeoutApiClientSession in the netlogon logging. After that ISA Server resets the secure channel and tries to make secure channel with another DC.

Resolution for this Particular Case

In this particular case the clients were using WPAD (automatic detection), which by default returns the IP address of the ISA Server rather than the name. This forced the client to use NTLM authentication rather than Kerberos (supported in IE7 or higher).

Note: The advantages to use Kerberos instead of NTLM are documented in this article.

In order to force WPAD to use FQDN instead of IP address we ran the script described in this post. After running the script, all the web proxy clients using WPAD started getting FQDN of the ISA server nodes and use Kerberos for authentication, which enhance the authentication traffic and decrease the number of authentication request.

Author
Suraj Singh
Security Support Engineer
Microsoft CSS Forefront Security Edge Team

Technical Reviewer
Yuri Diogenes
Sr Security Support Escalation Engineer
Microsoft CSS Forefront Security Edge Team