Hi all,
I'd like to perform some ldapsearch against my AD domain.
And I'd like to be able to perform these ldapsearch using GSSAPI to avoid
usage of password in scripts.
DC are using default configuration file:
----------------------------------------
# Global parameters
[global]
workgroup = SAMBA.DOMAIN
realm = SAMBA.DOMAIN.TLD
netbios name = M707
server role = active directory domain controller
dns forwarder = 10.156.248.245
idmap_ldb:use rfc2307 = yes
[netlogon]
path = /var/lib/samba/sysvol/samba.domain.tld/scripts
read only = No
write ok = Yes
[sysvol]
path = /var/lib/samba/sysvol
read only = No
write ok = Yes
----------------------------------------
Here the content of /etc/ldap/ldap.conf on client side:
----------------------------------------
TLS_REQCERT demand
BASE DC=SAMBA,DC=DOMAIN,DC=TLD
----------------------------------------
ldapsearch on 389 is working:
----------------------------------------
ldapsearch -LLL -p389 -h 10.156.248.238 cn=administrator -D
cn=administrator,cn=users,DC=samba,DC=domain,DC=tld -W
Enter LDAP Password:
dn: CN=Administrator,CN=Users,DC=samba,DC=domain,DC=tld
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: Administrator
description: Built-in account for administering the computer/domain
instanceType: 4
....
----------------------------------------
ldapsearch on 636 is not working:
----------------------------------------
ldapsearch -LLL -p636 -h 10.156.248.238 cn=administrator -D
cn=administrator,cn=users,DC=samba,DC=domain,DC=tld -W -d9
ldap_create
ldap_url_parse_ext(ldap://10.156.248.238:636)
Enter LDAP Password:
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP 10.156.248.238:636
ldap_new_socket: 4
ldap_prepare_socket: 4
ldap_connect_to_host: Trying 10.156.248.238:636
ldap_pvt_connect: fd: 4 tm: -1 async: 0
attempting to connect:
connect success
ldap_open_defconn: successful
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({i) ber:
ber_flush2: 90 bytes to sd 4
ldap_result ld 0x7efef3b29b00 msgid 1
wait4msg ld 0x7efef3b29b00 msgid 1 (infinite timeout)
wait4msg continue ld 0x7efef3b29b00 msgid 1 all 1
** ld 0x7efef3b29b00 Connections:
* host: 10.156.248.238 port: 636 (default)
refcnt: 2 status: Connected
last used: Thu Oct 15 12:46:14 2015
** ld 0x7efef3b29b00 Outstanding Requests:
* msgid 1, origid 1, status InProgress
outstanding referrals 0, parent count 0
ld 0x7efef3b29b00 request count 1 (abandoned 0)
** ld 0x7efef3b29b00 Response Queue:
Empty
ld 0x7efef3b29b00 response count 0
ldap_chkResponseList ld 0x7efef3b29b00 msgid 1 all 1
ldap_chkResponseList returns ld 0x7efef3b29b00 NULL
ldap_int_select
read1msg: ld 0x7efef3b29b00 msgid 1 all 1
ber_get_next
ber_get_next failed.
ldap_err2string
ldap_result: Can't contact LDAP server (-1)
ldap_free_request (origid 1, msgid 1)
ldap_free_connection 1 1
ldap_free_connection: actually freed
----------------------------------------
This leads me to the first question: any idea what I'm missing to be able
to use ldaps?
Then what I'm really trying is to use GSSAPI and keytab to authenticate
during ldapsearch.
First point I had to install "libsasl2-modules-gssapi-mit" or
"libsasl2-modules-gssapi-heimdal", both are Debian packages. Without
these
packages ldapsearch was asking me for a password:
----------------------------------------
ldapsearch -LLL -H ldap://m707:389 objectclass=user
SASL/NTLM authentication started
Please enter your password:
----------------------------------------
Once one of these packages was installed and after performing a kinit:
----------------------------------------
kinit -k -t /path/to/keytab.file administrator
klist
Credentials cache: FILE:/tmp/krb5cc_1000
Principal: administrator at SAMBA.DOMAIN.TLD
Issued Expires Principal
Oct 15 11:00:48 2015 Oct 15 21:00:48 2015
krbtgt/SAMBA.DOMAIN.TLD at SAMBA.DOMAIN.TLD
Oct 15 11:37:51 2015 Oct 15 21:00:48 2015 ldap/m707@
Oct 15 11:37:51 2015 Oct 15 21:00:48 2015 ldap/m707 at SAMBA.DOMAIN.TLD
Oct 15 11:42:11 2015 Oct 15 21:00:48 2015 ldap/m708@
Oct 15 11:42:11 2015 Oct 15 21:00:48 2015 ldap/m708 at SAMBA.DOMAIN.TLD
Oct 15 11:49:16 2015 Oct 15 21:00:48 2015 ldap/m709@
Oct 15 11:49:16 2015 Oct 15 21:00:48 2015 ldap/m709 at SAMBA.DOMAIN.TLD
----------------------------------------
GSSAPI starts to work, a little bit:
----------------------------------------
ldapsearch -LLL -H ldap://m707:389 objectclass=user
SASL/GSS-SPNEGO authentication started
SASL username: administrator at SAMBA.DOMAIN.TLD
SASL SSF: 0
ldap_result: Can't contact LDAP server (-1)
----------------------------------------
Here I'm wondering which one of these packages I should have, heimdal or
mit. Idem for Kerberos client, we can chose between heimdal-clients
(Heimdal) and krb5-user (MIT).
Anyway client seems to react identically with any of these Kerberos
implementation.
And the question: what do I missed to have that ldapsearch working with
GSSAPI?
Kindly regards,
mathias
Things goes further. To use GSSAPI and so the Kerberos ticket obtained with
kinit I was missing "-Y GSSAPI".
It seems GSSAPI and TLS are meant to be used together:
----------------------------------------
ldapsearch -Y GSSAPI -LLL -H ldaps://SAMBA.DOMAIN.TLD
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Server is unwilling to perform (53)
additional info: SASL:[GSSAPI]: Sign or Seal are not allowed if TLS
is used
----------------------------------------
So, the same using ldap:// rather than ldaps://
----------------------------------------
ldapsearch -Y GSSAPI -LLL -H ldap://SAMBA.DOMAIN.TLD
SASL/GSSAPI authentication started
SASL username: administrator at SAMBA.DOMAIN.TLD
SASL SSF: 56
SASL data security layer installed.
dn:
CN=6bcd5682-8314-11d6-977b-00c04f613221,CN=Operations,CN=DomainUpdates,CN...
----------------------------------------
Now to use ldapsearch without GSSAPI but password:
----------------------------------------
ldapsearch -LLL -H ldaps://ad.dgfip.finances.gouv.fr -D
cn=administrator,cn=users,DC=samba,DC=domain,DC=tld -w Passw0rd
dn:
CN=6bcd5682-8314-11d6-977b-00c04f613221,CN=Operations,CN=DomainUpdates,CN....
----------------------------------------
This links gave me information about -Y GSSAPI:
https://lists.samba.org/archive/samba-technical/2012-January/081241.html
As I said in my previous mail I was looking for a way to test different
services which compose AD, this ldapsearch using GSSAPI and previously
generated ticket give us possibility to test LDAP behaviour. To test each
DC we just have to replace ldap://SAMBA.DOMAIN.TLD
by ldap://DC1.SAMBA.DOMAIN.TLD, then ldap://DC2.SAMBA.DOMAIN.TLD...
To test Kerberos we need to use a dedicated Kerberos configuration file (by
default it's /eetc/krb5.conf). To do that we have to set environment
variable KRB5_CONFIG:
export KRB5_CONFIG=/path/to/krb5.DC1.conf
And in /path/to/krb5.DC1.conf:
----------------------------------------
[libdefaults]
default_realm = SAMBA.DOMAIN.TLD
rdns_lookup_realm = false
rdns_lookup_kdc = false
dns_lookup_realm = false
dns_lookup_kdc = false
[realms]
SAMBA.DOMAIN.TLD = {
admin_server = dc1.samba.domain.tld
kdc = dc1.samba.domain.tld
kpasswd_server = dc1.samba.domain.tld
master_kdc = dc1.samba.domain.tld
}
----------------------------------------
Then using kinit will be forced to use server declared in that file.
Creating one file per domain controller we can test Kerberos behaviour on
specific DC.
To test DNS a simple "dig @<IP DC1> somehost.samba.domain.tld".
To test CIFS access to SysVol:
----------------------------------------
smbclient //DC1.SAMBA.DOMAIN.TLD/sysvol -Uadministrator -k << EOF
ls samba.domain.tld/*
exit
EOF
----------------------------------------
Which should answer:
----------------------------------------
Domain=[SAMBA.DOMAIN] OS=[Windows 6.1] Server=[Samba 4.3.0-RedHat-02.el7]
. D 0 Wed Oct 14 17:01:50 2015
.. D 0 Wed Oct 14 17:01:50 2015
scripts D 0 Wed Oct 14 17:01:46 2015
Policies D 0 Wed Oct 14 17:01:50 2015
40880 blocks of size 131072. 17631 blocks available
----------------------------------------
I posted all that for those interested.
If anyone sees anything else to test, please tell me for I can improve my
tests ;)
Best regards,
mathias
2015-10-15 13:17 GMT+02:00 mathias dufresne <infractory at gmail.com>:
> Hi all,
>
> I'd like to perform some ldapsearch against my AD domain.
> And I'd like to be able to perform these ldapsearch using GSSAPI to
avoid
> usage of password in scripts.
>
> DC are using default configuration file:
> ----------------------------------------
> # Global parameters
> [global]
> workgroup = SAMBA.DOMAIN
> realm = SAMBA.DOMAIN.TLD
> netbios name = M707
> server role = active directory domain controller
> dns forwarder = 10.156.248.245
> idmap_ldb:use rfc2307 = yes
>
> [netlogon]
> path = /var/lib/samba/sysvol/samba.domain.tld/scripts
> read only = No
> write ok = Yes
>
> [sysvol]
> path = /var/lib/samba/sysvol
> read only = No
> write ok = Yes
> ----------------------------------------
>
> Here the content of /etc/ldap/ldap.conf on client side:
> ----------------------------------------
> TLS_REQCERT demand
> BASE DC=SAMBA,DC=DOMAIN,DC=TLD
> ----------------------------------------
>
>
> ldapsearch on 389 is working:
> ----------------------------------------
> ldapsearch -LLL -p389 -h 10.156.248.238 cn=administrator -D
> cn=administrator,cn=users,DC=samba,DC=domain,DC=tld -W
> Enter LDAP Password:
> dn: CN=Administrator,CN=Users,DC=samba,DC=domain,DC=tld
> objectClass: top
> objectClass: person
> objectClass: organizationalPerson
> objectClass: user
> cn: Administrator
> description: Built-in account for administering the computer/domain
> instanceType: 4
> ....
> ----------------------------------------
>
> ldapsearch on 636 is not working:
> ----------------------------------------
> ldapsearch -LLL -p636 -h 10.156.248.238 cn=administrator -D
> cn=administrator,cn=users,DC=samba,DC=domain,DC=tld -W -d9
> ldap_create
> ldap_url_parse_ext(ldap://10.156.248.238:636)
> Enter LDAP Password:
> ldap_sasl_bind
> ldap_send_initial_request
> ldap_new_connection 1 1 0
> ldap_int_open_connection
> ldap_connect_to_host: TCP 10.156.248.238:636
> ldap_new_socket: 4
> ldap_prepare_socket: 4
> ldap_connect_to_host: Trying 10.156.248.238:636
> ldap_pvt_connect: fd: 4 tm: -1 async: 0
> attempting to connect:
> connect success
> ldap_open_defconn: successful
> ldap_send_server_request
> ber_scanf fmt ({it) ber:
> ber_scanf fmt ({i) ber:
> ber_flush2: 90 bytes to sd 4
> ldap_result ld 0x7efef3b29b00 msgid 1
> wait4msg ld 0x7efef3b29b00 msgid 1 (infinite timeout)
> wait4msg continue ld 0x7efef3b29b00 msgid 1 all 1
> ** ld 0x7efef3b29b00 Connections:
> * host: 10.156.248.238 port: 636 (default)
> refcnt: 2 status: Connected
> last used: Thu Oct 15 12:46:14 2015
>
>
> ** ld 0x7efef3b29b00 Outstanding Requests:
> * msgid 1, origid 1, status InProgress
> outstanding referrals 0, parent count 0
> ld 0x7efef3b29b00 request count 1 (abandoned 0)
> ** ld 0x7efef3b29b00 Response Queue:
> Empty
> ld 0x7efef3b29b00 response count 0
> ldap_chkResponseList ld 0x7efef3b29b00 msgid 1 all 1
> ldap_chkResponseList returns ld 0x7efef3b29b00 NULL
> ldap_int_select
> read1msg: ld 0x7efef3b29b00 msgid 1 all 1
> ber_get_next
> ber_get_next failed.
> ldap_err2string
> ldap_result: Can't contact LDAP server (-1)
> ldap_free_request (origid 1, msgid 1)
> ldap_free_connection 1 1
> ldap_free_connection: actually freed
> ----------------------------------------
>
> This leads me to the first question: any idea what I'm missing to be
able
> to use ldaps?
>
> Then what I'm really trying is to use GSSAPI and keytab to authenticate
> during ldapsearch.
>
> First point I had to install "libsasl2-modules-gssapi-mit" or
> "libsasl2-modules-gssapi-heimdal", both are Debian packages.
Without these
> packages ldapsearch was asking me for a password:
> ----------------------------------------
> ldapsearch -LLL -H ldap://m707:389 objectclass=user
> SASL/NTLM authentication started
> Please enter your password:
> ----------------------------------------
>
> Once one of these packages was installed and after performing a kinit:
> ----------------------------------------
> kinit -k -t /path/to/keytab.file administrator
> klist
> Credentials cache: FILE:/tmp/krb5cc_1000
> Principal: administrator at SAMBA.DOMAIN.TLD
>
> Issued Expires Principal
> Oct 15 11:00:48 2015 Oct 15 21:00:48 2015
> krbtgt/SAMBA.DOMAIN.TLD at SAMBA.DOMAIN.TLD
> Oct 15 11:37:51 2015 Oct 15 21:00:48 2015 ldap/m707@
> Oct 15 11:37:51 2015 Oct 15 21:00:48 2015 ldap/m707 at SAMBA.DOMAIN.TLD
> Oct 15 11:42:11 2015 Oct 15 21:00:48 2015 ldap/m708@
> Oct 15 11:42:11 2015 Oct 15 21:00:48 2015 ldap/m708 at SAMBA.DOMAIN.TLD
> Oct 15 11:49:16 2015 Oct 15 21:00:48 2015 ldap/m709@
> Oct 15 11:49:16 2015 Oct 15 21:00:48 2015 ldap/m709 at SAMBA.DOMAIN.TLD
> ----------------------------------------
>
> GSSAPI starts to work, a little bit:
> ----------------------------------------
> ldapsearch -LLL -H ldap://m707:389 objectclass=user
> SASL/GSS-SPNEGO authentication started
> SASL username: administrator at SAMBA.DOMAIN.TLD
> SASL SSF: 0
> ldap_result: Can't contact LDAP server (-1)
> ----------------------------------------
>
> Here I'm wondering which one of these packages I should have, heimdal
or
> mit. Idem for Kerberos client, we can chose between heimdal-clients
> (Heimdal) and krb5-user (MIT).
>
> Anyway client seems to react identically with any of these Kerberos
> implementation.
>
> And the question: what do I missed to have that ldapsearch working with
> GSSAPI?
>
> Kindly regards,
>
> mathias
>
ERRATUM: It seems GSSAPI and TLS are *NOT* meant to be used together: 2015-10-15 16:20 GMT+02:00 mathias dufresne <infractory at gmail.com>:> Things goes further. To use GSSAPI and so the Kerberos ticket obtained > with kinit I was missing "-Y GSSAPI". > > It seems GSSAPI and TLS are meant to be used together: > ---------------------------------------- > ldapsearch -Y GSSAPI -LLL -H ldaps://SAMBA.DOMAIN.TLD > SASL/GSSAPI authentication started > ldap_sasl_interactive_bind_s: Server is unwilling to perform (53) > additional info: SASL:[GSSAPI]: Sign or Seal are not allowed if > TLS is used > ---------------------------------------- > > So, the same using ldap:// rather than ldaps:// > ---------------------------------------- > ldapsearch -Y GSSAPI -LLL -H ldap://SAMBA.DOMAIN.TLD > SASL/GSSAPI authentication started > SASL username: administrator at SAMBA.DOMAIN.TLD > SASL SSF: 56 > SASL data security layer installed. > dn: > CN=6bcd5682-8314-11d6-977b-00c04f613221,CN=Operations,CN=DomainUpdates,CN> ... > ---------------------------------------- > > Now to use ldapsearch without GSSAPI but password: > ---------------------------------------- > ldapsearch -LLL -H ldaps://ad.dgfip.finances.gouv.fr -D > cn=administrator,cn=users,DC=samba,DC=domain,DC=tld -w Passw0rd > dn: > CN=6bcd5682-8314-11d6-977b-00c04f613221,CN=Operations,CN=DomainUpdates,CN> .... > ---------------------------------------- > > This links gave me information about -Y GSSAPI: > https://lists.samba.org/archive/samba-technical/2012-January/081241.html > > As I said in my previous mail I was looking for a way to test different > services which compose AD, this ldapsearch using GSSAPI and previously > generated ticket give us possibility to test LDAP behaviour. To test each > DC we just have to replace ldap://SAMBA.DOMAIN.TLD > by ldap://DC1.SAMBA.DOMAIN.TLD, then ldap://DC2.SAMBA.DOMAIN.TLD... > > To test Kerberos we need to use a dedicated Kerberos configuration file > (by default it's /eetc/krb5.conf). To do that we have to set environment > variable KRB5_CONFIG: > export KRB5_CONFIG=/path/to/krb5.DC1.conf > > And in /path/to/krb5.DC1.conf: > ---------------------------------------- > [libdefaults] > default_realm = SAMBA.DOMAIN.TLD > rdns_lookup_realm = false > rdns_lookup_kdc = false > dns_lookup_realm = false > dns_lookup_kdc = false > [realms] > SAMBA.DOMAIN.TLD = { > admin_server = dc1.samba.domain.tld > kdc = dc1.samba.domain.tld > kpasswd_server = dc1.samba.domain.tld > master_kdc = dc1.samba.domain.tld > } > ---------------------------------------- > > Then using kinit will be forced to use server declared in that file. > Creating one file per domain controller we can test Kerberos behaviour on > specific DC. > > To test DNS a simple "dig @<IP DC1> somehost.samba.domain.tld". > > To test CIFS access to SysVol: > ---------------------------------------- > smbclient //DC1.SAMBA.DOMAIN.TLD/sysvol -Uadministrator -k << EOF > ls samba.domain.tld/* > exit > EOF > ---------------------------------------- > > Which should answer: > ---------------------------------------- > Domain=[SAMBA.DOMAIN] OS=[Windows 6.1] Server=[Samba 4.3.0-RedHat-02.el7] > . D 0 Wed Oct 14 17:01:50 2015 > .. D 0 Wed Oct 14 17:01:50 2015 > scripts D 0 Wed Oct 14 17:01:46 2015 > Policies D 0 Wed Oct 14 17:01:50 2015 > > 40880 blocks of size 131072. 17631 blocks available > ---------------------------------------- > > I posted all that for those interested. > If anyone sees anything else to test, please tell me for I can improve my > tests ;) > > Best regards, > > mathias > > > > > 2015-10-15 13:17 GMT+02:00 mathias dufresne <infractory at gmail.com>: > >> Hi all, >> >> I'd like to perform some ldapsearch against my AD domain. >> And I'd like to be able to perform these ldapsearch using GSSAPI to avoid >> usage of password in scripts. >> >> DC are using default configuration file: >> ---------------------------------------- >> # Global parameters >> [global] >> workgroup = SAMBA.DOMAIN >> realm = SAMBA.DOMAIN.TLD >> netbios name = M707 >> server role = active directory domain controller >> dns forwarder = 10.156.248.245 >> idmap_ldb:use rfc2307 = yes >> >> [netlogon] >> path = /var/lib/samba/sysvol/samba.domain.tld/scripts >> read only = No >> write ok = Yes >> >> [sysvol] >> path = /var/lib/samba/sysvol >> read only = No >> write ok = Yes >> ---------------------------------------- >> >> Here the content of /etc/ldap/ldap.conf on client side: >> ---------------------------------------- >> TLS_REQCERT demand >> BASE DC=SAMBA,DC=DOMAIN,DC=TLD >> ---------------------------------------- >> >> >> ldapsearch on 389 is working: >> ---------------------------------------- >> ldapsearch -LLL -p389 -h 10.156.248.238 cn=administrator -D >> cn=administrator,cn=users,DC=samba,DC=domain,DC=tld -W >> Enter LDAP Password: >> dn: CN=Administrator,CN=Users,DC=samba,DC=domain,DC=tld >> objectClass: top >> objectClass: person >> objectClass: organizationalPerson >> objectClass: user >> cn: Administrator >> description: Built-in account for administering the computer/domain >> instanceType: 4 >> .... >> ---------------------------------------- >> >> ldapsearch on 636 is not working: >> ---------------------------------------- >> ldapsearch -LLL -p636 -h 10.156.248.238 cn=administrator -D >> cn=administrator,cn=users,DC=samba,DC=domain,DC=tld -W -d9 >> ldap_create >> ldap_url_parse_ext(ldap://10.156.248.238:636) >> Enter LDAP Password: >> ldap_sasl_bind >> ldap_send_initial_request >> ldap_new_connection 1 1 0 >> ldap_int_open_connection >> ldap_connect_to_host: TCP 10.156.248.238:636 >> ldap_new_socket: 4 >> ldap_prepare_socket: 4 >> ldap_connect_to_host: Trying 10.156.248.238:636 >> ldap_pvt_connect: fd: 4 tm: -1 async: 0 >> attempting to connect: >> connect success >> ldap_open_defconn: successful >> ldap_send_server_request >> ber_scanf fmt ({it) ber: >> ber_scanf fmt ({i) ber: >> ber_flush2: 90 bytes to sd 4 >> ldap_result ld 0x7efef3b29b00 msgid 1 >> wait4msg ld 0x7efef3b29b00 msgid 1 (infinite timeout) >> wait4msg continue ld 0x7efef3b29b00 msgid 1 all 1 >> ** ld 0x7efef3b29b00 Connections: >> * host: 10.156.248.238 port: 636 (default) >> refcnt: 2 status: Connected >> last used: Thu Oct 15 12:46:14 2015 >> >> >> ** ld 0x7efef3b29b00 Outstanding Requests: >> * msgid 1, origid 1, status InProgress >> outstanding referrals 0, parent count 0 >> ld 0x7efef3b29b00 request count 1 (abandoned 0) >> ** ld 0x7efef3b29b00 Response Queue: >> Empty >> ld 0x7efef3b29b00 response count 0 >> ldap_chkResponseList ld 0x7efef3b29b00 msgid 1 all 1 >> ldap_chkResponseList returns ld 0x7efef3b29b00 NULL >> ldap_int_select >> read1msg: ld 0x7efef3b29b00 msgid 1 all 1 >> ber_get_next >> ber_get_next failed. >> ldap_err2string >> ldap_result: Can't contact LDAP server (-1) >> ldap_free_request (origid 1, msgid 1) >> ldap_free_connection 1 1 >> ldap_free_connection: actually freed >> ---------------------------------------- >> >> This leads me to the first question: any idea what I'm missing to be able >> to use ldaps? >> >> Then what I'm really trying is to use GSSAPI and keytab to authenticate >> during ldapsearch. >> >> First point I had to install "libsasl2-modules-gssapi-mit" or >> "libsasl2-modules-gssapi-heimdal", both are Debian packages. Without these >> packages ldapsearch was asking me for a password: >> ---------------------------------------- >> ldapsearch -LLL -H ldap://m707:389 objectclass=user >> SASL/NTLM authentication started >> Please enter your password: >> ---------------------------------------- >> >> Once one of these packages was installed and after performing a kinit: >> ---------------------------------------- >> kinit -k -t /path/to/keytab.file administrator >> klist >> Credentials cache: FILE:/tmp/krb5cc_1000 >> Principal: administrator at SAMBA.DOMAIN.TLD >> >> Issued Expires Principal >> Oct 15 11:00:48 2015 Oct 15 21:00:48 2015 >> krbtgt/SAMBA.DOMAIN.TLD at SAMBA.DOMAIN.TLD >> Oct 15 11:37:51 2015 Oct 15 21:00:48 2015 ldap/m707@ >> Oct 15 11:37:51 2015 Oct 15 21:00:48 2015 ldap/m707 at SAMBA.DOMAIN.TLD >> Oct 15 11:42:11 2015 Oct 15 21:00:48 2015 ldap/m708@ >> Oct 15 11:42:11 2015 Oct 15 21:00:48 2015 ldap/m708 at SAMBA.DOMAIN.TLD >> Oct 15 11:49:16 2015 Oct 15 21:00:48 2015 ldap/m709@ >> Oct 15 11:49:16 2015 Oct 15 21:00:48 2015 ldap/m709 at SAMBA.DOMAIN.TLD >> ---------------------------------------- >> >> GSSAPI starts to work, a little bit: >> ---------------------------------------- >> ldapsearch -LLL -H ldap://m707:389 objectclass=user >> SASL/GSS-SPNEGO authentication started >> SASL username: administrator at SAMBA.DOMAIN.TLD >> SASL SSF: 0 >> ldap_result: Can't contact LDAP server (-1) >> ---------------------------------------- >> >> Here I'm wondering which one of these packages I should have, heimdal or >> mit. Idem for Kerberos client, we can chose between heimdal-clients >> (Heimdal) and krb5-user (MIT). >> >> Anyway client seems to react identically with any of these Kerberos >> implementation. >> >> And the question: what do I missed to have that ldapsearch working with >> GSSAPI? >> >> Kindly regards, >> >> mathias >> > >