Storefront multi-domain configuration - Cannot complete your request

[Michael Sailer]

Authentication is working fine on Storefront 2.0 when user from Domain1 tries to authenticate.
This is the domain in which the Storefront Server has been setup initially.

When I try to logon with a user from Domain2, I get the error message:
Cannot complete your request

After checking on Storefront Server I see following two errors in Eventviewer:

Event 7, Webapplication
CitrixAGBasic single sign-on failed because the credentials failed verification with reason: Failed.

Error 1, Citrix Domain Services
An authentication attempt was made for user: <username> that resulted in: Failed (Windows Error Code: 1326)
Password expiry information was requested but none was returned.

Thanks for your help.
best regards
Michael

[CarlStalhood]

Do users in the other domain have Allow Log On Locally user right?

Is the other domain in the list of Trusted Domains? If UPN login, is the full UPN suffix in the list of Trusted Domains?

[Michael Sailer]

Dear Carl,

thanks for your reply.

I added both the UPN and the Netbios Name as described in setup article.

Log on locally is allowed for Domain Users of both Domains.

best regards
Michael

[Robert Ferro]

same problem here, i thing storefront do not receive domain name from netscaler

[john ashman1709151282]

First "Allow Logon Locally" is not required any more for StoreFront 2.x, a network logon is sufficient.

The Trusted Domains feature is used: firstly for display if you have a drop-list of domains, and secondly as a pre-filter on the credential supplied. It has no effect on whether or not SF can actually verify credentials from that domain.

The error you are getting is 1326: "The user name or password is incorrect."
This means either the username/password is incorrect or the credential belongs to a domain that is not trusted.

If you wish to use multiple domains for the user accounts, they must all have a two-way trust with the domain that contains the StoreFront server.

If you have a single domain for the user accounts, then it is possible to configure a one-way external trust in the SF domain to the account domain and have SF verify the credentials.

I am assuming that you are authenticating to the gateway with a password.

[CarlStalhood]

> {quote:title=johna wrote:}{quote}
> First "Allow Logon Locally" is not required any more for StoreFront 2.x, a network logon is sufficient.

Is this also true for changing expired passwords?

[john ashman1709151282]

Yes, this is true for all scenarios.

[Jan Cauwenbergh1709152054]

Hello,

 

I got almost the same problem.  I added all domains to the list of the SF servers.  SF servers are in domainA and there is also domainB with trust between them.  If I put domainA as default on the list on the SF server, only users from domainA can log on without putting their domain.  Users from domainB can log on if the first put their domain, like domainB\user.

 

If I put domainB as default in the list in the SF server, only users from domainB can log on.  Users from domainA can log on if they first put their domain, like domainA\user.

 

The error in the event log is:: An authentication attempt was made for user: xxx that resulted in: Failed (Windows Error Code: 1326)

Password expiry information was requested but none was returned.

 

note: the same setup on our current Web Interface 5 environment works without a problem.  Users from domainA & domainB can log on without putting their domain.

[Jan Cauwenbergh1709152054]

I addition to my previous comment: can someone tell me what authentication mechanism is different between Web Interface & Storefront as this is the reason why I have this problem.

[john ashman1709151282]

At the end of the day, both use the Win32 API LogonUser(), however there is a difference in approach. WI doesn't actually perform authentication of explicit credentials, but delegates it to the XenApp and XenDesktop servers. In a multi-domain case, these servers could be in different domains and WI could be configured to send credentials everywhere until it found a server that would authenticate the user.

In order to broaden the reach of StoreFront beyond XenApp and XenDesktop, the decision was made that StoreFront should do authentication itself. This is one of the reasons that it must be domain joined.

With the correct AD Trusts in place LogonUser() will find the correct domain controller and authenticate the user.

 

In your specific case, the issue is not with authentication but with the trusted domains. You can only have one default domain, and if the user doesn't specify a domain, then that default will be used. If you choose domainA and a user from domainB doesn't specify a domain, then the default will be added and there will be an attempt to authenticate the user: domainA\user which will fail.

 

I can't remember the exact details of how WI managed this, but it did send credentials speculatively to the back-end servers which is sub-optimal from a security perspective.

[Jan Cauwenbergh1709152054]

Thank you Josh for the clear answer:

 

In your specific case, the issue is not with authentication but with the trusted domains. You can only have one default domain, and if the user doesn't specify a domain, then that default will be used. If you choose domainA and a user from domainB doesn't specify a domain, then the default will be added and there will be an attempt to authenticate the user: domainA\user which will fail.

 

So there is no way to make sure SF goes searching on both domains instead of only looking is domainA (the default) and then giving the fail?   That is a step back from the old WI.

 

If I go via de Netscaler this works of course, as you can then specify multiple domains to search through.  But I want my internal users to bypass the Netscaler.

[Kyle Bassman]

I have exactly the same issue. With Sf 3.x via netScaler 10.1.

 

Works fine WITHOUT netScaler involved. 

 

Involve NetScaler and I cannot get the 'Other' domains to return any applications back to the landing page.

 

Any thoughts on that ?

[Ali Osman Tanaydin]

i have also same isse, someone solve it? 

[Timothy Hadlock1709158339]

OK, so I have the same issue. Things have been working fine up until this weekend.

 

The StoreFront 3.11 servers are in the US domain while the users are in the EU domain.

Users from the US domain can login without issue.

 

Going directly to StoreFront makes no difference except that they get "incorrect username or password."

Netscaler gives "cannot complete your request"

 

We have 2 domains with a 2-way trust in place.

I am able to get on the StoreFront and XenApp servers and add user groups from the other domain to local groups so it seems the trust is in order.

 

Any other ideas on how to fix this?

[Maniraj Selvaraj]

It's actually trust issue.. 
In our case  it's single one way trust - One way external trust on both the domains.

Recreating problematic domain trust fixes it.   

[Matt Urban1709160342]

On 7/31/2013 at 11:04 PM, Michael Sailer said:

Authentication is working fine on Storefront 2.0 when user from Domain1 tries to authenticate.
This is the domain in which the Storefront Server has been setup initially.

When I try to logon with a user from Domain2, I get the error message:
Cannot complete your request

After checking on Storefront Server I see following two errors in Eventviewer:

Event 7, Webapplication
CitrixAGBasic single sign-on failed because the credentials failed verification with reason: Failed.

Error 1, Citrix Domain Services
An authentication attempt was made for user: <username> that resulted in: Failed (Windows Error Code: 1326)
Password expiry information was requested but none was returned.

Thanks for your help.
best regards
Michael

 

I had this exact same problem.

 

After checking all of the things listed in here I finally found a solution to my problem.

 

In my case, I have a 'domain.local'.  However, I want my users to log in with their userPrincipalName (email address).  Storefront is working correctly, netscaler logs in but does not pass credentials to the Storefront correctly as identified in error 1 - mine specified the first part of the email address against the domain; domain.local

To fix this, I modified the session profiles on the netscaler.  After running the xendesk\xenapp intergration wizard, there are 2 profiles listed under :  configuration>citrix gateway>policies>session, one for the web receiver and one for the app.

 

 

I edited these two profiles and removed the SSO domain listed.   It seems that the wizard forces you to define this setting.   However, by having an SSO domain listed, the netscaler tries to use the domain to pass any credentials (by removing '@domain.com.au' and changing it to 'domain.local')

 

 

 

 

HTH.

[Brad Myers1709162551]

I've also seen this error occur when the LDAP server is incorrectly configured to pass the AD Credentials to storefront.  See below.