(Thanks for the mention Chris)
Assuming the clients have already been configured for IWA, I'd start by checking the metadata server and object spawner logs using a candidate workstation and user to verify that IWA with Kerberos is being used for the connection. There is more info on verifying this in the blog post: SAS & IWA: Check the Logs
If the connections are not IWA+Kerberos I'd check the client connection profile to ensure IWA is selected, and also double check the server configs (and metadata) to ensure IWA is enabled and only Kerberos is offered. Whilst the client connection profile can be configured for specific protocols and SPNs it's easier from a deployment perspective to configure everything at the server end so only basic config is required on the client (i.e. just ticking the IWA checkbox). There's info and links to SAS doco in this post: SAS and IWA: Two Hops
If the client and server configs are all ok and IWA+Kerberos is still not being used, I'd check the SPNs. If the logical names used to connect to the servers are different from the physical hostnames then you will need to add additional SPNs (done in AD by a domain admin). Logical and physical hostname differences occur when DNS aliases are used, often for portability or disaster recovery options. There is more info in these blog posts: SAS & IWA: Host Name Aliases and SPNs and SAS & IWA: Reviewing SPNs
Once you have IWA+Kerberos connections to the metadata server and workspace server(s), to get further IWA access to secondary/additional servers (e.g. UNC paths and/or access to SQL Server) from the workspace server(s) you need to get a domain admin to mark the workspace server(s) as trusted for delegation in AD. There's info about how non-admins can verify that status in this blog post: SAS & IWA: Verifying Trusted for Delegation Status
Hope this helps.
Cheers
Paul
