Hello everybody,
Last 2-3 weeks, I am trying to connect metabase with our LDAP.
I am running metabase with this command:
“java -Djavax.net.debug=all -Djavax.security.auth.useSubjectCredsOnly=false -jar metabase.jar“
Here are logs, when I am trying to connect using my account “psuchy”.
The logs from LDAP:
Mar 12 13:28:58 dhbfe06 slapd[17583]: conn=13477 fd=11 ACCEPT from IP=192.168.140.20:37574 (IP=192.168.140.11:636)
Mar 12 13:28:59 dhbfe06 slapd[17583]: conn=13477 fd=11 TLS established tls_ssf=256 ssf=256
Mar 12 13:28:59 dhbfe06 slapd[17583]: conn=13477 op=0 BIND dn=“cn=proxyusr,dc=xha,dc=app” method=128
Mar 12 13:28:59 dhbfe06 slapd[17583]: conn=13477 op=0 BIND dn=“cn=proxyusr,dc=xha,dc=app” mech=SIMPLE ssf=0
Mar 12 13:28:59 dhbfe06 slapd[17583]: conn=13477 op=0 RESULT tag=97 err=0 text=
Mar 12 13:28:59 dhbfe06 slapd[17583]: conn=13477 op=1 SRCH base=“ou=people,dc=xha,dc=app” scope=2 deref=0 filter="(cn=psuchy)"
Mar 12 13:28:59 dhbfe06 slapd[17583]: conn=13477 op=1 SRCH attr=*
Mar 12 13:28:59 dhbfe06 slapd[17135]: conn=1080 op=5564 SRCH base=“ou=people,dc=xha,dc=app” scope=2 deref=0 filter="(cn=psuchy)"
Mar 12 13:28:59 dhbfe06 slapd[17135]: conn=1080 op=5564 SRCH attr=*
Mar 12 13:28:59 dhbfe06 slapd[17410]: conn=1111 op=5570 SRCH base=“ou=people,dc=xha,dc=app” scope=2 deref=0 filter="(cn=psuchy)"
Mar 12 13:28:59 dhbfe06 slapd[17410]: conn=1111 op=5570 SRCH attr=*
Mar 12 13:28:59 dhbfe06 slapd[17410]: conn=1111 op=5570 SEARCH RESULT tag=101 err=0 nentries=0 text=
Mar 12 13:28:59 dhbfe06 slapd[17135]: conn=1080 op=5564 SEARCH RESULT tag=101 err=0 nentries=1 text=
Mar 12 13:28:59 dhbfe06 slapd[17583]: conn=13477 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
Mar 12 13:28:59 dhbfe06 slapd[17583]: conn=13477 op=2 UNBIND
As you can see:
“Mar 12 13:28:59 dhbfe06 slapd[17583]: conn=13477 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=”
It found 1 “result”, so it is working.
The logs in “terminal”:
Connection reader for connection 0 to dhbfe06.cdrs.telekom.de:636, READ: TLSv1.2 Application Data, length = 464
Padded plaintext after DECRYPTION: len = 464
0000: EE 13 F4 F4 9E 29 1D 8C B9 83 F7 0D 49 D7 AE 25 …)…I…%
0010: 30 82 01 97 02 01 02 64 82 01 90 04 21 63 6E 3D 0…d…!cn=
0020: 70 73 75 63 68 79 2C 6F 75 3D 70 65 6F 70 6C 65 psuchy,ou=people
0030: 2C 64 63 3D 78 68 61 2C 64 63 3D 61 70 70 30 82 ,dc=xha,dc=app0.
0040: 01 69 30 0F 04 03 75 69 64 31 08 04 06 70 73 75 .i0…uid1…psu
0050: 63 68 79 30 81 C3 04 0B 6F 62 6A 65 63 74 43 6C chy0…objectCl
0060: 61 73 73 31 81 B3 04 03 74 6F 70 04 07 61 63 63 ass1…top…acc
0070: 6F 75 6E 74 04 0C 70 6F 73 69 78 41 63 63 6F 75 ount…posixAccou
0080: 6E 74 04 0D 73 68 61 64 6F 77 41 63 63 6F 75 6E nt…shadowAccoun
0090: 74 04 0B 55 4E 49 58 41 43 43 4F 55 4E 54 04 0C t…UNIXACCOUNT…
00A0: 6B 72 62 50 72 69 6E 63 69 70 61 6C 04 0F 6B 72 krbPrincipal…kr
00B0: 62 50 72 69 6E 63 69 70 61 6C 41 75 78 04 12 6B bPrincipalAux…k
00C0: 72 62 54 69 63 6B 65 74 50 6F 6C 69 63 79 41 75 rbTicketPolicyAu
00D0: 78 04 0D 69 6E 65 74 4F 72 67 50 65 72 73 6F 6E x…inetOrgPerson
00E0: 04 0A 54 53 59 53 4D 45 54 41 49 44 04 14 6F 72 …TSYSMETAID…or
00F0: 67 61 6E 69 7A 61 74 69 6F 6E 61 6C 50 65 72 73 ganizationalPers
0100: 6F 6E 04 06 70 65 72 73 6F 6E 04 0D 4C 44 41 50 on…person…LDAP
0110: 50 55 42 4C 49 43 4B 45 59 30 14 04 09 67 69 64 PUBLICKEY0…gid
0120: 4E 75 6D 62 65 72 31 07 04 05 34 34 32 34 30 30 Number1…442400
0130: 0E 04 02 73 6E 31 08 04 06 70 73 75 63 68 79 30 …sn1…psuchy0
0140: 15 04 09 75 69 64 4E 75 6D 62 65 72 31 08 04 06 …uidNumber1…
0150: 32 35 30 37 39 39 30 0E 04 02 63 6E 31 08 04 06 2507990…cn1…
0160: 70 73 75 63 68 79 30 1C 04 0A 6C 6F 67 69 6E 53 psuchy0…loginS
0170: 68 65 6C 6C 31 0E 04 0C 2F 75 73 72 2F 62 69 6E hell1…/usr/bin
0180: 2F 6B 73 68 30 25 04 0D 68 6F 6D 65 44 69 72 65 /ksh0%…homeDire
0190: 63 74 6F 72 79 31 14 04 12 2F 68 6F 6D 65 2F 61 ctory1…/home/a
01A0: 64 6D 69 6E 2F 70 73 75 63 68 79 C6 61 98 F9 6A dmin/psuchy.a…j
01B0: BE A0 78 59 00 59 5E D4 E0 F3 DB C3 A0 D8 C2 57 …xY.Y^…W
01C0: C8 7F 67 5B 67 05 67 8F 2D 3D A9 04 04 04 04 04 …g[g.g.-=…
And the response is exactly same when I use command(without strange “HEX” numbers/letters):
“ldapsearch -h ‘dhbfe06.cdrs.telekom.de’ -b “ou=people,dc=xha,dc=app” -D “cn=proxyusr,dc=xha,dc=app” -W -v “cn=psuchy” –ZZ”
requesting: All userApplication attributes
extended LDIF
LDAPv3
base <ou=people,dc=xha,dc=app> with scope subtree
filter: cn=psuchy
requesting: ALL
psuchy, people, xha.app
dn: cn=psuchy,ou=people,dc=xha,dc=app
uid: psuchy
objectClass: top
objectClass: account
objectClass: posixAccount
objectClass: shadowAccount
objectClass: UNIXACCOUNT
objectClass: krbPrincipal
objectClass: krbPrincipalAux
objectClass: krbTicketPolicyAux
objectClass: inetOrgPerson
objectClass: TSYSMETAID
objectClass: organizationalPerson
objectClass: person
objectClass: LDAPPUBLICKEY
gidNumber: 44240
sn: psuchy
uidNumber: 250799
cn: psuchy
loginShell: /usr/bin/ksh
homeDirectory: /home/admin/psuchy
So I guess, we have LDAP settings correct, but there is still this error:
03-12 13:29:22 DEBUG middleware.log :: POST /api/session 400 749.0 ms (1 DB calls)
{:errors {:password “did not match stored password”}}
Is someone able to explain what can be wrong and what is happening in LDAP source files in Metabase project ?
We really want to use Metabase in production, but without LDAP it will not be possible I guess.
Thank you
Peter