Christian Marg skrev, on 04-09-2007 18:38:

I always find it helpful to look into the Logfiles of the openldap-servers. On FreeBSD it's /var/log/debug.log.

Personally I find

loglevel 256

which "stats log connections/operations/results" most helpful. If you are not sure how to interpret log entries, edit it to remove sensitive content and post them, perhaps - if its more than 10 lines or so - using a pastebin (eg. pastebin.ca or something)

Hmmm ... I'm used to tailing the slapd logs, I go square-eyed looking at them at all possible values. Level 256 below.

Of course it seems weird to first have to disable and then later on to enable "chain-rebind-as-user". It seems that this is because one shouldn't rely on default values (as they might change). In the second chain-uri-stanza of the example they don't set the rebind-flag again, so I'd assume that the "global" value set after "overlay chain" will be applied.

Anyway: the best thing next to an explanation I found of what ..rebind-as-user does is in slapd-ldap: ---------8<---------8<---------8<---------8<---------8<---------8<--------- rebind-as-user {NO|yes}

If this option is given, the client's bind credentials are remembered for rebinds, when trying to re-establish a broken connection, or when chasing a referral, if chase-referrals is set to yes. ---------8<---------8<---------8<---------8<---------8<---------8<---------

chase-referrals is specific to SLAPD-LDAP and isn't documented in SLAPO-CHAIN.

So I assume that something concerning the credentials breaks - the log should help you pinpoint what exactly.

Why should it? Do you have chaining running?

Log lines (really, there are only 3) while changing a test user's password on the chaining consumer/slave:

Sep 5 08:26:04 oikos slapd2.3[22295]: conn=23043 op=10 MOD dn="cn=bmyguest,ou=gasten,dc=barlaeus,dc=nl" Sep 5 08:26:04 oikos slapd2.3[22295]: conn=23043 op=10 MOD attr=userPassword Sep 5 08:26:04 oikos slapd2.3[22295]: conn=23043 op=10 RESULT tag=103 err=0 text=

The "103" signifies a referral with err=0; good, if there were problems with the referral there would have been an err=10.

Log on the provider/master:

Sep 5 08:26:04 mercurius slapd2.3[6028]: conn=189238 op=6356 MOD dn="cn=bmyguest,ou=gasten,dc=barlaeus,dc=nl" Sep 5 08:26:04 mercurius slapd2.3[6028]: conn=189238 op=6356 MOD attr=userPassword Sep 5 08:26:04 mercurius slapd2.3[6028]: conn=189238 op=6356 RESULT tag=103 err=0 text=

Honestly, I'm no wiser from this. It just shows that there has been a referral, that a MOD operation has been carried out with no error.

Googleing for chain-rebind-as-user brought up 2 helpful OL ML threads (out of a total of 3 references) whereby Pierangelo Masarati stressed the importance of the chaining proxy on the master having authZTo configured; well, since we use digest-md5 SASL for Postfix and other things, it is (this could cause further problems for Taymour A. El Erian).

I can only assume I'm one of the few people in the world who needs real-world chaining and has it - and subscribes to this ML.

Best,

--Tonni

Howard Chu skrev, on 05-09-2007 13:22:

...

chase-referrals is specific to SLAPD-LDAP and isn't documented in SLAPO-CHAIN.

slapo-chain(5): Any valid directives for the ldap database may be used; see slapd-ldap(5) for details.

Why do we need to specifically document it further than that?

Ok, looked it up and read it (again?). I suppose I can imagine a reason for first setting it to false, then to true. Stamping on it to teach it who's the boss, as it were ...

...

I can only assume I'm one of the few people in the world who needs real-world chaining and has it - and subscribes to this ML.

Most people need it, but most people who use LDAP (as opposed to X.500) don't realize how they need it...

Thanks for the pointer :)

Best,

--Tonni

Pierangelo Masarati skrev, on 05-09-2007 09:18:

...

The 2 2.3.37 and .38 chaining tests, 018 and 032 pass on my build machine. But when I put these ad lib into slapd.conf on the consumer, they don't.

What doesn't work after 'moduleload back_ldap.la':

overlay chain chain-uri ldap://mercurius.intern/ chain-idassert-bind bindmethod=simple binddn="cn=proxy,dc=barlaeus,dc=nl" credentials=secret mode=self

What do you mean "doesn't work"? Do you mean that it doesn't chain anonymous searches? Did you try an authenticated search? Anonymous operation chaining is implicitly disabled by the idassert-bind directive, as you can see from slapd-ldap(5).

"Doesn't work" means that I get tag=103 err=10 in the consumer log (loglevel 256), the client gets a referral. No clients on the consumer other than Samba tools understand this, so referrals aren't followed by them.

I'm not binding to the consumer anonymously, I'm binding as "cn=proxy,dc=barlaeus,dc=nl" who has full authZTo rights. I'd expect the above chain-idassert-bind to work, as it does in the tests, and it doesn't.

If you want to let them thru anonymously you need to add "flags=non-prescriptive" to the idassert-bind statement; if you want anonymous to be asserted as anonymous as well, leave the idassert-bind statement as is, and add

chain-idassert-authzFrom "*"

None of this is in test018 or test23. My above stanzas conform completely to the slapd.confs for these tests.

There's no point in binding anonymously, my ACLs prohibit all access than auth to userPassword and all access whatsoever to most other attributes.

[...]

...

overlay chain chain-rebind-as-user FALSE

chain-uri ldap://mercurius.intern/ chain-rebind-as-user TRUE chain-idassert-bind bindmethod=simple binddn="cn=proxy,dc=barlaeus,dc=nl" credentials=secret mode=self chain-tls start

Could someone please explain why the configuration for the two tests should pass, while it doesn't on my consumer, and why the config with the two chain-rebind-as-user stanzas does?

I don't think that adding chain-rebind-as-user really makes any difference, because rebinding as user makes no sense if you use identity assertion: the user is not going to rebind anyway, as its identity is going to be asserted. The only thing that could change is in case chaining implies further referral chasing, i.e. if while chaining the operation another referral is encountered.

I tried to go to pains to point out that the second config stanzas *work* (again, "work" means that the referral is recognized - tag=110 - and no error is returned), while the first stanzas *do not* work - tag=110 err=10. I also asked for an explanation of why (when this is not the case with the tests).

It's no good telling me that chain-rebind-as-user is useless, when:

1: it's documented - though without an explanation - in SLAPO-CHAIN, and 2: it works ("works" means the referral from the slave is accepted and passed to the master, while a config without it doesn't).

--Tonni

Pierangelo Masarati skrev, on 05-09-2007 14:38:

[...]

I could feel your pain, but I just tried, and adding rebind as user stuff didn't alter the behavior I could experience: it worked for authenticated operations, and it didn't for anonymous, unless explicitly letting them thru as already explained.

Ok, I'll believe it; I'm not going to start over now, since stuff is working and it's a production Samba PDC for over 1000 users - I've other things to worry about that don't work as I expect - such as ppolicy and pam_ldap. Won't go into that on this list ...

...

It's no good telling me that chain-rebind-as-user is useless, when:

Useless in that context. It is useful when automatically chasing referrals, and when idassert is not used.

...

1: it's documented - though without an explanation - in SLAPO-CHAIN, and

I'll remove it from the examples, since it appears to cause more trouble than necessary.

NO, NO, PLEASE! It's what saved what little sanity I've got left, just that pointer. Perhaps it will be good for others too?

...

2: it works ("works" means the referral from the slave is accepted and passed to the master, while a config without it doesn't).

Well, it doesn't here. I suspect the evil is in the details. You should provide producer and consumer slapd.conf, a minimal set of data and an example operation that shows the issue. Possibly thru the ITS, since if the behavior you complain abut is reproducible there's a bug.

I've got two test machines at home (this is one) and I'll try it again (and again and again) when I can; as I wrote, it used to work, so perhaps I'm doing somethingthing wrong.

Thanks for the patient expansion, you (and others) write the software and you should know.

Best,

--Tonni