Do we really need 2 app servers in order to get domain authentication to work with Foundation EP3 Unity API?

[Cecelia_Rocha]

Hyland FLOS configured our app server so that the Unity Client and Web Client can authenticate successfully. We are using AD - Enhanced authentication.   However, all our custom applications that use the Unity API now fail to authenticate/connect.  We are using  CreateDomainAuthenticationProperties().     The solution I was given was to stand up a new app server with different authentication properties in IIS just for the API.  I thought that the  Unity API contained all the functionality that the Unity Client has.   So why do I need a second app server?   Before upgrading to EP3 we were using OnBase 17 and AD - Basic authentication.  Thanks for your feedback/input!

[Rob_Keberdle]

@Adam Shane we do have an OnBase Web Server also pointing to that same Application Server / site / app pool.  The only thing we could not get to run on it was Dscan, but I understood that module was overlooked from the consideration of Foundation and Authentication.  I understand what you and others are saying regarding a best practice to simplify troubleshooting and to reduce the risk when migrating changes, etc. - but I'm still trying to answer the question of whether or not separate App Servers MUST be used.  In our environment that does not appear to be the case.

[AdamShaneHyland]

Hi @Rob Keberdle , I'm not familiar with the Disconnected Scanning authentication issue you referenced.  I do know that early on in the history for this particular authentication change there where a few issues.  It is possible that your experience with setting it up was around the time of the changes.

The answer of if there MUST be multiple OnBase Application Servers is dependent on your environment and authentication needs.  There are different configuration based on many factors which is why I can't give you a single answer without knowing what you are trying to setup.  However, what I can say is that if the Application Server is used for non-interactive authentication from a front end web application, then an SPN must be configured on the server running the Application Server which will prevent having older versions (prior to 18.0.1.67) of the OnBase Application Server supporting authentication on the same server as a later version (post 18.0.1.67) OnBase Application Server supporting authentication.  That is the ONLY absolute scenario which I can think of which is not supported (and this is a Microsoft implementation of Kerberos Authentication limitation).  

[Jim_Bullen1]

I figured I would chime in here because I have a few questions about Disconnected Scanning and AutoLogin.  I did some digging and from what I gathered in the MRGs is that Disconnected Scanning only supports AutoLogin if you utilize the OnBase IdP and configure it for AutoLogin in OnBase 18. 

Based on that assumption (please let me know if I am wrong) would you need to configure the AppServer for Kerberos Authentication in IIS and set an SPN?  From what I undertsand that would require setting the AppServer for "Optimized Windows Authentication" which would cause the OnBase IdP to fail.

I have not found clear documentation on what the working configuration for AutoLogin with Disconnected Scanning is in OnBase 18 post Kerberos authentication changes and would like to get some clarification.

Thanks!

[AdamShaneHyland]

Hey @Jim Bullen , I'm not aware of a requirement that Disconnected Scanning MUST use the IDP (OnBase IDP in 17/18 or Hyland IDP in OnBase Foundation and higher) for domain authentication.  According to the MRG, AD and LDAP authentication is still supported.  However, Disconnect Scanning CAN use the IDP.

With regards to Optimized Windows Authentication, this feature is confusing because enabling the settings both configures optimization for Windows Authentication AND it configures Kerberos Authentication.  Kerberos Authentication is ONLY needed when there is a front end web app that needs to pass credentials from the authenticating user.  With Disconnect Scanning (like the other remote apps), the user running Disconnect Scanning is directly authenticating against the Application Server and therefore Kerberos Delegation is not needed (and therefore no SPNs).  However, Optimized Windows Authentication DOES configure page level authentication for the Application Server so there is less back and forth authentication traffic between the client workstation running the remote app and the server running the Application Server.

[Rob_Keberdle]

@Jim Bullen - I cannot speak to version 18 as we upgraded from 17 to EP3.  However, we do not use IdP, and we use non-interactive auto-login for Web Client, Unity Client, and Disconnected Scanning.  Prior to Foundation all three of these modules flowed through the same App Server whose Virtual Directory was configured to only allow Windows Authentication.  Upon upgrading we had to configure an (SPN as discussed above), but we also had to enable Anonymous Authentication on the VDIR.  This broke Disconnected Scanning.  As such, we copied the site (created new DNS/certificates and updated config flies etc.) and broke this module off from the other two.