Alias in LDAP tree
by Bogdan Rudas
Hello all!
I have base prefix like 'dc=company,dc=com' and want to replace it with
'dc=newcompany,dc=biz'. I can't change base prefix everywhere at once due
to application release cycle, change management policy and so on.
It is hard to confirm that all our LDAP clients have aliases dereferencing
enabled and handles it right way. Are there any kind of 'request rewrite'
or 'transparent proxy' options?
Thank you.
--
Bogdan Rudas
Head of Minsk IT Support Department
Exadel Inc.
http://www.exadel.com/
E-mail: brudas(a)exadel.com
Skype ID: bogdan.rudas
--
CONFIDENTIALITY NOTICE: This email and files attached to it are
confidential. If you are not the intended recipient you are hereby notified
that using, copying, distributing or taking any action in reliance on the
contents of this information is strictly prohibited. If you have received
this email in error please notify the sender and delete this email.
4 years, 4 months
Re: Logging with LDIF format style
by Sylvain
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>
>
>
4 years, 4 months
Re: Logging with LDIF format style
by Quanah Gibson-Mount
--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>
4 years, 4 months
Logging with LDIF format style
by Sylvain
Hi !
Is there any way (overlay, script, patch, ...) to have OpenLDAP log with
LDIF format style for easier debugging ?
Sylvain
4 years, 4 months
Re: PROXIED attributeDescription "<foo>" inserted
by Howard Chu
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/
4 years, 5 months
PROXIED attributeDescription "<foo>" inserted
by btb＠bitrate.net
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
4 years, 5 months
Re: delta-synrepl consumer randomly delete objects
by Quanah Gibson-Mount
--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>
4 years, 5 months
Re: password sync issues
by Arun Gupta
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
>>>
>>
>>
>
4 years, 5 months
Re: delta-synrepl consumer randomly delete objects
by Quanah Gibson-Mount
--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 years, 5 months
Re: OpenSSL 1.1 Support ?
by Quanah Gibson-Mount
--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>
4 years, 5 months
