Kerberos logon to Terminal Server prevents folder redirection

[McDavid]

Environment:
- Terminal Server
- Windows 2008 x64 Server Standard
- Kerberos Token Size set to maximum
- Profile and Folder Redirection hosts
- Windows 2003 x64 Server Standard
- Kerberos Token Size set to maximum

Issue:
When our users logon to our Terminal Servers using kerberos, they receive a
temporary profile and none of the Folder Redirection policies are applied.
The event log reports both processing failing with "Logon failure: unknown
user name or bad password.". However the user is successfully logged onto
the server using kerberos. The server hosting the profiles also reports
"unknown user name or bad password" in the security log and the
authentication package as NTLM. The users can navigate to the network
locations of their roaming profiles and redirected folders just fine without
any errors.

If the users logon to our Terminal Servers using NTLM, their roaming profile
is loaded and folder redirection policies applied successfully.

Kerberos is the required authentication method for logging into our Terminal
Servers. We are using Citrix Web Interface and single signon leverages
kerberos.

Initial Troubleshooting:
I turned on Kerberos logging on the Terminal Server. When the user logs into
the Terminal Server using kerberos, the logon process attempts to load their
profile and redirect their profiles using kerberos. This is failing because
we don't have SPNs registered for these resources. I'm guessing the logon
process then attempts NTLM and that is failing because they didn't login with
NTLM.

Is there any way to get the fallback to NTLM to function? If not, how does
one go about registering SPNs for file-shares that are cluster resources
(virtual IPs and computer names that aren't regisered in Active Directory).
In addition, how does one go about registering SPNs for DFS roots?

Any/all help is appreciated.

Thanks.

[McDavid]

Found that we don't have kerberos enabled on our clustered file shares.
Would still like to know if there is a way to have the logon process revert
to NTLM if kerberos authentication fails (because the user logged onto the
Terminal Server with kerberos and the file share doesn't currently support
kerberos).

[Anthony [MVP]]

McDavid,
I am not an expert in Kerberos, so you may get a more expert answer from
someone else, but:
- we run Citrix with Web Interface and single sign-on, and you don't need to
do anything special to do it.
- when you sign on to the WI server, it authenticates you to other servers
in the farm: I don't think this is AD Kerberos, although it is
Kerberos-like. You get a ticket from a Citrix Secure Ticket Authority (STA)
and present this to other servers in the farm
- I suspect the problem lies with the cluster resources and delegated
authentication. What cluster is this?
- You can use the SetSPN utility to create additional SPN's:
http://technet.microsoft.com/en-us/library/cc773257.aspx
Hope that helps,
Anthony
http://www.airdesk.com

"McDavid" <McD...@discussions.microsoft.com> wrote in message
news:BA2F1119-EDF2-4EEA...@microsoft.com...

[McDavid]

Kerberos (and possibly ADFS) is the only supported single sign-on protocol
when authenticating to a Web Interface (or PN Agent site) from a XenApp
Server. I believe the XenApp Client readme states this limitation. When
running the XenApp client from a XenApp server, the ssonsvr.exe process is
not available to perform the sign-on.

Kerberos authentication is working fine for us to the Web Interface server.
And the Web Interface is passing kerberos just fine, logging the users into
the Terminal Servers. The logon process is attempting to use kerberos to
load the roaming profile and perform folder redirection. That is failing
because we have kerberos disabled on the cluster resources. I'm going to
enable kerberos on the cluster resources during our next maintenance window.
However, I would still like to figure out an interim solution. Is there a
way to force the logon process to use NTLM even though the user logged on
with kerberos?

Our file shares are hosted on a Windows 2003 x64 cluster.

[Anthony [MVP]]

I have been puzzling over this.
As you say, you can enable Kerberos authentication on the cluster:
http://support.microsoft.com/kb/302389
But I am curious what it is about the logon process that makes the profile
load fail.
As you are already aware, there are numerous authentication processes in
Citrix. Can you tell us how people authenticate initially from their client
to the Web Interface? Are you using Pass-through authentication with
Kerberos enabled?
Anthony
http://www.airdesk.com

"McDavid" <McD...@discussions.microsoft.com> wrote in message

news:2DC4EA86-A572-4368...@microsoft.com...

[McDavid]

Client-to-WebInterface authentication = kerberos using passthrough. This is
the authentication method that results in profile/FolderRedirecton failure
(since kerberos is not enabled on the file-share cluster).

When the users choose explicit logon at the Web Interface (which I believe
results in the Web Interface passing the users credentials to the XenApp
Server using NTLM), their profiles load just fine.

[Anthony [MVP]]

Pass-through refers to the client browser passing through credentials to the
Web Interface server; so you can still use Pass-through without enabling the
option "Use Kerberos authentication to connect to servers".
Likewise with the PNAgent you can enable Pass-through using the
single-signon service without enabling the option "Use Kerberos only".

I know there is a problem if you try to daisy-chain Citrix servers (i.e log
on to Web Interface, connect to a published desktop on a Citrix server, and
from there connect to a published app on another Citrix server).

"Pass-through authentication is not available when accessing a published
application from within a published desktop on XenApp 5.0 servers. Instead,
the user must provide valid credentials to launch a session within a desktop
session even when pass-through authentication is enabled in the plugin. To
resolve this issue, you must install a server-side hotfix that contains Fix
#194894. [#194894]"

So it looks to me as though you either need to enable Kerberos on the
cluster; or disable Kerberos options in the Pass-through,
Anthony
http://www.airdesk.com

"McDavid" <McD...@discussions.microsoft.com> wrote in message

news:FFB08F3B-9C87-4A93...@microsoft.com...

[McDavid]

Originally the README had said that single sign-on was not available from a
published desktop unless you used kerberos. So, we configured our Web
Interface site to use kerberos (as opposed to spinning off and managing
another site that doesn't use kerberos... one for the clients and one for the
XenApp desktop).

I didn't realize they had published a hotfix for this issue. Might resolve
our issue if cranking up kerberos on the file shares doesn't work.

[Anthony [MVP]]

OK, good luck. It sounds as thought there isn't any reason for the cluster
not to use Kerberos anyway,
Anthony,
http://www.airdesk.com

"McDavid" <McD...@discussions.microsoft.com> wrote in message

news:929EA5D5-1DC9-46B1...@microsoft.com...