Cloud not bind to ldap

Clientpflege Linuxclient
1

Hallo Zusammen,

wir haben zur Zeit das Problem, dass der Login in unsere linuxclient’s nicht mehr richtig klappt.
„Error found when loading /etc/profile“:

lm
lm934×205 366 KB

cat /var/log/syslog | grep linuxmuster-linuxclient7 | grep ERROR

ergibt

Jan 30 10:19:44 linux-efi-vm linuxmuster-linuxclient7: [ERROR] Cloud not bind to ldap!
Jan 30 10:19:44 linux-efi-vm linuxmuster-linuxclient7: [ERROR] === An exception occurred ===
Jan 30 10:19:44 linux-efi-vm linuxmuster-linuxclient7: [ERROR] {desc: Local error, info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Server not found in Kerberos database)}
Jan 30 10:19:44 linux-efi-vm linuxmuster-linuxclient7: [ERROR] === end exception ===
(...)

Connect mit „LDAP Admin“ von einem Win10 PC aus klappt aber mit und auch ohne SSL.

Was könnte das Problem sein?

Vielen Dank für Antworten in vorraus.

2

Möglicherweise ein Netzwerk oder DNS-Problem?
Möglicherweise ein Problem mit dem LDAP-Zeritifkat?

Was dein Screenshot angeht: könnte auch ein inhaltlicher Fehler in den GPOs sein.

3

Netzwerk und DNS sollten ok sein. Das LDAP-Zeritifkat eigentlich auch, bin mir aber nicht ganz sicher.

Wir haben mal die LDAP-Verbindung mit telnet und openssl getestet und es sieht eigentlich so aus, als wenn ldap (port 389) und ldaps (port 636) antwortet und Zertifikat gültig ist:

root@linux-efi-vm:~# telnet 10.0.0.1 389
Trying 10.0.0.1...
Connected to 10.0.0.1.
Escape character is '^]'.
Müll eingegeben, damit ldap-server die Verbindung bendet
Connection closed by foreign host.
root@linux-efi-vm:~#
root@linux-efi-vm:~# openssl s_client -showcerts -connect 10.0.0.1:636 | openssl x509 -noout -dates
Can't use SSL_get_servername
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = xxx.xx.xxxxxxxxxxxx.de
verify return:1
notBefore=Dec 29 22:18:14 2023 GMT
notAfter=Mar 28 22:18:13 2024 GMT
Müll eingegeben, damit ldap-server die Verbindung bendet
root@linux-efi-vm:~#

Wir haben mal untersucht, wo der Fehler auftritt. Nämlich beim Auftruf von
/etc/profile.d/99-linuxmuster-linuxclient7.sh
via
/usr/share/linuxmuster-linuxclient7/scripts/executeHookWithEnvFix.sh onLogin
via
/usr/share/linuxmuster-linuxclient7/scripts/onLogin → user.mountHomeShare()
via
/usr/lib/python3/dist-packages/linuxmusterLinuxclient7/user.py → readAttributes() → ldapHelper.searchOne(f"(sAMAccountName={user.username()})")
via
/usr/lib/python3/dist-packages/linuxmusterLinuxclient7/ldapHelper.py → searchOne(filter) → conn() → _connect()
und da bei der ersten Verwendung von
sasl_auth,
das dort auf
sasl_auth = ldap.sasl.sasl({} ,'GSSAPI')
gesetzt wird.
Verwendet wird es bei
_currentLdapConnection.sasl_interactive_bind_s("", sasl_auth), aber auch schon ein
logging.warning("Hier5.1 ", sasl_auth) teminiert nicht und erzeugt die gleiche Fehlermeldung.

sasl_auth scheint also hier das Problem zu sein.

Wir sind da aber nicht die Experten.

Irgend welche Vorschläge?

4

Bin jetzt eher von der Systemintegrativen Sorte, denke die Entwickler melden sich sicher :slight_smile:

Was passiert, wenn du ein ldapsearch ausführt?

ldapsearch -H ldaps://ip:636 -x -b OU=SCHOOLS,DC=linuxmuster,DC=lan -D CN=global-admin,OU=Management,OU=default-school,OU=SCHOOLS,DC=linuxmuster,DC=la -W

Wenn das fehlschlägt kannst du mal LDAPTLS_REQCERT=never voranstellen - wenn es dan ngeht, stimmt etwas mit dem LDAP-Zert nicht.

LDAPTLS_REQCERT=never  -H ldaps://ip:636 -x -b OU=SCHOOLS,DC=linuxmuster,DC=lan -D CN=global-admin,OU=Management,OU=default-school,OU=SCHOOLS,DC=linuxmuster,DC=la n-W

Die Domain musst du natürlich auf dich anpassen. Vielleicht musst du noch die LDAP-Utils mittels apt isntallieren.

5

Hallo,
derzeit kommen meine Antworten nicht mehr in Discourse an. Hier meine Nachricht von Gestern.
LG
Holger

Hallo,

wir haben zur Zeit das Problem, dass der Login in unsere linuxclient’s nicht mehr richtig klappt.

an allen Clients? Ode rnur an manchen?

„Error found when loading /etc/profile“:

Was könnte das Problem sein?

ich meine das passiert, wenn der Client nicht mehr in der Domäne ist.

Was habt ihr den da?
Welche lmn?
Welches linbo?
Welchen linuxmuster-client?
Welches ubuntu am Client?

Stimmt die Systemzeit am Client mit der am Server überein?

LG

Holger

6

Also:

root@linux-efi-vm:~# ldapsearch -H ldaps://10.0.0.1:636 -x -b DC=sn,DC=xxxxxxxxxx,DC=de -D CN=global-admin,OU=Management,OU=GLOBAL,DC=sn,DC=xxxxxxxxxx,DC=de -W
Enter LDAP Password:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
root@linux-efi-vm:~#

Jedoch statt mit ip den kompletten hostnamen genommen, kommen ein ganzer Schwall von Daten:

root@linux-efi-vm:~# ldapsearch -H ldaps://srv.sn.xxxxxxxxxx.de:636 -x -b DC=sn,DC=xxxxxxxxxx,DC=de -D CN=global-admin,OU=Management,OU=GLOBAL,DC=sn,DC=xxxxxxxxxx,DC=de -W
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <DC=sn,DC=xxxxxxxxxx,DC=de> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
(...)
# search reference
ref: ldap://sn.xxxxxxxxxx.de/DC=ForestDnsZones,DC=sn,DC=xxxxxxxxxx,DC=
 de
# search result
search: 2
result: 0 Success
# numResponses: 2809
# numEntries: 2805
# numReferences: 3
root@linux-efi-vm:~#

Was uns aber noch aufgefallen ist:

Wir scheinen ein TLS-Problem zu haben?!

Aufruf im linuxclient:

root@linux-efi-vm:~# ldbsearch -H ldaps://srv.sn.xxxxxxxxxx.de -d=1  "cn=test.lehrer" -k yes
WARNING: The option -k|--kerberos is deprecated!
lpcfg_do_global_parameter: WARNING: The "client use spnego" option is deprecated
TLS ../../source4/lib/tls/tls_tstream.c:1423 - check failed for verify_peer[ca_and_name] and peer_name[srv.sn.xxxxxxxxxx.de] status 0x42 (invalid signer_not_found )
Failed to connect to ldap URL 'ldaps://srv.sn.xxxxxxxxxx.de' - LDAP client internal error: NT_STATUS_INVALID_PARAMETER
Failed to connect to 'ldaps://srv.sn.xxxxxxxxxx.de' with backend 'ldaps': LDAP client internal error: NT_STATUS_INVALID_PARAMETER
Failed to connect to ldaps://srv.sn.xxxxxxxxxx.de - LDAP client internal error: NT_STATUS_INVALID_PARAMETER
root@linux-efi-vm:~#

Derselbe Aufruf direkt auf dem linuxmuster-server:

root@srv:~# ldbsearch -H ldaps://srv.sn.xxxxxxxxxx.de -d=1  "cn=test.lehrer" -k yes
Password for [global-admin@SN.xxxxxxxxxx.DE]:
(...)
# Referral
ref: ldap://sn.xxxxxxxxxx.de/DC=ForestDnsZones,DC=sn,DC=xxxxxxxxxx,DC=de
# returned 4 records
# 1 entries
# 3 referrals

Zum System:
Server:

root@srv:~# dpkg -l | grep linuxmuster
ii  linuxmuster-base7                             7.1.21-0                                        all          linuxmuster.net configuration scripts
ii  linuxmuster-linbo-gui7                        7.0.6                                           all          Linuxmuster Linbo GUI
ii  linuxmuster-linbo7                            4.0.46-0                                        all          linuxmuster-linbo7
ii  linuxmuster-prepare                           7.2.1-1                                         all          linuxmuster.net pre setup configuration scripts
ii  linuxmuster-webui7                            7.1.51                                          all          Next generation web-based management tool for linuxmuster.net v7.x
root@srv:~#

Linux-Client:

root@linux-efi-vm:~# dpkg -l | grep linuxmuster
ii  linuxmuster-linuxclient7                   1.0.9                                       all          Package for Ubuntu clients to connect to the linuxmuster.net 7 active directory server.
root@linux-efi-vm:~#
7

Vermutlich liegt hier das Problem vor.

Bezüglich LDAP kannst du das austricksen, in dem du in die /etc/ldap/ldap.conf
tls_reqcert never (<- nur so ganz grob ausm kopf)
ergänzt.

Ich könnte mir vorstellen, dass das das eigentlcihe Problem aber nicht behebt.

Möglicherweise hilft ein neue Beitritt mit

sudo linuxmuster-linuxclient7 setup

AFAIK holt er sich da acuh nochmal neu die CA und so…
Könnte aber sein, dass sich die anderen Geräte dann nicht mehr anmelden können (wegen Computerpasswort) - bin da unsicher, weiß der Holger sicher besser…

8

Die /etc/ldap/ldap.conf auf dem Server oder die auf dem client oder beide anpassen?

Und genau das fragen wir uns hier schon länger: Haben wir eigetlich ein Problem mit dem Server oder mit den Linuxclient’s? Zur Erinnerung: LDAPAdmin von Win10 klappt, Radius etc. auch.

Das mit sudo linuxmuster-linuxclient7 setup haben wir schon mal gemacht, brachte aber nichts.

Was uns auch noch aufgefallen ist:

Kein Problem direkt auf dem Server (aber auch von einem Win10-Debian aus):

root@srv:~# ldapsearch -H ldaps://srv.sn.xxxxxxxx.de
SASL/NTLM authentication started
Please enter your password:
root@srv:~#

aber Fehler auf dem Linuxclient:

root@linux-efi-vm:~# ldapsearch -H ldaps://srv.sn.xxxxxxxx.de
SASL/GSS-SPNEGO authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
        additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (SPNEGO cannot find mechanisms to negotiate)
root@linux-efi-vm:~#

D.h.
mit SASL/NTLM authentication started klappt es,
mit SASL/GSS-SPNEGO authentication gibt es einen Fehler.

Kann man den linuxclient auf NTLM umstellen?

9

mit Option -Y ntlm klappt ldapsearch auch auf dem linuxclient:

root@linux-efi-vm:~# ldapsearch -H ldaps://srv.sn.antoniuskolleg.de -Y ntlm
SASL/NTLM authentication started
Please enter your password:
10

Hallo,

wir haben zur Zeit das Problem, dass der Login in unsere linuxclient’s
nicht mehr richtig klappt.

an allen Clients? Ode rnur an manchen?

„Error found when loading /etc/profile“:

Was könnte das Problem sein?

ich meine das passiert, wenn der Client nicht mehr in der Domäne ist.

Was habt ihr den da?
Welche lmn?
Welches linbo?
Welchen linuxmuster-client?
Welches ubuntu am Client?

Stimmt die Systemzeit am Client mit der am Server überein?

LG

Holger

11

So wie wir es aus dem Fehlermelungen der Kollegen interpretieren: Ja, wohl an allen linuxclients. Die werden in der Nacht immer alle geklont, und, da wie gesagt schon linuxmuster-linuxclient7 setup mit anschließendem prepare und Imageerstellung gelaufen ist, werden die das Problem auch alle haben.

Und:

Ubuntu-Version linuxclient:

root@linux-efi-vm:~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.6 LTS
Release:        20.04
Codename:       focal
root@linux-efi-vm:~#

Systemzeiten stimmen überein und werden syncronisiert.

12

Hallo Zusammen,
gibt es noch irgendwelche Vorschläge? Wir kommen hier wirklich nicht weiter. Es liegen seit mehr als einer Woche über 150 Clients brach. Kein Informatikunterricht etc…
Danke für weitere Vorschläge.

13

Auf dem Client müsste eigentlich reichen.

14

Wir haben jetzt noch ein paar Schritte versucht:

tls_reqcert auf dem client eingetragen. → keine Änderung

Server und Client geupdated, da war auch ldap mit dabei auf dem Server.

Geräteimport angestoßen.

Die einzigen Fehler die hier auffallen:

No option 'systemtype' in section: 'LINBO'
(häufig wiederholt)
---
No option 'cache' in section: 'LINBO'
No option 'cache' in section: 'LINBO'
No option 'systemtype' in section: 'LINBO'
'NoneType' object has no attribute 'replace'

Mit Ausnahme des start.conf.nopxe haben alle einen systemtype:

SystemType = efi64

Danach nochmal komplettes Image gemacht.

Jetzt kein login möglich.

15 
-- Subject: A start job for unit fprintd.service has finished successfully
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
--
-- A start job for unit fprintd.service has finished successfully.
--
-- The job identifier is 2609.
Feb 02 14:27:39 pxeclient ldap_child[23190]: Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: Preauthentication failed. Unable to create GSSAPI-encrypted LDAP connection.
Feb 02 14:27:43 pxeclient gdm-password][23143]: pam_unix(gdm-password:auth): check pass; user unknown
Feb 02 14:27:43 pxeclient gdm-password][23143]: pam_unix(gdm-password:auth): authentication failure; logname= uid=0 euid=0 tty=/dev/tty1 ruser= rhost=
Feb 02 14:27:43 pxeclient gdm-password][23143]: pam_winbind(gdm-password:auth): getting password (0x00000388)
Feb 02 14:27:43 pxeclient gdm-password][23143]: pam_winbind(gdm-password:auth): pam_get_item returned a password
Feb 02 14:27:43 pxeclient audit[1267]: AVC apparmor="ALLOWED" operation="open" profile="/usr/sbin/sssd" name="/proc/23143/cmdline" pid=1267 comm="sssd_pam" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Feb 02 14:27:43 pxeclient gdm-password][23143]: pam_sss(gdm-password:auth): authentication failure; logname= uid=0 euid=0 tty=/dev/tty1 ruser= rhost= user=test.lehrer
Feb 02 14:27:43 pxeclient gdm-password][23143]: pam_sss(gdm-password:auth): received for user test.lehrer: 10 (Benutzer bei zu Grunde liegendem Legitimierungsmodul nicht bekannt)
Feb 02 14:27:43 pxeclient kernel: audit: type=1400 audit(1706880463.032:133): apparmor="ALLOWED" operation="open" profile="/usr/sbin/sssd" name="/proc/23143/cmdline" pid=1267 comm="sssd_pam" requested_mask="r>Feb 02 14:27:43 pxeclient ldap_child[23272]: Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: Preauthentication failed. Unable to create GSSAPI-encrypted LDAP connection.
Feb 02 14:27:43 pxeclient ldap_child[23273]: Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: Preauthentication failed. Unable to create GSSAPI-encrypted LDAP connection.
Feb 02 14:27:55 pxeclient gnome-shell[1557]: ActUserManager: user (null) has no username (uid: -1)
Feb 02 14:27:55 pxeclient gdm-password][23497]: accountsservice: ActUserManager: user (null) has no username (uid: -1)
Feb 02 14:27:55 pxeclient audit[1266]: AVC apparmor="ALLOWED" operation="open" profile="/usr/sbin/sssd" name="/proc/23497/cmdline" pid=1266 comm="sssd_nss" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Feb 02 14:27:55 pxeclient kernel: audit: type=1400 audit(1706880475.304:134): apparmor="ALLOWED" operation="open" profile="/usr/sbin/sssd" name="/proc/23497/cmdline" pid=1266 comm="sssd_nss" requested_mask="r>Feb 02 14:28:01 pxeclient gdm-password][23497]: pam_unix(gdm-password:auth): check pass; user unknown
Feb 02 14:28:01 pxeclient gdm-password][23497]: pam_unix(gdm-password:auth): authentication failure; logname= uid=0 euid=0 tty=/dev/tty1 ruser= rhost=
Feb 02 14:28:01 pxeclient gdm-password][23497]: pam_winbind(gdm-password:auth): getting password (0x00000388)
Feb 02 14:28:01 pxeclient gdm-password][23497]: pam_winbind(gdm-password:auth): pam_get_item returned a password
Feb 02 14:28:01 pxeclient audit[1267]: AVC apparmor="ALLOWED" operation="open" profile="/usr/sbin/sssd" name="/proc/23497/cmdline" pid=1267 comm="sssd_pam" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Feb 02 14:28:01 pxeclient gdm-password][23497]: pam_sss(gdm-password:auth): authentication failure; logname= uid=0 euid=0 tty=/dev/tty1 ruser= rhost= user=global-admin
Feb 02 14:28:01 pxeclient gdm-password][23497]: pam_sss(gdm-password:auth): received for user global-admin: 10 (Benutzer bei zu Grunde liegendem Legitimierungsmodul nicht bekannt)
Feb 02 14:28:01 pxeclient kernel: audit: type=1400 audit(1706880481.268:135): apparmor="ALLOWED" operation="open" profile="/usr/sbin/sssd" name="/proc/23497/cmdline" pid=1267 comm="sssd_pam" requested_mask="r>Feb 02 14:28:06 pxeclient gdm-password][23708]: accountsservice: ActUserManager: user (null) has no username (uid: -1)
Feb 02 14:28:06 pxeclient audit[1266]: AVC apparmor="ALLOWED" operation="open" profile="/usr/sbin/sssd" name="/proc/23708/cmdline" pid=1266 comm="sssd_nss" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Feb 02 14:28:06 pxeclient kernel: audit: type=1400 audit(1706880486.264:136): apparmor="ALLOWED" operation="open" profile="/usr/sbin/sssd" name="/proc/23708/cmdline" pid=1266 comm="sssd_nss" requested_mask="r>Feb 02 14:28:07 pxeclient systemd[1]: fprintd.service: Succeeded.
16

Hallo zusammen,

nach den wildesten Tests und Recherchen konnten wir das Problem lösen:

  • der Reverse-DNS Eintrag von srv konnte nicht aufgelöst werden, damit ging auch kein Kerberos mehr.

SSL etc. waren große Nebelkerzen, aber nicht das Problem…

Der Weg dahin war steinig. wir haben auch einige Debugging-Techniken in den linuxmuster-client ldap eingebaut, falls da interesse ist, können wir das zur Verfügung stellen.

Danke an alle die geholfen haben.

Viele Grüße

Christian

1 „Gefällt mir“
17

Eventuell auch die Lösung für unser Proxy-Problem?

Wie genau habt ihr das Problem gelöst?

Danke und Gruß

Lars

18

Hallo Lars,

wir haben eine Liste zur Kerberos-Fehlersuche abgearbeitet, in etwa wie folgende: Problembehebung für Kerberos - Tableau

Bei folgendem Abschnitt wurden wir fündig.

DNS-Reverse-Lookup für die IP-Adresse des Servers.
Damit wird ein DNS-Name mithilfe einer IP-Adresse gesucht.
Geben Sie bei einer Eingabeaufforderung Folgendes ein:
ping servername
führen Sie mit der vom Ping-Befehl für den Server zurückgegebenen IP-Adresse ein DNS-Lookup aus und geben Sie Folgendes ein:
nslookup <ip address>
Der nslookup-Befehl gibt Netzwerkinformationen für die IP-Adresse zurück. Stellen Sie im Teil Nicht autorisierende Antwort der Antwort sicher, dass der vollständig qualifizierte Domänenname mit den folgenden konfigurierten Werten übereinstimmt:

  • Kerberos-Keytab-Datei
  • Service Principal Name (SPN) für den Server

Danach haben wir den Reverse-Eintrag vom Client aus wieder erreichbar gemacht. (opnsense-unbound DNS-Server)

Viele Grüße