SSO not working: unsupported mechanism?

UCS - Univention Corporate Server
, ,
#1

Hallo!

Wir sind momentan am Austesten von UCS@school und haben ein Problem mit dem Single-Sign-On. Wir haben alle Einstellungen nach Anleitung durchgeführt und doppelt überprüft. Sie sollten alle stimmen.

Beim Aufrufen des Portals bekommen wir die folgende Meldung:

[Mon Aug 05 09:22:47.251889 2019] [cgi:error] [pid 11742] [client 172.25.72.196:61313] AH01215: PHP Warning: KRB5NegotiateAuth::doAuthentication(): An unsupported mechanism was requested (65536,0) in /usr/share/simplesamlphp/modules/negotiate/lib/Auth/Source/Negotiate.php on line 143: /var/www/saml/php-cgi, referer: https://edu01.testdomain.de/univention/portal/

Ich frage mich nun, was die Meldung “An unsupported mechanism was requested (65536,0)” genau bedeutet. Kann jemand diese Meldung interpretieren?
Was ist hier mit “mechanism” gemeint? Ein Verschlüsselungsalgorithmus oder ein Authentifizierungsverfahren? Was sagen die Zahlen?

Oder vielleicht hat jemand schon genau diese Meldung gesehen und kann einen Tip geben?

Gruß
Sven

#2

Pauschal kann man das auf Grund der Fehlermeldung nicht beantworten. Ich würde mit diesem Debuggingartikel bei der Fehlersuche beginnen: https://help.univention.com/t/8176. Insbesondere die Punkte Is the keytab generated and can a Kerberos ticket created? und Does the logged in user in Windows or Linux have a valid Kerberos Ticket for the UCS domain

#3

Den Artikel haben wir schon durch. Das sollte alles stimmen.

Nur bei dem Punkt dem dem gültigen Ticket für die UCS Domäne bin ich mir unsicher. Dort steht einfach nur: "Does the logged in user in Windows or Linux have a valid Kerberos Ticket for the UCS domain? Check with klist"
Wie überprüfe ich das genau bzw. welche Ausgabe wird von klist erwartet?

Aber nochmal zurück zur Fehlermeldung. Ist denn hier eindeutig festlegbar, was mit “mechanism” gemeint ist? Würde mir bei der Interpretation der Fehlermeldung weiterhelfen…

#4

Hallo!
Vielleicht helfen ja die Ausgaben weiter.

Ich vermisse auf dem Client ein Ticket für HTTP. Bin mir hier nicht sicher, da es ja nicht funktioniert und ich keine Referenz habe, wo ich nachschauen könnte, aber müsste da nicht ein Ticket vom Typ HTTP existieren?

Vielleicht kann ja noch jemand helfen…

Gruß
Sven

Ausgaben auf dem Master-DC:

root@mdc01:~# klist

Credentials cache: FILE:/tmp/krb5cc_0
        Principal: HTTP/ucs-sso.testdomain.de@TESTDOMAIN.DE

  Issued                Expires               Principal
Aug  5 15:04:25 2019  Aug  6 15:04:25 2019  krbtgt/TESTDOMAIN.DE@TESTDOMAIN.DE
Aug  5 15:05:14 2019  Aug  6 15:04:25 2019  host/standort1-vw01.testdomain.de@
Aug  5 15:05:14 2019  Aug  6 15:04:25 2019  host/standort1-vw01.testdomain.de@TESTDOMAIN.DE
Aug  5 15:05:15 2019  Aug  6 15:04:25 2019  host/standort1-edu01.testdomain.de@
Aug  5 15:05:15 2019  Aug  6 15:04:25 2019  host/standort1-edu01.testdomain.de@TESTDOMAIN.DE
Aug  5 15:10:57 2019  Aug  6 15:04:25 2019  host/standort2-edu01.testdomain.de@
Aug  5 15:10:57 2019  Aug  6 15:04:25 2019  host/standort2-edu01.testdomain.de@TESTDOMAIN.DE

root@mdc01:~# ktutil --keytab=/etc/simplesamlphp.keytab list
/etc/simplesamlphp.keytab:

Vno  Type                     Principal                                                 Aliases
  1  aes256-cts-hmac-sha1-96  HTTP/ucs-sso.testdomain.de@TESTDOMAIN.DE  
  1  des3-cbc-sha1            HTTP/ucs-sso.testdomain.de@TESTDOMAIN.DE  
  1  des-cbc-md4              HTTP/ucs-sso.testdomain.de@TESTDOMAIN.DE  
  1  des-cbc-crc              HTTP/ucs-sso.testdomain.de@TESTDOMAIN.DE  
  1  aes128-cts-hmac-sha1-96  HTTP/ucs-sso.testdomain.de@TESTDOMAIN.DE  
  1  arcfour-hmac-md5         HTTP/ucs-sso.testdomain.de@TESTDOMAIN.DE  
  1  des-cbc-md5              HTTP/ucs-sso.testdomain.de@TESTDOMAIN.DE

Auf dem Windows-Client:

Windows 10 (10.0.18362.239) mit Login “schueler”

I:\> klist
Aktuelle Anmelde-ID ist 0:0x57678

Zwischengespeicherte Tickets: (5)

#0>     Client: schueler @ TESTDOMAIN.DE
        Server: krbtgt/TESTDOMAIN.DE @ TESTDOMAIN.DE
        KerbTicket (Verschlüsselungstyp): AES-256-CTS-HMAC-SHA1-96
        Ticketkennzeichen 0x60ac0000 -> forwardable forwarded renewable pre_authent ok_as_delegate 0x80000
        Startzeit: 8/6/2019 11:50:49 (lokal)
        Endzeit:   8/6/2019 21:50:48 (lokal)
        Erneuerungszeit: 8/13/2019 11:50:48 (lokal)
        Sitzungsschlüsseltyp: AES-256-CTS-HMAC-SHA1-96
        Cachekennzeichen: 0x2 -> DELEGATION
        KDC aufgerufen: standort2-edu01.testdomain.de

#1>     Client: schueler @ TESTDOMAIN.DE
        Server: krbtgt/TESTDOMAIN.DE @ TESTDOMAIN.DE
        KerbTicket (Verschlüsselungstyp): AES-256-CTS-HMAC-SHA1-96
        Ticketkennzeichen 0x40e00000 -> forwardable renewable initial pre_authent
        Startzeit: 8/6/2019 11:50:48 (lokal)
        Endzeit:   8/6/2019 21:50:48 (lokal)
        Erneuerungszeit: 8/13/2019 11:50:48 (lokal)
        Sitzungsschlüsseltyp: AES-256-CTS-HMAC-SHA1-96
        Cachekennzeichen: 0x1 -> PRIMARY
        KDC aufgerufen: STANDORT2-EDU01

#2>     Client: schueler @ TESTDOMAIN.DE
        Server: cifs/standort2-edu01.testdomain.de/testdomain.de @ TESTDOMAIN.DE
        KerbTicket (Verschlüsselungstyp): AES-256-CTS-HMAC-SHA1-96
        Ticketkennzeichen 0x40ac0000 -> forwardable renewable pre_authent ok_as_delegate 0x80000
        Startzeit: 8/6/2019 11:51:20 (lokal)
        Endzeit:   8/6/2019 21:50:48 (lokal)
        Erneuerungszeit: 8/13/2019 11:50:48 (lokal)
        Sitzungsschlüsseltyp: AES-256-CTS-HMAC-SHA1-96
        Cachekennzeichen: 0
        KDC aufgerufen: standort2-edu01.testdomain.de

#3>     Client: schueler @ TESTDOMAIN.DE
        Server: LDAP/standort2-edu01.testdomain.de/testdomain.de @ TESTDOMAIN.DE
        KerbTicket (Verschlüsselungstyp): AES-256-CTS-HMAC-SHA1-96
        Ticketkennzeichen 0x40ac0000 -> forwardable renewable pre_authent ok_as_delegate 0x80000
        Startzeit: 8/6/2019 11:51:20 (lokal)
        Endzeit:   8/6/2019 21:50:48 (lokal)
        Erneuerungszeit: 8/13/2019 11:50:48 (lokal)
        Sitzungsschlüsseltyp: AES-256-CTS-HMAC-SHA1-96
        Cachekennzeichen: 0
        KDC aufgerufen: standort2-edu01.testdomain.de

#4>     Client: schueler @ TESTDOMAIN.DE
        Server: cifs/STANDORT2-EDU01 @ TESTDOMAIN.DE
        KerbTicket (Verschlüsselungstyp): AES-256-CTS-HMAC-SHA1-96
        Ticketkennzeichen 0x40ac0000 -> forwardable renewable pre_authent ok_as_delegate 0x80000
        Startzeit: 8/6/2019 11:50:49 (lokal)
        Endzeit:   8/6/2019 21:50:48 (lokal)
        Erneuerungszeit: 8/13/2019 11:50:48 (lokal)
        Sitzungsschlüsseltyp: AES-256-CTS-HMAC-SHA1-96
        Cachekennzeichen: 0
        KDC aufgerufen: standort2-edu01.testdomain.de

I:\>
#5

Zur Fehlermeldung: Ich kann daran nicht ersehen, was der genaue Fehler ist. Vermutlich stimmt ein Teil in der Kette bei der Kerberos Authentifizierung nicht.

Die Ausgaben sehen soweit erst einmal in Ordnung aus. Ich nehme an hier wurde testdomain.de in den Ausgaben eingesetzt, um die wahre Domain nicht zu nennen? Wichtig ist, dass die Hostnamen und Kerberos Domänen übereinstimmen. Ist der UCS Identity Provider wirklich über https unter der genannten URL ucs-sso.testdomain.de erreichbar? Oder wird ein anderer interner Hostname verwendet? Wenn die URL des IdP geändert wurde, müssen die Kerberoseinstellungen entsprechend angepasst werden, siehe auch den SAML/Kerberos Abschnitt in diesem Artikel: https://help.univention.com/t/6681

Funktioniert das Single Sign-On denn, wenn die Kerberos Variante wieder deaktiviert wird, also wieder ucr set saml/idp/authsource=univention-ldap gesetzt ist?

#6

Hallo!

Die Hostnamen und die Kerberos Domänen stimmen überein. Unter ucs-sso.testdomain.de bekomme ich die Anmeldeseite. Ich denke damit ist der Redirect korrekt?

Wenn ich auf https://edu01.testdomain.de/univention/portal/ gehe, dann bekomme ich die Startseite und sehe oben den “ANMELDEN” Knopf. Wenn ich dort drücke, bekomme ich einen Redirect auf ucs-sso.testdomain.de und sehe die Anmeldemaske.
Ich hätte jetzt hier erwartet, daß die Anmeldung durchgeführt wird…

Habe ich nun saml/idp/authsource=univention-ldap aktiviert, so passiert gar nichts weiter.
Ist hingegen saml/idp/authsource=univention-negotiate gesetzt, so erhalte ich im Apache2-Logfile die Meldung PHP Warning: KRB5NegotiateAuth::doAuthentication(): An unsupported mechanism was requested (65536,0) ..., wobei anschließend beim Edge (im Gegensatz zum Firefox) noch zusätzlich ein Fenster mit “Windows-Sicherheit” mit Benutzername/Kennwort Anfrage kommt und die Verbindung zu “ucs-sso.testdomain.de” hergestellt würde.

Ich verstehe nun auch nicht, wie das mit saml/idp/authsource=univention-ldap funktionieren soll. Sollte hier auch der Benutzer automatisch auf der Portalseite angemeldet werden? Ich dachte Kerberos ist dafür Pflicht?!

Außerdem würde ich immer noch gerne wissen, ob auf dem Client ein Kerberos-Ticket für HTTP existieren sollte! Vielleicht kann das ja mal jemand, der gerade erfolgreich via SSO angemeldet wurde mit klist überprüfen?!

Gruß
Sven

#7

Das Popup ist ein wichtiger Hinweis. Wenn der Browser kein Kerberos Zertifikat zum Single Sign-On Server schickt, erscheint bei manchen Browsern ebendieser Popup, weil die Software nicht weiß, wie mit dem http 403 Request umgegangen werden soll. (https://forge.univention.org/bugzilla/show_bug.cgi?id=47242)

Um das zu lösen muss sichergestellt sein, dass den Browsern erlaubt ist, das Kerberosticket an den Single Sign-On server zu schicken. Im Handbuch ist das für verschiedene Browser beschrieben: https://docs.software-univention.de/handbuch-4.4.html#domain:saml

Zu dem HTTP Ticket: Wenn ich mich richtig erinnere, erhält man das mit der ersten Anmeldung per Kerberos + SSO, vorher taucht es also nicht in der klist Ausgabe auf.

#8

So, ich habe noch einmal die Einstellungen für den Edge und Firefox kontrolliert. Die stimmen auch so. Beim Edge hatte wir einmal etwas gespielt und den Eintrag in den “Vertrauenswürdigen Sites” und nicht im “Lokales Intranet” gemacht, daher vermutlich der PopUp.

Und ich denke die Anmeldung wird korrekt an den DC geschickt, da ich hier ja auch die Fehlermeldung des simplesamlphp sehe. Also stimmt irgendetwas nicht mit dem was geschickt wird.

Gibt es irgendeine Möglichkeit das simplesamlphp zu debuggen?

Gruß
Sven

#9

Hallo,
können Sie einmal folgende Zeilen (Quelle) als Skript test.php unter /usr/share/simplesamlphp/www/ anlegen und ausführbar machen?

<?php
 if(!extension_loaded('krb5')) {
     die('KRB5 Extension not installed');
 }

 if(!empty($_SERVER['HTTP_AUTHORIZATION'])) {
     list($mech, $data) = explode(' ', $_SERVER['HTTP_AUTHORIZATION']);
     if(strtolower($mech) == 'basic') {
         echo "Client sent basic";
         die('Unsupported request');
     } else if(strtolower($mech) != 'negotiate') {
         echo "Couldn't find negotiate";
         die('Unsupported request');
     }
     $auth = new KRB5NegotiateAuth('/etc/simplesamlphp.keytab');
     $reply = '';
     if($reply = $auth->doAuthentication()) {
         header('HTTP/1.1 200 Success');
         echo 'Success - authenticated as ' . $auth->getAuthenticatedUser() . '<br>';
     } else {
         echo 'Failed to authN.';
         die();
     }
 } else {
     header('HTTP/1.1 401 Unauthorized');
     header('WWW-Authenticate: Negotiate',false);
     echo 'Not authenticated. No HTTP_AUTHORIZATION available.';
     echo 'Check headers sent by the browser and verify that ';
     echo 'apache passes them to PHP';
 }

Anschließend dann einmal https://edu01.testdomain.de/simplesamlphp/test.php aufrufen, Fehlermeldung posten und Skript wieder entfernen.

Gruß
Michel

#10

Hallo!
Danke für das Skript und der Verweis auf die Quelle.

Es sieht so aus, daß er mit den Kerberos Authentifizierung anfängt, also wohl die entsprechend passenden Daten erhält. Nur leider sieht der Fehler wieder dem schon angegebenen Fehler sehr ähnlich:

[Wed Aug 14 09:34:52.910693 2019] [cgi:error] [pid 9432] [client 172.25.72.196:50352] AH01215: PHP Warning:  KRB5NegotiateAuth::doAuthentication(): An unsupported mechanism was requested (65536,0) in /usr/share/simplesamlphp/www/test.php on line 17: /var/www/saml/php-cgi
[Wed Aug 14 09:34:52.911239 2019] [cgi:error] [pid 9432] [client 172.25.72.196:50352] AH01215: PHP Fatal error:  Uncaught Exception: Error while accepting security context in /usr/share/simplesamlphp/www/test.php:17: /var/www/saml/php-cgi
[Wed Aug 14 09:34:52.911417 2019] [cgi:error] [pid 9432] [client 172.25.72.196:50352] AH01215: Stack trace:: /var/www/saml/php-cgi
[Wed Aug 14 09:34:52.911679 2019] [cgi:error] [pid 9432] [client 172.25.72.196:50352] AH01215: #0 /usr/share/simplesamlphp/www/test.php(17): KRB5NegotiateAuth->doAuthentication(): /var/www/saml/php-cgi
[Wed Aug 14 09:34:52.911830 2019] [cgi:error] [pid 9432] [client 172.25.72.196:50352] AH01215: #1 {main}: /var/www/saml/php-cgi
[Wed Aug 14 09:34:52.912084 2019] [cgi:error] [pid 9432] [client 172.25.72.196:50352] AH01215:   thrown in /usr/share/simplesamlphp/www/test.php on line 17: /var/www/saml/php-cgi

Da ja der Fehler in der Funktion doAuthentication() passiert und die Klasse zuvor mit $auth = new KRB5NegotiateAuth('/etc/simplesamlphp.keytab'); erzeugt wird, habe ich mal die verwendete keytab ausgegeben.

Mit dem Kommando ktutil -k /etc/simplesamlphp.keytab list --timestamp erhalte ich folgendes:

/etc/simplesamlphp.keytab:

Vno  Type                     Principal                                 Date         Aliases
  1  aes256-cts-hmac-sha1-96  HTTP/ucs-sso.testdomain.de@TESTDOMAIN.DE  2019-04-03   
  1  des3-cbc-sha1            HTTP/ucs-sso.testdomain.de@TESTDOMAIN.DE  2019-04-03                   
  1  des-cbc-md4              HTTP/ucs-sso.testdomain.de@TESTDOMAIN.DE  2019-04-03                                                   
  1  des-cbc-crc              HTTP/ucs-sso.testdomain.de@TESTDOMAIN.DE  2019-04-03                                                   
  1  aes128-cts-hmac-sha1-96  HTTP/ucs-sso.testdomain.de@TESTDOMAIN.DE  2019-04-03                                   
  1  arcfour-hmac-md5         HTTP/ucs-sso.testdomain.de@TESTDOMAIN.DE  2019-04-03                                   
  1  des-cbc-md5              HTTP/ucs-sso.testdomain.de@TESTDOMAIN.DE  2019-04-03

Sieht also wie zuvor aus. Mich wundert nur der relative alte Timestamp vom April. Ist das ok?!

Weitere Ideen?

Gruß
Sven

#11

Was muss den ein setspn -q HTTP/usc-sso.testdomain.de zurückliefern?
Hier bekomme ich nur:

Die Domäne "DC=testdomain,DC=de" wird überprüft.

Es wurde kein derartiger SPN gefunden.

Wenn ich das auf den EDU Server mache mit setspn -q HTTP/edu01.testdomain.de bekomme ich:

Die Domäne "DC=testdomain,DC=de" wird überprüft.
CN=http-proxy-edu01,CN=Users,DC=testdomain,DC=de
      HTTP/edu01.testdomain.de

Bestehender SPN wurde gefunden.

Ist das korrekt?

Kann die Meldung An unsupported mechanism was requested (65536,0) auch bedeuten, dass er gar nicht mit Kerberos ankommt, sondern noch ein anderes Verfahren (z.B. NTLM) versucht?

Gruß
Sven

#12

Hi Sven,

für mich sieht das tatsächlich so aus als ob fälschlicherweise NTLM versucht wird. Ich bin aber leider etwas überfragt, was hier das Problem sein könnte.
Vertraut der Browser den generell dem Zertifikat unter ucs-sso…?
Gegebenenfalls könnte ich dir einen Zugang auf einem unserer Demo-Systeme einrichten damit du die Konfiguration mit einem funktionierenden Setup vergleichen kannst.
Wäre das etwas?

Beste Grüße
Michel

#13

Hallo!

ich werde versuchen das noch tiefer zu analysieren.
Dem Zertifkat wird vertraut, dazu hatte ich Stammzertifikat entsprechend eingespielt, aber ich kontrolliere das auch noch einmal.

Ein Zugang auf dem Demo-System würde vermutlich helfen. Einfach schon alleine um die Ausgaben zu vergleichen und dadurch den Fehler einzugrenzen.

Gruß
Sven

#14

Hallo!

Ich habe diese Problem immer noch nicht gelöst und muss dies daher nochmal reaktvieren…

Das Problem haben wir auf einem Testsystem des Kunden. Dieses besteht aus einem Master-DC und einem Backup-DC sowie einem EDU-Server. Meine SSO-Tests mache ich dort von einem virtuellen Windows-10 Client aus.

In einer virtuellen Umgebung habe mir jetzt noch einmal eine Testumgebung aufgebaut um das Problem hier zu testen. Dies ist allerdings ein kleineres System und besteht nur aus einem DC und einem Windows-10 Client.
Und in dieser Umgebung funktioniert das SSO problemlos.

Ich habe dann einmal angefangen zu vergleichen und mindestens (bisher) die folgenden beiden Unterschiede festgestellt:

Erstes:
Das Kommando setspn -q HTTP/usc-sso.testdomain.de (ausgeführt auf dem Windows-10 Client) liefert auf der problematischen Umgebung dies zurück:

Die Domäne "DC=testdomain,DC=de" wird überprüft. 
Es wurde kein derartiger SPN gefunden.

Auf der funktionierenden Umgebung bekomme ich

Die Domäne "DC=demoschule,DC=intranet" wird überprüft. 
CN=ucs-sso,CN=Users,DC=demoschule,DC=intranet
          HTTP/ucs-sso.demoschule.intranet
Bestehender SPN wurde gefunden.

Ich denke dies ist falsch. Wie kann ich das korrigieren?

Zweitens:

Das Kommando ktutil -k /etc/simplesamlphp.keytab list --timestamp liefert in der problematischen Umgebung die folgende Ausgabe:

/etc/simplesamlphp.keytab:

Vno  Type                     Principal                                 Date         Aliases
  1  aes256-cts-hmac-sha1-96  HTTP/ucs-sso.testdomain.de@TESTDOMAIN.DE  2020-03-23   
  1  des3-cbc-sha1            HTTP/ucs-sso.testdomain.de@TESTDOMAIN.DE  2020-03-23                   
  1  des-cbc-md4              HTTP/ucs-sso.testdomain.de@TESTDOMAIN.DE  2020-03-23                                                   
  1  des-cbc-crc              HTTP/ucs-sso.testdomain.de@TESTDOMAIN.DE  2020-03-23                                                   
  1  aes128-cts-hmac-sha1-96  HTTP/ucs-sso.testdomain.de@TESTDOMAIN.DE  2020-03-23                                   
  1  arcfour-hmac-md5         HTTP/ucs-sso.testdomain.de@TESTDOMAIN.DE  2020-03-23                                   
  1  des-cbc-md5              HTTP/ucs-sso.testdomain.de@TESTDOMAIN.DE  2020-03-23

In der funktionierenden Umgebung habe ich die folgende Ausgabe:

/etc/simplesamlphp.keytab:

Vno  Type                     Principal                                             Date        Aliases
  2  des-cbc-crc              HTTP/ucs-sso.demoschule.intranet@DEMOSCHULE.INTRANET  2020-03-25  
  2  des-cbc-crc              ucs-sso@DEMOSCHULE.INTRANET                           2020-03-25  
  2  des-cbc-md5              HTTP/ucs-sso.demoschule.intranet@DEMOSCHULE.INTRANET  2020-03-25  
  2  des-cbc-md5              ucs-sso@DEMOSCHULE.INTRANET                           2020-03-25  
  2  arcfour-hmac-md5         HTTP/ucs-sso.demoschule.intranet@DEMOSCHULE.INTRANET  2020-03-25  
  2  arcfour-hmac-md5         ucs-sso@DEMOSCHULE.INTRANET                           2020-03-25  
  2  aes128-cts-hmac-sha1-96  HTTP/ucs-sso.demoschule.intranet@DEMOSCHULE.INTRANET  2020-03-25  
  2  aes128-cts-hmac-sha1-96  ucs-sso@DEMOSCHULE.INTRANET                           2020-03-25  
  2  aes256-cts-hmac-sha1-96  HTTP/ucs-sso.demoschule.intranet@DEMOSCHULE.INTRANET  2020-03-25  
  2  aes256-cts-hmac-sha1-96  ucs-sso@DEMOSCHULE.INTRANET                           2020-03-25

Hier ist mir aufgefallen, daß auf dem funktionierenden System zusätzliche Einträge ohne HTTP/ vorhanden sind.
Kann dies irgendjemand beurteilen?
Hat jemand eine Idee, wieso diese Einträge fehlen?

Der für mich wichtigste Unterschied scheint zu sein, daß die eine Umgebung eine Multi-Site Umgebung ist und die andere (funktionierende) eine Single-Site Umgebung ist.
Daher stelle ich mir die Frage, ob bei Multi-Site Umgebungen irgendeine wichtige Konfiguration angepaßt gehört?!

Gruß
Sven

#15

Habe noch einen Unterschied festgestellt:

Das Kommando samba-tool spn list ucs-sso liefert in der funktionierenden Umgebung:

ucs-sso
User CN=ucs-sso,CN=Users,DC=demoschule,DC=intranet has the following servicePrincipalName: 
	 HTTP/ucs-sso.demoschule.intranet

In der nicht funktionierenden Umgebung habe entweder (auf dem EDU Server):

ucs-sso
User CN=ucs-sso,CN=Users,DC=testdomain,DC=de has no servicePrincipalName

oder auf den Master und Backup DCs die folgende Fehlermeldung:

ltdb: tdb(/var/lib/samba/private/sam.ldb): tdb_open_ex: could not open file /var/lib/samba/private/sam.ldb: No such file or directory

Unable to open tdb '/var/lib/samba/private/sam.ldb': No such file or directory
Failed to connect to '/var/lib/samba/private/sam.ldb' with backend 'tdb': Unable to open tdb '/var/lib/samba/private/sam.ldb': No such file or directory

Ist das normal, dass auf den DCs das Kommando nicht funktioniert?
Und ich denke der Unterschied hier erklärt dann auch den Unterschied der Anzeige unter Windows…

#16

Hallo!

Ich habe inzwischen eine Rückmeldung von Univention:

Dies funktioniert in Multi-Site-Schulumgebungen (UCS@school) zur Zeit
nicht für die Clients an der Schule. Allerdings für Clients in
UCS@school-Umgebungen, die direkt gegen den Master gejoined sind, bspw.
Single-School-Umgebungen).

Dies ist allerdings kein Problem nur in UCS@school Umgebungen, sondern
betrifft den UCS Core. Es gibt hierzu inzwischen einen Bugzilla-Eintrag:

http://forge.univention.org/bugzilla/show_bug.cgi?id=51078

Mastodon