openldap-technical

openldap-technical@openldap.org

1 participants
9961 discussions

[Q] amendments to schemes existent
by Zeus Panchenko 18 Oct '17

18 Oct '17

greetings, I'm wondering of search possibility lack for some attributes my question is: is it correct/good/sane/e.t.c. to patch them this way? is there other way to get those attributes searchable? for example I have to patch some schemes like this: ---[ PATCH SAMPLES START ]--------------------------------------------------- --- dhcp.schema.orig 2017-08-25 13:14:26.691570000 +0300 +++ dhcp.schema 2017-08-25 13:15:56.558980000 +0300 @@ -14,6 +14,7 @@ attributetype ( 2.16.840.1.113719.1.203. NAME 'dhcpStatements' EQUALITY caseIgnoreIA5Match DESC 'Flexible storage for specific data depending on what object this exists in. Like conditional statements, server parameters, etc. This allows the standard to evolve without needing to adjust the schema.' + SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( 2.16.840.1.113719.1.203.4.4 @@ -38,6 +39,7 @@ attributetype ( 2.16.840.1.113719.1.203. NAME 'dhcpOption' EQUALITY caseIgnoreIA5Match DESC 'Encoded option values to be sent to clients. Each value represents a single option and contains (OptionTag, Length, OptionValue) encoded in the format used by DHCP.' + SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( 2.16.840.1.113719.1.203.4.8 @@ -199,6 +201,7 @@ attributetype ( 2.16.840.1.113719.1.203. attributetype ( 2.16.840.1.113719.1.203.4.34 NAME 'dhcpHWAddress' EQUALITY caseIgnoreIA5Match + SUBSTR caseIgnoreIA5SubstringsMatch DESC 'The clients hardware address that requested this IP address.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) --- ldapns.schema.orig 2014-09-15 23:47:56.135989000 +0300 +++ ldapns.schema 2015-02-15 23:50:53.714906292 +0200 @@ -1,6 +1,7 @@ attributetype ( 1.3.6.1.4.1.5322.17.2.1 NAME 'authorizedService' DESC 'IANA GSS-API authorized service name' EQUALITY caseIgnoreMatch + SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) objectclass ( 1.3.6.1.4.1.5322.17.1.1 NAME 'authorizedServiceObject' --- nis.schema.orig 2017-02-11 21:38:48.984906000 +0200 +++ nis.schema 2017-10-02 13:20:52.140691000 +0300 @@ -55,6 +55,7 @@ attributetype ( 1.3.6.1.1.1.1.2 NAME 'ge attributetype ( 1.3.6.1.1.1.1.3 NAME 'homeDirectory' DESC 'The absolute path to the home directory' EQUALITY caseExactIA5Match + SUBSTR caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) attributetype ( 1.3.6.1.1.1.1.4 NAME 'loginShell' ---[ PATCH SAMPLES STOP ]--------------------------------------------------- -- IT dpt., I.B.S. LLC

2 2

[ldapmodify] multiple entries of the same attibute
by richard lucassen 18 Oct '17

18 Oct '17

Hello list, I've got records with e.g. multiple mail: entries per dn: dn: cn=Joe Sixpack,ou=addressbook,dc=example,dc=org [ 8< 8< 8< snip objectclasses and other stuff 8< 8< 8< ] mail: user1(a)example.com mail: user2(a)example.com mail: user3(a)example.com GUI ldap clients like jxplorer are able to change a single mail: entry. Using "ldapmodify" I replace the first mail: entry, but it will delete the other mail: antries: ################################################################# change.diff file: dn: cn=Joe Sixpack,ou=addressbook,dc=example,dc=com changetype: modify replace: mail mail: otheruser(a)example.com - ################################################################# invoke: ldapmodify -x -D "cn=admin,dc=example,dc=com" -W -f change.ldif ################################################################# result: dn: cn=Joe Sixpack,ou=addressbook,dc=example,dc=org [ 8< 8< 8< snip objectclasses and other stuff 8< 8< 8< ] mail: otheruser(a)example.com ################################################################# Is there a way to tell ldapmodify to change just a particular entry? R. -- richard lucassen http://contact.xaq.nl/

4 6

Re: Empty directory memory consumption
by Quanah Gibson-Mount 18 Oct '17

18 Oct '17

--On Wednesday, October 18, 2017 5:04 PM +1300 Ivan Kurnosov <zerkms(a)zerkms.ru> wrote: > I have found, that just installed slapd (2.4.42+dfsg-2ubuntu3.2) on > ubuntu 16.04 consumes 730MB+ or resident memory (RSS). Only consumes 12 MB on my Ubuntu 16.04 system. But I don't use the build supplied by Ubuntu, I use my own. So I cannot say what Ubuntu's done to cause this. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Empty directory memory consumption
by Ivan Kurnosov 17 Oct '17

17 Oct '17

Hi, I have found, that just installed slapd (2.4.42+dfsg-2ubuntu3.2) on ubuntu 16.04 consumes 730MB+ or resident memory (RSS). It's an empty database (with `cn=config` only and whatever comes by default), is it supposed to consume so much memory? -- With best regards, Ivan Kurnosov

1 0

Re: Admin roles by group membership per OU
by Quanah Gibson-Mount 16 Oct '17

16 Oct '17

--On Monday, October 16, 2017 6:05 PM +0200 Ervin Hegedüs <airween(a)gmail.com> wrote: >> Hm, yes, that's correct. You'll need to do something like utilize by * >> break appropriately, or have multiple "access to userPassword" ACLs by >> group, then a catchall after that. > > I'm sorry - could you give me an example? Sure, no problem. :) One way to do it is to have an access line per subtree for those attributes, adding the group permission, with a final access to just userPassword itself limiting off all other access for anything outside of those trees: dn: olcDatabase={1}mdb,cn=config olcAccess: {0}to dn.children="ou=ABC Customer,dc=core,dc=hdt,dc=hu" attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read by group.exact="cn=groupabcadmin,ou=ABC Customer,dc=core,dc=hdt,dc=hu" write ... Addtional subtree ACLs with groups for userPassword/shadowLastChange access... olcAccess: {#}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read olcAccess: {#}to dn.children="ou=ABC Customer,dc=core,dc=hdt,dc=hu" by self write by group.exact="cn=groupabcadmin,ou=ABC Customer,dc=core,dc=hdt,dc=hu" write by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read olcAccess: {#}to * by * read The other option is to use "by * break", which tells slapd to continue processing additional rules. If you do that, you'll need to be particularly careful not to give access beyond what you intended. For that purpose, I added a final ACL rule that says zero access to userPassword prior to the "* by * read" ACL. dn: olcDatabase={1}mdb,cn=config olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read by * break olcAccess: {1}to dn.children="ou=ABC Customer,dc=core,dc=hdt,dc=hu" by self write by group.exact="cn=groupabcadmin,ou=ABC Customer,dc=core,dc=hdt,dc=hu" write by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read ... Additional subtree ACLs with groups ... olcAccess: {#} to userPassword by * none olcAccess: {#}to * by * read --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Admin roles by group membership per OU
by Quanah Gibson-Mount 16 Oct '17

16 Oct '17

--On Monday, October 16, 2017 5:55 PM +0200 Ervin Hegedüs <airween(a)gmail.com> wrote: > without any real testing, I'm afraid that the rule{0} gives the > write access to cn=groupabcadmin to _all_ db, not just the ou=ABC > Cumstomer subtree. > > Em I right? Hm, yes, that's correct. You'll need to do something like utilize by * break appropriately, or have multiple "access to userPassword" ACLs by group, then a catchall after that. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Admin roles by group membership per OU
by Quanah Gibson-Mount 16 Oct '17

16 Oct '17

--On Monday, October 16, 2017 11:45 AM +0200 Ervin Hegedüs <airween(a)gmail.com> wrote: > dn: olcDatabase={1}mdb,cn=config > olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by > anonymous auth by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read by * none > olcAccess: {1}to dn.children="ou=ABC Customer,dc=core,dc=hdt,dc=hu" by > self write by group.exact="cn=groupabcadmin,ou=ABC > Customer,dc=core,dc=hdt,dc=hu" write by > dn="uid=repuser,dc=core,dc=hdt,dc=hu" read olcAccess: {2}to * by * read > > > and a member of cn=groupabcadmin,ou=ABC Customer,dc=core,dc=hdt,dc=hu > can modify any attributes at any users under the ou=ABC Customer, > EXCEPT the userPassword - when I want to modify that, I get > permission error: That would be expected, given your ACLs. > How can I combine the attrs and group permissions? Should I list > all attributes in rule? You need to add a rule in the userPassword ACL to allow the group to write to the attribute. ACLs are processed in the order they are listed, and STOP at the first match. This is clearly documented in the slapd.access(5) man page. I.e., you would need: dn: olcDatabase={1}mdb,cn=config olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read by group.exact="cn=groupabcadmin,ou=ABC Customer,dc=core,dc=hdt,dc=hu" write olcAccess: {1}to dn.children="ou=ABC Customer,dc=core,dc=hdt,dc=hu" by self write by group.exact="cn=groupabcadmin,ou=ABC Customer,dc=core,dc=hdt,dc=hu" write by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read olcAccess: {2}to * by * read I would note again that "by * none" is implicit on any ACL, there's no need to specifically list it. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Initialize ldap with mdb
by Howard Chu 16 Oct '17

16 Oct '17

Michael Ströder wrote: > rammohan ganapavarapu wrote: >> You mean we can resize db any time? > > You can increase but *not decrease* maxsize later. > >> Wouldn't it be nice to have no max >> limit and grow db dynamically? > > Not possible with a memory-mapped DB. > Others can explain better in detail why. "No limit" is kind of a pointless phrase. The physical limit will always be the size of free space in your filesystem. Aside from that you can simply do what the documentation says - configure a huge size and let the DB grow dynamically within that size. Use 64TB or whatever, and forget about it. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: Admin roles by group membership per OU
by Quanah Gibson-Mount 16 Oct '17

16 Oct '17

--On Thursday, October 12, 2017 6:32 PM +0200 Ervin Hegedüs <airween(a)gmail.com> wrote: > rules: > > olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by > anonymous auth by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read by * none > olcAccess: {1}to dn.base="" by * read > olcAccess: {2}to dn.children="ou=ABC Customer,dc=core,dc=hdt,dc=hu" by > self write by group.exact="cn=groupabcadmin,ou=ABC > Customer,dc=core,dc=hdt,dc=hu" write by self write by anonymous auth by > dn="uid=repuser,dc=mycompany,dc=hu" read olcAccess: {3}to * by * read Your olcAccess: {1} value does not belong in your back-MDB database. That rule goes in the {-1}frontend,cn=config portion of the database as a global access rule. You probably also want a rule that reads: to dn.base="cn=subschema" by * read in the {-1}frontend,cn=config database as well. So for your back-mdb database, what one would expect is more something like: olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read olcAccess: {1}to dn.children="ou=ABC Customer,dc=core,dc=hdt,dc=hu" by self write by group.exact="cn=groupabcadmin,ou=ABC Customer,dc=core,dc=hdt,dc=hu" write by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read olcAccess: {2}to * by * read --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 2

Ensure uniqueness over multiple attributes?
by Karsten Heymann 13 Oct '17

13 Oct '17

Hi, does the unique overlay support checking multiple values for a single uniqueness check? Our clients can use emails in two attributes (think mail and mailAlias) and addresses have to be unique in regard to both fields, which means an address that is used in either of them cannot be used in any other of them. Is that possible? +Karsten

3 4

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical