Re: Replication error

[Quanah Gibson-Mount]

--On Tuesday, October 10, 2017 6:39 PM +0200 Ervin Hegedüs 
 wrote:



  binddn="uid=repuser,dc=my,dc=domain,dc=hu"



Anyway - how can I solve this problem?


Your uid=repuser,dc=my,dc=domain,dc=hu user does not have "read" access on 
the userPassword attribute.


--Quanah


--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Admin roles by group membership per OU

[Ervin Hegedüs]

Hi,

here is my scenario:

dn: dc=mycompany,dc=hu

dn: ou=ABC Customer,dc=mycompany,dc=hu
+- dn: cn=group1abc,ou=ABC Customer,dc=mycompany,dc=hu
+- dn: cn=group2abc,ou=ABC Customer,dc=mycompany,dc=hu
+- dn: cn=groupabcadmin,ou=ABC Customer,dc=mycompany,dc=hu
+- dn: uid=user1,ou=ABC Customer,dc=mycompany,dc=hu
+- dn: uid=user2,ou=ABC Customer,dc=mycompany,dc=hu

dn: ou=XYZ Customer,dc=mycompany,dc=hu
+- dn: cn=group1xyz,ou=XYZ Customer,dc=mycompany,dc=hu
+- dn: cn=group2xyz,ou=XYZ Customer,dc=mycompany,dc=hu
+- dn: uid=user1,ou=XYZ Customer,dc=mycompany,dc=hu
+- dn: uid=user2,ou=XYZ Customer,dc=mycompany,dc=hu
...


the cn=groupabcadmin,ou=ABC Customer node above looks like this:

dn: cn=groupabcadmin,ou=ABC Customer,dc=mycompany,dc=hu
objectClass: groupOfNames
cn: groupabcadmin
member: uid=user1,ou=ABC Customer,dc=mycompany,dc=hu

I'ld like to set up, that the all member of cn=groupabcadmin
group, now the "uid=user1,ou=ABC Customer",... user can write
the db (add, modify, delete) under his own OU, specially the
ou=ABC Customer,dc=mycompany,dc=hu.

I've found this example:
http://www.openldap.org/faq/data/cache/52.html

Now the config looks like this:

dn: olcDatabase={1}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=mycompany,dc=hu
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous 
auth by * none
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to * by * read
olcAccess: {3}to dn.children="ou=ABC Customer,dc=mycompany,dc=hu" by self write 
by group.exact="cn=groupabcadmin,ou=ABC Customer,dc=mycompany,dc=hu" write by * 
auth
olcLastMod: TRUE

The uid=user1 user password is right, I can read with it from DB.
But when I would like to add a new user, I've got:

ldap_add: Insufficient access (50)
additional info: no write access to parent

and in log:

Oct 11 17:03:16 open-ldap slapd[25821]: mdb_dn2entry("uid=user2,ou=abc 
customer,dc=mycompany,dc=hu")
Oct 11 17:03:16 open-ldap slapd[25821]: => mdb_dn2id("uid=user2,ou=abc 
customer,dc=mycompany,dc=hu")
Oct 11 17:03:16 open-ldap slapd[25821]: <= mdb_dn2id: get failed: MDB_NOTFOUND: 
No matching key/data pair found (-30798)
Oct 11 17:03:16 open-ldap slapd[25821]: => mdb_entry_decode:
Oct 11 17:03:16 open-ldap slapd[25821]: <= mdb_entry_decode
Oct 11 17:03:16 open-ldap slapd[25821]: => access_allowed: add access to 
"ou=ABC Customer,dc=mycompany,dc=hu" "children" requested
Oct 11 17:03:16 open-ldap slapd[25821]: => dn: [2]
Oct 11 17:03:16 open-ldap slapd[25821]: => acl_get: [3] attr children
Oct 11 17:03:16 open-ldap slapd[25821]: => acl_mask: access to entry "ou=ABC 
Customer,dc=mycompany,dc=hu", attr "children" requested
Oct 11 17:03:16 open-ldap slapd[25821]: => acl_mask: to all values by 
"uid=user1,ou=abc customer,dc=mycompany,dc=hu", (=0)
Oct 11 17:03:16 open-ldap slapd[25821]: <= check a_dn_pat: *
Oct 11 17:03:16 open-ldap slapd[25821]: <= acl_mask: [1] applying read(=rscxd) 
(stop)
Oct 11 17:03:16 open-ldap slapd[25821]: <= acl_mask: [1] mask: read(=rscxd)
Oct 11 17:03:16 open-ldap slapd[25821]: => slap_access_allowed: add access 
denied by read(=rscxd)
Oct 11 17:03:16 open-ldap slapd[25821]: => access_allowed: no more rules
Oct 11 17:03:16 open-ldap slapd[25821]: mdb_add: no write access to parent
Oct 11 17:03:16 open-ldap slapd[25821]: send_ldap_result: conn=1208 op=1 p=3
Oct 11 17:03:16 open-ldap slapd[25821]: send_ldap_result: err=50 matched="" 
text="no write access to parent"
Oct 11 17:03:16 open-ldap slapd[25821]: send_ldap_response: msgid=2 tag=105 
err=50
Oct 11 17:03:16 open-ldap slapd[25821]: conn=1208 op=1 RESULT tag=105 err=50 
text=no write access to parent


What do I miss?


Thanks,


a.

Replication error

[Ervin Hegedüs]

Hi,

I (think I) setting up completly a master-slave replication.

The replication user can access from the slave (ldapsearch
works).

Here is the config, what I added on slave:

dn: olcDatabase={1}mdb,cn=config
changetype: modify
replace: olcSyncRepl
olcSyncRepl: rid=001
  provider=ldaps://master:636/
  bindmethod=simple
  binddn="uid=repuser,dc=my,dc=domain,dc=hu"
  credentials=SECRET
  searchbase="dc=my,dc=domain,dc=hu"
  scope=sub
  schemachecking=on
  type=refreshAndPersist
  retry="30 5 300 3"
  interval=00:00:05:00
  tls_cacert=/etc/ldap/CAcert.pem
  tls_cert=/etc/ldap/slave_cert.pem
  tls_key=/etc/ldap/slave_key.pem
  tls_reqcert=demand

And now I found these lines in syslog:

Oct 10 17:36:40 open-ldap2 slapd[4640]: Entry (cn=admin,dc=my,dc=domain,dc=hu): 
object class 'simpleSecurityObject' requires attribute 'userPassword'
Oct 10 17:36:40 open-ldap2 slapd[4640]: null_callback : error code 0x41
Oct 10 17:36:40 open-ldap2 slapd[4640]: syncrepl_entry: rid=001 be_add 
cn=admin,dc=my,dc=domain,dc=hu failed (65)
Oct 10 17:36:41 open-ldap2 slapd[4640]: do_syncrepl: rid=001 rc 65 retrying (4 
retries left)

I think this occures, because the cn=admin,dc=... user is a
simpleSecurityObject, and could't access the userPassword from
the ldapsearch - or not :).


Anyway - how can I solve this problem?

Thanks,

a.

Re: Question about automounting nfs directories within ldap

[Ulf Volmer]

On 09.10.2017 10:07, Bänsch, Christian (TF) wrote:

> Now I have the next question about automounting nfs directories.

i can't see that your NFS problem is related to openldap. I think, you
should post your issue in a OS specific mailing list.

Besides that:

> Oct  9 09:59:13 fautm89 automount[13131]: >> mount.nfs: access denied 
  ^^^
> by server while mounting fautm89.ltm.uni-erlangen.de:/export
   ^^^


It looks for me that client and server points to the same node.

best regards
Ulf

Re: make test seg fault related to libc

[Scott Classen]

yum erase cyrus-sasl-ldap fixed the problem.
'make test' completed without problems and no segmentation faults.


> On Oct 11, 2017, at 12:49 PM, Quanah Gibson-Mount  wrote:
> 
> --On Wednesday, October 11, 2017 1:02 PM -0700 Scott Classen 
>  wrote:
> 
>> # ulimit -a
> 
> Hm, well, that doesn't appear to be it. :/
> 
> You might look at the testrun logs and see what slapd is logging when it dies 
> as well.
> 
> --Quanah
> 
> 
> 
> --
> 
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> 
> 

Re: make test seg fault related to libc

[Quanah Gibson-Mount]

--On Wednesday, October 11, 2017 1:02 PM -0700 Scott Classen 
 wrote:



# ulimit -a


Hm, well, that doesn't appear to be it. :/

You might look at the testrun logs and see what slapd is logging when it 
dies as well.


--Quanah



--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Re: make test seg fault related to libc

[Scott Classen]

# ulimit -a
core file size  (blocks, -c) 0
data seg size   (kbytes, -d) unlimited
scheduling priority (-e) 0
file size   (blocks, -f) unlimited
pending signals (-i) 514289
max locked memory   (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files  (-n) 1024
pipe size(512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority  (-r) 0
stack size  (kbytes, -s) 8192
cpu time   (seconds, -t) unlimited
max user processes  (-u) 514289
virtual memory  (kbytes, -v) unlimited
file locks  (-x) unlimited




> On Oct 11, 2017, at 11:57 AM, Quanah Gibson-Mount  wrote:
> 
> --On Wednesday, October 11, 2017 10:44 AM -0700 Scott Classen 
>  wrote:
> 
>> Hello,
>> 
>> I've built openldap 2.4.45 on a CentOS 7.4.1708 machine with the
>> following configuration:
> 
> I've seen this happen when a ulimit value was unreasonably small.  Check the 
> limits on -m or -v perhaps.
> 
> --Quanah
> 
> 
> 
> --
> 
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> 
> 

Re: make test seg fault related to libc

[Quanah Gibson-Mount]

--On Wednesday, October 11, 2017 10:44 AM -0700 Scott Classen 
 wrote:



Hello,

I've built openldap 2.4.45 on a CentOS 7.4.1708 machine with the
following configuration:


I've seen this happen when a ulimit value was unreasonably small.  Check 
the limits on -m or -v perhaps.


--Quanah



--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

make test seg fault related to libc

[Scott Classen]

Hello,

I've built openldap 2.4.45 on a CentOS 7.4.1708 machine with the following 
configuration:

./configure --enable-bdb=no --enable-hdb=no --enable-mdb --with-tls=openssl 
--enable-spasswd --enable-syslog --enable-modules --enable-cleartext 
--enable-overlays --enable-accesslog --enable-auditlog --with-threads 
--enable-shared --enable-ldap --enable-monitor --enable-deref --enable-slapd 
--enable-ppolicy --enable-memberof

When I run make test I receive numerous segmentation faults:

output from make test:

> ./scripts/test028-idassert: line 252: 28923 Segmentation fault  (core 
> dumped) $SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING > $LOG1 2>&1
> > test028-idassert completed OK for mdb.
> 
> > Starting test029-ldapglue for mdb...
> running defines.sh
> ### This test requires the ldap backend and glue overlay.
> ### If available, and explicitly requested, it can use SASL bind;
> ### note that SASL must be properly set up, and the requested
> ### mechanism must be available.  Define SLAPD_USE_SASL={yes|},
> ### with "yes" defaulting to DIGEST-MD5 to enable SASL authc[/authz].
> Using proxyAuthz with simple authc...
> Running slapadd to build slapd database...
> Starting local slapd on TCP/IP port 9011...
> Starting remote slapd 1 on TCP/IP port 9012...
> Starting remote slapd 2 on TCP/IP port 9013...
> Using ldapsearch to check that slapd is running...
> Using ldapsearch to check that slapd is running...
> Using ldapsearch to check that slapd is running...
> Testing ldapsearch as uid=bjorn,ou=People,dc=example,dc=com for 
> "dc=example,dc=com"...
> Filtering ldapsearch results...
> Filtering original ldif used to create database...
> Comparing filter output...
> Testing ldapsearch as anonymous for "dc=example,dc=com"...
> Filtering ldapsearch results...
> Filtering original ldif used to create database...
> Comparing filter output...
> > Test succeeded
> ./scripts/test029-ldapglue: line 222: 28992 Segmentation fault  (core 
> dumped) $SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING > $LOG1 2>&1
> ./scripts/test029-ldapglue: line 222: 28994 Segmentation fault  (core 
> dumped) $SLAPD -f $CONF2 -h $URI2 -d $LVL $TIMING > $LOG2 2>&1
> ./scripts/test029-ldapglue: line 222: 28996 Segmentation fault  (core 
> dumped) $SLAPD -f $CONF3 -h $URI3 -d $LVL $TIMING > $LOG3 2>&1
> > test029-ldapglue completed OK for mdb.


In /var/log/messages:

> Oct 11 09:31:42 www kernel: slapd[9039]: segfault at 1100f7 ip 
> 7febd7a2f4dc sp 7ffe832541f8 error 4 in 
> libc-2.17.so[7febd79af000+1b8000]
> Oct 11 09:31:42 www kernel: slapd[8997]: segfault at 1100f7 ip 
> 7f48923e44dc sp 7ffec5a22658 error 4 in 
> libc-2.17.so[7f4892364000+1b8000]
> Oct 11 09:31:42 www kernel: slapd[8975]: segfault at 1100f7 ip 
> 7f01a727d4dc sp 7ffd9a127698 error 4 in 
> libc-2.17.so[7f01a71fd000+1b8000]
> Oct 11 09:31:42 www abrt-hook-ccpp: Process 8975 (slapd) of user 0 killed by 
> SIGSEGV - ignoring (repeated crash)
> Oct 11 09:31:42 www abrt-hook-ccpp: Process 9039 (slapd) of user 0 killed by 
> SIGSEGV - dumping core
> Oct 11 09:31:42 www abrt-hook-ccpp: Process 8997 (slapd) of user 0 killed by 
> SIGSEGV - dumping core


I don't see any obvious problems with the linked libraries:

[me@here openldap-2.4.45]# ldd servers/slapd/slapd
linux-vdso.so.1 =>  (0x7ffd98751000)
libltdl.so.7 => /lib64/libltdl.so.7 (0x7f930d78b000)
libicuuc.so.50 => /lib64/libicuuc.so.50 (0x7f930d412000)
libicudata.so.50 => /lib64/libicudata.so.50 (0x7f930be3d000)
libsasl2.so.3 => /lib64/libsasl2.so.3 (0x7f930bc2)
libssl.so.10 => /lib64/libssl.so.10 (0x7f930b9ae000)
libcrypto.so.10 => /lib64/libcrypto.so.10 (0x7f930b54c000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x7f930b332000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x7f930b116000)
libc.so.6 => /lib64/libc.so.6 (0x7f930ad52000)
libdl.so.2 => /lib64/libdl.so.2 (0x7f930ab4e000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x7f930a846000)
libm.so.6 => /lib64/libm.so.6 (0x7f930a543000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f930a32d000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x7f930a0f6000)
libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x7f9309ea8000)
libkrb5.so.3 => /lib64/libkrb5.so.3 (0x7f9309bc)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x7f93099bc000)
libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x7f9309788000)
libz.so.1 => /lib64/libz.so.1 (0x7f9309572000)
/lib64/ld-linux-x86-64.so.2 (0x55eefaf24000)
libfreebl3.so => /lib64/libfreebl3.so (0x7f930936e000)
libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x7f930916)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x7f9308f5c000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x7f9308d34000)

Re: Upgrade from 2.4.40 to 2.4.44

[Simone Piccardi]

Il 15/09/2017 18:33, Michael Ströder ha scritto:
> 
> I hope slapd.conf will never go away. :-/
> 
I hope that also ...

Regards
Simone