Re: slapd: null_callback : error code 0x14

[Paul B. Henson]

On Fri, Sep 22, 2017 at 08:50:38AM -0700, Quanah Gibson-Mount wrote:

> Oh, I thought you had said you only had two masters.  This could well be 

Ah, my bad, there are a total of 4 nodes, and while technically I guess
they could all be "masters", only two of them ever receive writes, one
is the primary behind a hardware load balancer and the other is the
secondary; so in my head I have two masters and two read only systems.
Which I suppose isn't really accurate from an openldap architecture
perspective, sorry.

> ITS#8444 (ignore the ITS title, it has nothing to do with memberOf), where 
> there are out of sync problems with 3+ MMR nodes and delta-syncrepl when 
> syncprov checkpoints.

Oh, I remember that ITS, I thought I'd fixed that issue by getting rid
of the memberOf overlay and switching to dynlist 8-/. It seems since I
stopped paying attention to it it's moved on in other directions.

I see there was a proposed patch posted on 8/25 that's been applied to
RE24, I'll add that to my system and see if the issue goes away. Am I
correct in my assumption that the patch only needs to be applied to the
system that is receiving the updates?

Thanks...

Re: Openldap 2.4.40-13.el7 on CentOS 7 and SSL/TLS

[Quanah Gibson-Mount]

--On Friday, September 22, 2017 5:32 PM -0400 Christopher Wood 
 wrote:



Two things I notice from below:

olcTLSCACertificateFile: /etc/openldap/certs/ca_cert.pem
  -rw-r--r--. 1 root root  1696 Sep 22 14:18 ca-cert.pem

Underscore in the first, dash in the second.


Good catch!

It's also important to note that RedHat links to MozNSS rather than GnuTLS 
or OpenSSL, so the standard caveats apply, and be sure to follow the 
documentation to MozNSS when setting up both the slapd and client 
(ldapsearch) side of things.


--Quanah

--

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

Re: Openldap 2.4.40-13.el7 on CentOS 7 and SSL/TLS

[Christopher Wood]

Two things I notice from below:

olcTLSCACertificateFile: /etc/openldap/certs/ca_cert.pem
  -rw-r--r--. 1 root root  1696 Sep 22 14:18 ca-cert.pem

Underscore in the first, dash in the second.

Per netstat you're running ldaps on 636 so you can start your TLS diagnostics 
with openssl and work your way down to ldapsearch.

openssl s_client -CApath /etc/openldap/certs -connect
(if I recall correctly)

ldapsearch -H ldaps://host:636 -x -D binddn -W filter=what
(or something)

On Fri, Sep 22, 2017 at 04:16:43PM -0400, Robert Heller wrote:
> What is the *correct* way to set up Openldap to use SSL/TLS?  The 
> documentation is somewhat confusing.
> 
> My cn=config.ldif file looks like this:
> 
> dn: cn=config
> objectClass: olcGlobal
> cn: config
> olcArgsFile: /var/run/openldap/slapd.args
> olcPidFile: /var/run/openldap/slapd.pid
> olcTLSCACertificatePath: /etc/openldap/certs
> olcTLSCACertificateFile: /etc/openldap/certs/ca_cert.pem
> olcTLSCertificateFile: /etc/openldap/certs/c764guest.cert
> olcTLSCertificateKeyFile: /etc/openldap/certs/privkey.pem
> structuralObjectClass: olcGlobal
> entryUUID: 7e6a3298-30da-1037-9c4f-458bcc6c0ce0
> creatorsName: cn=config
> createTimestamp: 20170918163057Z
> entryCSN: 20170918163057.597791Z#00#000#00
> modifiersName: cn=config
> modifyTimestamp: 20170918163057Z
> 
> in /etc/openldap/certs are these files:
> 
> [root@c764guest heller]# ls -l /etc/openldap/certs
> total 104
> -rw-r--r--. 1 root root  5137 Sep 22 14:42 c764guest.cert
> -rw-r--r--. 1 root root  1074 Sep 22 14:37 c764guest.csr
> -rw-r--r--. 1 root root  1696 Sep 22 14:18 ca-cert.pem
> -rw-r--r--. 1 root root 65536 Sep 18 12:30 cert8.db
> -rw-r--r--. 1 root root 16384 Sep 18 12:30 key3.db
> -r--r-. 1 root ldap45 Jan 10  2016 password
> -rw-r--r--. 1 root root  1834 Sep 22 14:37 privkey.pem
> -rw-r--r--. 1 root root 16384 Jan 10  2016 secmod.db
> 
> /etc/sysconfig/slapd contains:
> 
> # OpenLDAP server configuration
> # see 'man slapd' for additional information
> 
> # Where the server will run (-h option)
> # - ldapi:/// is required for on-the-fly configuration using client tools
> #   (use SASL with EXTERNAL mechanism for authentication)
> # - default: ldapi:/// ldap:///
> # - example: ldapi:/// ldap://127.0.0.1/ ldap://10.0.0.1:1389/ ldaps:///
> SLAPD_URLS="ldapi:/// ldap://127.0.0.1/ ldap://192.168.250.98/ ldaps:///"
> 
> # Any custom options
> #SLAPD_OPTIONS="-s 128"
> 
> # Keytab location for GSSAPI Kerberos authentication
> #KRB5_KTNAME="FILE:/etc/openldap/ldap.keytab"
> 
> /etc/openldap/ldap.conf contains:
> 
> #
> # LDAP Defaults
> #
> 
> # See ldap.conf(5) for details
> # This file should be world readable but not world writable.
> 
> BASE dc=deepsoft,dc=com
> URI ldaps://192.168.250.98/
> TLS_CACERT /etc/openldap/certs/ca-cert.pem
> TLS_CACERTDIR /etc/openldap/certs
> TLS_REQCERT demand
> 
> #SIZELIMIT  12
> #TIMELIMIT  15
> #DEREF  never
> 
> TLS_CACERTDIR /etc/openldap/cacerts
> 
> # Turning this off breaks GSSAPI used with krb5 when rdns = false
> SASL_NOCANONon
> 
> 
> But now when I try to do a ldapsearch I get:
> 
> [heller@c764guest ~]$ ldapsearch -x
> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
> 
> even though:
> [root@c764guest heller]# netstat -a|grep ldap
> tcp0  0 0.0.0.0:ldaps   0.0.0.0:*   LISTEN
>  
> tcp0  0 c764guest.deepsoft:ldap 0.0.0.0:*   LISTEN
>  
> tcp0  0 localhost:ldap  0.0.0.0:*   LISTEN
>  
> tcp0  0 c764guest.deepsof:33302 c764guest.deepsoft:ldap 
> ESTABLISHED
> tcp0  0 c764guest.deepsoft:ldap c764guest.deepsof:33302 
> ESTABLISHED
> tcp6   0  0 [::]:ldaps  [::]:*  LISTEN
>  
> 
> Is this correct?  I am not sure if I should be using ldaps:/// or not.  And I 
> am not sure what the proper "magic" to get TLS working is.
> 
> 
>  
> 
> -- 
> Robert Heller -- 978-544-6933
> Deepwoods Software-- Custom Software Services
> http://www.deepsoft.com/  -- Linux Administration Services
> hel...@deepsoft.com   -- Webhosting Services
>  
> 

Openldap 2.4.40-13.el7 on CentOS 7 and SSL/TLS

[Robert Heller]

What is the *correct* way to set up Openldap to use SSL/TLS?  The 
documentation is somewhat confusing.

My cn=config.ldif file looks like this:

dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /var/run/openldap/slapd.args
olcPidFile: /var/run/openldap/slapd.pid
olcTLSCACertificatePath: /etc/openldap/certs
olcTLSCACertificateFile: /etc/openldap/certs/ca_cert.pem
olcTLSCertificateFile: /etc/openldap/certs/c764guest.cert
olcTLSCertificateKeyFile: /etc/openldap/certs/privkey.pem
structuralObjectClass: olcGlobal
entryUUID: 7e6a3298-30da-1037-9c4f-458bcc6c0ce0
creatorsName: cn=config
createTimestamp: 20170918163057Z
entryCSN: 20170918163057.597791Z#00#000#00
modifiersName: cn=config
modifyTimestamp: 20170918163057Z

in /etc/openldap/certs are these files:

[root@c764guest heller]# ls -l /etc/openldap/certs
total 104
-rw-r--r--. 1 root root  5137 Sep 22 14:42 c764guest.cert
-rw-r--r--. 1 root root  1074 Sep 22 14:37 c764guest.csr
-rw-r--r--. 1 root root  1696 Sep 22 14:18 ca-cert.pem
-rw-r--r--. 1 root root 65536 Sep 18 12:30 cert8.db
-rw-r--r--. 1 root root 16384 Sep 18 12:30 key3.db
-r--r-. 1 root ldap45 Jan 10  2016 password
-rw-r--r--. 1 root root  1834 Sep 22 14:37 privkey.pem
-rw-r--r--. 1 root root 16384 Jan 10  2016 secmod.db

/etc/sysconfig/slapd contains:

# OpenLDAP server configuration
# see 'man slapd' for additional information

# Where the server will run (-h option)
# - ldapi:/// is required for on-the-fly configuration using client tools
#   (use SASL with EXTERNAL mechanism for authentication)
# - default: ldapi:/// ldap:///
# - example: ldapi:/// ldap://127.0.0.1/ ldap://10.0.0.1:1389/ ldaps:///
SLAPD_URLS="ldapi:/// ldap://127.0.0.1/ ldap://192.168.250.98/ ldaps:///"

# Any custom options
#SLAPD_OPTIONS="-s 128"

# Keytab location for GSSAPI Kerberos authentication
#KRB5_KTNAME="FILE:/etc/openldap/ldap.keytab"

/etc/openldap/ldap.conf contains:

#
# LDAP Defaults
#

# See ldap.conf(5) for details
# This file should be world readable but not world writable.

BASE dc=deepsoft,dc=com
URI ldaps://192.168.250.98/
TLS_CACERT /etc/openldap/certs/ca-cert.pem
TLS_CACERTDIR /etc/openldap/certs
TLS_REQCERT demand

#SIZELIMIT  12
#TIMELIMIT  15
#DEREF  never

TLS_CACERTDIR /etc/openldap/cacerts

# Turning this off breaks GSSAPI used with krb5 when rdns = false
SASL_NOCANONon


But now when I try to do a ldapsearch I get:

[heller@c764guest ~]$ ldapsearch -x
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

even though:
[root@c764guest heller]# netstat -a|grep ldap
tcp0  0 0.0.0.0:ldaps   0.0.0.0:*   LISTEN 
tcp0  0 c764guest.deepsoft:ldap 0.0.0.0:*   LISTEN 
tcp0  0 localhost:ldap  0.0.0.0:*   LISTEN 
tcp0  0 c764guest.deepsof:33302 c764guest.deepsoft:ldap ESTABLISHED
tcp0  0 c764guest.deepsoft:ldap c764guest.deepsof:33302 ESTABLISHED
tcp6   0  0 [::]:ldaps  [::]:*  LISTEN 

Is this correct?  I am not sure if I should be using ldaps:/// or not.  And I 
am not sure what the proper "magic" to get TLS working is.


 

-- 
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

[Robert Heller]

At Fri, 22 Sep 2017 16:34:44 +0200 m.wan...@t-online.de wrote:

> 
> Am 22.09.2017 um 15:45 schrieb Robert Heller:
> > At Fri, 22 Sep 2017 10:47:29 +0200 Dieter =?UTF-8?B?S2zDvG50ZXI=?= 
> >  wrote:
> > 
> >>
> >> Am Thu, 21 Sep 2017 10:01:48 -0400 (EDT)
> >> schrieb Robert Heller :
> >> [...]
> >>
> >>> Sep 21 09:50:01 c764guest.deepsoft.com slapd[17535]: <=3D acl_mask: [1]
> >>> mask: write(=3Dwrscxd) Sep 21 09:50:01 c764guest.deepsoft.com
> >>> slapd[17535]: =3D> slap_access_allowed: search access granted by
> >>> write(=3Dwrscxd) Sep 21 09:50:01 c764guest.deepsoft.com slapd[17535]:
> >>> =3D> access_allowed: search access granted by write(=3Dwrscxd) Sep 21
> >>> 09:50:01 c764guest.deepsoft.com slapd[17535]: conn=3D1000 op=3D11 SEARCH
> >>> RESULT tag=3D101 err=3D0 nentries=3D0 text=3D
> >> [...]
> >>
> >> You should find out why operation 11 results in 0 entries.
> > 
> > Operation 11 *seems* to be fetching the uid, using self, which has write 
> > access, which implies read access, which seems to work just fine, using 
> > ldapsearch from the command line:
> > 
> > [heller@c764guest ~]$ ldapsearch -D 
> > uid=test2user,ou=People,dc=deepsoft,dc=com -W -LLL '(uid=test2user)' uid
> > Enter LDAP Password: 
> > dn: uid=test2user,ou=People,dc=deepsoft,dc=com
> > uid: test2user
> > 
> > I don't know what is going on here.
> > 
> > Also: there is a "TLS negotiation failure" failure. I have not even enabled
> > TLS and/or ssl. At least I don't think I have it enabled. I *think* I have 
> > it
> > disabled everywhere. I want to test things without messing with creating a 
> > SSL
> > Cert (none of this is anything close to a public facing production
> > environment). I have ldap_id_use_start_tls set to false in 
> > /etc/sssd/sssd.conf 
> > -- is there some other option I need to set?
> > 
> Ok, if you use auth_provider = ldap in your sssd  SSL/TLS is a must.
> IMHO it isn't possible to get it work without.

Yesh :-(. Now I have to get the SSL/TLS working... I have a cert now, but it
is own my own CA and I am not sure how to get that to work...

> 

> 
> best regards
> Michael
> 
> > Is there any change that selinux is having any effect?  Selinux can be 
> > pesky 
> > at times.
> > 
> >>
> >> -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

[Robert Heller]

At Fri, 22 Sep 2017 07:36:48 -0700 Quanah Gibson-Mount  wrote:

> 
> --On Friday, September 22, 2017 10:45 AM -0400 Robert Heller 
>  wrote:
> 
> 
> > Operation 11 *seems* to be fetching the uid, using self, which has write
> > access, which implies read access, which seems to work just fine, using
> > ldapsearch from the command line:
> >
> > [heller@c764guest ~]$ ldapsearch -D
> > uid=test2user,ou=People,dc=deepsoft,dc=com -W -LLL '(uid=test2user)' uid
> > Enter LDAP Password:
> > dn: uid=test2user,ou=People,dc=deepsoft,dc=com
> > uid: test2user
> 
> Is PAM actually bound as uid=testuser2, or is it bound as anonymous or some 
> other DN?  I can't tell from the little snippet of log that was in this 
> thread.  So yes, it works for you using ldapsearch when you bind as 
> uid=test2user, but is that what pam is using?

It *seems* to be matching on the ACL for "self" in op 11.

But it turns out that sssd insists on using SSL/TLS, so I need to get that 
working first...

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

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

Openldap periodic cpu spikes in one of the servers in two node MMR

[rammohan ganapavarapu]

Hi,

I have two node MMR ldap cluster with hdb, but for some reason one of the
servers CPU get spiked every minute, I am not sure what is causing this
spike every minute, we have same server configuration in both the server.
Also when i do db_stat on *.bdb files this server is taking too long to
respond for db_stat, i am pasting top and strace out put of that thread
here. Also attach a graph shows cpu spikes and active threads spikes in
both the servers (green and yellow lines),

*Openldap Version: openldap-2.4.43*

[root@localhost ldap]# db_stat -d id2entry.bdb
Thu Sep 21 22:16:15 2017 Local time

date
^CKilled
[root@localhost ldap]# date
Thu Sep 21 22:27:54 UTC 2017


* du -sh id2entry.bdb*
*7.6G id2entry.bdb*

DB_CONFIG

sudo cat /var/lib/ldap/DB_CONFIG |grep -v "^#"


set_cachesize 8 0 1


set_lg_regionmax 262144
set_lg_bsize 2097152


set_lk_max_locks 3000
set_lk_max_objects 1500
set_lk_max_lockers 1500




*Top output of busy thread at the time of cpu spike:*

ldap_top..20170922.165808.886367620: 61437 ldap  20   0 14.8g  13g 8.2g
S  0.0 47.5  18:01.04 slapd
ldap_top..20170922.165811.390769103: 61437 ldap  20   0 14.8g  13g 8.2g
S  0.0 47.5  18:01.04 slapd
ldap_top..20170922.165813.895158022: 61437 ldap  20   0 14.8g  13g 8.2g
S  0.0 47.5  18:01.04 slapd
ldap_top..20170922.165816.399627768: 61437 ldap  20   0 14.8g  13g 8.2g
S  0.0 47.5  18:01.04 slapd
ldap_top..20170922.165818.903936890: 61437 ldap  20   0 14.8g  13g 8.2g
S  0.0 47.5  18:01.04 slapd
ldap_top..20170922.165821.408275241: 61437 ldap  20   0 14.8g  13g 8.2g
S  0.0 47.5  18:01.04 slapd
ldap_top..20170922.165823.912707039: 61437 ldap  20   0 14.8g  13g 8.2g
S  0.0 47.5  18:01.05 slapd
ldap_top..20170922.165826.417287284: 61437 ldap  20   0 14.8g  13g 8.2g
R 101.8 47.5  18:02.51 slapd
ldap_top..20170922.165828.922186726: 61437 ldap  20   0 14.8g  13g 8.2g
R 99.8 47.5  18:05.01 slapd
ldap_top..20170922.165831.427101922: 61437 ldap  20   0 14.8g  13g 8.2g
R 99.8 47.5  18:07.51 slapd
ldap_top..20170922.165833.931996934: 61437 ldap  20   0 14.8g  13g 8.2g
R 99.8 47.5  18:09.92 slapd
ldap_top..20170922.165836.436814788: 61437 ldap  20   0 14.8g  13g 8.2g
R 99.8 47.5  18:12.42 slapd
ldap_top..20170922.165838.941597309: 61437 ldap  20   0 14.8g  13g 8.2g
R 99.8 47.5  18:14.92 slapd
ldap_top..20170922.165841.446448385: 61437 ldap  20   0 14.8g  13g 8.2g
R 99.8 47.5  18:17.18 slapd
ldap_top..20170922.165843.951329579: 61437 ldap  20   0 14.8g  13g 8.2g
R 97.8 47.5  18:19.67 slapd
ldap_top..20170922.165846.456172321: 61437 ldap  20   0 14.8g  13g 8.2g
R 99.8 47.5  18:21.85 slapd
ldap_top..20170922.165848.961017603: 61437 ldap  20   0 14.8g  13g 8.2g
R 99.8 47.5  18:24.35 slapd
ldap_top..20170922.165851.465897714: 61437 ldap  20   0 14.8g  13g 8.2g
R 101.8 47.5  18:26.49 slapd
ldap_top..20170922.165853.970797751: 61437 ldap  20   0 14.8g  13g 8.2g
S 57.9 47.5  18:28.77 slapd
ldap_top..20170922.165856.475641225: 61437 ldap  20   0 14.8g  13g 8.2g
S  0.0 47.5  18:28.77 slapd
ldap_top..20170922.165858.980268851: 61437 ldap  20   0 14.8g  13g 8.2g
S  0.0 47.5  18:28.77 slapd
ldap_top..20170922.165901.485817704: 61437 ldap  20   0 14.8g  13g 8.2g
S  0.0 47.5  18:28.77 slapd
ldap_top..20170922.165903.990499397: 61437 ldap  20   0 14.8g  13g 8.2g
S  0.0 47.5  18:28.78 slapd
ldap_top..20170922.165906.495260168: 61437 ldap  20   0 14.8g  13g 8.2g
S  0.0 47.5  18:28.78 slapd
ldap_top..20170922.165909.078879876: 61437 ldap  20   0 14.8g  13g 8.2g
S  0.0 47.5  18:28.78 slapd
ldap_top..20170922.165911.583657585: 61437 ldap  20   0 14.8g  13g 8.2g
S  0.0 47.5  18:28.78 slapd
ldap_top..20170922.165914.088384025: 61437 ldap  20   0 14.8g  13g 8.2g
S  0.0 47.5  18:28.78 slapd
ldap_top..20170922.165916.593114635: 61437 ldap  20   0 14.8g  13g 8.2g
S  0.0 47.5  18:28.78 slapd
ldap_top..20170922.165919.097562041: 61437 ldap  20   0 14.8g  13g 8.2g
S  0.0 47.5  18:28.78 slapd
ldap_top..20170922.165921.602221629: 61437 ldap  20   0 14.8g  13g 8.2g
S  0.0 47.5  18:28.78 slapd
ldap_top..20170922.165924.106739600: 61437 ldap  20   0 14.8g  13g 8.2g
S  0.0 47.5  18:28.78 slapd
ldap_top..20170922.165926.65008: 61437 ldap  20   0 14.8g  13g 8.2g
S  0.0 47.5  18:28.78 slapd
ldap_top..20170922.165929.115600777: 61437 ldap  20   0 14.8g  13g 8.2g
S  0.0 47.5  18:28.78 slapd
ldap_top..20170922.165931.620082217: 61437 ldap  20   0 14.8g  13g 8.2g
S  0.0 47.5  18:28.78 slapd
ldap_top..20170922.165934.124916755: 61437 ldap  20   0 14.8g  13g 8.2g
S  0.0 47.5  18:28.78 slapd

*strace output on that thread around that time:*

grep "16:58:26" ldap_strace.61437
16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0
16:58:26 futex(0x5602707aea40, FUTEX_WAKE_PRIVATE, 1) = 0
16:58:26 futex(0x5602707aea00, FUTEX_WAKE_PRIVATE, 1) = 0
16:58:26 futex(0x5602707aea00, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN
(Resource temporarily unavailable)
16:58:26 

Re: Olc deployment vs slapd.conf based deployment

[Michael Ströder]

Quanah Gibson-Mount wrote:

The real issue with ppolicy is that it shouldn't be shipping with a
separate schema, and instead it should have its configuration schema
fully internalized.


Hmm, you could say that about for standard schema file shipped by 
OpenLDAP but considered immutable (like core.schema etc.). Especially if 
you change the code to move schema declarations from a schema file to 
schema_prep.c or an overlay foobar.c your stuck with having to update 
cn=config:

1. Before software you must not add/remove the schema declaration.
2. After software you cannot add/remove the schema declaration.

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Olc deployment vs slapd.conf based deployment

[Quanah Gibson-Mount]

--On Friday, September 22, 2017 10:47 AM -0700 Quanah Gibson-Mount 
 wrote:



The current ITS system is already scheduled for replacement.  The current
OpenLDAP infrastructure is already being migrated


*being migrated (one server complete, one underway as time allows).

--Quanah



--

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

Re: Olc deployment vs slapd.conf based deployment

[Quanah Gibson-Mount]

--On Wednesday, September 20, 2017 6:40 PM +0200 Ondřej Kuzník 
 wrote:



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.


The current ITS system is already scheduled for replacement.  The current 
OpenLDAP infrastructure is already being migrated (The old git-master 
server was migrated earlier this year).  The larger issue with migrating 
the other piece of infrastructure is it is a mess to detangle.  It's a 
rather old debian box that still has freeBSD binaries on it from when it 
was migrated from freeBSD to debian, and the current software setup is... 
interesting. ;)  So as a part of migrating it to the new server, I'm 
redoing the configurations and documenting everything as I go along. It's 
rather time consuming.


--Quanah

--

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

Re: slapd: null_callback : error code 0x14

[Quanah Gibson-Mount]

--On Thursday, September 21, 2017 9:59 PM -0700 "Paul B. Henson" 
 wrote:



It seems there are updates for that group coming from rid 002
(egeria.ldap.cpp.edu) and 003 (minerva.ldap.cpp.edu), but none from rid
001 (themis.ldap.cpp.edu) which is serverid 4, where the change was
actually made?


Oh, I thought you had said you only had two masters.  This could well be 
ITS#8444 (ignore the ITS title, it has nothing to do with memberOf), where 
there are out of sync problems with 3+ MMR nodes and delta-syncrepl when 
syncprov checkpoints.


--Quanah

--

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

Re: Locker killed to resolve a deadlock

[Quanah Gibson-Mount]

--On Friday, September 22, 2017 4:26 PM +0900 Jorgen Lundman 
 wrote:



This has started to cause trouble, in the last month or so. The errors
are:

Sep 22 06:08:26 vmx02 slapd[14039]: [ID 960831 local4.debug] =>
bdb_idl_delete_key: c_get failed: DB_LOCK_DEADLOCK: Locker killed to
resolve a deadlock (-30994)


These can be safely ignored.  See 




--Quanah

--

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

Re: Olc deployment vs slapd.conf based deployment

[Quanah Gibson-Mount]

--On Friday, September 22, 2017 8:38 AM -0400 Frank Swasey 
 wrote:



My take away from this lengthy discussion is the following:

1) cn=config is not ready for "make; make test; make install" level of
upgrade.  Until it is, it is not usable in a production environment.


I've been doing binary upgrades on deployments using cn=config for years 
(Since 2011 or so), with servers all across the globe.  However, I didn't 
use ppolicy in my configurations.  The real issue with ppolicy is that it 
shouldn't be shipping with a separate schema, and instead it should have 
its configuration schema fully internalized.  I've already made a note to 
that that needs to be fixed for OpenLDAP 2.5 so it doesn't occur again. 
Outside of that, I'm not aware of it being deficient in comparison to 
slapd.conf, and I'm quite aware of numerous ways in which it is 
substantially better.


--Quanah


--

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

Re: Olc deployment vs slapd.conf based deployment

[Howard Chu]

Peter wrote:

olcSchemaFile: {0}include: file://$ABS_SCHEMADIR/core.ldif
olcSchemaFile: {1}include: file://$ABS_SCHEMADIR/cosine.ldif
olcSchemaFile: {2}include: file://$ABS_SCHEMADIR/inetorgperson.ldif 


That is a very nice proposal, it would sort of give us the good things of both 
worlds.


It means you would not be able to edit the schema contained within these 
directives over LDAP, since those elements aren't themselves part of the 
cn=config DIT. So no, it's not the good things of both worlds.



IMHO schema is the only thing where cn=config makes life harder than slapd.conf.

Being a long time lurker on this list it is fun to see that although same 
subjects like config alternatives,  turn up again and again, the arguments and 
solution proposals at least sometimes do progress.


Cheers

Peter



Am 15.09.2017 um 20:33 schrieb Quanah Gibson-Mount:
--On Friday, September 15, 2017 12:24 PM -0700 Ryan Tandy  
wrote:




There was some talk, either in IRC or on -devel, of creating a way for
cn=config to reference schema files (possibly LDIF) on disk rather than
importing them into the config database. I think that would be an
improvement. Importing schemas into cn=config is cool - especially if you
want to replicate the config - but I'm not sure it's a good default.


Since ordering is mandatory, it would be nice if you could just do something 
like:


olcSchemaFile: {0}include: file://$ABS_SCHEMADIR/core.ldif
olcSchemaFile: {1}include: file://$ABS_SCHEMADIR/cosine.ldif
olcSchemaFile: {2}include: file://$ABS_SCHEMADIR/inetorgperson.ldif


etc.  Then you could change the schema files on disk, and cn=config would 
just load them in when it started.  It'd certainly make the behavior 
analagous to slapd.conf, and allow for easier rollback/testing.


--Quanah


--

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








--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Proper Way To Securely Bind With LDAP Server

[Douglas Duckworth]

Hi

As I have read the StartTLS extended operation seems to be preferred over
SSL:

http://www.openldap.org/faq/data/cache/605.html

Therefore* I have always* used -ZZ with ldap://URI to bind to my server.
Eg:

ldapsearch -ZZ -b base -H ldap://server -D uid=admin,ou=users,base -W
cn=search

I thought this would thus encrypt my password by encapsulating the TCP 389
connection with TLS encryption.  However, to my severe dismay, I can see my
password in "-d3" debug output, using the above command, as well as when
dropping the -ZZ and using ldaps://

Can you please provide guidance?

ldap_url_parse_ext(ldap://ldap.server.domain)
ldap_create
ldap_url_parse_ext(ldap://ldap.server.domain:389/??base)
ldap_extended_operation_s
ldap_extended_operation
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP ldap.server.domain:389
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying LDAP_SERVER:389
ldap_pvt_connect: fd: 3 tm: -1 async: 0
attempting to connect:
connect success
ldap_open_defconn: successful
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({) ber:
ber_flush2: 31 bytes to sd 3
ldap_write: want=31, written=31
  :  30 1d 02 01 01 77 18 80  16 31 2e 33 2e 36 2e 31
0w...1.3.6.1
0010:  2e 34 2e 31 2e 31 34 36  36 2e 32 30 30 33 37
 .4.1.1466.20037
ldap_result ld 0xdea060 msgid 1
wait4msg ld 0xdea060 msgid 1 (infinite timeout)
wait4msg continue ld 0xdea060 msgid 1 all 1
** ld 0xdea060 Connections:
* host: ldap.server.domain  port: 389  (default)
  refcnt: 2  status: Connected
last used: Fri Sep 22 10:23:35 2017

TLS certificate verification: subject:
CN=ldap.server.domain,OU=BLAH,issuer: CN=InCommon RSA Server
CA,OU=InCommon,O=Internet2,L=Ann Arbor,ST=MI,C=US, cipher: *AES-256*, *security
level: high*, secret key bits: 256, total key bits: 256, cache hits: 0,
cache misses: 0, cache not reusable: 0

Enter LDAP Password:  <-- I Enter Password

The server logs show:

Sep 22 10:27:41 server slapd[21471]: conn=131126 op=1 BIND dn="admin"
method=128
Sep 22 10:27:41 server slapd[21471]: conn=131126 op=1 BIND dn="admin"
mech=SIMPLE ssf=0

The password then appears in -d3 output after I authenticate.

However, I do not see the password in tcpdump using a full packet capture
on both the client and ldap server.

As expected I do see the password in tcpdump when dropping the -ZZ and
using -x for simple bind.

So in summary seeing credentials when using -ZZ and -d3 should not bring
concern as they're encrypted over the wire.  So I guess can you explain how
"-d3" works?



Thanks,

Douglas Duckworth, MSc, LFCS
HPC System Administrator
Scientific Computing Unit
Physiology and Biophysics
Weill Cornell Medicine
E: d...@med.cornell.edu
O: 212-746-6305
F: 212-746-8690

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

[Quanah Gibson-Mount]

--On Friday, September 22, 2017 10:45 AM -0400 Robert Heller 
 wrote:




Operation 11 *seems* to be fetching the uid, using self, which has write
access, which implies read access, which seems to work just fine, using
ldapsearch from the command line:

[heller@c764guest ~]$ ldapsearch -D
uid=test2user,ou=People,dc=deepsoft,dc=com -W -LLL '(uid=test2user)' uid
Enter LDAP Password:
dn: uid=test2user,ou=People,dc=deepsoft,dc=com
uid: test2user


Is PAM actually bound as uid=testuser2, or is it bound as anonymous or some 
other DN?  I can't tell from the little snippet of log that was in this 
thread.  So yes, it works for you using ldapsearch when you bind as 
uid=test2user, but is that what pam is using?


--Quanah

--

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

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

[Michael Wandel]

Am 22.09.2017 um 15:45 schrieb Robert Heller:
> At Fri, 22 Sep 2017 10:47:29 +0200 Dieter =?UTF-8?B?S2zDvG50ZXI=?= 
>  wrote:
> 
>>
>> Am Thu, 21 Sep 2017 10:01:48 -0400 (EDT)
>> schrieb Robert Heller :
>> [...]
>>
>>> Sep 21 09:50:01 c764guest.deepsoft.com slapd[17535]: <=3D acl_mask: [1]
>>> mask: write(=3Dwrscxd) Sep 21 09:50:01 c764guest.deepsoft.com
>>> slapd[17535]: =3D> slap_access_allowed: search access granted by
>>> write(=3Dwrscxd) Sep 21 09:50:01 c764guest.deepsoft.com slapd[17535]:
>>> =3D> access_allowed: search access granted by write(=3Dwrscxd) Sep 21
>>> 09:50:01 c764guest.deepsoft.com slapd[17535]: conn=3D1000 op=3D11 SEARCH
>>> RESULT tag=3D101 err=3D0 nentries=3D0 text=3D
>> [...]
>>
>> You should find out why operation 11 results in 0 entries.
> 
> Operation 11 *seems* to be fetching the uid, using self, which has write 
> access, which implies read access, which seems to work just fine, using 
> ldapsearch from the command line:
> 
> [heller@c764guest ~]$ ldapsearch -D 
> uid=test2user,ou=People,dc=deepsoft,dc=com -W -LLL '(uid=test2user)' uid
> Enter LDAP Password: 
> dn: uid=test2user,ou=People,dc=deepsoft,dc=com
> uid: test2user
> 
> I don't know what is going on here.
> 
> Also: there is a "TLS negotiation failure" failure. I have not even enabled
> TLS and/or ssl. At least I don't think I have it enabled. I *think* I have it
> disabled everywhere. I want to test things without messing with creating a SSL
> Cert (none of this is anything close to a public facing production
> environment). I have ldap_id_use_start_tls set to false in 
> /etc/sssd/sssd.conf 
> -- is there some other option I need to set?
> 
Ok, if you use auth_provider = ldap in your sssd  SSL/TLS is a must.
IMHO it isn't possible to get it work without.


best regards
Michael

> Is there any change that selinux is having any effect?  Selinux can be pesky 
> at times.
> 
>>
>> -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
>>
>> 
>>
> 

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

[Andreas Hasenack]

On Fri, Sep 22, 2017 at 10:45 AM, Robert Heller  wrote:

> At Fri, 22 Sep 2017 10:47:29 +0200 Dieter =?UTF-8?B?S2zDvG50ZXI=?= <
> die...@dkluenter.de> wrote:
>
> >
> > Am Thu, 21 Sep 2017 10:01:48 -0400 (EDT)
> > schrieb Robert Heller :
> > [...]
> >
> > > Sep 21 09:50:01 c764guest.deepsoft.com slapd[17535]: <=3D acl_mask:
> [1]
> > > mask: write(=3Dwrscxd) Sep 21 09:50:01 c764guest.deepsoft.com
> > > slapd[17535]: =3D> slap_access_allowed: search access granted by
> > > write(=3Dwrscxd) Sep 21 09:50:01 c764guest.deepsoft.com slapd[17535]:
> > > =3D> access_allowed: search access granted by write(=3Dwrscxd) Sep 21
> > > 09:50:01 c764guest.deepsoft.com slapd[17535]: conn=3D1000 op=3D11
> SEARCH
> > > RESULT tag=3D101 err=3D0 nentries=3D0 text=3D
> > [...]
> >
> > You should find out why operation 11 results in 0 entries.
>
> Operation 11 *seems* to be fetching the uid, using self, which has write
> access, which implies read access, which seems to work just fine, using
> ldapsearch from the command line:
>
> [heller@c764guest ~]$ ldapsearch -D uid=test2user,ou=People,dc=deepsoft,dc=com
> -W -LLL '(uid=test2user)' uid
> Enter LDAP Password:
> dn: uid=test2user,ou=People,dc=deepsoft,dc=com
> uid: test2user
>

I haven't checked your logs, so apologies if the answers to my points are
in there.

Is your search above the same search done by the tool? Consider:
- base: where does the search start? dc=deepsoft,dc=com? ou=People?
- type of search: base, one, sub
- search filter: is (uid=test2user) the only filter? Usually there are
objectClass filters together with that

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

[Robert Heller]

Things are still not working.  Here is my olcDatabase=\{2}hdb.ldif file 
(which contains the access control):

dn: olcDatabase={2}hdb
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {2}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=deepsoft,dc=com
olcRootDN: cn=Manager,dc=deepsoft,dc=com
olcRootPW: {SSHA}rAk/xVPcZRGhumUTuc2T9xngcSQwL5Sx
olcAccess: {0}to attrs=userPassword
  by self write
  by anonymous auth
  by dn=uid=sssd,ou=People,dc=deepsoft,dc=com read
  by dn=uid=nslcd,ou=People,dc=deepsoft,dc=com read
  by * none
olcAccess: {1}to *
  by self write
  by anonymous auth
  by * read
olcDbIndex: objectClass eq,pres
olcDbIndex: ou,cn,mail,surname,givenname eq,pres,sub
structuralObjectClass: olcHdbConfig
entryUUID: 7e6a8cd4-30da-1037-9c55-458bcc6c0ce0
creatorsName: cn=config
createTimestamp: 20170918163057Z
entryCSN: 20170918163057.600191Z#00#000#00
modifiersName: cn=config
modifyTimestamp: 20170918163057Z

And here is the log files from slapd (run with -s 128) and sssd_map (also with 
debugging enabled):

● slapd.service - OpenLDAP Server Daemon
   Loaded: loaded (/usr/lib/systemd/system/slapd.service; enabled; vendor 
preset: disabled)
   Active: active (running) since Thu 2017-09-21 09:46:06 EDT; 4min 7s ago
 Docs: man:slapd
   man:slapd-config
   man:slapd-hdb
   man:slapd-mdb
   file:///usr/share/doc/openldap-servers/guide.html
  Process: 17533 ExecStart=/usr/sbin/slapd -u ldap -h ${SLAPD_URLS} 
$SLAPD_OPTIONS (code=exited, status=0/SUCCESS)
  Process: 17495 ExecStartPre=/usr/libexec/openldap/check-config.sh 
(code=exited, status=0/SUCCESS)
 Main PID: 17535 (slapd)
   CGroup: /system.slice/slapd.service
   └─17535 /usr/sbin/slapd -u ldap -h ldapi:/// ldap://127.0.0.1/ 
ldap://192.168.250.98/ -s 128

Sep 21 09:47:09 c764guest.deepsoft.com slapd[17535]: <= acl_mask: [3] applying 
read(=rscxd) (stop)
Sep 21 09:47:09 c764guest.deepsoft.com slapd[17535]: <= acl_mask: [3] mask: 
read(=rscxd)
Sep 21 09:47:09 c764guest.deepsoft.com slapd[17535]: => slap_access_allowed: 
read access granted by read(=rscxd)
Sep 21 09:47:09 c764guest.deepsoft.com slapd[17535]: => access_allowed: read 
access granted by read(=rscxd)
Sep 21 09:47:09 c764guest.deepsoft.com slapd[17535]: => access_allowed: result 
not in cache (homeDirectory)
Sep 21 09:47:09 c764guest.deepsoft.com slapd[17535]: => access_allowed: read 
access to "uid=test2user,ou=People,dc=deepsoft,dc=com" "homeDirectory" requested
Sep 21 09:47:09 c764guest.deepsoft.com slapd[17535]: => acl_get: [2] attr 
homeDirectory
Sep 21 09:47:09 c764guest.deepsoft.com slapd[17535]: => acl_mask: access to 
entry "uid=test2user,ou=People,dc=deepsoft,dc=com", attr "homeDirectory" 
requested
Sep 21 09:47:09 c764guest.deepsoft.com slapd[17535]: => acl_mask: to value by 
"uid=sssd,ou=people,dc=deepsoft,dc=com", (=0)
Sep 21 09:47:09 c764guest.deepsoft.com slapd[17535]: <= check a_dn_pat: self
Sep 21 09:47:09 c764guest.deepsoft.com slapd[17535]: <= check a_dn_pat: 
anonymous
Sep 21 09:47:09 c764guest.deepsoft.com slapd[17535]: <= check a_dn_pat: *
Sep 21 09:47:09 c764guest.deepsoft.com slapd[17535]: <= acl_mask: [3] applying 
read(=rscxd) (stop)
Sep 21 09:47:09 c764guest.deepsoft.com slapd[17535]: <= acl_mask: [3] mask: 
read(=rscxd)
Sep 21 09:47:09 c764guest.deepsoft.com slapd[17535]: => slap_access_allowed: 
read access granted by read(=rscxd)
Sep 21 09:47:09 c764guest.deepsoft.com slapd[17535]: => access_allowed: read 
access granted by read(=rscxd)
Sep 21 09:47:09 c764guest.deepsoft.com slapd[17535]: => access_allowed: result 
not in cache (loginShell)
Sep 21 09:47:09 c764guest.deepsoft.com slapd[17535]: => access_allowed: read 
access to "uid=test2user,ou=People,dc=deepsoft,dc=com" "loginShell" requested
Sep 21 09:47:09 c764guest.deepsoft.com slapd[17535]: => acl_get: [2] attr 
loginShell
Sep 21 09:47:09 c764guest.deepsoft.com slapd[17535]: => acl_mask: access to 
entry "uid=test2user,ou=People,dc=deepsoft,dc=com", attr "loginShell" requested
Sep 21 09:47:09 c764guest.deepsoft.com slapd[17535]: => acl_mask: to value by 
"uid=sssd,ou=people,dc=deepsoft,dc=com", (=0)
Sep 21 09:47:09 c764guest.deepsoft.com slapd[17535]: <= check a_dn_pat: self
Sep 21 09:47:09 c764guest.deepsoft.com slapd[17535]: <= check a_dn_pat: 
anonymous
Sep 21 09:47:09 c764guest.deepsoft.com slapd[17535]: <= check a_dn_pat: *
Sep 21 09:47:09 c764guest.deepsoft.com slapd[17535]: <= acl_mask: [3] applying 
read(=rscxd) (stop)
Sep 21 09:47:09 c764guest.deepsoft.com slapd[17535]: <= acl_mask: [3] mask: 
read(=rscxd)
Sep 21 09:47:09 c764guest.deepsoft.com slapd[17535]: => slap_access_allowed: 
read access granted by read(=rscxd)
Sep 21 09:47:09 c764guest.deepsoft.com slapd[17535]: => access_allowed: read 
access granted by read(=rscxd)
Sep 21 09:47:09 c764guest.deepsoft.com slapd[17535]: => access_allowed: result 
not in cache (gecos)
Sep 21 09:47:09 c764guest.deepsoft.com slapd[17535]: => access_allowed: read 
access to 

Locker killed to resolve a deadlock

[Jorgen Lundman]

openldap-2.4.36
db-4.8.30.NC
Solaris-10u11


Hello list,

We've been running those LDAP versions for years and we have been pretty
pleased with it.

But then "they" went and added an automated test script, that adds some
records every 10 mins, confirms they are replicated all the way to the
frontends, then deletes the records.

This has started to cause trouble, in the last month or so. The errors are:

Sep 22 06:08:26 vmx02 slapd[14039]: [ID 960831 local4.debug] =>
bdb_idl_delete_key: c_get failed: DB_LOCK_DEADLOCK: Locker killed to
resolve a deadlock (-30994)

Sep 22 06:13:37 vmx02 last message repeated 36 times

Sep 22 06:13:44 vmx02 slapd[14039]: [ID 960831 local4.debug] =>
bdb_idl_delete_key: c_get failed: DB_LOCK_DEADLOCK: Locker killed to
resolve a deadlock (-30994)

Sep 22 06:20:17 vmx02 last message repeated 39 times

Until we restart slapd. Setup is:

prov (1 writer) -> ldapmaster -> ldapslave(s) -> frontend(s)
  -> ldapslave(s) -> frontend(s)
  -> frontend(s)

The problem happens the most on frontend servers, but occasionally on
ldapslaves, and twice now on ldapmaster. So we don't think it is syncrepl
related.

One answer would be to stop the 10min "ldap sync test" script of course,
but it would be nice to solve the actual problem.


slapd.conf, on slaves/frontend look like:


include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/nis.schema
include /usr/local/etc/openldap/company-schema/qmail.schema
include /usr/local/etc/openldap/company-schema/local.schema
include /usr/local/etc/openldap/company-schema/RADIUS-LDAPv3.schema
include /usr/local/etc/openldap/company-schema/AmavisdLDAP.schema
include /usr/local/etc/openldap/company-schema/analyse.schema
include /usr/local/etc/openldap/company-schema/formail.schema
include /usr/local/etc/openldap/company-schema/filter.schema
pidfile /usr/local/var/run/slapd.pid
argsfile/usr/local/var/run/slapd.args
loglevelsync
database monitor
access to dn.subtree="cn=Monitor"
   by dn="cn=admin,dc=company,dc=jp" read
   by * none
databasebdb
suffix  "dc=company,dc=jp"
rootdn  "cn=admin,dc=company,dc=jp"
lastmod on
checkpoint 128 15
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
cachesize 1
idlcachesize 15000
directory   /usr/local/var/openldap-data
index   objectClass eq
index   uid eq
index   uidNumber   eq
index   maileq
index   mailAlternateAddresspres,eq
index   deliveryModeeq
index   accountStatus   eq
index   gecos   eq
index   radiusGroupName eq
index   o   pres,eq
index   entryCSN,entryUUID  eq

dbconfig set_lk_detect DB_LOCK_DEFAULT
dbconfig set_lg_max 52428800
dbconfig set_cachesize 0 67108864 1
dbconfig set_flags db_log_autoremove
dbconfig set_lk_max_objects 1500
dbconfig set_lk_max_locks 1500
dbconfig set_lk_max_lockers 1500

syncrepl   rid=345
provider=ldap://ldapslave01
type=refreshAndPersist
interval=00:00:00:30
searchbase="dc=company,dc=jp"
filter="(objectClass=*)"
attrs="*,+"
scope=sub
schemachecking=off
bindmethod=simple

binddn="uid=replicate,o=companyserver.jp,ou=admin,dc=company,dc=jp"
credentials=""
retry="60 10 300 +"

updateref   ldap://ldapmaster01


-- 
Jorgen Lundman   | 
Unix Administrator   | +81 (0)90-5578-8500
Shibuya-ku, Tokyo| Japan

Re: Instructions for Open LDAP library?

[Martin van den Nieuwelaar]

On 19/09/17 08:00, John Lewis wrote:

On Mon, 2017-09-18 at 14:31 +1200, Martin van den Nieuwelaar wrote:

Hi People,

I'm writing an application using Qt and wish to use the openldap
library
within my program to query an LDAP server.  I have been searching
for
instructions on using the library from a client point of view but
have
not been successful.  I tried using the man pages and I think I'm
part
way there but have reached an impasse on the correct way (or any way
at
all for that matter) to extract the results from an LDAPMessage
*.  I
have an example search working using the command line program
ldap_search, so the next thought is to look at the source for
ldap_search and see what calls it makes to figure things out.  This
somehow seems like the wrong way to be going about things however.

Is there something equivalent for openldap to the documentation for
libcurl, https://ec.haxx.se/libcurl-easyhandle.html ?  If there is
that
would be brilliant.

The libcurl library supports LDAP. Howard Chu even wrote a new LDAP
implementation for it back in 2010 to make it fully asynchronous. Is
there a good reason not to use it?

Thanks for the suggestion.  I hadn't even thought to see if libcurl 
could perform LDAP queries, but indeed it looks like it can so this is 
definitely worth looking into.


In the interim I did get my Qt program working, not by using the 
openldap library calls for which I'm still none the wiser but by using 
Qt's very capable and well documented QProcess class for running 
external programs and calling the ldapsearch command line program.


Thanks again for the reply.

--
R A Ward Ltd. | We take the privacy of our customers seriously.
Christchurch  | All sensitive E-Mail attachments MUST be encrypted.
New Zealand

Re: Olc deployment vs slapd.conf based deployment

[Peter]

olcSchemaFile: {0}include: file://$ABS_SCHEMADIR/core.ldif
olcSchemaFile: {1}include: file://$ABS_SCHEMADIR/cosine.ldif
olcSchemaFile: {2}include: file://$ABS_SCHEMADIR/inetorgperson.ldif 


That is a very nice proposal, it would sort of give us the good things 
of both worlds.


IMHO schema is the only thing where cn=config makes life harder than 
slapd.conf.


Being a long time lurker on this list it is fun to see that although 
same subjects like config alternatives,  turn up again and again, the 
arguments and solution proposals at least sometimes do progress.


Cheers

Peter



Am 15.09.2017 um 20:33 schrieb Quanah Gibson-Mount:
--On Friday, September 15, 2017 12:24 PM -0700 Ryan Tandy 
 wrote:




There was some talk, either in IRC or on -devel, of creating a way for
cn=config to reference schema files (possibly LDIF) on disk rather than
importing them into the config database. I think that would be an
improvement. Importing schemas into cn=config is cool - especially if 
you

want to replicate the config - but I'm not sure it's a good default.


Since ordering is mandatory, it would be nice if you could just do 
something like:


olcSchemaFile: {0}include: file://$ABS_SCHEMADIR/core.ldif
olcSchemaFile: {1}include: file://$ABS_SCHEMADIR/cosine.ldif
olcSchemaFile: {2}include: file://$ABS_SCHEMADIR/inetorgperson.ldif


etc.  Then you could change the schema files on disk, and cn=config 
would just load them in when it started.  It'd certainly make the 
behavior analagous to slapd.conf, and allow for easier rollback/testing.


--Quanah


--

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





--
___

Peter Gietz (CEO)
DAASI International GmbH   phone: +49 7071 407109-0
Europaplatz 3  Fax:   +49 7071 407109-9
D-72072 Tübingen   mail:  peter.gi...@daasi.de
GermanyWeb:   www.daasi.de

DAASI International GmbH, Tübingen
Geschäftsführer Peter Gietz, Amtsgericht Stuttgart HRB 382175

Directory Applications for Advanced Security and Information Management
___

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

[Robert Heller]

At Fri, 22 Sep 2017 10:47:29 +0200 Dieter =?UTF-8?B?S2zDvG50ZXI=?= 
 wrote:

> 
> Am Thu, 21 Sep 2017 10:01:48 -0400 (EDT)
> schrieb Robert Heller :
> [...]
> 
> > Sep 21 09:50:01 c764guest.deepsoft.com slapd[17535]: <=3D acl_mask: [1]
> > mask: write(=3Dwrscxd) Sep 21 09:50:01 c764guest.deepsoft.com
> > slapd[17535]: =3D> slap_access_allowed: search access granted by
> > write(=3Dwrscxd) Sep 21 09:50:01 c764guest.deepsoft.com slapd[17535]:
> > =3D> access_allowed: search access granted by write(=3Dwrscxd) Sep 21
> > 09:50:01 c764guest.deepsoft.com slapd[17535]: conn=3D1000 op=3D11 SEARCH
> > RESULT tag=3D101 err=3D0 nentries=3D0 text=3D
> [...]
> 
> You should find out why operation 11 results in 0 entries.

Operation 11 *seems* to be fetching the uid, using self, which has write 
access, which implies read access, which seems to work just fine, using 
ldapsearch from the command line:

[heller@c764guest ~]$ ldapsearch -D uid=test2user,ou=People,dc=deepsoft,dc=com 
-W -LLL '(uid=test2user)' uid
Enter LDAP Password: 
dn: uid=test2user,ou=People,dc=deepsoft,dc=com
uid: test2user

I don't know what is going on here.

Also: there is a "TLS negotiation failure" failure. I have not even enabled
TLS and/or ssl. At least I don't think I have it enabled. I *think* I have it
disabled everywhere. I want to test things without messing with creating a SSL
Cert (none of this is anything close to a public facing production
environment). I have ldap_id_use_start_tls set to false in /etc/sssd/sssd.conf 
-- is there some other option I need to set?

Is there any change that selinux is having any effect?  Selinux can be pesky 
at times.

> 
> -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: Olc deployment vs slapd.conf based deployment

[Howard Chu]

Frank Swasey wrote:

My take away from this lengthy discussion is the following:

1) cn=config is not ready for "make; make test; make install" level of 
upgrade.  Until it is, it is not usable in a production environment.


Nobody is denying that more work needs to be done. Where did you ever get that 
impression?



2) As usual, the OpenLDAP developers are saying "my way or the highway".


This is totally ignorant and off base. Crazy suggestions like "OpenLDAP should 
change its license to suit my needs" are completely ludicrous. Nobody within 
the OpenLDAP Project has the authority to do that. There's no *my way* here, 
there's simply reality vs delusion.


--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: Olc deployment vs slapd.conf based deployment

[Frank Swasey]

My take away from this lengthy discussion is the following:

1) cn=config is not ready for "make; make test; make install" level of 
upgrade.  Until it is, it is not usable in a production environment.


2) As usual, the OpenLDAP developers are saying "my way or the highway". 
As a Proof of Concept, OpenLDAP can do that.  As a production software, 
that's the way to become something people used to use.


--
Frank Swasey| http://www.uvm.edu/~fcs
Sr Systems Administrator| Always remember: You are UNIQUE,
University of Vermont   |just like everyone else.
  "I am not young enough to know everything." - Oscar Wilde (1854-1900)

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

[Dieter Klünter]

Am Thu, 21 Sep 2017 10:01:48 -0400 (EDT)
schrieb Robert Heller :
[...]

> Sep 21 09:50:01 c764guest.deepsoft.com slapd[17535]: <= acl_mask: [1]
> mask: write(=wrscxd) Sep 21 09:50:01 c764guest.deepsoft.com
> slapd[17535]: => slap_access_allowed: search access granted by
> write(=wrscxd) Sep 21 09:50:01 c764guest.deepsoft.com slapd[17535]:
> => access_allowed: search access granted by write(=wrscxd) Sep 21
> 09:50:01 c764guest.deepsoft.com slapd[17535]: conn=1000 op=11 SEARCH
> RESULT tag=101 err=0 nentries=0 text=
[...]

You should find out why operation 11 results in 0 entries.

-Dieter

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