In many GroupWise environments, customers have been using Single Sign On (SSO) via the respective directory service (eDir or AD) for years, others are gradually moving to it. In principle, the setup is documented, but there are always stumbling blocks sometimes in environments that have actually been working with it for years without any problems.

The following description is based on incidents in such an environment. The customer has been running a Groupwisesystem for years, currently on SLES15 servers, connected to an AD. The original setup of the SSO connection was done several years ago according to the very detailed description in the „Quickstart Guide: Setting up Active Directory Single Sign-On (SSO) on a SLES11, SLES12, or SLES15 Linux Post Office for GroupWise 14.2.2 or 18.1, in a non-clustered environment“ (TID 7018598 https://support.microfocus.com/kb/doc.php?id=7018598) subsequently supplemented by the configuration from TID 7023422 „Manual creation of AD Service Connection Point (SCP) for a Linux POA for functionality similar to ngwnameserver“ https://support.microfocus.com/kb/doc.php?id=7023422.

The user login incidents in this environment began in temporal connection with the changeover to Groupwise 18.3 and the associated changes to the supported encryption methods. So the first thing to do is to check the existing settings analogous to the procedure in the TIDs mentioned above. Unfortunately without success at first.

Troubleshooting revealed an aging non-updated CA on AD side that could only offer SHA1. Unfortunately, in this situation, this was a bit too little to still work. Here the CA had to be migrated to SHA256, new certificates for the domain controllers had to be generated and in the directory service connection of the Groupwise admin console had to be replaced. With this configuration the SSO should work again, but unfortunately the password was asked again during the client login. Here the description of the TID TID7022506 helps „SSO against AD does not work on Windows based GroupWise system after upgrading to GW18“ https://support.microfocus.com/kb/doc.php?id=7022506. (by the way also for linux based installations).

Finally there was still to fight with the behavior that SSO sometimes worked and sometimes it came again to password queries. The solution to this problem was to reduce the LDAP servers in the PO configuration to the directory service itself.

Finally, a big thank you to Laura and Peter from the MF support team for their help in solving the problem.