ldap-Authentifzierung scheitert


#1

Hallo zusammen,

heute Morgen musste ich feststellen, dass sich Benutzer der Nextcloud nicht mehr anmelden können. Das Log der Cloud zeigt:

“user_ldap Bind failed: 49: Invalid credentials
Warning core Login failed: ‘hu’ (Remote IP: ‘XX.XX.XXX.XXX’)”

Ein Test der Ldap-Konfiguration der Nexctloud zeigte aber keine Auffälligkeiten. Alles so, wie es sein muss.

Ich habe dann mal auf dem Server nachgesehen: da war doch die Partition vollgelaufen, da ein share nicht mehr erreicht wurde (k.a. wieso, vllt. hat der Hausmeister mal wieder mit dem Strom gespielt).
Hab die Daten gelöscht,
ein Reboot mit fsck durchgeführt,
mit service slapd status geschaut, ob der Ldap läuft
ein sophomorix-dump-pg2ldap gemacht,
ohne Erfolg.

Ein Blick ins Syslog bracht lediglich folgende Einträge:

11:52:05 server cyrus/pop3[3991]: executed
Apr 4 11:52:05 server cyrus/pop3[3991]: accepted connection
Apr 4 11:52:05 server cyrus/pop3[3991]: counts: retr=<0> top=<0> dele=<0>
Apr 4 11:52:29 server cyrus/pop3[3991]: accepted connection
Apr 4 11:52:29 server cyrus/pop3[3991]: fetching user_deny.db entry for ‘huber’
Apr 4 11:52:31 server cyrus/pop3[3991]: badlogin: localhost.localdomain [127.0.0.1] plaintext huber SASL(-13): authentication failure: checkpass failed
Apr 4 11:52:34 server cyrus/pop3[3991]: counts: retr=<0> top=<0> dele=<0>

Ich bin im Moment echt ratlos. Vllt. hat ja einer von euch ne Idee.
Ach ja, ich habe letztens den Ipfire auf Core 119 geupdated und dort gibt es scheinbar ein Problem mit DNSSec, hab mir das aber noch nicht weiter angeschaut.

Danke fürs Mitdenken

Viele Grüße

christian


#2

Ich antworte mir mal selbst.
Das Problem scheint sich auf die komplette Benutzeranmeldung zu beziehen. An den Clients im Haus kann man sich auch nicht mehr anmelden. Offenbar hat es eine Stromunterbrechung gegeben. Wieso die USV das nicht abgefangen hat, weiß ich auch nicht.
Der LDAP läuft allerdings…

Gruß ch


#3

Hallo Christian,

jetzt in den Ferien würde ich nicht lange suchen, sondern ein Backup zurückspielen und die USV überprüfen.

Viele Grüße

Wiflried


#4

Hallo Wilfried,

tja, es wurmt mich aber tierisch. Und ein Backup zurückspielen ist für mich nur das letzte Mittel…

Viele Grüße

christian


#5

Hallo Christian,

Stromausfall hat deinen LDAP beschädigt… kein Problem, es gibt ein Backup.
Zurückspielen mittels

sophomorix-dump-pg2ldap

fertig

LG

Holger


#6

Hallo Holger,

das hatte ich schon versucht, leider ohne Erfolg…
sophomorix-dump-pg2ldap läuft ohne Probleme durch

Gruß ch


#7

Hallo,

läuft der ldap

was ergibt

ps -A|grep ldap

Wenn er nicht läuft, welche Antwort ergibt

service slapd start

oder

service slapd restart

Gruß

Alois


#8

Hallo Alois,

ps -A | grep ldap gibt nichts aus.

service slapd restart

  • Stopping OpenLDAP slapd [ OK ]
  • Starting OpenLDAP slapd [ OK ]

service slapd status

  • slapd is running

Sieht eigentlich recht unauffällig aus.

Viele Grüße

ch


#9

Hallo,

ja, sieht gut aus. Gehts jetzt?

Kommst Du irgendwie auf einen Rechner in der Schule? Wenn ja, klappt der Login dort?

Die Abfrage muss lauten

ps -A|grep sla

zurückkommen müsste

19:18/1 server ~ # ps -A|grep sla
24580 ? 00:00:07 slapd
25572 ? 00:00:00 saslauthd
25573 ? 00:00:00 saslauthd
25574 ? 00:00:00 saslauthd
25575 ? 00:00:00 saslauthd
25576 ? 00:00:00 saslauthd

Gruß

Alois


#10

Hallo Alois,

ps -A|grep sla:
3427 ? 00:00:00 saslauthd
3428 ? 00:00:00 saslauthd
3429 ? 00:00:00 saslauthd
3431 ? 00:00:00 saslauthd
3432 ? 00:00:00 saslauthd
27853 ? 00:00:04 slapd

Weiterhin keine Anmeldung möglich (mrbs, cloud). An einen Rechner in der Schule komme ich im Moment nicht ran. da muss ich erst meinen virtuellen reaktivieren.

Gruß ch


#11

Hallo,

da auch der bind in der Fehlermeldung auftaucht versuch den mal zu restarten

service bind9 restart

was passiert?

Gruß

Alois


#12

Hallo,

service bind9 restart

  • Stopping domain name service… bind9
    waiting for pid 1682 to die
    [ OK ]
  • Starting domain name service… bind9 [ OK ]

Keine Veränderung. Alles wie gehabt…

Danke trotzdem

gruß ch


#13

Hallo,

ich würde mal den IPFire kontrollieren: der war ja dann auch abgeschmiert.
Sind die Portweiterleitungen noch drin?

Läuft mrbs auf dem Server oder extern?

Dann schau mal nach deiner/etc/ldap/slapd.conf
War da die Nextcloud eingetragen?
Steht sie noch drin?

LG

Holger


#14

Hallo Holger,

mrbs läuft auf dem server.
Alle Regeln sind im IPfire noch vorhanden.
Ebenso der Eintrag für die Cloud im IPFire in /etc/ldap/slapd.conf

Hmmm, das ist echt komisch. Wahrscheinlich hab ich einfach nur irgendein Detail übersehen…

Gruß ch


#15

Hallo Christian,

dann müssen wir weiter suchen.

Wie sieht es mit Anmeldung an horde3 aus?
Was erscheint den so in den syslog und ldap/slapd logdateien?
Kommen Anfragen von der nextcloud überhaupt an?

poste doch mal deine /etc/ldap/slapd.conf
(ohne das slapd secret darin).

Kontrollier auch nochmal, ob inzwischen genügend Platz auf dem Server ist.

Setzt mal das Passwort eines users mittels spohomorix-passwd -u nutzer
–passwd=geheim und teste den mrbs/horde ZUgang mit ihm.

LG

Holger


#16

Hallo Holger,

die Anmeldung an horde3, mrbs, portfolio (auf dem server) und cloud (nicht auf dem server) scheitert nach wie vor.
Anmeldung an den Clients ebenfalls (Stand gestern Nachmittag)

syslog beim Anmeldeversuch an horde:
Apr 5 09:06:10 server cyrus/pop3s[7736]: counts: retr=<0> top=<0> dele=<0>
Apr 5 09:06:13 server master[7740]: about to exec /usr/lib/cyrus/bin/imapd
Apr 5 09:06:13 server cyrus/imap[7740]: executed
Apr 5 09:06:13 server cyrus/imap[7740]: accepted connection
Apr 5 09:06:16 server cyrus/imap[7740]: badlogin: server.paedml-linux.lokal [10 .16.1.1] PLAIN [SASL(-13): authentication failure: Password verification failed]

hier die slapd.conf

>>  ##### 
> > ##### 
> > ##### 
> > # $Id: slapd.conf 1334 2012-07-20 12:03:39Z tschmitt $
> > #######################################################################
> > #
> > # Global Directives:
> > 
> > # Features to permit
> > #allow bind_v2
> > 
> > # Schema and objectClass definitions
> > include         /etc/ldap/schema/core.schema
> > include         /etc/ldap/schema/cosine.schema
> > include         /etc/ldap/schema/misc.schema
> > include         /etc/ldap/schema/nis.schema
> > include         /etc/ldap/schema/inetorgperson.schema
> > include         /etc/ldap/schema/samba.schema
> > include         /etc/ldap/schema/sophomorix.schema
> > 
> > # Schema check allows for forcing entries to
> > # match schemas for their objectClasses's
> > #schemacheck     on
> > 
> > # Where the pid file is put. The init.d script
> > # will not stop the server if you change this.
> > pidfile         /var/run/slapd/slapd.pid
> > 
> > # List of arguments that were passed to the server
> > argsfile        /var/run/slapd/slapd.args
> > 
> > # Read slapd.conf(5) for possible values
> > loglevel        0
> > 
> > # Where the dynamically loaded modules are stored
> > modulepath	/usr/lib/ldap
> > moduleload	back_hdb
> > 
> > # The maximum number of entries that is returned for a search operation
> > sizelimit       unlimited
> > 
> > # use passwords encrypted with ssha
> > password-hash {SSHA}
> > 
> > #######################################################################
> > # Specific Backend Directives for bdb:
> > # Backend specific directives apply to this backend until another
> > # 'backend' directive occurs
> > backend		hdb
> > 
> > #######################################################################
> > # Specific Directives for database #1, of type sql:
> > # Database specific directives apply to this databasse until another
> > # 'database' directive occurs
> > database        hdb
> > 
> > #LDAP Suffix 
> > suffix          "dc=paedml-linux,dc=lokal"
> > 
> > #LDAP Admin
> > rootdn          "cn=admin,dc=paedml-linux,dc=lokal"
> > rootpw          xxxxxxxxxxx
> > 
> > # Where the database file are physically stored for database #1
> > directory       "/var/lib/ldap"
> > 
> > # The dbconfig settings are used to generate a DB_CONFIG file the first
> > # time slapd starts.  They do NOT override existing an existing DB_CONFIG
> > # file.  You should therefore change these settings in DB_CONFIG directly
> > # or remove DB_CONFIG and restart slapd for changes to take effect.
> > 
> > # For the Debian package we use 2MB as default but be sure to update this
> > # value if you have plenty of RAM
> > dbconfig set_cachesize 0 2097152 0
> > 
> > # Sven Hartge reported that he had to set this value incredibly high
> > # to get slapd running at all. See http://bugs.debian.org/303057 for more
> > # information.
> > 
> > # Number of objects that can be locked at the same time.
> > dbconfig set_lk_max_objects 1500
> > # Number of locks (both requested and granted)
> > dbconfig set_lk_max_locks 1500
> > # Number of lockers
> > dbconfig set_lk_max_lockers 1500
> > 
> > # Indexing options for database #1
> > index	objectClass,uid,uidNumber,gidNumber,memberUid	eq
> > index	cn,mail,surname,givenname			eq,subinitial
> > index	sambaSID					eq
> > index	sambaPrimaryGroupSID				eq
> > index	sambaDomainName					eq
> > 
> > # Save the time that the entry gets modified, for database #1
> > lastmod         on
> > 
> > # Checkpoint the BerkeleyDB database periodically in case of system
> > # failure and to speed slapd shutdown.
> > checkpoint      512 30
> > 
> > #######################################################################
> > #Limits Access:
> > access to attrs=sambaLMPassword,sambaNTPassword,sambaPwdLastSet,sambaPwdMustChange,sambaAcctFlags,userPassword
> >        by anonymous peername.ip=10.16.1.254 auth
> >        by anonymous peername.ip=10.16.1.1 auth
> >        by anonymous peername.ip=XXX.XXX.XXX.XXX auth -> das ist die Cloud. IP stimmte
> >        by anonymous peername.ip=127.0.0.1 auth
> >        by anonymous peername.ip=129.143.228.4 auth
> >        by anonymous peername.ip=10.16.1.20 auth
> >        by anonymous peername.ip=10.16.1.11 auth
> >        by anonymous peername.ip=10.16.1.23 auth
> >        by anonymous ssf=56 auth
> >        by self peername.ip=127.0.0.1 write
> >        by self ssf=56 write
> >        by * none 
> > 
> > access to *
> >        by * read
> > 
> > #######################################################################
> > # TLS:
> > #TLSCipherSuite HIGH:MEDIUM:+SSLv2
> > TLSCACertificateFile /etc/ssl/private/server.pem
> > TLSCertificateFile /etc/ssl/private/server.pem
> > TLSCertificateKeyFile /etc/ssl/private/server.pem
> > 
> > # Use the following if client authentication is required
> > #TLSVerifyClient demand
> > # ... or not desired at all
> > #TLSVerifyClient never 
> > 
> > #The cachesize directive defines the number of entries that the LDAP backend will maintain in memory
> > #cachesize 10000

Genug Platz ist jetzt wieder:

 df -h:
Dateisystem                 Größe Benutzt Verf. Verw% Eingehängt auf
/dev/vda2                     16G    3,4G   12G   23% /
udev                          12G     12K   12G    1% /dev
tmpfs                        2,3G    1,7M  2,3G    1% /run
none                         5,0M       0  5,0M    0% /run/lock
none                          12G       0   12G    0% /run/shm
/dev/vdb1                    673G    349G  291G   55% /media/backup/migration-backup
/dev/vda1                    453M     59M  368M   14% /boot
/dev/sdb                     395G    196G  179G   53% /var
/dev/sda                     404G    151G  233G   40% /home
/dev/sdc                     9,1G     21M  8,6G    1% /var/spool/cups
10.16.1.5:/rsnapshot-server  3,6T    389G  3,3T   11% /media/backup/rsnapshot-migration

Ändere ich das Passwort für einen User, geht die Anmeldung an Horde, mrbs etc. und an der Cloud.
(Anmeldung am Client kann ich im Moment nicht testen)
Kann man hier einen Anhang mitschicken. Wenn ja, hänge ich noch die Ausgabe des syslog zum ldap an.

ldap-log.odt (26,0 KB)

Viele Grüße

Christian


#17

Hallo Christian,

hier die slapd.conf

sieht bei mir entsprechend aus.

Ändere ich das Passwort für einen User, geht die Anmeldung an Horde,
mrbs etc. und an der Cloud.

… das habe ich befürchtet.

(Anmeldung am Client kann ich im Moment nicht testen)

wird dann wohl auch gehen.

Wie es sich mir darstellt würde ich sagen es ist so abgelaufen:

  1. der Stromausfall hat die Datenbank beschädigt (passiert bei
    chrashenden virtualisierten Servern viel eher als bei welchen, die auf
    dem Blech laufen …).
  2. entweder ist der lauf von sophomorix-dump-pg2ldap nicht ordentlich
    durchgelaufen (hoffentlich) oder das Backup war auch korrupt… dann
    haben wir ein Problem.

Deswegen versuch erstmal einen weiteren sophomorix-dump-pg2ldap
Wenn das nicht hilft, dann frage ich bei Rüdiger nach, wie man ein
älteres Backup des ldap zurückspielen kann.

Ich drück dir die Daumen.

LG

Holger


#18

Hallo Holger,

oh je!!!
Hier mal die Ausgabe von sophomorix-dump-pg2ldap. So sah das gestern auch aus.

10:16/0 server ~ # service slapd status
 * slapd is running
10:17/0 server ~ # sophomorix-dump-pg2ldap
#### /usr/sbin/sophomorix-dump-pg2ldap started ...                        ####
Dumping to /var/log/sophomorix/pg2ldif...
   * Dumping groups.sql to /var/log/sophomorix/pg2ldif
   * Dumping accounts.sql to /var/log/sophomorix/pg2ldif
   * Dumping groups_users.sql to /var/log/sophomorix/pg2ldif
   * Appending dump of primary groups to /var/log/sophomorix/pg2ldif
Converting to slapd.ldif with dc=paedml-linux,dc=lokal ...
Loading ldif file /var/log/sophomorix/pg2ldif/slapd.ldif
 * Stopping OpenLDAP slapd                                                                                                                                      [ OK ]
slapd: Kein Prozess gefunden
throwing away old ldap tree and creating a new...
 * Starting OpenLDAP slapd                                                                                                                                      [ OK ]
 * Stopping OpenLDAP slapd                                                                                                                                      [ OK ]
Populating ldap with /usr/share/sophomorix/config-templates/ldap/local-gen.ldif using the following command:
slapadd -c -l /usr/share/sophomorix/config-templates/ldap/local-gen.ldif -f /etc/ldap/slapd.conf
_#################### 100.00% eta   none elapsed            none fast!
Closing DB...
Loading dump: slapadd -c -l /var/log/sophomorix/pg2ldif/slapd.ldif -f /etc/ldap/slapd.conf
*#################### 100.00% eta   none elapsed             51s spd  26.9 k/s
Closing DB...
 * Starting OpenLDAP slapd                                                                                                                                      [ OK ]
#### /usr/sbin/sophomorix-dump-pg2ldap terminated regularly               ####
10:18/0 server ~ #

Hat nicht geholfen

Gruß

ch


#19

Hallo Christian,

ich habe Rüdiger geschrieben.

Nach dem erneuten dump geht die Anmeldung mit dem Account, der nach der
Passwortänderung ging, nicht mehr. Stimmts?

LG

Holger


#20

Hallo,
die Ausgabe von sophomorix-dump-pg2ldap sieht eigentlich gut aus.
(OK der ldap kann nicht gestoppt werden, weil er garnicht läuft, nehme ich an?)

Stehen in /usr/share/sophomorix/config-templates/ldap/local-gen.ldif typische ldif-Daten?

Was tut denn nicht?
Läuft der ldap?