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
>>
>
>