On 10/28/2016 11:22 PM, Ryan Tandy wrote:
On Fri, Oct 28, 2016 at 09:50:30PM -0600, Joshua Schaeffer wrote:
> dn: olcDatabase={1}mdb,cn=config
> changetype: modify
> replace: olcSuffix
> olcSuffix: dc=harmonywave,dc=com
> -
> replace: olcRootDN
> olcRootDN: cn=admin,dc=harmonywave,dc=com
You may have done this - I didn't see it - but if you change the suffix this way when
there are existing entries in that database, and you don't clear them out, you risk
exposing yourself to issues such as <
https://bugs.debian.org/546368>. If you change
your suffix this way, after you do it, consider initializing a new, empty database: stop
slapd, rm /var/lib/ldap/*, and start it again. I'm bringing this up because it looks
like you're using the Debian/Ubuntu package, which does indeed add a couple of entries
to the default database during setup.
Yes, I am using Debian's Jessie's package. So would it just be easier to not
change the olcSuffix to start with?
> Oct 28 21:39:02 baneling slapd[12540]: conn=4421 fd=36 TLS
established tls_ssf=128 ssf=128
As I understand it, using Kerberos with OpenLDAP already gets you an encrypted transport
- I believe using TLS on top of that is redundant.
Whenever I don't include the TLS portion I get a TLS confidentiality error on the
provider size. I'm assuming this is because of my olcSecurity: tls=128 on the
database.
> Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=3 BIND
authcid="ldap/koprulu.harmonywave.com(a)HARMONYWAVE.COM"
authzid="ldap/koprulu.harmonywave.com(a)HARMONYWAVE.COM"
> Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=3 BIND
dn="uid=ldap/koprulu.harmonywave.com,cn=harmonywave.com,cn=gssapi,cn=auth"
mech=GSSAPI sasl_ssf=56 ssf=128
> Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=3 RESULT tag=97 err=0 text=
That looks fine, the GSSAPI bind seems to have succeeded.
So at this point, based on your ACLs above, I'd expect it to be able to read all of
your data (to * by * read), except for the userPassword and shadowLastChange attributes.
> Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=4 SRCH
base="dc=harmonywave,dc=com" scope=2 deref=0 filter="(objectClass=*)"
> Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=4 SRCH attr=* +
> Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=5 UNBIND
> Oct 28 21:39:02 baneling slapd[12540]: conn=4421 fd=36 closed
Odd - I was expecting to see a RESULT line there. Not sure what that means. I guess
something goes wrong on the client and it aborts early?
It would be interesting to see logs from the syncrepl consumer, at loglevel
'sync', when you bring it up with an empty database.
Okay, I'll turn that on and run through the process again.
If you do an ldapsearch against the provider as anonymous, or doing a GSSAPI bind using
that sevice ticket, do you see all the data returned that you expected?
If you want a decent example config to compare your work against, I would suggest
rjsystems' articles:
http://www.rjsystems.nl/en/2100-d6-kerberos-openldap-provider.php
http://www.rjsystems.nl/en/2100-d6-kerberos-openldap-consumer.php
It's a little dated, but not too badly. (For example, most or all of the bugs he
mentions have since been fixed; and the hdb backend is deprecated now in favour of mdb.)
I actually used that consumer guide as my main reference. I didn't look at the
provider as setting up the provider is pretty straightforward. I'll take a look at it
to see if I missed any steps.