Jump to content
Welcome to our new Citrix community!
  • 0

FAS single user issue


Rastislav Kovac

Question

Hi,

 

I came upon the following problem with a single user.
Setup: We have a customer that has Okta as Identity Provider configured on our ADC, so they use SAML authentication to log on.

They use their mail address from customer domain to log on. On our end we create a shadow account in our AD, with the required AD groups.

The logon uses their mail address as UPN and shorter ID provided by customer as the samaccountname.

Recently one of the user's account was recreated and since then the user is unable to launch the app. It's possible to authenticate, the user sees the apps on StoreFront, but when trying to launch the app, it just gives the incorrect username and password message. Certificate doesn't get created on the CA at all.

I revoked all the certs that were present for the user, recreated the account again from scratch, which didn't help.

I also restored the original account in AD which has been deleted and still the same problem.

When I try to log on as user@ourdomain.local but to the FAS enabled store, it works and it creates a certificate for me without any problems.

However when the end user is logging in with user@customerdomain.xx then it doesn't work.

 

Could the revoked certs which are visible in the CA console cause any issues? The issue was present even before that, just want to make sure. I think it should issue new cert regardless.

I tried to go through all possible logs, check everything I could think of, but I'm out of ideas. If anyone ever had a similar issue, any suggestions would be welcome.

 

UPDATE:

It started working a day later, probably due to restoration of the old AD account, also deleted the old profile just in case, but that shouldn't have any effect.

Link to comment

3 answers to this question

Recommended Posts

  • 0

it look like the new account didn't have the permissions on the FAS rule or all the required properties correctly set.

Next time you can also check if you see on the CA the failed certificate, maybe there could be some hints.

Link to comment
  • 0

The permissions were OK, we have specific AD groups in place for that and the user was member of the said groups. I compared everything down to each attribute in AD with a working account. There were no failed certs or anything denied, I checked both in the console for the certificates which were issued and the logs too. Spent hours verifying that everything is set correctly, but couldn't find the problem. The re-created account was exactly the same in everything apart from the SID in AD. Not sure what it was, but at least it's working now.

Link to comment
  • 0

Possible Root cause:
When Okta creates a Shadow account in AD (being Okta the main directory source) the account created is setup to "Change password on next logon" and the password is set to expired, in such case, the user will be able to login to Storefront but won't be able to launch a session until password for that shadow account is fixed. 
my recommendation is to setup Okta on a OU where the password expiration is not enforced or setup an AD script that would set random passwords on shadow accounts, uncheck the change password on next logon

one last item to test.

on FAS you could use the test-fascertificatesigningrequest to make sure that user account's UPN (using the format that Okta sends) can be generated in the CA

Link to comment

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...