Michael Sailer Posted July 31, 2013 Share Posted July 31, 2013 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, WebapplicationCitrixAGBasic single sign-on failed because the credentials failed verification with reason: Failed.Error 1, Citrix Domain ServicesAn 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 Link to comment Share on other sites More sharing options...
CarlStalhood Posted July 31, 2013 Share Posted July 31, 2013 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? Link to comment Share on other sites More sharing options...
Michael Sailer Posted August 1, 2013 Author Share Posted August 1, 2013 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 Link to comment Share on other sites More sharing options...
Robert Ferro Posted August 12, 2013 Share Posted August 12, 2013 same problem here, i thing storefront do not receive domain name from netscaler Link to comment Share on other sites More sharing options...
john ashman1709151282 Posted August 12, 2013 Share Posted August 12, 2013 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. Link to comment Share on other sites More sharing options...
CarlStalhood Posted August 12, 2013 Share Posted August 12, 2013 > {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? Link to comment Share on other sites More sharing options...
john ashman1709151282 Posted August 12, 2013 Share Posted August 12, 2013 Yes, this is true for all scenarios. Link to comment Share on other sites More sharing options...
Jan Cauwenbergh1709152054 Posted November 18, 2013 Share Posted November 18, 2013 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. 1 Link to comment Share on other sites More sharing options...
Jan Cauwenbergh1709152054 Posted November 18, 2013 Share Posted November 18, 2013 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. Link to comment Share on other sites More sharing options...
john ashman1709151282 Posted November 19, 2013 Share Posted November 19, 2013 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. Link to comment Share on other sites More sharing options...
Jan Cauwenbergh1709152054 Posted January 6, 2014 Share Posted January 6, 2014 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. 1 Link to comment Share on other sites More sharing options...
Kyle Bassman Posted January 29, 2016 Share Posted January 29, 2016 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 ? Link to comment Share on other sites More sharing options...
Ali Osman Tanaydin Posted October 18, 2016 Share Posted October 18, 2016 i have also same isse, someone solve it? Link to comment Share on other sites More sharing options...
Timothy Hadlock1709158339 Posted July 16, 2017 Share Posted July 16, 2017 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? Link to comment Share on other sites More sharing options...
Maniraj Selvaraj Posted June 18, 2019 Share Posted June 18, 2019 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. Link to comment Share on other sites More sharing options...
Matt Urban1709160342 Posted October 3, 2019 Share Posted October 3, 2019 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, WebapplicationCitrixAGBasic single sign-on failed because the credentials failed verification with reason: Failed.Error 1, Citrix Domain ServicesAn 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. Link to comment Share on other sites More sharing options...
Brad Myers1709162551 Posted August 16, 2022 Share Posted August 16, 2022 I've also seen this error occur when the LDAP server is incorrectly configured to pass the AD Credentials to storefront. See below. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now