SSO Configured but still getting confirmation prompts for new users

  • 1
  • Problem
  • Updated 3 weeks ago
We have SSO successfully enabled but newly added users still get the verification prompts.
I've gone through these articles but they haven't helped pinpoint the issue:
https://support.citrix.com/article/CTX234702
https://support.citrix.com/article/CTX208557

The behavor we're experiencing is that on first login for a new user, they get prompted to go through the verification process which tries to set a password and fails because SSO is enabled. If a user simply closes that browser tab and navigates back to the login page a second time, they are not prompted and SSO works as intended.

Support have been unable to assist or even verify if this behavior is expected and I'm hoping someone here can help.

The articles point to this behavior:

If any of the following is true on a ShareFile account where SAML is enabled on the account AND properly configured, then ShareFile will auto-confirm the user upon user creation:
  1. The user does not have permissions to change his/her ShareFile password AND does not have any admin permissions.
  2. If Request SSO Login is set to ‘yes’ under Admin Settings – Security – Login & Security Policy – SAML Optional Settings AND the employee does not have any admin permissions.
  3. The login page for your ShareFile account is set to auto- redirect to your SAML login page, then all employees will be auto confirmed.

So to tick each one off:
1. when our users are created they have no password permissions, nor do they have any administrative permissions.
2. SSO login is set to yes and again, our employees do not have admin permissions.
3. Our login page is redirected to our SAML login page.

So by all accounts, our employees should not be getting the verification prompts.

If anyone can assist it would be really appreciated.
Photo of Systems Administrator

Systems Administrator

  • 6 Posts
  • 0 Reply Likes
  • frustrated at the lack of support from Citrix

Posted 1 month ago

  • 1
Photo of Dale Smith

Dale Smith, Software Engineer

  • 158 Posts
  • 19 Reply Likes
Hi Systems Administrator,

I'm surprised Support didn't flag this. I'll see if I can repro (should be able to given your statements) and if so, it definitely seems like a bug to me. I'll create a ticket if that's the case.

Thanks,
Dale Smith
Photo of Dale Smith

Dale Smith, Software Engineer

  • 158 Posts
  • 19 Reply Likes
Hi Systems Administrator,

I was unable to repro on my test account. A couple of questions that may help:

1) You have Enable SSO set to true, do you also have Force SSO set to true? This is the first question in the "Optional Settings" section in web app's Login and Security Policy menu.
2) What exact roles are you giving the employees when you create them? Some of our roles, while they do not seem administrative do flag as an admin role for SSO.

Thanks,
Dale Smith
Photo of Systems Administrator

Systems Administrator

  • 6 Posts
  • 0 Reply Likes
Hi Dale, thanks for your replies! I must admit the support has been very poor so far regarding this issue but I'm very glad for your assistance.
In answer to your questions, yes SSO is enabled and Force SSO is set to true.
Employees have no items enabled under User Access. They are members of distribution groups which grant them access to folders.
The current use case for ShareFile is that it's being used as a DR location for important information that certain employees can access in the event of our managed network being unavailable.


Photo of Dale Smith

Dale Smith, Software Engineer

  • 158 Posts
  • 19 Reply Likes
Thanks for that additional information. Also apologies that Support was not helpful for your case, I'll see if I can escalate this concern to management over there. 

If you wouldn't mind, could you please upload a text file with your account (subdomain is fine) and a couple of the users who have been afflicted with this (email addresses are fine) to the following link:

https://citrix.sharefile.com/r-rcd031473de445458

I'm unable to repro with the settings you described, so need to dig into the database to determine if there is something else causing the issue you're seeing. You are right though that this should not be happening. Your users should definitely not see the confirmation given the circumstances you've described.

Thanks,
Dale Smith
(Edited)
Photo of Systems Administrator

Systems Administrator

  • 6 Posts
  • 0 Reply Likes
Hi Dale, I've uploaded a txt file with the information requested :)
Photo of Dale Smith

Dale Smith, Software Engineer

  • 158 Posts
  • 19 Reply Likes
Good afternoon,

I just wanted to follow up. I'm still looking through the database and logs based on the values you provided me. One thing that would help would just describe how you go about creating the user. For instance, are you using the web app or one of the desktop/mobile clients? Are you going directly to the Employees list and creating from there? I'm still digging, but any extra info you can provide will help it go faster. (For instance, one thing I noticed is if you create them as a client user, and then upgrade them to employee before they login they get prompted for confirmation, but based on the logs it doesn't look like you're doing that.)

Thanks,
Dale Smith
Photo of Dave Flood

Dave Flood

  • 2 Posts
  • 0 Reply Likes

Hi Dale

 

Dave here, I'm the developer who wrote the interface which Scott is referring to.

 

It was developed in c# /.Net Core. Using your .Net ShareFile Client SDK. https://github.com/citrix/ShareFile-NET

 

I create an account user (Employee) with the following code....

 

            var accountUser = new AccountUser();

            try

            {

                accountUser.Username = contact.FirstName + " " + contact.LastName;

                accountUser.Email = contact.Email;

                accountUser.FirstName = contact.FirstName;

                accountUser.LastName = contact.LastName;

                accountUser.Company = "IHC";

                accountUser.Password = "xxx";

                accountUser.IsAdministrator = false;

                accountUser.CanCreateFolders = false;

                accountUser.CanUseFileBox = false;

                accountUser.CanManageUsers = false;

                accountUser.IsConfirmed = true;

 

                accountUser.Preferences = new UserPreferences

                {

                    CanResetPassword = false,

                    CanViewMySettings = false

                };

 

                var iqUser = _sfClient.Users.CreateAccountUser(accountUser); //, false, false, false, false);

                var newEmployee = iqUser.Execute();

            }

 

 

Also.. I don’t know if this is of any relevance...

A long time ago when I generated the API keys for our app I left the Redirect URI set to the default (http://secure.sharefile.com/oauth/oauthcomplete.aspx)

It worked, so I never revisited this. Is this correct in our scenario?

 

I hope this sheds a bit more light on things.

 

Thanks

Dave
Photo of Dale Smith

Dale Smith, Software Engineer

  • 158 Posts
  • 19 Reply Likes
Hi Dave,

Thanks so much, that is helpful. I think we've narrowed down the issue. Just to make sure, would you or your system admin send me the user's email address that is currently logged in when users are being created? You can upload it to the link above, it should still be active. (If it isn't let me know and I'll generate a new one)

As for the redirect URI, that's fine. The only time you'd want to update that to something else is if you are using the OAuth 2.0 Authorization Code flow and want the authorization code to return to a site you are hosting. 

Thanks,
Dale
Photo of Dave Flood

Dave Flood

  • 2 Posts
  • 0 Reply Likes
Hi Dale

The email our app uses to log into ShareFile is 'svc_IHCMS_Sharefile@ihc.org.nz'

Thanks
Dave
Photo of Systems Administrator

Systems Administrator

  • 6 Posts
  • 0 Reply Likes
Hi Dale, have you had any luck identifying the issue?
Photo of Systems Administrator

Systems Administrator

  • 6 Posts
  • 0 Reply Likes
Hi Dale, we'd still very much like to resolve this issue. Can you please shed some light on what you believe you've narrowed down the issue to?
Photo of Dale Smith

Dale Smith, Software Engineer

  • 158 Posts
  • 19 Reply Likes
Apologies, I thought I had replied to this thread and must not have hit submit.  I was able to confirm the issue and have written up a ticket. The ticket has been pulled into the sprint that starts tomorrow. The defect is around what happens when a user is created by a user which does not have the AdminSSO role. Without it, some code further into the stack is failing causing the user to not be auto confirmed. 

In the mean time, if you give the service account user the ability to AdminSSO, it should resolve the issue where the users are not auto confirmed. I'll update this thread once the change has been completed and is 100% live.

Dale

Photo of Systems Administrator

Systems Administrator

  • 6 Posts
  • 0 Reply Likes
Thank you Dale! I've tested and can confirm this works. What a relief.
Photo of Dale Smith

Dale Smith, Software Engineer

  • 158 Posts
  • 19 Reply Likes
Excellent news! Again, apologies for not replying earlier. I'll update this thread once the fix is live so that you can remove the role.

Dale