Hi Angus -
The issue is that for an existing Portal with 100+ users, SSO is not working for everyone using the IIS method of setting authentication at the Web Adaptor level. Works for most, but not all, and we have users who are on Virtual (VDI) machines which don't work with this method of SSO (our VDI environment conveniently sits on a different domain than our users). And yes, some users can't sign in when configured this way, some are prompted to sign in and authentication fails.
Also Firefox requires some changes to advanced settings at the client level which is just not feasible for us.
So, in our Test Portal site, we are trying to implement AD FS, and were having trouble. However, it turns out that we can create new accounts through the SAML option and that works fine with AD FS. The problem is for existing Portal accounts created through the 'Add members based on existing enterprise users' method - those have the Username@DOMAIN format, which is not the format that AD FS server needs.
We did find that for those existing accounts, you can make them work with AD FS if you go into Portaladmin > Security > Users > Update Enterprise User and enter the Username@DOMAIN in the 'Username' box, then enter 'Username' (removing the @DOMAIN) in the IDP Username box and updating.
After doing this, a user can use SSO via AD FS, but a few clicks are required (no actual typing of user name/password though, which is acceptable for our purposes) and this works for our VDI users.
No we need to figure out how to programatically run existing enterprise users through this tool instead of manually doing that for 100+ accounts in our production Portal.