Failed to check SAML-Certificates / LDAP invalid Credentials

UCS - Univention Corporate Server
#1

Hi,

UCS: 5.0-6 errata898
Installed: cups=2.2.1 dhcp-server=12.0 fetchmail=6.3.26 kopano-core=8.7.25.0-2 kopano-webapp=5.3.0.0-1 samba4=4.16 self-service=5.0 self-service-backend=5.0 z-push-kopano=2.6.4 4.4/benno-mailarchiv=2.8.16

the horror startet with this error in system diagnose, after a long update from 5.0-3

Zertifikat https://192.168.8.160/simplesamlphp/saml2/idp/certificate konnte nicht geladen werden: HTTPSConnectionPool(host='192.168.8.160', port=443): Max retries exceeded with url: /simplesamlphp/saml2/idp/certificate (Caused by NewConnectionError(': Failed to establish a new connection: [Errno 111] Verbindungsaufbau abgelehnt'))
Führen Sie das Join-Skript 92univention-management-console-web-server via Modul "Domänenbeitritt" oder univention-run-join-scripts --force --run-scripts 92univention-management-console-web-server auf der Befehlszeile as Benutzer root aus.

The certtificate is seems ok, but the ip address mentioned in that error message is wrong. The server was set up in a different network environment before going down to the server room. Where is “192.168.8.160” stored? It’s not in the univention registry. I believe, if i could change that ip address the error will be gone.

So i followed the instructions here to renew the SSL-Certs: Renewing the SSL certificates
That made everything worse. System diagnosis:

  1. Kritisch: Überprüfung der SAML-Zertifikate fehlgeschlagen

  2. Kritisch: Noch nicht migrierte Nutzer Objekte
    Irgendwelche Python-Fehlermeldungen und am Ende steht “ldap.INVALID_CREDENTIALS: {‘desc’: ‘Invalid credentials’}”

  3. Problem: Nicht synchronisierte S4-Objekte:
    " raise univention.admin.uexceptions.authFail(_(“Authentication failed”))
    univention.admin.uexceptions.authFail: Authentisierung fehlgeschlagen."

  4. Problem: LDAP-Objekte:
    " ldap.INVALID_CREDENTIALS: {‘desc’: ‘Invalid credentials’} "

  5. Problem: Server Role Windows
    " ldap.INVALID_CREDENTIALS: {‘desc’: ‘Invalid credentials’} "

  6. Problem: LDAP-Schema.Dateien sind nicht ordentlich registriert
    " ldap.INVALID_CREDENTIALS: {‘desc’: ‘Invalid credentials’} "

  7. Problem: Überprüfe Probleme mit der UDN Replikation
    " Univention Directory Notifier ID und die lokal gespeicherte Version unterscheiden sich.
    Dies mag auf einen Fehler oder noch ausstehende Transaktionen hinweisen. "

  8. Problem: Überprüfe Datei-Berechtigungen
    " Datei ‘/etc/ldap.secret’ hat den Besitzer ‘root:Backup Join’, während ‘root:DC Backup Hosts’ erwartet war.
    Datei ‘/etc/univention/ssl’ hat Datei-Modus 775, 755 war erwartet.
    Datei ‘/etc/univention/ssl/tuxserver.habdieschnauze.voll’ hat den Besitzer ‘root:DC Backup Hosts’, während ‘tuxserver$:DC Backup Hosts’ erwartet war. "

  9. Warnung: Validierung der LDAP- und Schema-Dateien
    " Die LDAP-Schema-Validierung ist mit den folgenden Fehlern oder Warnungen fehlgeschlagen:
    UNKNOWN attributeDescription “NEXTCLOUDENABLED” inserted.
    UNKNOWN attributeDescription “BAREOSENABLEJOB” inserted.
    UNKNOWN attributeDescription “CLIENTSECRET” inserted.
    UNKNOWN attributeDescription “CLIENTID” inserted.
    UNKNOWN attributeDescription “APPLICATIONTYPE” inserted.
    UNKNOWN attributeDescription “REDIRECTURI” inserted.
    UNKNOWN attributeDescription “TRUSTED” inserted. "

  10. Warnung: Teste die LDAP-Datenbank auf Inkosistenzen in Gruppen-Mitgliedschaften
    " /usr/share/univention-directory-manager-tools/proof_uniqueMembers -c hat einen Fehler in der LDAP-Datenbank mit Gruppenmitgliedschafts-Attributen gefunden. "

What the heck can i do here?

#3

So, i’m a bit further.
Restored server from backup by follwing that guid step by step: Cool Solution - Single Server Backup and Restore for UCS 4.3

and i have much less errors in system check.
Funny about this

root@tuxserver:~# id Administrator
id: „Administrator“: Einen solchen Benutzer gibt es nicht
root@tuxserver:~# ucr get server/role
domaincontroller_master
root@tuxserver:~# service slapd restart
root@tuxserver:~# service slapd status
● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)
   Loaded: loaded (/etc/init.d/slapd; generated)
   Active: active (running) since Tue 2023-12-19 17:55:02 CET; 12s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 15088 ExecStart=/etc/init.d/slapd start (code=exited, status=0/SUCCESS)
 Main PID: 15101 (slapd)
    Tasks: 3 (limit: 4915)
   Memory: 17.5M
   CGroup: /system.slice/slapd.service
           └─15101 /usr/sbin/slapd -h ldapi:/// ldap://:7389/ ldaps://:7636/ -f /etc/ldap/slapd.conf

Dez 19 17:55:01 tuxserver systemd[1]: Starting LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)...
Dez 19 17:55:02 tuxserver slapd[15100]: @(#) $OpenLDAP: slapd  (May 21 2022 17:09:54) $
                                                Debian OpenLDAP Maintainers <pkg-openldap-devel@lists.alioth.debian.org>
Dez 19 17:55:02 tuxserver slapd[15100]: Loaded metadata from "/usr/share/univention-management-console/saml/idp/ucs-sso.burglenzen.local.xml"
Dez 19 17:55:02 tuxserver slapd[15101]: WARNING: No dynamic config support for overlay translog.
Dez 19 17:55:02 tuxserver slapd[15101]: WARNING: No dynamic config support for overlay shadowbind.
Dez 19 17:55:02 tuxserver slapd[15101]: slapd starting
Dez 19 17:55:02 tuxserver slapd[15088]: Starting ldap server(s): slapd ...done.
Dez 19 17:55:02 tuxserver ldapsearch[15107]: DIGEST-MD5 common mech free
Dez 19 17:55:02 tuxserver slapd[15088]: Checking Schema ID: ...done.
Dez 19 17:55:02 tuxserver systemd[1]: Started LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol).
root@tuxserver:~# univention-ldapsearch uid=Administrator
# extended LDIF
#
# LDAPv3
# base <dc=burglenzen,dc=local> (default) with scope subtree
# filter: uid=Administrator
# requesting: ALL
#

# search result
search: 3
result: 0 Success

# numResponses: 1
root@tuxserver:~#  univention-ldapsearch -s base
# extended LDIF
#
# LDAPv3
# base <dc=habdieschnauze,dc=voll> (default) with scope baseObject
# filter: (objectclass=*)
# requesting: ALL
#

# habdieschnauze.voll
dn: dc=habdieschnauze,dc=voll
dc: habdieschnauze
univentionObjectType: container/dc
krb5RealmName: HABDIESCHNAUZE.VOLL
nisDomain: habdieschnauze.voll
associatedDomain: habdieschnauze.voll
objectClass: top
objectClass: krb5Realm
objectClass: univentionPolicyReference
objectClass: nisDomainObject
objectClass: domainRelatedObject
objectClass: domain
objectClass: univentionBase
objectClass: univentionObject
objectClass: msGPO
msGPOLink: [LDAP://CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=habdieschnauze,DC=voll;0]
univentionPolicyReference: cn=default-settings,cn=pwhistory,cn=users,cn=policies,dc=habdieschnauze,dc=volll
univentionPolicyReference: cn=default-users,cn=admin-settings,cn=users,cn=policies,dc=habdieschnauze,dc=voll
univentionPolicyReference: cn=UCS 4.0,cn=desktop,cn=policies,dc=habdieschnauze,dc=voll
univentionPolicyReference: cn=map-country-to-st,cn=config-registry,cn=policies,dc=habdieschnauze,dc=voll

# search result
search: 3
result: 0 Success

# numResponses: 2
# numEntries: 1

So where is Administrator? It is in the S4-Database:

root@tuxserver:~# univention-s4search -b "CN=Administrator,ou=Techniker,dc=habdieschnauze,dc=voll"
# record 1
dn: CN=Administrator,OU=Techniker,DC=habdieschauze,DC=voll
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: Administrator
userCertificate::......................
#4

hat sich erledigt. Ich mache einen neuen Beitrag auf.

Mastodon