Re: slapd: null_callback : error code 0x14

2017-09-20 Thread Paul B. Henson
On Tue, Sep 19, 2017 at 07:22:19PM -0700, Quanah Gibson-Mount wrote:

> Well, my first question is, do you see these changes to this group entry in 
> the log from your other rid as well?  I.e., if it is being applied twice, 
> you should see each modification logged twice.  Usually with sync logging, 
> you have lines noting what the CSN is that's being processed as well. 
> There's not enough log information here to act on. :)

Ah, I don't have sync logging on, just stats right now; I'll turn on
sync logging and see what shows up tomorrow. I'm sorry for the bad bug
reporting :(, but OTOH the fact that I'm in such bad practice at
reporting bugs is a tribute to how infrequently I have to do so :).

Thanks...




Re: Getting ldappasswd and PAM in the same page under CentOS 7

2017-09-20 Thread Dieter Klünter
Am Wed, 20 Sep 2017 14:20:54 -0400 (EDT)
schrieb Robert Heller :

> At Wed, 20 Sep 2017 19:30:17 +0200 Dieter =?UTF-8?B?S2zDvG50ZXI=?=
>  wrote:
> 
> > 
> > Am Wed, 20 Sep 2017 12:32:37 -0400 (EDT)
> > schrieb Robert Heller :
{...]
> I added:
> 
> logLevel: 128
> 
> to the end of /etc/openldap/slapd.d/cn=config.ldif
> 
> But it does not like it:
> 
> Sep 20 13:59:47 c764guest.deepsoft.com slapd[32362]: UNKNOWN
> attributeDescription "LOGLEVEL" inserted.
> 
> The documentaion talks about loglevel in slapd.conf, but I am not
> using slapd.conf...

I am not talking about logging and loglevel, I am talkling about
debugging and debug level.

-Dieter

-- 
Dieter Klünter | Systemberatung
http://sys4.de
GPG Key ID: E9ED159B
53°37'09,95"N
10°08'02,42"E



Re: Getting ldappasswd and PAM in the same page under CentOS 7

2017-09-20 Thread Dieter Klünter
Am Wed, 20 Sep 2017 14:20:54 -0400 (EDT)
schrieb Robert Heller :

> At Wed, 20 Sep 2017 19:30:17 +0200 Dieter =?UTF-8?B?S2zDvG50ZXI=?=
>  wrote:
> 
> > 
> > Am Wed, 20 Sep 2017 12:32:37 -0400 (EDT)
> > schrieb Robert Heller :
> >   
> > > OK, I fixed the ACLs (I think), but it is still not working.  I
> > > turned on verbose debugging for sssd[pam] and moderate debugging
> > > for slapd.
> > >=20
> > > Here are my ACLs
> > > in /etc/openldap/slapd.d/cn\=3Dconfig/olcDatabase\=3D{2}hdb.ldif:
> > >=20
> > > olcAccess: {0}to attrs=3DuserPassword
> > >   by self write
> > >   by anonymous auth
> > >   by dn=3Duid=3Dheller,ou=3DPeople,dc=3Ddeepsoft,dc=3Dcom write
> > >   by * none
> > > olcAccess: {1}to *
> > >   by dn=3Duid=3Dheller,ou=3DPeople,dc=3Ddeepsoft,dc=3Dcom write
> > >   by * read
> > >=20
> > > There are also these olcAccess entries:
> > >=20
> > > in /etc/openldap/slapd.d/cn\=3Dconfig/olcDatabase\=3D{0}config.ldif:
> > >=20
> > > olcAccess: {0}to * by
> > > dn.base=3D"gidNumber=3D0+uidNumber=3D0,cn=3Dpeercred,cn=3Dextern
> > > al,cn=3D=  
> > auth"  
> > > manage by * none
> > >=20
> > > and
> > > in /etc/openldap/slapd.d/cn\=3Dconfig/olcDatabase\=3D{1}monitor.ldif:
> > >=20
> > > olcAccess: {0}to * by
> > > dn.base=3D"gidNumber=3D0+uidNumber=3D0,cn=3Dpeercred,cn=3Dextern
> > > al,cn=3D=  
> > auth"  
> > > read by dn.base=3D"cn=3DManager,dc=3Ddeepsoft,dc=3Dcom" read by *
> > > none  
> > [...]
> > 
> > You may run slapd in debugging mode 128.  
> 
> How do I do that using the "new" configuration method in 
> /etc/openldap/slapd.d?
> 
> I added:
> 
> logLevel: 128
> 
> to the end of /etc/openldap/slapd.d/cn=config.ldif
> 
> But it does not like it:
[...]

man slapd(8),
$(EXECDIR)/slapd -h ldap:/// -F $(CONFIGDIR)/slapd.d -u $USER -g
$GROUP -d 128

-Dieter

-- 
Dieter Klünter | Systemberatung
http://sys4.de
GPG Key ID: E9ED159B
53°37'09,95"N
10°08'02,42"E



Re: Getting ldappasswd and PAM in the same page under CentOS 7

2017-09-20 Thread Robert Heller
At Wed, 20 Sep 2017 19:30:17 +0200 Dieter =?UTF-8?B?S2zDvG50ZXI=?= 
 wrote:

> 
> Am Wed, 20 Sep 2017 12:32:37 -0400 (EDT)
> schrieb Robert Heller :
> 
> > OK, I fixed the ACLs (I think), but it is still not working.  I
> > turned on verbose debugging for sssd[pam] and moderate debugging for
> > slapd.
> >=20
> > Here are my ACLs
> > in /etc/openldap/slapd.d/cn\=3Dconfig/olcDatabase\=3D{2}hdb.ldif:
> >=20
> > olcAccess: {0}to attrs=3DuserPassword
> >   by self write
> >   by anonymous auth
> >   by dn=3Duid=3Dheller,ou=3DPeople,dc=3Ddeepsoft,dc=3Dcom write
> >   by * none
> > olcAccess: {1}to *
> >   by dn=3Duid=3Dheller,ou=3DPeople,dc=3Ddeepsoft,dc=3Dcom write
> >   by * read
> >=20
> > There are also these olcAccess entries:
> >=20
> > in /etc/openldap/slapd.d/cn\=3Dconfig/olcDatabase\=3D{0}config.ldif:
> >=20
> > olcAccess: {0}to * by
> > dn.base=3D"gidNumber=3D0+uidNumber=3D0,cn=3Dpeercred,cn=3Dextern al,cn=3D=
> auth"
> > manage by * none
> >=20
> > and in /etc/openldap/slapd.d/cn\=3Dconfig/olcDatabase\=3D{1}monitor.ldif:
> >=20
> > olcAccess: {0}to * by
> > dn.base=3D"gidNumber=3D0+uidNumber=3D0,cn=3Dpeercred,cn=3Dextern al,cn=3D=
> auth"
> > read by dn.base=3D"cn=3DManager,dc=3Ddeepsoft,dc=3Dcom" read by * none
> [...]
> 
> You may run slapd in debugging mode 128.

How do I do that using the "new" configuration method in 
/etc/openldap/slapd.d?

I added:

logLevel: 128

to the end of /etc/openldap/slapd.d/cn=config.ldif

But it does not like it:

Sep 20 13:59:47 c764guest.deepsoft.com slapd[32362]: UNKNOWN 
attributeDescription "LOGLEVEL" inserted.

The documentaion talks about loglevel in slapd.conf, but I am not using 
slapd.conf...

> 
> -Dieter
> 
> --=20
> Dieter Kl=C3=BCnter | Systemberatung
> http://sys4.de
> GPG Key ID: E9ED159B
> 53=C2=B037'09,95"N
> 10=C2=B008'02,42"E
> 
>  

-- 
Robert Heller -- 978-544-6933
Deepwoods Software-- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
hel...@deepsoft.com   -- Webhosting Services
 



Re: Getting ldappasswd and PAM in the same page under CentOS 7

2017-09-20 Thread Dieter Klünter
Am Wed, 20 Sep 2017 12:32:37 -0400 (EDT)
schrieb Robert Heller :

> OK, I fixed the ACLs (I think), but it is still not working.  I
> turned on verbose debugging for sssd[pam] and moderate debugging for
> slapd.
> 
> Here are my ACLs
> in /etc/openldap/slapd.d/cn\=config/olcDatabase\={2}hdb.ldif:
> 
> olcAccess: {0}to attrs=userPassword
>   by self write
>   by anonymous auth
>   by dn=uid=heller,ou=People,dc=deepsoft,dc=com write
>   by * none
> olcAccess: {1}to *
>   by dn=uid=heller,ou=People,dc=deepsoft,dc=com write
>   by * read
> 
> There are also these olcAccess entries:
> 
> in /etc/openldap/slapd.d/cn\=config/olcDatabase\={0}config.ldif:
> 
> olcAccess: {0}to * by
> dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=extern al,cn=auth"
> manage by * none
> 
> and in /etc/openldap/slapd.d/cn\=config/olcDatabase\={1}monitor.ldif:
> 
> olcAccess: {0}to * by
> dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=extern al,cn=auth"
> read by dn.base="cn=Manager,dc=deepsoft,dc=com" read by * none
[...]

You may run slapd in debugging mode 128.

-Dieter

-- 
Dieter Klünter | Systemberatung
http://sys4.de
GPG Key ID: E9ED159B
53°37'09,95"N
10°08'02,42"E



Re: Olc deployment vs slapd.conf based deployment

2017-09-20 Thread Ondřej Kuzník
On Mon, Sep 18, 2017 at 06:08:16PM +0200, Radovan Semancik wrote:
> On 09/18/2017 05:20 PM, Howard Chu wrote:
>> Radovan Semancik wrote:
>>> I would ... if this was a wiki, or github-like pull request and if there
>>> was an example of how a good result should look like. But it does not
>>> make sense for me to spend few hours just figuring out how to contribute
>>> documentation fix.
>> 
>> So you're still saying, it's fine for other people to put in the hours to
>> produce something you benefit from, but it's too much trouble for you to
>> contribute in return. And in the meantime, it's perfectly OK for you to
>> sit back and complain that things haven't been fixed. Got it.
> 
> I'm afraid that you haven't got the point. According to my experience people
> are willing to contribute. I'm willing to contribute. Just the barrier is
> too high. But the worst thing is that I feel that the barrier could be much
> lower if there was a bit of will to lower it. But the will is just not
> there. And I do not see why. It is not 1990s any more. There are ways how to
> make cooperation easier. Why not use them?
> 
> I'm willing to do the work. In fact, I did some work already. Much more than
> just few hours. I'm just not willing to overcome unreasonable barriers that
> take a lot of time, do not significantly increase quality of the product and
> make my future work miserable. I would rather invest that time to make the
> software better. And that is exactly what I'm going to do.

I'm a bit concerned that a complaint about how contributing a completely
new tool to the project might seem not worth the hassle[0] has provoked
a thread which has since shifted to problems about general contribution
to the project but still revolving around the same arguments whether
they transpose well or not, so you end up talking past each other. No
disrespect meant, but this is not helping the community or the project
(its codebase).

This is a popular project in terms of usage (isn't the library itself
installed on a majority of UNIX systems?) that is simultaneously quite
complex[1]. It is maintained by a very small team and little in the way
of capacity to process existing contributions quickly and attract new
ones. Yes, in my eyes, the project needs to grow or it will die
eventually - how many subsystems have been marked as 'experimental' for
years?.

On Tue, Sep 19, 2017 at 10:54:56AM +0200, Radovan Semancik wrote:
> [...]
> In addition to that github has hooks that can be
> used to direct the comments directly to the mailing list. The best solution
> that I have seen is probably in the Apache CXF project where pull request
> comments are automatically synchronized with bug tracking system comments.
> There is always a way ... if there is a will.
> 
> What I see as a major problem is that there is no will. OpenLDAP project
> clearly needs major improvement. But there are almost no contributors to
> improve the project. I'm trying to explain that there may reasons why people
> are not keen to contribute. But what I see as a response only makes all of
> this worse. I'm sorry about that. Really sorry.
> 
>> You could still use "format-patch" to send your change requests via
>> E-Mail.
> 
> You could still write your letter by hand, put it into envelope and send it
> by post. But we are usually not doing that these days, are we? I'm quite
> sure we all know the reasons.

That is not a situation that's pleasant or helpful to you, but just
adding another way to contribute is not the silver bullet[2]. There are
successful projects that request contributions in way of patches (Linux,
PostgreSQL, just to quote the better known), and the IPR policy is
dictated by the foundation and unlikely to change, so let's stop
complaining about these policies in principle. On the other hand,
suggestions to making their implementation better, especially while
committing to make it work and help maintain it(!) are AFAIK
appreciated.

In terms of that, some of us would like to have a different bug tracking
system, if it supports attaching patches to it I guess that's something
you'd find a bit more welcoming.

I'd like to improve this, simplify things and make them more transparent
if I can and if you want to help, you're welcome as well, but please be
constructive, just re-hashing discussions about things that go against
fundamental policy[3] and only add more work for questionable benefit
does not seem constructive to me. Start small if you don't want the
responsibility to maintain things indefinitely, and to give an example,
I think merging documentation patches has been quite hassle-free and
time to merge quite short.

Ondrej

[0]. And the same arguments apply pretty much everywhere in the OSS
world, so while most are completely valid, they might not be entirely
fair
[1]. Hell, I don't understand half of its codebase after 8 years since
I've first been exposed to it
[2]. Not to mention that this only increases the workload for people
processing the 

Re: Getting ldappasswd and PAM in the same page under CentOS 7

2017-09-20 Thread Robert Heller
At Wed, 20 Sep 2017 09:09:23 +0200 =?UTF-8?Q?Cl=c3=a9ment_OUDOT?= 
 wrote:

> 
> 
> 
> Le 19/09/2017 =C3=A0 18:45, Robert Heller a =C3=A9crit :
> > I am having a hard time setting a user password using ldap (OpenLDAP
> > 2.4.40-13.el7) on a CentOS 7 system.
> >
> > I have installed OpenLDAP 2.4.40-13.el7 (stock CentOS 7 server and clie=
> nt),
> > nss-pam-ldapd (0.8.13-8.el7) and used authconfig to enable ldap. I have
> > created a user in the ldap database, and getent works just fine -- the =
> uid and
> > gid are seen, etc. But I cannot set the user's password in a way that w=
> orks
> > for su (and presumably login/slogin, etc.).  I am using ldappasswd to s=
> et the
> > user's password.
> >
> > I am thinking that PAM and ldappasswd are using *different* oneway encr=
> yption
> > methods and I am guessing I need to update a configuration somewhere (e=
> ither
> > for pam, sssd, or nslcd), but I am not finding it.
> 
> PAM is an LDAP client so does not read the password, it just sends BIND=20
> requests and OpenLDAP server then check the passsword by using the=20
> hashing method corresponding to the current password value.
> 
> Can you check in your server ACLs (olcAccess parameter) that anonymous=20
> users have the 'auth' right on userPassword attribute?

OK, I will check...

> 
> --=20
> Cl=C3=A9ment OUDOT
> Consultant en logiciels libres, Expert infrastructure et s=C3=A9curit=C3=A9
> Savoir-faire Linux
> 137 boulevard de Magenta - 75010 PARIS
> Blog: http://sflx.ca/coudot
> 
> 
>   
>  

-- 
Robert Heller -- 978-544-6933
Deepwoods Software-- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
hel...@deepsoft.com   -- Webhosting Services
  



Re: Using overlay rwm to rewrite search base depending on search filter

2017-09-20 Thread Clément OUDOT

Le 13/09/2017 à 16:29, Clément OUDOT a écrit :


Hello,

I am playing with overlay rwm to try to change the base DN of a search 
depending on a value in search filter.


The goal is to rewrite base "dc=example,dc=com" to 
"dc=test,dc=example,dc=com" if I have (uid=login@test) in the LDAP 
filter. Has someone already done this?



My configuration for the moment is the following, but I don't 
understant how to capture a value in searchFilter context to use it in 
searchDN context:


dn: olcOverlay={0}rwm,olcDatabase={1}meta,cn=config
objectClass: olcOverlayConfig
objectClass: olcRwmConfig
olcOverlay: rwm
olcRwmRewrite: rwm-rewriteEngine on
olcRwmRewrite: rwm-rewriteContext searchFilter
olcRwmRewrite: rwm-rewriteRule "uid=(.*@)(.*)" "uid=$0$1" ":"
olcRwmRewrite: rwm-rewriteContext searchDN
olcRwmRewrite: rwm-rewriteRule "dc=example,dc=com" 
"dc=${searchFilter($1)},dc=example,dc=com" ":"





Hello all,

I just wanted to know if my use case is something that can be achieved 
with rwm overlay or if I need to find another solution.


Thanks,

Clément.



Re: Getting ldappasswd and PAM in the same page under CentOS 7

2017-09-20 Thread Clément OUDOT



Le 19/09/2017 à 18:45, Robert Heller a écrit :

I am having a hard time setting a user password using ldap (OpenLDAP
2.4.40-13.el7) on a CentOS 7 system.

I have installed OpenLDAP 2.4.40-13.el7 (stock CentOS 7 server and client),
nss-pam-ldapd (0.8.13-8.el7) and used authconfig to enable ldap. I have
created a user in the ldap database, and getent works just fine -- the uid and
gid are seen, etc. But I cannot set the user's password in a way that works
for su (and presumably login/slogin, etc.).  I am using ldappasswd to set the
user's password.

I am thinking that PAM and ldappasswd are using *different* oneway encryption
methods and I am guessing I need to update a configuration somewhere (either
for pam, sssd, or nslcd), but I am not finding it.


PAM is an LDAP client so does not read the password, it just sends BIND 
requests and OpenLDAP server then check the passsword by using the 
hashing method corresponding to the current password value.


Can you check in your server ACLs (olcAccess parameter) that anonymous 
users have the 'auth' right on userPassword attribute?


--
Clément OUDOT
Consultant en logiciels libres, Expert infrastructure et sécurité
Savoir-faire Linux
137 boulevard de Magenta - 75010 PARIS
Blog: http://sflx.ca/coudot