[Samba] ldapsearch against Samba4 AD questions
mathias dufresne
infractory at gmail.com
Thu Oct 15 14:20:17 UTC 2015
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
>
More information about the samba
mailing list