SSO (Single-Sign-On) Secure Logon to FAB Network Controller

Users working from FAB Teletext Editor can use SSO (Single-Sign-On) when connecting to FAB Network Controller. When configured correctly, the user will be logged on automatically for teletext operations in the same way as when using Windows shared folders or accessing SQL or Exchange servers. The identity of the user is used that has been used to logon to Windows. The connection is authenticated using Kerberos or NTLM. After a client and server has used Kerberos or NTLM to successfully prove their identity, they also encrypt all of their communications to assure privacy and data integrity. There is no need for the user to logon separately in the teletext editor.

For security reasons, we recommend that you configure the FAB Network Controller as well as FAB Teletext Editors in a way to use a more secure Kerberos authentication instead of NTLM authentication. With Kerberos neither plaintext passwords nor password hashes are sent over the network, so they can’t be captured.

Prerequisites:

  • FAB NC version 3.98 or higher.

  • FAB Teletext Editor 4.07 or higher. When started with parameter /DISABLESSO , SSO support is disabled. In the Teletext Editor versions 4.04 to 4.06, SSO can be enabled using the parameter /ENABLESSO.

Configuration:

  • In the Teletext Editor Options/Connections select one of the three secure connection options. The last two in the list will not allow any communication in the case secure SSO login could not be established:

  • In the Teletext Editor Options/Connections make sure that in the field “Network name or IP Address” the network name is used. It has to be one of the two network names from the registered SPNs (see below), for example TTXSRV.ad.mydomain.de or TTXSRV. When using other network name or IP Address, only NTLM will be used instead of Kerberos.

  • On the FAB Network Controller side, configure Users or User groups. These must be from the domain in which the Network Controller resides, a local one (use . in the field Windows domain) or from any other trusted domain (specify the domain name in the field Windows domain). Select “With his own username and password”:

When a user is present in the list as an individual user as well as a member of a group, the settings of individual user will be used. When a user is not present in a list as an individual user, but is member of more than one group, settings of one of the groups will be used. Only users/groups that are present in this list will be able to logon using SSO to the Network Controller. Access to teletext pages is controlled by rights specified in user’s settings in the configuration as well as using NTFS security of the file system.

  • Register SPNs that are required for Kerberos to work. Normally an error message will be written by the Network Controller to the log file status.log similar to the following: 2018-01-17|registering SPN: Adding SPN-DNS failed, Error 0x00002098, SPN:FABSTSVC/TTXSRV.ad.mydomain.de, User:CN=ttxsrvuser,OU=Serviceaccounts,OU=Users,OU=Unit01,DC=mydomain,DC=de Error registering SPN: Adding SPN-NB failed, Error 0x00002098, SPN:FABSTSVC/TTXSRV, User:CN=ttxsrvuser,OU=Serviceaccounts,OU=Users,OU=Unit01,DC=mydomain,DC=de This means that the two SPN entries could not be registered in the active directory. Without them the Kerberos authentication is not possible. Only a bit less secure NTML can be used in such a case. Both SPNs can be registered from any domain computer when a user with sufficient rights to write into AD is logged on. The following two commands have to be used. Use the names from the error message on your system. They will not be those used here as an example: setspn -S FABSTSVC/TTXSRV.ad.mydomain.de ttxsrvuser setspn -S FABSTSVC/TTXSRV ttxsrvuser You can verify the correct registration of the SPNs using the following command on any domain computer: setspn -l ttxsrvuser In the displayed list you should see FABSTSVC/TTXSRV.ad.mydomain.de und FABSTSVC/TTXSRV. In the case of domains with multiple names like in the case of migrating from domain with .local ending to another domain name, the Error 0x0000202B can keep appearing in the log even while the two SPNs are registered correctly and Kerberos is working. This is normal behavior for such domains.

Troubleshooting:

  • ACC command can be used in the teletext editor to verify whether and with which credentials the user has been signed on. The presence of NET-User field on the page indicates that SSO secure connection is in use.

  • The Network Controller verifies after start all users/groups configured in NC Configuration. For those users/groups where Windows reports that they do not exist neither in active directory nor in Windows user management, the Network Controller writes such users/groups to the log file status.log like for example:

2018-02-20|20:00:37|Configured user object MisspelledUser not found in AD.

Such users cannot login to the Network Controller. Neither using SSO nor using the old-style logon. Therefore to reduce security risks it is advised to remove them from NC configuration. Alternatively if the user name is misspelled or wrong domain name is specified, correct those data.

Remarks:

  • SSO only works during a user is connected to the FAB Network controller. The credentials cannot be used after the user disconnects or closes the teletext editor. This makes it impossible to use timed/delayed commands like TMC with user credentials. If you wish to keep using timed commands, make sure to activate “Execute time commands with administrator rights” in NC configuration / Defaults. You can individually enable TMC only for certain users in “NC Configuration/User accounts/User rights/Allow executing cmd.pages & TMC”. The limitations from NC Configuration like write access ranges will still be respected in such case. Just the NTFS rights cannot be enforced during the execution of timed commands.

  • The entries “_Default user” and “_Logged off user” in NC Configuration are not used for SSO. If you want to allow the users which logged on without SSO through “_Default user”, also using SSO, then add the AD group(s) which contain(s) that users. To allow all domain users to logon using SSO, add the group “Domain Users” or “Domänen-Benutzer”.