7:23 p.m.
Hello
When using SASL OTP, the one time password sequence number is stored in
a cmusaslsecretOTP attribute. On every successful authentication, it
should be decreased.
That works fine until used with a syncrepl setup: authenticating to a
replica may cause its local cmusaslsecretOTP, but this change will be
overriden by the value from the master.
As a result, I see sometime the sequence number decreasing just after a
succeeded authentication, but that does not last very long. Soon or
later, the older value is restored.
How is it supposed to work? As far as I understand, there needs to be
some code for the replica to send the update to the master. Is the code
missing, or do I have a configuration problem that prevent it from
working? Or do I hit a bug?
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu(a)netbsd.org
10:46 p.m.
Emmanuel Dreyfus wrote:
Hello
When using SASL OTP, the one time password sequence number is stored in
a cmusaslsecretOTP attribute. On every successful authentication, it
should be decreased.
That works fine until used with a syncrepl setup: authenticating to a
replica may cause its local cmusaslsecretOTP, but this change will be
overriden by the value from the master.
As a result, I see sometime the sequence number decreasing just after a
succeeded authentication, but that does not last very long. Soon or
later, the older value is restored.
How is it supposed to work?
Most likely it's not. Since almost nobody uses SASL OTP with OpenLDAP, it's
never gotten much attention.
As far as I understand, there needs to be
some code for the replica to send the update to the master. Is the code
missing, or do I have a configuration problem that prevent it from
working? Or do I hit a bug?
Look into chaining...
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
11:16 p.m.
Howard Chu <hyc(a)symas.com> wrote:
> How is it supposed to work?
Most likely it's not. Since almost nobody uses SASL OTP with OpenLDAP, it's
never gotten much attention.
What do people use, then?
> As far as I understand, there needs to be
> some code for the replica to send the update to the master. Is the code
> missing, or do I have a configuration problem that prevent it from
> working? Or do I hit a bug?
Look into chaining...
I have it configured already. Do you confirm this is a bug to be fixed
in the chain overlay?
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu(a)netbsd.org
11:35 p.m.
Emmanuel Dreyfus wrote:
Howard Chu<hyc(a)symas.com> wrote:
>> How is it supposed to work?
> Most likely it's not. Since almost nobody uses SASL OTP with OpenLDAP, it's
> never gotten much attention.
What do people use, then?
DIGEST-MD5
>> As far as I understand, there needs to be
>> some code for the replica to send the update to the master. Is the code
>> missing, or do I have a configuration problem that prevent it from
>> working? Or do I hit a bug?
> Look into chaining...
I have it configured already. Do you confirm this is a bug to be fixed
in the chain overlay?
No, since I have never used SASL OTP with syncrepl I don't confirm anything.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12:34 a.m.
Emmanuel Dreyfus wrote:
Howard Chu <hyc(a)symas.com> wrote:
>> How is it supposed to work?
> Most likely it's not. Since almost nobody uses SASL OTP with OpenLDAP, it's
> never gotten much attention.
What do people use, then?
>> As far as I understand, there needs to be
>> some code for the replica to send the update to the master. Is the code
>> missing, or do I have a configuration problem that prevent it from
>> working? Or do I hit a bug?
> Look into chaining...
I have it configured already. Do you confirm this is a bug to be fixed
in the chain overlay?
Not necessarily. Every write to a well-configured replica should be
rejected with a referral. The chain overlay will intercept the referral
and chase it, applying the modification to the master. You need to
check why no referral is returned, since the master's value eventually
overrides the replica's. Either the configuration uses an identity that
bypasses shadow checks (like the updatedn) or some SASL-related code
(slap_auxprop_store?) is performing an internal modification with some
special flag that bypasses shadow checks. I'm not going to debug this
issue right now (no time, sorry), but you should look at something along
these lines.
p.
2 a.m.
Pierangelo Masarati <masarati(a)aero.polimi.it> wrote:
Not necessarily. Every write to a well-configured replica should be
rejected with a referral. The chain overlay will intercept the referral
and chase it, applying the modification to the master. You need to
check why no referral is returned, since the master's value eventually
overrides the replica's. Either the configuration uses an identity that
bypasses shadow checks (like the updatedn) or some SASL-related code
(slap_auxprop_store?) is performing an internal modification with some
special flag that bypasses shadow checks.
I beleive the offending code is in
servers/slapd/sasl.h:slap_auxprop_store()
It seems we use the authc Id:
slap_propnames[SLAP_SASL_PROP_AUTHC]
But there is no special flags:
mod->sml_flags = 0;
Nothing in the logs on the master. On the client I have this at bind
time:
SASL [conn=219246] Error: SASL error opening password file. Do you have
write permissions?
SASL [conn=219246] Failure: Could not open db for write
But it happens all the time, OTP being used or not.
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu(a)netbsd.org
8:59 a.m.
Pierangelo Masarati <masarati(a)aero.polimi.it> wrote:
> Not necessarily. Every write to a well-configured replica should be
> rejected with a referral. The chain overlay will intercept the referral
> and chase it, applying the modification to the master. You need to
> check why no referral is returned, since the master's value eventually
> overrides the replica's. Either the configuration uses an identity that
> bypasses shadow checks (like the updatedn) or some SASL-related code
> (slap_auxprop_store?) is performing an internal modification with some
> special flag that bypasses shadow checks.
I beleive the offending code is in
servers/slapd/sasl.h:slap_auxprop_store()
It seems we use the authc Id:
slap_propnames[SLAP_SASL_PROP_AUTHC]
But there is no special flags:
mod->sml_flags = 0;
Nothing in the logs on the master. On the client I have this at bind
time:
SASL [conn=219246] Error: SASL error opening password file. Do you have
write permissions?
SASL [conn=219246] Failure: Could not open db for write
But it happens all the time, OTP being used or not.
I think this is not related. This definitely looks like the known issue
that libsasl always tries to check the sasldb, as soon as libsasldb.so is
available.
I've never used SASL OTP with slapd, so I'm not aware of all details, can
you post how you configured the whole stuff?
What I suspect, in your issue, is that slap_auxprop_store() writes
something locally, bypassing the fact that it is writing on a shadow
database. Whether having authentications on a shadow database modify the
master is the correct behavior or not, it is not entirely clear to me.
Apparently, this is a requirement for OTP, but it might be undesirable in
other cases. Consider for example all the issues related to replicating
(or not replicating) attributes specific to password policy... things need
to be at least discussed to figure out all the details and implications.
p.
5:24 a.m.
On Thu, 3 Dec 2009, Emmanuel Dreyfus wrote:
> Most likely it's not. Since almost nobody uses SASL OTP with
OpenLDAP, it's
> never gotten much attention.
What do people use, then?
For what it's worth, our OTP sequences are upstream of OpenLDAP (when
encountering an OTP user, OpenLDAP merely works as a proxy, viz.
contrib/slapd-modules/passwd/radius.c). Our OTP servers provide RADIUS
support so this was a bit of a no-brainer drop in...and of course we had
this preexisting infrastructure (for a couple decades at this point) to
work with and, for the usual reasons, zero desire to multihome (on legacy
+ OpenLDAP) the sequence data.
Admittedly from a "ground up" fresh deployment scenario, that would be an
unneeded additional service versus your approach; you're Probably On The
Right Track strictly speaking. I'm merely answering the "what do people
use" with one illustration.
4921
days inactive
4926
days old
openldap-software@openldap.org
7 comments
5 participants
participants (5)
-
Aaron Richton -
Howard Chu -
manu＠netbsd.org -
masarati＠aero.polimi.it -
Pierangelo Masarati