[Samba] "00002020: Operation unavailable without authentication" using python-ldap

[Jonathon Reinhart]

On Sun, Apr 7, 2019 at 2:17 PM Rowland Penny via samba <
samba at lists.samba.org> wrote:
>
> On Sun, 7 Apr 2019 13:45:11 -0400
> Jonathon Reinhart <jonathon.reinhart at gmail.com> wrote:
>
> > Interesting, I'm getting the same error using the LDB tools:
> >
> > ONTHEFIVE\jreinhart-admin at samba-dc3:~$ samba-tool user list -H
> > ldap://localhost
>
> Does the DC use itself as its first nameserver in /etc/resolv.conf ?
> if it does, it should work without authentication:
>
> root at dc4:~# samba-tool user list -H ldap://localhost
> testuser
> groupuser2
> User27
> .......
> ....
> ...

Yes, the DC uses only "nameserver 127.0.0.1".  As root, that command works.

> > ONTHEFIVE\jreinhart-admin at samba-dc3:~$ ldbsearch -H ldap://localhost
> > -b 'dc=ad,dc=onthefive,dc=com'
> > search error - LDAP error 1 LDAP_OPERATIONS_ERROR -  <00002020:
> > Operation unavailable without authentication> <>
>
> Listing users should work on a DC or a Unix domain member, but it must
> be done as root (or using sudo) and for Unix domain members, you must
> use a DC's shorthostname instead of localhost.
>
> >
> >
> > Prior to this, I did a fresh kdestroy / kinit.
> >
> > It happens also on another Linux box. (Not yet "joined", but had a
> > TGT for jreinhart-admin):
> >
> > $ ldbsearch -H ldap://samba-dc3.ad.onthefive.com
> > search error - 00002020: Operation unavailable without authentication
> >
> >
> > $ kinit Administrator at AD.ONTHEFIVE.COM
> > Password for Administrator at AD.ONTHEFIVE.COM:
> > $ ldbsearch -H ldap://samba-dc3.ad.onthefive.com
> > search error - 00002020: Operation unavailable without authentication
>
> Did you run 'samba-tool user list --help' ? and if so did you miss:
>
>   Credentials Options:
>     --simple-bind-dn=DN
>                         DN to use for a simple bind
>     --password=PASSWORD
>                         Password
>     -U USERNAME, --username=USERNAME
>                         Username
>     -W WORKGROUP, --workgroup=WORKGROUP
>                         Workgroup
>     -N, --no-pass       Don't ask for a password
>     -k KERBEROS, --kerberos=KERBEROS
>                         Use Kerberos
>     --ipaddress=IPADDRESS
>                         IP address of server
>     -P, --machine-pass  Use stored machine account password
>     --krb5-ccache=KRB5CCNAME
>                         Kerberos Credentials cache
>
> Try it as a normal user on a Unix domain member, kinit as the user, then
> run this:
>
> samba-tool user list -H ldap://samba-dc3 -k yes

I don't yet have a Unix domain member to test. But on the DC (as non-root
user), passing "-k yes" to either samba-tool and ldbsearch works.

I also tried this from a non-joined Linux box, and that worked as well:

ldbsearch -k yes -H ldap://samba-dc3 -b 'dc=ad,dc=onthefive,dc=com'


>
> > For reference, here is my smb.conf:
> >
> > # Global parameters
> > [global]
> >     dns forwarder = 10.0.1.1
> >     netbios name = SAMBA-DC3
> >     realm = AD.ONTHEFIVE.COM
> >     server role = active directory domain controller
> >     workgroup = ONTHEFIVE
> >     # Winbind settings
> >     idmap_ldb:use rfc2307 = yes
> >     template shell = /bin/bash
> >     template homedir = /home/%D/%U
>
> You might as well remove the line above, it is the default.
>
> >     kerberos method = system keytab
>
> Please don't use the line above, it stops you using secrets.tdb

Okay thanks. I looked but couldn't find any recommendations on the "right"
choice for "kerberos method". I added this line (changing it from the
default) so I could SSH w/ Kerberos auth to the DC. I guess "secrets and
keytab" is the "right" choice then? Did I miss this, or should this be
expanded upon in the Wiki? What is the effect of not using secrets.tdb?

Thanks for setting me straight with the -k option.

However, I still have this issue with my Python LDAP tests.  I had hoped
that "kerberos method = secrets and keytab" would make a difference, but it
did not. This issue occurs on three different machines, using python-ldap
3.1.0, 2.5.2, and pyldap (a fork), version 2.4.25.1.

I tried writing some standalone C code to replicate this, but I didn't
quite get it working. My next step might be to try some other
language/library that has GSSAPI support, but I'm getting stuck.

Any ideas how I might be able to go about proving this is python-ldap's
issue or Samba's? I might have to install a MS AD server for comparison.

Thanks,

Jonathon