4.2. Login#

UCS provides a central login page. You can sign in to the UCS web interface with the credentials of the respective domain account. On the portal at https://FQDN/univention/portal/ you can use the following ways to sign in:

  • Click the tile Login on the portal page.

  • Go to Menu ‣ Login.

It opens the login page as shown in Fig. 4.2.

UCS sign-in page

Fig. 4.2 UCS sign-in page#

If a page in the management system, such as a UMC module, requires a login, your browser redirects you to the central login page.

When you sign in at the local UCS system, the browser session closes by default after 8 hours of inactivity. You can change the timeout through the UCR variable umc/http/session/timeout. To get a new the session, the user must sign in again.

To sign out of the management system, click Logout in the user menu.

By installing a third-party application, such as privacyIDEA, it’s possible to extend the UCS web interface authentication with a two-factor authentication (2FA).

4.2.1. Refresh portal tabs on logout#

All browser tabs where the user is logged into the portal will automatically refresh when a logout is detected. This feature is deactivated by default and can be toggled through the UCR Variable portal/reload-tabs-on-logout.

4.2.2. Choose the right user account#

To sign in, enter the Username and Password of the corresponding domain account in the login mask.

Administrator

When you sign in with the Administrator account on a Primary Directory Node or Backup Directory Node, the UCS management system shows the UMC modules for the administration and configuration of the local system, as well as, UMC modules for the administration of data in the domain.

You specified the initial password for the Administrator account in the setup wizard during installation. The password corresponds to the initial password of the local root account. Use the Administrator account for the initial sign in at a newly installed Primary Directory Node.

root

In some cases, it might be necessary to sign in with the system’s local root account. For more information, refer to Administrative access with the root account. The root account only enables access to UMC modules for the administration and configuration of the local system.

Other user accounts

When you sign in with another user account, the UCS management system shows the UMC modules approved for the user. For additional information on allowing further modules, refer to Delegated administration for UMC modules.

4.2.3. Single sign-on#

By default, the login page for the portal has single sign-on deactivated. The following sections describe how to activate single sign-on. After a successful sign in, the session is valid for all UCS systems of the domain, as well as, for third party apps, if the apps support web based single sign-on.

For sign-in through single sing-on, the browser session closes for 8 hours of inactivity. To get a fresh session, the user must sign in again.

It’s possible to enforce the sign in on the local system by clicking the link Login without Single Sign On on the login page, as show in Fig. 4.3.

UCS sign-in page for single sign-on

Fig. 4.3 UCS sign-in page for single sign-on#

4.2.3.1. SAML for single sign-on#

UCS has SAML activated by default. This section describes how to activate it for the Login buttons in the Portal. For more information about SAML, refer to SAML identity provider.

Activate#

To activate single sign-on through SAML, use the following steps:

  1. Ensure that all users in your domain who want to use the portal and the UCS management system with single sign-on can reach ucs-sso.[Domain Name].

  2. Change the Univention Configuration Registry Variable portal/auth-mode to saml with ucr set. The default value was ucs.

  3. For the change to take effect, restart the portal server with the following command:

    $ systemctl restart univention-portal-server.service
    

4.2.3.2. OpenID Connect for single sign-on#

New in version 5.0-8-erratum-1118: With UCS 5.0 erratum 1118 the portal and the UCS management system have the capability to allow single sign-on with OpenID Connect. The capability is deactivated by default.

OpenID Connect (OIDC) is a protocol that allows single sign-on. OIDC is a more lightweight protocol than SAML. It’s one variant for using single sign-on in the portal and the UCS management system. This section describes how to use it with UCS.

Requirements#

Before you can use OIDC for single sign-on, you must meet the following requirements:

  1. You must at least have UCS 5.0 erratum 1118 installed throughout your UCS domain.

    For information about how to upgrade, refer to Updates of UCS systems.

  2. You must have the app Keycloak installed in your UCS domain.

    For information about the installation of Keycloak, refer to Installation in Univention Keycloak app documentation [4].

Activation#

First, you need to decide on which UCS systems you want to enable single sign-on using OpenID Connect. Second, you need to apply the following steps to each of those UCS systems.

  1. Deactivate SAML for portal sign-in through the UCR variable umc/web/sso/enabled so that the automatic to sign in again doesn’t try SAML first, but instead uses OIDC directly.

    Change the Univention Configuration Registry Variable umc/web/oidc/enabled to true with ucr set.

    $ ucr set \
       umc/web/sso/enabled=false \
       umc/web/oidc/enabled=true
    
  2. Run the join script for the UMC web server:

    $ univention-run-join-scripts \
       --force \
       --run-scripts \
       92univention-management-console-web-server.inst
    
  3. Change the Univention Configuration Registry Variable portal/auth-mode to oidc with ucr set. The default value was ucs.

  4. For the change to take effect, restart the portal server with the following command:

    $ systemctl restart univention-portal-server.service
    

Verification and log files#

To verify that the setup works, open the URL https://FQDN/univention/oidc in a web browser, such as Mozilla Firefox, and sign in. Open a UMC module, such as Users, and perform a search.

You find relevant logging information in the following locations:

  • Log file: /var/log/univention/management-console.server.log

  • journald: journalctl -u slapd.service

To reflect the changes for the login method in the portal, you need to edit the Login tile manually, similar to the setup with SAML for single sign-on. The link must point to /univention/oidc/.

Deactivate#

First, you need to decide on which UCS systems you want to deactivate single sign-on using OpenID Connect. Second, you need to apply the following steps to each of those UCS systems.

  1. Unset the Univention Configuration Registry Variable umc/web/oidc/enabled with ucr unset:

    $ ucr unset umc/web/oidc/enabled
    
  2. Remove the OIDC RP from Keycloak with the following command:

    $ univention-keycloak oidc/rp remove \
       "$(ucr get umc/oidc/$(hostname -f)/client-id)"
    
  3. Unset all Univention Configuration Registry Variables that you can find with the following searches:

    $ ucr search --brief --key ^umc/oidc
    $ ucr search --brief --key ^ldap/server/sasl/oauthbearer
    
  4. Remove the OIDC secret from the system and restart affected services:

    $ rm -f \
       /etc/umc-oidc.secret \
       /usr/share/univention-management-console/oidc/http*
    $ systemctl restart slapd univention-management-console-server
    
  5. Manually update the portal tile for Login, so that the link points to /univention/login/.

  6. Change the Univention Configuration Registry Variable portal/auth-mode to ucs with ucr set and restart the portal server.

Identity Provider with non-standard FQDN#

By default, the FQDN for the Keycloak identity provider is ucs-sso-ng.$domainname. However, it’s possible to configure a different FQDN for the identity provider. For more information, see Configuration of the identity provider in Univention Keycloak app documentation [4].

If you have such a setup, you have to configure the identity provider for the OpenID Connect authentication in UMC on each UCS system. Change the Univention Configuration Registry Variable umc/oidc/issuer to the FQDN of your Keycloak identity provider and run the join script of the UMC web server again, as shown in Listing 4.2.

Listing 4.2 Set non-standard FQDN for identity provider Keycloak#
$ IDP="auth.extern.test"
$ ucr set umc/oidc/issuer="https://$IDP/realms/ucs"
$ univention-run-join-scripts --force \
   --run-scripts 92univention-management-console-web-server

Non-standard FQDN for the Univention Portal and UMC#

By default, the UMC is available under the FQDN $hostname.$domainname. If you have a setup with a different FQDN for the UMC you have to change the Univention Configuration Registry Variable umc/oidc/rp/server to the FQDN of the UMC, and run the join script of the UMC web server again, as shown in Listing 4.3.

Listing 4.3 Set non-standard FQDN for the portal and UMC#
$ ucr set umc/oidc/rp/server="portal.extern.test"
$ univention-run-join-scripts --force \
   --run-scripts 92univention-management-console-web-server
$ systemctl restart slapd

Important

If you want to run multiple Portal/UMC servers behind a load balancer, you need to run these commands on all UCS systems.

Since all the systems use the same OIDC client in this setup, make sure that the file /etc/umc-oidc.secret has the same contents on each system and matches the client secret in Keycloak for that client.

Back-channel sign-out#

If you use OIDC back-channel sign-out together with multiprocessing of the UMC, the UMC needs a database for session storage to handle the session logout correctly. You have enabled multiprocessing in UMC if the Univention Configuration Registry Variable umc/http/processes has a value greater than one (> 1).

If you have only one UMC server without UMC multiprocessing, you don’t need to change the configuration.

To keep track of the sessions in the database for UMC, you need to configure the database connection string with the univention-mangement-console-settings script, as shown in Listing 4.5.

However, if the Univention Portal or UMC uses multiple UCS servers for load balancing, or if UMC has a configuration for multiprocessing, it’s necessary to use a PostgreSQL database that all the UCS systems can access. In these cases, you must consider the following aspects:

  1. PostgreSQL database server:

    You either need to provide a PostgreSQL database yourself that all the UMC servers have access to.

    Or you install and configure PostgreSQL on one of the UCS servers. As shown in the example in Listing 4.4, you can freely choose the values for db_user, db_name, and db_password. db_host is the UCS system with PostgreSQL running.

    Listing 4.4 Example for installation of PostgreSQL#
    $ univention-install univention-postgresql
    $ su postgres -c "createdb db_name"
    $ su postgres -c "/usr/bin/createuser db_user"
    $ su postgres -c "psql db_name -c \"ALTER ROLE db_user WITH ENCRYPTED PASSWORD 'db_password'\""
    $ ucr set postgres11/pg_hba/config/host="db_name db_user 0.0.0.0/0 md5"
    $ systemctl restart postgresql
    
  2. Set the SQL connection URI on the Primary Directory Node:

    Listing 4.5 Set SQL connection URI#
    $ univention-management-console-setting set \
       -u 'postgresql+psycopg2://db_user:db_password@db_host:5432/db_name'
    
  3. Restart the UMC on all UCS servers:

    $ systemctl restart univention-management-console-server
    

Important

The feature for the refresh of the portal tabs on sign-out or session timeout requires PostgreSQL.

You can also use a local SQLite database for one UMC server with multiprocessing, or you can use MariaDB as central database for multiple load-balancing UMC servers. In both cases, the refresh of the portal tabs isn’t supported and won’t work, as it requires a PostgreSQL database.