O365 login not working after UCS 4.4 upgrade

Apps & App Center
, , ,
#1

Hi all,
after i upgraded our system to 4.4, SSO to O365 is not working anymore, see the attached screenshot:

ucssso

Because of the increased complexity of the apache2 configuration with php handlers, I cant find the error.
I think it must be somewhere in the SSO configuration, here’s my config file (I can’t remember to change something):

# Warning: This file is auto-generated and might be overwritten by
#          univention-config-registry.
#          Please edit the following file(s) instead:
# Warnung: Diese Datei wurde automatisch generiert und kann durch
#          univention-config-registry ueberschrieben werden.
#          Bitte bearbeiten Sie an Stelle dessen die folgende(n) Datei(en):
#
#       /etc/univention/templates/files/etc/apache2/sites-available/univention-saml.conf
#

Alias /simplesamlphp/saml2/idp/certificate /etc/simplesamlphp/ucs-sso.XXXXX.de-idp-certificate.crt
<Directory "/etc/simplesamlphp">
        <Files "ucs-sso.XXXXX.de-idp-certificate.crt">
                Require all granted
        </Files>
</Directory>


Alias /simplesamlphp /usr/share/simplesamlphp/www

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^/?simplesamlphp/(.*) https://%{SERVER_NAME}/simplesamlphp/$1 [R,L]



<Directory /usr/share/simplesamlphp/www/>
        <FilesMatch ".+\.ph(p[345]?|t|tml)$">
                SetHandler php-cgi
        </FilesMatch>
        Action php-cgi /saml-bin/php-cgi

        Order allow,deny
        Allow from all
</Directory>
<Directory /var/www/saml/>
        Options -Indexes
</Directory>

<IfModule mod_ssl.c>
<VirtualHost *:443>
        IncludeOptional /etc/apache2/sso-vhost.conf.d/*.conf
        SSLEngine on
        SSLProxyEngine on
        ServerName ucs-sso.XXXXX.de
        SSLCertificateFile /etc/univention/letsencrypt/signed_chain.crt
        SSLCertificateKeyFile /etc/univention/letsencrypt/domain.key
        SSLCACertificateFile /etc/univention/letsencrypt/intermediate.pem
                SSLCertificateChainFile /etc/univention/letsencrypt/intermediate.pem
        DocumentRoot /var/www/
        RedirectMatch ^/$ /simplesamlphp/

        ScriptAlias /saml-bin /var/www/saml
        SuexecUserGroup samlcgi samlcgi

        RewriteEngine on
        RewriteCond %{HTTP:Authorization}  !^$
        RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]

        Include /etc/apache2/sites-available/univention-proxy.conf
</VirtualHost>
<VirtualHost *:80>
        IncludeOptional /etc/apache2/sso-vhost.conf.d/*.conf
        ServerName ucs-sso.XXXXX.de
        DocumentRoot /var/www/
        RedirectMatch ^/$ /simplesamlphp/

        ScriptAlias /saml-bin /var/www/saml
        SuexecUserGroup samlcgi samlcgi

        RewriteEngine on
        RewriteCond %{HTTP:Authorization}  !^$
        RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]

        Include /etc/apache2/sites-available/univention-proxy.conf
</VirtualHost>
</IfModule>

This error is pretty painful as nobody is able to Login to Office 365 at the moment!
Any ideas?
If more information is required, just let me know.

Thanks!
Felix

#2

Please post the output of the following commands:

univention-check-templates
dpkg -l '*saml*'
#3

Hi Moritz, thanks for your answer!
First command:

root@intern:~# univention-check-templates
WARNING: The following UCR files are modified locally.
Updated versions will be named FILENAME.dpkg-*.
The files should be checked for differences.

/etc/univention/templates/files/etc/apache2/sites-available/000-default.d/00start
/etc/univention/templates/files/etc/apache2/sites-available/000-default.d/99end
/etc/univention/templates/files/etc/apache2/sites-available/ssl.d/00start
/etc/univention/templates/files/etc/apache2/sites-available/ssl.d/99end

Those edits are made on purpose and do not affect the ucs-sso sub-domain. Those were made years ago to have a second vhost on the server to serve second webpage.

Second command:

root@intern:~# dpkg -l '*saml*'
Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten
| Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/
         Halb installiert/Trigger erWartet/Trigger anhängig
|/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: GROSS=schlecht)
||/ Name                                                      Version                           Architektur                       Beschreibung
+++-=========================================================-=================================-=================================-=======================================================================================================================
ii  cy2-saml                                                  1.8.0-3A~4.2.0.201708041146       amd64                             SASL plugin for SAML authentication
ii  pam-saml                                                  1.8.0-3A~4.2.0.201708041146       amd64                             PAM module for SAML authentication
ii  python-pysaml2                                            3.0.0-5A~4.2.0.201702151906       all                               SAML Version 2 to be used in a WSGI environment - Python 2.x
ii  simplesamlphp                                             1.14.11-1+deb9u1A~4.3.0.201803051 all                               Authentication and federation application supporting several protocols
ii  univention-saml                                           6.0.2-1A~4.4.0.201903061529       all                               Integrates simpleSAMLphp Identity Provider into UCS
ii  univention-saml-schema                                    6.0.2-1A~4.4.0.201903061529       all                               UCS simpleSAMLphp ldap integration

Regards,
Felix

#4

Big update:

Solved the problem for now! Issue was:
I used Letsencrypt to obtain the certificate for the ucs-sso domain, too.
I think since the last update, the Letsencrypt app created apache2 VHost configs for all the subdomains set in the app’s settings. Those overwrote the ucs-sso SAML config and prevented external access to the saml backend.
After commenting out the whole ucs-sso VHost in /etc/apache2/sites-available/univention-letsencrypt.conf, it’s working again.

I think this is maybe a bigger issue other people might experience, too…

#5

Hi! Commenting out those lines did lead to the self-signed UCS certificate to be used for the ics-sso vHost. So i had to change the linex in the generated lines in /etc/apache2/sites-available/univention-saml.conf as well:

        SSLCertificateFile /etc/univention/letsencrypt/signed_chain.crt
        SSLCertificateKeyFile /etc/univention/letsencrypt/domain.key
#       SSLCertificateFile /etc/univention/ssl/ucs-sso.<yourdomain>/cert.pem
#       SSLCertificateKeyFile /etc/univention/ssl/ucs-sso.<yourdomain>/private.key
#       SSLCACertificateFile /etc/univention/ssl/ucsCA/CAcert.pem

So this indeed is a bigger issue between the letsencrypt mechanisms not integrated correctly. That of course is not an easy task.

Mastodon