[Q] amendments to schemes existent
by Zeus Panchenko
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
5 years, 11 months
[ldapmodify] multiple entries of the same attibute
by richard lucassen
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/
5 years, 11 months
Re: Empty directory memory consumption
by Quanah Gibson-Mount
--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>
5 years, 11 months
Empty directory memory consumption
by Ivan Kurnosov
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
5 years, 11 months
Re: Admin roles by group membership per OU
by Quanah Gibson-Mount
--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>
5 years, 11 months
Re: Admin roles by group membership per OU
by Quanah Gibson-Mount
--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>
5 years, 11 months
Re: Admin roles by group membership per OU
by Quanah Gibson-Mount
--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>
5 years, 11 months
Re: Initialize ldap with mdb
by Howard Chu
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/
5 years, 11 months
Re: Admin roles by group membership per OU
by Quanah Gibson-Mount
--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>
5 years, 11 months
Ensure uniqueness over multiple attributes?
by Karsten Heymann
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
5 years, 11 months
