We're working on getting set up with AD FS integration for our Portal site to facilitate single sign-on.
Previously we have tried going the 'regular' Single Sign-on - enabling windows authentication and disabling anonymous authentication in IIS at the Portal Web Adaptor level.
This was moderately successful, but not at all 100% successful for all of our users, hence the AD FS attempt.
We're struggling a bit with the implementation, so I wanted to know what the IIS Web Adaptor settings should be when handing over SSO duties to our AD FS server. Same as described above? Or does Anonymous need to be enabled? Some other combination?
Do you mind clarifying the problem you are having? Are some users not experiencing SSO? Are they prompted for a username/pass, provide these credentials and can then log in? Or, are some users not able to login at all as Portal cannot read the AD domain those users exist in?
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.
When it comes to ADFS (SAML based login) and IWA/SSO, we don't really mix these two authentication types together. For SAML utilization we would need anonymous authentication enabled or else we would never be able to actually initialize the SAML login (as we wouldn't be able to physically select the login option since IWA would automatically log us in via Windows Authentication).
The other issues with trying use Windows Auth and SAML is the username builds will be different. Windows Auth typically has the username build of username@DOMAIN, which for most default AD builds, there is no attribute values that equate to this build which would allow us to configure SAML to use this type of username build (most typical AD attributes used are samAccountName and UserPrincipleName which equate to firstname.lastname@example.org and username).
When using IWA/SSO, is there a particular issue your users were encountering?
With SAML, you can configure your ADFS to allow for a SSO experience (which shouldn't require enabling IWA in IIS) https://enterprise.arcgis.com/en/portal/latest/administer/windows/configure-adfs.htm -- looks like step 7 highlights the manual enabling of the SSO experience.
Thanks Trevor -
The issue we have essentially is how to get AD FS SSO to work with existing Portal accounts created with the 'Add members based on existing enterprise users' before we hooked up to AD FS. See above response to Angus.
But yes, my initial question was about Authentication in IIS - and as you say, we did get things behaving mostly as desired by enabling anonymous and disabling IWA at the Portal Web Adaptor level.
Thank you for getting back to me.
I see what you are after now and this could be a difficult one to get corrected. As you stated above, the primary issue is the username builds of the accounts created via IWA (existing enterprise users). The format of these accounts is typically username@DOMAIN and there isn't really an attribute value within ADFS that would provide the same build.
Unfortunately, there is no real supported method for updated an existing username value which was created via IWA to work with SAML. Your workflow of updating the username via portaladmin is an intriguing one, and curious what the ramifications would be for doing this. If you are familiar with Python at all, you could possibly look into utilizing Portals sharing/rest API and partially automating the updating of the usernames perhaps, but I wouldn't be able to advise on this workflow and how/if it would work, unfortunately.
Thanks Trevor -
Yes, looking at some Python-based Portal/Enterprise administrative options for setting the IDP username property - will follow up when/if that gets figured out, along with any other things that may be of interest that come up as we go forward.