SSO & Active Directory

Good morning,

We have a client using both Sales & Service 9 who would like to begin using Active Directory to sign into SuperOffice. They would like to test first for 1 user to make sure everything is set up correctly before setting this up company-wide.

The checklist set up by SuperOffice is as follows:

  • Web server is enlisted in Active Directory
  • The hostname used for accessing is registered in DNS (not hosts file)
  • Remote NetServer (where Web and NetServer are on different servers) is not supported due to Kerberos double-hop issues
  • Users are configured with Active Directory authentication in SuperOffice
  • The IIS site where SuperOffice is located is configured to use Windows Authentication
  • Customer Service & Pocket CRM must use a separate NetServer site where Windows Authentication is turned off. It can point to the same physical path as NetServer for Sales but with its own IIS Application with Windows auth turned off.
  • You should now be able to test with your browser to see if SSO works for users.
  • To enable SSO with Mail Link and TrayApp, you will need to change the protocolMapping to use WindowsAuth in the web.config file.

Also:

symmetricKey and symmetricSecret values are the same between SuperOffice Web and Customer Service config files

Also:

Add the following to the web.config file:

<CustomerService>
<add key="ImpersonateCsUser" value="True" />
<add key="CsUserName" value="" />
<add key="CsPassword" value="" />
<add key="CsDomain" value="" />
</CustomerService>

My question is: after these changes are made, can a mix of both SuperOffice & Active Directory logins exist together? Or, once the process begins, must the change to an Active Directory login be made for everyone at the same time? Will making these changes cause any type of detrimental effects for uses who are still allowing SuperOffice to be responsible for the username and password?

Thank you,

Brian

 

RE: SSO & Active Directory

Hi Brian,

I don't know if you already have gotten answers via other channels, but as I just have implemented SSO in an onsite environment using SO 9.2 I thought I would give you some input at least. :)

As long as you have made all the necessary technical preparations as listed in your post, the usage of AD-connected SO-users can be set on user level. You can mix both normal SO-users together with AD-connected SO-Users. In my case I let all user accounts be AD-connected, while we also have a normal SO-user without AD-connection that work as a joint Admin-user, to be used by administrators.

Also, as you suggest, as long as the tech prep's are made, you can try the functionality of the SSO in a small scale before implementing in full scale, which is practical.

When it comes to detrimental effects for users NOT using a AD-connected account, I don't know of any obvious of such nature.

Though, file access rights on website folder level could affect different behaviours depending on which rights that are applied, which type of account the applications pools are using, etc. But probably only if you have been restricting the access a bit.

For example, in my case the implementation is made for a Swedish bank and as they have a lot of security policies and best practices when it comes to who should be able to access which system, I have stripped the "all users" read access on the web site folders, and added a AD SO Users group instead. This makes it impossible for AD-users without a membership in that AD group to even access the login page of SuperOffice. If they are members, they are automatically given access to the login page via the browsers built in SSO-functionality. As everything is only available on a local network, all users that could access the page is always logged in as a AD user, so the login functionality gets totally transparent for the SO users that should have access.

Though, always when you strip down user file rights, you really need to understand the underlying functionality to not get stuck on things. It could affect integrations that wants to communicate directly with the REST API on a Net Server endpoint, etc.

I have also noticed on the server that I get AD users login alerts in the GUI when SuperOffice notifications are sent in the GUI. That might be due to some kind of internal communication between a SCIL-component in the GUI and the internal Net Server, that might not get access as it should due to some reason. But this is not a behaviour that have been reported from the end users. So it might be related to that I am logged in on the local server with a non-AD-connected admin user, so that my AD credentials is missing in these calls in some way or so. I have a ticket with our RnD-support regarding this but haven't gotten any further feedback on this yet.

But all in all, everything seems to be working as it should when it comes to the SSO-behaviour.

LDAPS

One thing that you might have to investigate is if the customer have disabled LDAP-access and only allows LDAPS-communication. I believe this is used for the AD User lookup (when connecting a SO-User to an AD-user in SO Admin) and potentially when doing the AD authentication calls. According to SO RnD, SuperOffice only have official support for LDAP (non-encrypted).

My customer claims to only allow LDAPS, but in practice this haven't actually been a problem. I have run some tests but haven't investigated this in detail as it works. It might be a fact that LDAP communication is still enabled and actually allowed. If that is the case there might be workarounds using 3rd party tools such as Stunnel. There could also be other reasons such as that LDAP-communication is actually not used for these calls or something like that. Or that they are made to some kind of middleware component on the Windows server that then routes the calls in an encrypted way to the end point. I haven't taken the time to actually dig that deep to get the answers as there are workarounds that might solve this in a quite simple way. :)

Stunnel

Stunnel is a proxy service that could be installed locally on the SuperOffice server and is able to route traffic on specific ports between HTTP and HTTPS. It also states to have support for LDAP and LDAPS. I have successfully been using this tool for older SuperOffice implementations such as SO 7.5, that miss support for the latest TLS-levels and other encryption standards and a newer mail server, for example. This to be able to connect to email servers that only support encrypted IMAPS/POPS while still using non-encrypted IMAP/POP in Service. The traffic is then only unencrypted between Service and the local Stunnel-port on the server which then routs the communication in an encrypted connection to the recieving end.

 

I hope this answers some of your questions! Good luck! :)

Best Regards
Marcus

Af: Marcus Svenningsson 2. sep 2021

RE: SSO & Active Directory

Hi Marcus,

Thank you for the extensive and thoughtful reply. This is exactly what i was looking for and I have no doubt this will help many others as well.

I know that editing the web.config file can have some uninteded consequences if not done properly so I wanted to verify that adding the extra configuration settings was not going to cause any detetrimental effects in a production setting. You more than answered my questions and gave me some other aspects to consider.

Thank you again.

Brian

Af: Brian Huelsman 2. sep 2021