Keine Anmeldung an SuiteCRM möglich

Hallo allerseits,

habe eben einen frischen UCS 4.1-2 Server aufgesetzt, um mal die APP SuiteCRM zu testen. Die Installation verlief ohne Fehler, aber ich kann mich auf der CRM Anmeldeseite weder als root noch als Administrator einloggen. Es werden dann zwei Fehlermeldungen angezeigt:

You have been logged out because your session has expired.
You must specify a valid username and password.

In dem Modul steht noch der Hinweis: Benutzer müssen in der Domänenadministration für diesen Dienst freigeschaltet werden
Der Server, auf dem die SuietCRM APP installiert ist, ist ein UCS Member Server.

Dass diese Anwendung nicht kostenlos ist, habe ich gelesen - aber kostenlos testen sollte möglich sein, oder?
Wo müsste ich die Benutzer freischalten?

Gruß,
Dirk Mauz

Hallöchen,

jetzt kann ich mir selbst die Antwort geben :slight_smile:
Da war ich wohl etwas blind…

In den Eigenschaften der Benutzerkonten gibt es nun einen neuen Menüeintrag “SuiteCRM”. Klickt man darauf, kann man “SuiteCRM benutzen” aktivieren.
Ich hatte irrtümlicherweise vorausgesetzt, dass man als Administrator die Anwendung sowieso benutzen darf.

Gruß,
Dirk Mauz

Guten Tag!

nachdem die APP SuiteCRM nun etwa zwei Wochen zu gebrauchen war, ist nun das nächste Problem aufgetreten: Keiner kann sich mehr anmelden…

You have been logged out because your session has expired.
Invalid credentials

Am UCS-Member Server selbst kann ich mich noch mit der Domain-Kennung anmelden.
Beim UCS-Domaincontroller steht in der APP Verwaltung bei “Installationen in der Domäne verwalten” unter Status: Unterschiedliche UCS Version. Eingeschränkte Funktionen
Warum die UCS Version unterschiedlich sein soll ist mir ein Rätsel, sind beide auf aktuellem Stand.

Kann mir jemand sagen, ob es außer den eingeschränkten Funktion bei der Testversion noch ein zeitliches Limit gibt?
In welchem Logfile könnte ich weitere Hinweise finden?

Gruß,
Dirk Mauz

Sehr geehrter Herr Mauz,

seitens SuiteCRM gibt es keinernlei zeitliche Einschränkung bzgl. der Funktionsfähigkeit der Software.
Wenn es Ihnen möglich ist, würde ich gern das log-file “/var/log/univention/server_password_change.log” sehen, von dem Zeitpunkt an, wo das Problem aufgetreten ist.
Die Angabe der unterschiedlichen UCS Versionen kann ich mir nicht erklären, dies ist vielleicht eher ein Fall für Univention.

Beste Grüße
Heiko Ahrens


Heiko Ahrens
IT Consultant

DIGITEC GmbH
Johannes-Brahms-Platz 1
20355 Hamburg

Hallo Heiko Ahrens,

danke schon mal für die Information.
In den Log Dateien steht nicht viel drin.

UCS Domain Controller:
root@srvmucudcb01:~# cat /var/log/univention/server_password_change.log
Starting server password change (Mon Jul 18 01:06:55 CEST 2016)
No server password change scheduled for today, terminating without a change
Starting server password change (Tue Jul 19 01:00:23 CEST 2016)
No server password change scheduled for today, terminating without a change
Starting server password change (Wed Jul 20 01:08:16 CEST 2016)
No server password change scheduled for today, terminating without a change

UCS Server mit SuiteCRM:

root@srvmucappb01:~# cat /var/log/univention/server_password_change.log
Starting server password change (Mon Jul 18 01:08:16 CEST 2016)
No server password change scheduled for today, terminating without a change
Starting server password change (Tue Jul 19 01:07:39 CEST 2016)
No server password change scheduled for today, terminating without a change
Starting server password change (Wed Jul 20 01:03:37 CEST 2016)
No server password change scheduled for today, terminating without a change

Das könnte daran liegen, dass es eine Active Directory-Verbindung gibt. Die AD-Verbindung hatte ich aber gleich am Anfang eingerichtet, noch bevor SuiteCRM installiert wurde. Und die Anmeldung hat ja bereits ungefähr zwei Wochen mit der AD-Verbindung funktioniert. Was ich bisher probiert habe:

  • Server neugestartet
  • neuen Benutzer für SuiteCRM aktiviert
  • Kennwörter geändert
  • verschiedene Rechner und Browser verwendet

sonnige Grüße aus Unterhaching,
Dirk Mauz

Guten Tag zusammen,

nun habe ich noch ein paar Logfiles durchstöbert. Hier steht was brauchbares drin:
/var/www/suitecrm/suitecrm.log

Wed Jul 20 11:22:06 2016 [45165][-none-][FATAL] SECURITY: ldapauth: failed LDAP bind (login) by ucsadmin, could not construct bind_user
Wed Jul 20 11:22:06 2016 [45165][-none-][FATAL] SECURITY: User authentication for ucsadmin failed
Wed Jul 20 11:23:28 2016 [45167][-none-][FATAL] [LDAP ERROR][49]Invalid credentials
Wed Jul 20 11:23:28 2016 [45167][-none-][FATAL] SECURITY: ldapauth: failed LDAP bind (login) by ucsadmin, could not construct bind_user
Wed Jul 20 11:23:28 2016 [45167][-none-][FATAL] SECURITY: User authentication for ucsadmin failed
Wed Jul 20 11:26:05 2016 [15623][-none-][FATAL] [LDAP ERROR][49]Invalid credentials
Wed Jul 20 11:26:05 2016 [15623][-none-][FATAL] SECURITY: ldapauth: failed LDAP bind (login) by ucsadmin, could not construct bind_user
Wed Jul 20 11:26:05 2016 [15623][-none-][FATAL] SECURITY: User authentication for ucsadmin failed
Wed Jul 20 11:27:18 2016 [58649][-none-][FATAL] [LDAP ERROR][49]Invalid credentials
Wed Jul 20 11:27:18 2016 [58649][-none-][FATAL] SECURITY: ldapauth: failed LDAP bind (login) by ucsadmin, could not construct bind_user
Wed Jul 20 11:27:18 2016 [58649][-none-][FATAL] SECURITY: User authentication for ucsadmin failed
Wed Jul 20 11:27:19 2016 [45166][-none-][FATAL] [LDAP ERROR][49]Invalid credentials
Wed Jul 20 11:27:19 2016 [45166][-none-][FATAL] SECURITY: ldapauth: failed LDAP bind (login) by ucsadmin, could not construct bind_user
Wed Jul 20 11:27:19 2016 [45166][-none-][FATAL] SECURITY: User authentication for ucsadmin failed
Wed Jul 20 11:27:20 2016 [45165][-none-][FATAL] [LDAP ERROR][49]Invalid credentials
Wed Jul 20 11:27:20 2016 [45165][-none-][FATAL] SECURITY: ldapauth: failed LDAP bind (login) by ucsadmin, could not construct bind_user
Wed Jul 20 11:27:20 2016 [45165][-none-][FATAL] SECURITY: User authentication for ucsadmin failed
Wed Jul 20 11:27:21 2016 [45162][-none-][FATAL] [LDAP ERROR][49]Invalid credentials
Wed Jul 20 11:27:21 2016 [45162][-none-][FATAL] SECURITY: ldapauth: failed LDAP bind (login) by ucsadmin, could not construct bind_user
Wed Jul 20 11:27:21 2016 [45162][-none-][FATAL] SECURITY: User authentication for ucsadmin failed
Wed Jul 20 14:21:55 2016 [58649][-none-][FATAL] [LDAP ERROR][49]Invalid credentials
Wed Jul 20 14:21:55 2016 [58649][-none-][FATAL] SECURITY: ldapauth: failed LDAP bind (login) by Administrator, could not construct bind_user
Wed Jul 20 14:21:55 2016 [58649][-none-][FATAL] SECURITY: User authentication for Administrator failed
Wed Jul 20 14:21:55 2016 [58649][-none-][FATAL] SECURITY: User authentication for Administrator failed
Wed Jul 20 14:21:55 2016 [58649][-none-][FATAL] FAILED LOGIN:attempts[1] - Administrator
Wed Jul 20 14:24:31 2016 [45162][-none-][FATAL] [LDAP ERROR][49]Invalid credentials
Wed Jul 20 14:24:31 2016 [45162][-none-][FATAL] SECURITY: ldapauth: failed LDAP bind (login) by Administrator, could not construct bind_user
Wed Jul 20 14:24:31 2016 [45162][-none-][FATAL] SECURITY: User authentication for Administrator failed
Wed Jul 20 14:24:31 2016 [45162][-none-][FATAL] SECURITY: User authentication for Administrator failed
Wed Jul 20 14:24:31 2016 [45162][-none-][FATAL] FAILED LOGIN:attempts[1] - Administrator
Wed Jul 20 15:32:38 2016 [15626][-none-][FATAL] [LDAP ERROR][49]Invalid credentials
Wed Jul 20 15:32:38 2016 [15626][-none-][FATAL] SECURITY: ldapauth: failed LDAP bind (login) by Support, could not construct bind_user
Wed Jul 20 15:32:38 2016 [15626][-none-][FATAL] SECURITY: User authentication for Support failed
Wed Jul 20 15:32:38 2016 [15626][-none-][FATAL] SECURITY: User authentication for Support failed
Wed Jul 20 15:32:39 2016 [15626][-none-][FATAL] FAILED LOGIN:attempts[1] - Support
Wed Jul 20 15:33:13 2016 [15624][-none-][FATAL] [LDAP ERROR][49]Invalid credentials
Wed Jul 20 15:33:13 2016 [15624][-none-][FATAL] SECURITY: ldapauth: failed LDAP bind (login) by Support, could not construct bind_user
Wed Jul 20 15:33:13 2016 [15624][-none-][FATAL] SECURITY: User authentication for Support failed
Wed Jul 20 15:33:13 2016 [15624][-none-][FATAL] SECURITY: User authentication for Support failed
Wed Jul 20 15:33:13 2016 [15624][-none-][FATAL] FAILED LOGIN:attempts[1] - Support
Wed Jul 20 15:48:03 2016 [45167][-none-][FATAL] [LDAP ERROR][49]Invalid credentials

Darauf hin habe ich die Active Directory Verbindung auf dem UCS Domain Controller deinstalliert und neuinstalliert. Das hatte zur Folge, dass der Memberserver, auf dem SuiteCRM läuft, neu zur Domain gejoint werden musste. Aber leider hatte die Aktion auch nichts gebracht.

Was mir an dem Log noch auffällt: ldapauth: failed LDAP bind (login) by ucsadmin
Der Benutzer ucsadmin sagt mir nichts! Auch in der Benutzerverwaltung ist er nicht finden.

Server habe ich noch mal aktualisiert. Die momentan installierte Version ist 4.1-2 errata220
Hat noch jemand Hinweise für mich?

Ciao,
Dirk Mauz

Hi

sieht für mich so aus, als ob die Änderung des Passwort des Rechner-Accounts (also des Memberservers) nicht an SuiteCRM durchgesickert ist (SuiteCRM verwendet für den LDAP Bind das Rechner-Konto). Das scheint kein generisches Problem zu sein, da ein Wechsel des Passwort in meiner Testumgebung funktioniert hat (SuiteCRM bringt einen eigenes Hook-Script mit um das neue Passwort in die entsprechenden Konfigs zu schreiben).

Folgendes würde ich vorschlagen:
Bitte prüfen Sie zunächst ob der Account des Rechner noch ordnungsgemäß funktioniert (also root auf der CMD bitte einmal univention-ldapsearch “cn=$(hostname)”). Falls das funktioniert, kann mit

bash /usr/lib/univention-server/server_password_change.d/suitecrm-pw-change postchange

das aktuelle Passwort des Rechner-Accounts in die SuiteCRM Konfig übernommen werden.

Danach bitte nochmal die Anmeldung testen.

Viele Grüße
Felix

Servus Felix,

univention-ldapsearch “cn=$(hostname)” bringt folgende Ausgabe:

root@srvmucappb01:~# univention-ldapsearch "cn=$(hostname)"
# extended LDIF
#
# LDAPv3
# base <dc=becon,dc=de> (default) with scope subtree
# filter: cn=srvmucappb01
# requesting: ALL
#

# srvmucappb01, UCS, MUC, Server, BECON, becon.de
dn: cn=srvmucappb01,ou=UCS,ou=MUC,ou=Server,ou=BECON,dc=becon,dc=de
macAddress: 00:15:5d:00:03:4d
krb5PrincipalName: host/srvmucappb01.becon.de@BECON.DE
uidNumber: 2709
sambaAcctFlags: [W          ]
krb5MaxLife: 86400
uid: srvmucappb01$
krb5MaxRenew: 604800
aRecord: 192.168.8.154
loginShell: /bin/sh
univentionObjectType: computers/memberserver
univentionServerRole: member
displayName: srvmucappb01
associatedDomain: becon.de
sambaSID: S-1-5-21-2231228107-1648847474-2204682860-6420
sn: srvmucappb01
homeDirectory: /dev/null
gidNumber: 5007
sambaPrimaryGroupSID: S-1-5-21-2231228107-1648847474-2204682860-11015
univentionObjectFlag: synced
univentionNagiosEnabled: 1
objectClass: krb5KDCEntry
objectClass: univentionMemberServer
objectClass: univentionVirtualMachineHostOC
objectClass: top
objectClass: univentionHost
objectClass: univentionObject
objectClass: krb5Principal
objectClass: person
objectClass: univentionNagiosHostClass
objectClass: shadowAccount
objectClass: sambaSamAccount
objectClass: posixAccount
univentionService: Samba 3
univentionService: NFS
univentionService: Univention Management Console
univentionService: SuiteCRM
cn: srvmucappb01
description: UCS SuiteCRM Prod

# search result
search: 3
result: 0 Success

# numResponses: 2
# numEntries: 1

Ob das nun erfolgreich ist, bin ich mir unsicher! Einerseits gibt es sinnvollen Output und keine Fehlermeldung, aber am Ende die Zeile result: 0 Success macht mich dann doch stutzig.

Das Commando

bash /usr/lib/univention-server/server_password_change.d/suitecrm-pw-change postchange habe ich ausgeführt, es gab weder Erfolgs- noch Fehlermeldung.

Am Zustand hat sich leider nichts geändert. Anmeldung an SuiteCRM nach wie von nicht möglich. :frowning:
Dass ich mich mit einem Domainadminkonto an der univention-management-console des Memberservers anmelden kann, hatte ich schon erwähnt.

Weitere Ideen?

Gruß,
Dirk

Hi

das univention-ldapsearch war erfolgreich, ich wollte hier nur sehen, ob sich der Maschinen-Account am LDAP anmelden kann. Wenn das nicht klappt, gibt es auch direkt eine entsprechende Fehlermeldung.

Ich bin aber immer noch nicht ganz überzeugt, dass die SuiteCRM LDAP Settings korrekt sind. Bitte mal folgendes prüfen.

mysql -u root --password=$(< /etc/mysql.secret) -e "select * from config where category='ldap'" suitecrm

Damit sollten die aktuellen LDAP Einstellungen angezeigt werden (bitte nicht posten, da sind sensible Daten drin). Wichtig sind hier folgende Attribute hostname, port, admin_user, admin_password, base_dn und login_filter.

Damit können wir einen ldapsearch Befehl konstruieren, der alle SuiteCRM Benutzer finden sollte. Das Passwort muss vorher noch einmal konvertiert werden Dafür bitte eine Datei (/tmp/mytest) mit folgendem Inhalt anlegen

<? define('sugarEntry', true); require_once('include/entryPoint.php'); $value="ADMIN_PASSWORD"; $v=blowfishDecode(blowfishGetKey('encrypt_field'),$value); print $v;
und ADMIN_PASSWORD mit dem admin_password aus dem obigen mysql Befehl ersetzen. Dann das Script mit

cd /var/www/suitecrm && php5 -f /tmp/mytest

ausführen. Da sollte jetzt das LDAP Passwort des Maschinen-Accounts ausgegeben werden (sollte gleich sein mit dem Inhalt von /etc/machine.secret).

Nun bitte einmal einen entsprechenden ldapsearch abschicken (alle großgeschriebenen Parameter muss mit den entsprechenden Settings in der Ausgabe des mysql-Befehls ersetzt werden, außer das Passwort, dort bitte das aus der Ausgabe des php Scripts verwenden):

ldapsearch -h HOSTNAME -p PORT -D ADMIN_USER -x -w PASSWORD  -b BASE_DN 'LOGIN_FILTER' dn

Ist HOSTNAME der korrekt Server (sollte wohl der UCS master sein)?
Ist der Port 7389?
Gibt das ldapsearch die entsprechenden Benutzer aus?

Servus,

die Commandos habe ich ausgeführt. Das konvertierte Passwort entspricht, wie erwartet, dem aus /etc/machine.secret

Ja, ist der UCS Master

Ja.

Leider nein. Fehlermeldung:
ldap_bind: Invalid credentials (49)

Aber die Ausgabe der MySQL Abfrage könnte noch einen Hinweis liefern. Ich hatte das Computerkonto von srvmucudcb01 im Active Directory in eine andere Organisationseinheit verschoben. Möglicherweise ist das die Ursache des Problems. Nun habe ich das Objekt aber wieder zurück verschoben, in den Standard Container “Computers”. Das hat leider auch noch nicht die Lösung gebracht.

Aber was mir noch auffällt: beim Parameter admin_user steht:

cn=srvmucappb01,cn=memberserver,cn=computers,dc=becon,dc=de

Im AD sieht der Pfad so aus:
becon.de/Computers/srvmucappb01

Eine OU memberserver existiert nicht. Ich kann im Container Computers auch keine Organisationseinheit anlegen.
Danke übrings für die umfangreiche Hilfestellung bisher :slight_smile:

Gruß,
Dirk

Ich sehe gerade, dass ich gestern den falschen Servernamen genannt habe:

An der Stelle von srvmucudcb01 sollte srvmucappb01 stehen, sorry.

Hallo mal wieder :slight_smile:

um irgendwie weiterzukommen, habe ich nun einen zusätzlichen UCS als Memberserver mit der SuiteCRM App installiert. An diesem System kann man sich anmelden :slight_smile: Auch die LDAP-Abfrage mit:
ldapsearch -h HOSTNAME -p PORT -D ADMIN_USER -x -w PASSWORD -b BASE_DN ‘LOGIN_FILTER’ dn
liefert die gewünschte Liste mit den aktivierten SuiteCRM-Benutzern.

An dem anderen SuiteCRM System kann man sich leider immernoch nicht anmelden. Das war zwar noch nicht produktiv, aber es steckt trotzdem schon einiges an Arbeit drin. Und mit dem neuen von vorne zu beginnen ist auch irgendwie blöd, ohne die Ursache zu kennen - dann könnte es ja wieder passieren…

Wie könnte ich herausfinden, was der Unterscheid zwischen den beiden Systemen ist?
Was passiert, wenn ich auf dem “defekten” SuiteCRM System die APP deinstalliere und neu installiere? Sind die Daten dann futsch? Oder gibt es Hoffnung, dass die Datenbank bestehen bleibt?

Gruß,
Dirk

Hi

kannst du bitte nochmal prüfen, ob der admin_user in der mysql Ausgabe richtig ist. Da muss die LDAP DN des Rechner-Kontos stehen.

Den korrekten Wert dafür kann man sich auf dem entsprechenden Rechner über

ucr get ldap/hostdn

bzw.

univention-ldapsearch "cn=$(hostname)" dn

ausgeben lassen.

Die DN im AD ist erstmal egal, da suiteCRM gegen das LDAP auf UCS geht. Wichtig ist halt, dass die config Einstellungen bzgl. LDAP in SuiteCRM passen, also der LDAP Server, Port, der amdin_user (das ist die LDAP DN, mit dem sich suiteCRM am LDAP anmeldet), …

also, so siehts aus…

root@srvmucappb01:~# mysql -u root --password=$(< /etc/mysql.secret) -e “select * from config where category=‘ldap’” suitecrm
–> admin_user: cn=srvmucappb01,cn=memberserver,cn=computers,dc=becon,dc=de

root@srvmucappb01:~# ucr get ldap/hostdn
–>cn=srvmucappb01,ou=UCS,ou=MUC,ou=Server,ou=BECON,dc=becon,dc=de

root@srvmucappb01:~# univention-ldapsearch “cn=$(hostname)” dn
–> ldap_bind: Invalid credentials (49)

Offenbar passt der dn des admin_user nicht. Wie lässt sich das anpassen?
Das was ucr get ldap/hostdn ausgibt, ist die OU wo ich im AD das Computerobjekt mal hingeschoben hatte, aber seit gestern wieder zurück im Standardcontainer ist.
Wenn ich im UCS LDAP Verzeichnis (mit Browser) nachsehe ist die OU: ou=UCS,ou=MUC,ou=Server,ou=BECON,dc=becon,dc=de leer.

Ciao,
Dirk

[quote=“dmauz”]also, so siehts aus…

root@srvmucappb01:~# mysql -u root --password=$(< /etc/mysql.secret) -e “select * from config where category=‘ldap’” suitecrm
–> admin_user: cn=srvmucappb01,cn=memberserver,cn=computers,dc=becon,dc=de

root@srvmucappb01:~# ucr get ldap/hostdn
–>cn=srvmucappb01,ou=UCS,ou=MUC,ou=Server,ou=BECON,dc=becon,dc=de

root@srvmucappb01:~# univention-ldapsearch “cn=$(hostname)” dn
–> ldap_bind: Invalid credentials (49)
[/quote]

Das univention-ldapsearch hat doch “oben” noch funktioniert?
Wie auch immer, das ist nicht gut und muss funktionieren. Bitte einmal auf dem UCS Master die aktuelle UCS LDAP DN des Rechners holen

univention-ldapsearch "cn=srvmucappb01" dn

Diese dann als mit der “ldap/hostdn” auf dem Rechner srvmucappb01 vergleichen (muss gleich sein). Falls die nicht gleich sind, kann die ldap/hostdn mit

ucr set ldap/hostdn="$DN"

gesetzt werden.

Auch die DN in admin_user muss den gleichen Wert haben. Setzen kann man die mit

mysql -u root --password=$(< /etc/mysql.secret) -e "update config set value='DN_DES_RECHNERS' where name='admin_user'" suitecrm

SuiteCRM verwendet das UCS LDAP und muss sich dort auch mit dem Rechner-Konto anmelden (ebenso wie univention-ldapsearch sich am UCS LDAP mit dem Rechner-Konto anmeldet). Das AD LDAP spielt hier keine Rolle (die DN des Rechner-Account im AD und UCS LDAP müssen auch nicht notwendigerweise gleich sein).

Servus,

das Problem ist gelöst :-))

Die DNs waren unterschiedlich. Die beiden Kommandos:

root@srvmucappb01:~#ucr set ldap/hostdn="cn=srvmucappb01,cn=computers,dc=becon,dc=de"

root@srvmucappb01:~#mysql -u root --password=$(< /etc/mysql.secret) -e "update config set value='cn=srvmucappb01,cn=computers,dc=becon,dc=de' where name='admin_user'" suitecrm

haben die Lösung gebracht.

Besten Dank für die tolle Unterstützung!!

Schönes Wochenende,
Dirk Mauz

Mastodon