openldap-technical

openldap-technical@openldap.org

7 participants
9864 discussions

Re: Logging with LDIF format style
by Sylvain 18 Nov '16

18 Nov '16

Oh yes, why not ? slapo-auditlog overlay seems to be nice too ;) Thanks, Sylvain 2016-11-17 18:47 GMT+01:00 Quanah Gibson-Mount <quanah(a)symas.com>: > --On Thursday, November 17, 2016 3:27 PM +0100 Sylvain < > debian.roxx(a)gmail.com> wrote: > > >> >> >> Hi ! >> >> Is there any way (overlay, script, patch, ...) to have OpenLDAP log with >> LDIF format style for easier debugging ? >> > > man slapo-accesslog ? > > DESCRIPTION > The Access Logging overlay can be used to record all accesses > to a > given backend database on another database. This allows all of > the > activity on a given database to be reviewed using arbitrary > LDAP > queries, instead of just logging to local flat text files. > Configuration options are available for selecting a subset of > operation > types to log, and to automatically prune older log records from > the > logging database. Log records are stored with audit schema (see > below) > to assure their readability whether viewed as LDIF or in raw form. > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

1 0

Re: Logging with LDIF format style
by Quanah Gibson-Mount 17 Nov '16

17 Nov '16

--On Thursday, November 17, 2016 3:27 PM +0100 Sylvain <debian.roxx(a)gmail.com> wrote: > > > > Hi ! > > Is there any way (overlay, script, patch, ...) to have OpenLDAP log with > LDIF format style for easier debugging ? man slapo-accesslog ? DESCRIPTION The Access Logging overlay can be used to record all accesses to a given backend database on another database. This allows all of the activity on a given database to be reviewed using arbitrary LDAP queries, instead of just logging to local flat text files. Configuration options are available for selecting a subset of operation types to log, and to automatically prune older log records from the logging database. Log records are stored with audit schema (see below) to assure their readability whether viewed as LDIF or in raw form. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Logging with LDIF format style
by Sylvain 17 Nov '16

17 Nov '16

Hi ! Is there any way (overlay, script, patch, ...) to have OpenLDAP log with LDIF format style for easier debugging ? Sylvain

1 0

Re: PROXIED attributeDescription "<foo>" inserted
by Howard Chu 11 Nov '16

11 Nov '16

btb(a)bitrate.net wrote: > recently i noticed these entries in slapcat output: > >> slapcat -F '/var/lib/ldap/config' -b 'cn=config' -H 'ldap:///cn=config??base' > 5824aae9 PROXIED attributeDescription "OU" inserted. > 5824aae9 PROXIED attributeDescription "DC" inserted. > dn: cn=config > objectClass: olcGlobal > cn: config > olcArgsFile: /var/run/slapd/slapd.args > olcConnMaxPending: 1000 > olcConnMaxPendingAuth: 1000 > olcGentleHUP: FALSE > olcIdleTimeout: 0 > olcPidFile: /var/run/slapd/slapd.pid > olcReadOnly: FALSE > olcReverseLookup: FALSE > olcSaslSecProps: noanonymous > olcTLSCACertificateFile: /etc/pki/trusted_root_authorities/example_corp_ > root_ca-cert.pem > olcTLSCertificateFile: /etc/ldap/pki/dsa1.example.net-cert.pem > olcTLSCertificateKeyFile: /etc/ldap/pki/dsa1.example.net-key.pem > olcTLSVerifyClient: never > olcAttributeTypes: {0}( 2.5.4.11 NAME ( 'ou' 'organizationalUnitName' ) > DESC ' > RFC2256: organizational unit this object belongs to' SUP name ) > olcAttributeTypes: {1}( 0.9.2342.19200300.100.1.25 NAME ( 'dc' > 'domainComponen > t' ) DESC 'RFC1274/2247: domain component' EQUALITY caseIgnoreIA5Match > SUBSTR > caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 > SINGLE-VAL > UE ) > structuralObjectClass: olcGlobal > entryUUID: 65ca1166-8375-102d-9386-497a4dd6665c > creatorsName: cn=config > createTimestamp: 20090130235646Z > contextCSN: 20120805020044.490450Z#000000#000#000000 > contextCSN: 20120317151625.496021Z#000000#001#000000 > olcLogLevel: stats sync > entryCSN: 20161110171407.752985Z#000000#000#000000 > modifiersName: uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=net > modifyTimestamp: 20161110171407Z > > in the past, i'd seen this, due to ou and dc attributes being referenced > before their schema elements were loaded. so, as can be seen above, i > moved the declarations of these attributes to the beginning of the config, > so to speak, at which point, the messages were no longer printed. > > but now they're back, and i'm curious why. there is very little parsed > prior to the attribute declarations, i believe? what am i missing? > presumably, it's as it was before, and something is referencing these attributes, but how can i determine what? It is the cn=config entry itself. The LDIF is parsed into Attributes before the Attributes themselves are processed by the config engine. In this case you can either ignore the message, since it's harmless, or change your admin DNs to avoid using non-core attributes. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

PROXIED attributeDescription "<foo>" inserted
by btb＠bitrate.net 11 Nov '16

11 Nov '16

recently i noticed these entries in slapcat output: > slapcat -F '/var/lib/ldap/config' -b 'cn=config' -H 'ldap:///cn=config??base' 5824aae9 PROXIED attributeDescription "OU" inserted. 5824aae9 PROXIED attributeDescription "DC" inserted. dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcConnMaxPending: 1000 olcConnMaxPendingAuth: 1000 olcGentleHUP: FALSE olcIdleTimeout: 0 olcPidFile: /var/run/slapd/slapd.pid olcReadOnly: FALSE olcReverseLookup: FALSE olcSaslSecProps: noanonymous olcTLSCACertificateFile: /etc/pki/trusted_root_authorities/example_corp_ root_ca-cert.pem olcTLSCertificateFile: /etc/ldap/pki/dsa1.example.net-cert.pem olcTLSCertificateKeyFile: /etc/ldap/pki/dsa1.example.net-key.pem olcTLSVerifyClient: never olcAttributeTypes: {0}( 2.5.4.11 NAME ( 'ou' 'organizationalUnitName' ) DESC ' RFC2256: organizational unit this object belongs to' SUP name ) olcAttributeTypes: {1}( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domainComponen t' ) DESC 'RFC1274/2247: domain component' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VAL UE ) structuralObjectClass: olcGlobal entryUUID: 65ca1166-8375-102d-9386-497a4dd6665c creatorsName: cn=config createTimestamp: 20090130235646Z contextCSN: 20120805020044.490450Z#000000#000#000000 contextCSN: 20120317151625.496021Z#000000#001#000000 olcLogLevel: stats sync entryCSN: 20161110171407.752985Z#000000#000#000000 modifiersName: uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=net modifyTimestamp: 20161110171407Z in the past, i'd seen this, due to ou and dc attributes being referenced before their schema elements were loaded. so, as can be seen above, i moved the declarations of these attributes to the beginning of the config, so to speak, at which point, the messages were no longer printed. but now they're back, and i'm curious why. there is very little parsed prior to the attribute declarations, i believe? what am i missing? presumably, it's as it was before, and something is referencing these attributes, but how can i determine what? -ben

1 0

Re: delta-synrepl consumer randomly delete objects
by Quanah Gibson-Mount 10 Nov '16

10 Nov '16

--On Thursday, November 10, 2016 1:06 PM +0100 Raffael Sahli <public(a)raffaelsahli.com> wrote: > > On 11/03/2016 04:02 PM, Quanah Gibson-Mount wrote: >> >> If your pulling down an empty replica from a master, then that is not >> using delta-sycnrepl at all. I've never had luck with doing that. I >> only do a slapcat from the master then slapadd to the replica, and >> start from there. > No difference, soon after the whole thing was added with slapadd and > restarted slapd it > started to remove most objects again. Again, your log snippet leaves out /why/ it fell back to syncrepl from delta-syncrepl. That's the first thing you need to identify. Something's clearly broken, either in your data or elsewhere, for it to fall back immediately after a slapadd. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: password sync issues
by Arun Gupta 10 Nov '16

10 Nov '16

Hi Anirudh and all, As might be you have seen that I have 2 tree for single user (one have unix password and another have samba password for same user) which have following DN 1. dn: uid=2011150,ou=User,dc=acer,dc=in 2. dn: uid=test1,ou=samba,dc=acer,dc=in How can be use ldappasswd so that password will be sync in both different different trees. Regards, Arun > > Message: 1 > Date: Fri, 4 Nov 2016 16:30:56 +0530 > From: Anirudh Malhotra <8zero2ops(a)gmail.com> > To: Arun Gupta <arung(a)cdac.in> > Cc: openldap-technical(a)openldap.org > Subject: Re: password sync issues > Message-ID: > <CAK7iNp4kJEs0Db7x04cwD5dkq7UY_jDB-ofT8PWsBQv1uig0tQ(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi, > > Running the command:- > > ldappasswd -H ldap://server_domain_or_IP -x -D "user's_dn" -w old_passwd -a >> old_passwd -s new_passwd > > > In shell of openldap server will change the password of "user dn". > > Hope this helps! > > BR, > Anirudh Malhotra > Mail: 8zero2.in(a)gmail.com > Facebook: www.facebook.com/8zero2 > Twitter: @8zero2_in > Blog: blog.8zero2.in > > On Fri, Nov 4, 2016 at 9:57 AM, Arun Gupta <arung(a)cdac.in> wrote: > >> Hi, >> >> Thanks Anirudh.. for response, as I am newbie in openldap, please let me >> know any already avaliabe script or some tutorial for the same. >> >> Regards, >> Arun >> >> >> and I think it may be also possible if On Thu, 3 Nov 2016, Anirudh >> Malhotra wrote: >> >> Hi, >>> >>> You can write a custom script which whenever the password is set in samba >>> it >>> sets it for the other tree as well, And you can attach this to the >>> password >>> changing app also. >>> >>> BR, >>> Anirudh Malhotra >>> Mail: 8zero2.in(a)gmail.com >>> Facebook: www.facebook.com/8zero2 >>> Twitter: @8zero2_in >>> Blog: blog.8zero2.in >>> >>> On Tue, Nov 1, 2016 at 6:49 PM, Arun Gupta <arung(a)cdac.in> wrote: >>> Hi, >>> >>> I have configured 2 ldap tree, one for unix account (ou=User) >>> (below is sample ldif) >>> >>> >>> dn: uid=2011150,ou=User,dc=acer,dc=in >>> empID: 2011150 >>> username: test1 >>> cn: test1 >>> centre: PN >>> objectClass: inetOrgPerson >>> objectClass: posixAccount >>> objectClass: top >>> objectClass: shadowAccount >>> oldempid: 1150 >>> mail: test1(a)acer.in >>> givenName: test1 >>> uid: 2011150 >>> shadowLastChange: 15590 >>> loginShell: /bin/bash >>> uidNumber: 11150 >>> gidNumber: 11150 >>> homeDirectory: /mbox4.2/test1 >>> userPassword: {SHA}1SrgdEGUPa/U6KM43Kq9xTgnI7A= >>> >>> >>> and another for samba tree (ou=samba) - (below is sample tree) >>> >>> dn: uid=test1,ou=samba,dc=acer,dc=in >>> uid: test1 >>> sambaSID: S-1-5-21-4079184197-2446238136-3299756537-1005 >>> displayName: test1 >>> sambaAcctFlags: [UX ] >>> objectClass: sambaSamAccount >>> objectClass: account >>> sambaLMPassword: C2F63206FC9CF08A1AA818381E4E281B >>> sambaNTPassword: 0242A7FEC5CD294F916925766089E573 >>> >>> and I am able to authenticate with samba configuration. But I am >>> not able to find out how the password will sync means if user >>> change his password then how NT password will reflect (here two >>> different tree). Is it possible to sync, if yes please please >>> help me out. >>> >>> -- >>> >>> Thanks & Regards, >>> >>> Arun Kumar Gupta >>> >> >> >

1 0

Re: delta-synrepl consumer randomly delete objects
by Quanah Gibson-Mount 10 Nov '16

10 Nov '16

--On Thursday, November 03, 2016 1:16 PM +0100 Raffael Sahli <public(a)raffaelsahli.com> wrote: > I have no clue what changed that we have now such problems. > What else is related to (delta)-syncrepl? time? > Could it be wrong/strange slapd configurations? (acl, limits, > syncrepl,...) But actually not much changed and the sync does work for > some time... "time" must be in sync between all nodes, that's well documented. If your pulling down an empty replica from a master, then that is not using delta-sycnrepl at all. I've never had luck with doing that. I only do a slapcat from the master then slapadd to the replica, and start from there. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

4 4

Re: OpenSSL 1.1 Support ?
by Quanah Gibson-Mount 10 Nov '16

10 Nov '16

--On Wednesday, November 09, 2016 3:58 PM -0800 Norm Green <norm.green(a)gemtalksystems.com> wrote: > I could certainly do that. Would that get us closer to a new release of > OpenLDAP? It would make it more likely that OpenSSL 1.1.0 support makes the next release. I've already been working on the 2.4.45 release... Of course, if you check the commit logs, you'd see that. ;) Currently one blocking issue that needs resolution, and some triage on some of the open items. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: OpenSSL 1.1 Support ?
by Quanah Gibson-Mount 09 Nov '16

09 Nov '16

--On Wednesday, November 09, 2016 2:24 PM -0800 Norm Green <norm.green(a)gemtalksystems.com> wrote: > I've asked before and got nothing but crickets so I'm asking again. > > Any idea in what timeframe we will have a release of OpenLDAP that > supports OpenSSL 1.1? 2016? 2017? 2018? Anyone? Bueller? Bueller? Is > this thing even on? Feel free to backport the commits for ITS#8353 and report back on how they work for you. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical