Re: dhcp.schema attribute dhcpStatements value in filter
by Harry Jede
Zeus Panchenko wrote:
> hi,
>
> I configured my isc-dhcpd servers to work with openldap, all works
>
> now when I want to find dn for some definite MAC or IP, I am unable
> to do that
...
> I use filter:
> "(&(objectClass=dhcpHost)(dhcpStatements=fixed-address 10.0.0.222))"
>
> and receive empty result ...
Then you make a mistake :-(
$ ldapsearch -xLLL -H ldap://10.100.0.1 '(&(objectclass=dhcphost)
(dhcpStatements=fixed-address 10.100.0.102))' dn dhcpStatements
dn: cn=DEBIAN,ou=hosts,cn=DHCP Config,dc=europa,dc=xx
dhcpStatements: fixed-address 10.100.0.102
> it is the same picture for anything except dhcpStatements=* ...
>
> so, how is it correct to write the filter to get all objects with IP
> like 10.0.0.2* ?
By default, that's not possible. You need to modify the schema to make
this work.
step 1: find the dhcp schema
# ldapsearch -LLLY external -H ldapi:/// -b cn=schema,cn=config dn|grep
dhcp
dn: cn={7}dhcp,cn=schema,cn=config
step2: prepare a ldapmodify input file
# echo 'dn: cn={7}dhcp,cn=schema,cn=config' > /tmp/dhcp_s.ldif
# echo 'changetype: modify' >> /tmp/dhcp_s.ldif
# echo 'replace: olcAttributeTypes' >> /tmp/dhcp_s.ldif
step 3: retrieve the attributes from cn=config
# ldapsearch -LLLY external -H ldapi:/// -b cn=schema,cn=config
'cn={7}dhcp' olcAttributeTypes >> /tmp/dhcp_s.ldif
step 4.1: add Substring match to dhcpStatements with an editor
this I have added "SUBSTR caseIgnoreIA5SubstringsMatch" to
dhcpStatements. The result is:
olcAttributeTypes: {2}( 2.16.840.1.113719.1.203.4.3 NAME
'dhcpStatements' 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.' EQUALITY caseIgnoreIA5Match SUBSTR
caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
step 4.2 remove line number 4
in my config 'dn: cn={7}dhcp,cn=schema,cn=config'
step 5: update the server
# ldapmodify -Y external -H ldapi:/// -f /tmp/dhcp_s.ldif
step 6: be happy ;-)
$ ldapsearch -xLLL -H ldap://10.100.0.1 '(&(objectclass=dhcphost)
(dhcpStatements=fixed-address 10.100.0.*))' dn dhcpStatementsdn:
cn=ainf-01,ou=hosts,cn=DHCP Config,dc=europa,dc=xx
dhcpStatements: fixed-address 10.100.0.101
dn: cn=ainf-02,ou=hosts,cn=DHCP Config,dc=europa,dc=xx
dhcpStatements: fixed-address 10.100.0.103
dhcpStatements: filename "pxelinux.0"
dhcpStatements: next-server 10.100.0.1
dhcpStatements: broadcast-address 10.100.255.255
dn: cn=ainf-22,ou=hosts,cn=DHCP Config,dc=europa,dc=xx
dhcpStatements: fixed-address 10.100.0.104
dn: cn=DEBIAN,ou=hosts,cn=DHCP Config,dc=europa,dc=xx
dhcpStatements: fixed-address 10.100.0.102
hints:
1. modify an objectclass this way, will not work
2. an index on dhcpStatements is not required to make this work
perhaps good for performance reasons
3. try it first on a test server :-)
--
Harry Jede
7 years
Volunteers for Linuxtag 2014
by Dieter Klünter
Hi,
The OpenLDAP Project will be present at Linuxtag 2014 in Berlin
http://linuxtag.org/2014/
I am looking for volunteers to support the OpenLDAP booth. Prospective
volunteers may contact me.
-Dieter
--
Dieter Klünter | Systemberatung
http://sys4.de
GPG Key ID: E9ED159B
53°37'09,95"N
10°08'02,42"E
7 years
Re: Changing cert paths may cause openldap to stop
by Quanah Gibson-Mount
--On Thursday, March 27, 2014 1:52 PM +0200 Nick Milas
<nick(a)eurobjects.com> wrote:
> Hi,
>
> On 2.4.39 (CentOS 5.10 x86_64), I found that if I attempt to change
> certificate values but there is an error in a path, openldap stops.
>
> I would expect this should be avoided. Openldap should reject the
> modification and not stop.
>
> Running the modification below, it hungs; we press Ctrl-C (and we print a
> full backtrace), then we find slapd is stopped.
File an ITS.
--Quanah
--
Quanah Gibson-Mount
Architect - Server
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
7 years
Re: Problem after migration openldap 2.3.43 to 2.4.23 --> 32 No Such Object
by Jonas Kellens
On 01-04-14 10:53, Terje Trane wrote:
> On 01.04.2014 09:58, Jonas Kellens wrote:
>>
>> even if I add at the beginning of slapd.conf the following :
>>
>> access to * by *
>>
>> I still get no results with the user 'cn=U101001,ou=101001,dc=mydomain'
>>
>> I only get result with 'cn=Manager,dc=mydomain'
>>
>
> Remember that ACLs are "first match used".
>
> If a database does not have an ACL the global ACL applies.
>
> But if it has a database specific ACL, that one is read first when
> accessing that particular database, and the global then *only* used if
> there is no match (or a control keyword like break or continue is
> specified)
I posted it before, but will post it again. This is the database
specific ACL :
database bdb
suffix "dc=mydomain"
rootdn "cn=Manager,dc=mydomain"
rootpw {SSHA}blCAG/CNdFPY597Cf4Ssuj
access to attrs=userPassword
by * auth
access to dn.regex="ou=tbook[12345],ou=contacten,ou=101001,dc=mydomain"
attrs=children
by group.exact="cn=admins,ou=101001,dc=mydomain" write
by * none break
access to dn.one="ou=tbook1,ou=contacten,ou=101001,dc=mydomain"
by group.exact="cn=admins,ou=101001,dc=mydomain" write
by group.exact="cn=tbook1,ou=gebruikers,ou=101001,dc=mydomain" read
access to dn.one="ou=tbook2,ou=contacten,ou=101001,dc=mydomain"
by group.exact="cn=admins,ou=101001,dc=mydomain" write
by group.exact="cn=tbook2,ou=gebruikers,ou=101001,dc=mydomain" read
access to dn.one="ou=tbook3,ou=contacten,ou=101001,dc=mydomain"
by group.exact="cn=admins,ou=101001,dc=mydomain" write
by group.exact="cn=tbook3,ou=gebruikers,ou=101001,dc=mydomain" read
access to dn.one="ou=tbook4,ou=contacten,ou=101001,dc=mydomain"
by group.exact="cn=admins,ou=101001,dc=mydomain" write
by group.exact="cn=tbook4,ou=gebruikers,ou=101001,dc=mydomain" read
access to dn.one="ou=tbook5,ou=contacten,ou=101001,dc=mydomain"
by group.exact="cn=admins,ou=101001,dc=mydomain" write
by group.exact="cn=tbook5,ou=gebruikers,ou=101001,dc=mydomain" read
If user 'cn=U101001,ou=101001,dc=mydomain' is member of group
"cn=tbook1,ou=gebruikers,ou=101001,dc=mydomain", wouldn't you agree that
it should be able to read the entries in dn
"ou=tbook1,ou=contacten,ou=101001,dc=mydomain" ??
Kind regards,
Jonas.
7 years
RE: Slave not able to update master pwdFailureTime via chain.
by serpent6877
Anyone else have an answer for this?
Thanks,
Brad
-------- Original message --------
From: Brad dameron <serpent6877(a)hotmail.com>
Date:03/24/2014 8:36 AM (GMT-08:00)
To: Esteban Pereira <esteban.pereira(a)gepsit.fr>,openldap-technical(a)openldap.org
Subject: RE: Slave not able to update master pwdFailureTime via chain.
>From what I read I need to setup authzTo. But having problems understanding what I need to set in the slaps.conf and on the allowed user.
-------- Original message --------
From: Esteban Pereira <esteban.pereira(a)gepsit.fr>
Date:03/20/2014 10:55 AM (GMT-08:00)
To: Brad dameron <serpent6877(a)hotmail.com>,openldap-technical(a)openldap.org
Subject: Re: Slave not able to update master pwdFailureTime via chain.
I've never configured this kind of architecture, but as far as I know the
ppolicy, I think my first thought configuring this would have been to not
rebind as user because the attribute modified is an operational one which
need the manage right (not sure about that)
So I should have configured this with the replication user with manage
right and without rebinding as a user when chaining to the master.
Hope this help
On Thu, Mar 20, 2014 at 6:14 PM, Brad dameron <serpent6877(a)hotmail.com>wrote:
> I understand what you are saying. But this is what the
> ppolicy_forward_updates says:
>
> ppolicy_forward_updates
> Specify that policy state changes that result from Bind operations (such as recording
> failures, lockout, etc.) on a consumer should be forwarded to a master instead of
> being written directly into the consumer’s local database. This setting is only use‐
> ful on a replication consumer, and also requires the updateref setting and chain
> overlay to be appropriately configured.
>
> So when a password failure occurs "pwdFailureTime" it relays it to the master as the user doing a MOD
> from what I have seen in my logs. And thus the user doesn't have access to modify this attribute.
>
> Brad
>
>
>
> ------------------------------
> Date: Thu, 20 Mar 2014 12:13:02 +0100
> Subject: Re: Slave not able to update master pwdFailureTime via chain.
> From: esteban.pereira(a)gepsit.fr
> To: serpent6877(a)hotmail.com
> CC: openldap-technical(a)openldap.org
>
>
> Hi Brad,
>
> pwdFailureTime is an operational attribute, I don't think any user can
> modify it on any instance. May be you should try to modify it on the master
> to see if it comes from this assumption.
>
> Esteban
>
>
> On Thu, Mar 20, 2014 at 11:33 AM, Brad dameron <serpent6877(a)hotmail.com>wrote:
>
> OpenLDAP 2.4.23-26 on CentOS 5. I am trying to get the pwdFailureTime
> updated on the master when the slave recieves a password failure. Here is
> my config. It's pretty simple and basic. No TLS.
>
> Master:
>
> access to attrs=userPassword
> by group.exact="cn=ldapadmins,ou=Groups,dc=test,dc=net" write
> by dn.exact="cn=replication,dc=test,dc=net" read
> by self write
> by anonymous auth
> by * none
> access to *
> by group.exact="cn=ldapadmins,ou=Groups,dc=test,dc=net" write
> by dn.exact="cn=replication,dc=test,dc=net" write
> by self write
> by users read
> by anonymous read
> by * none
>
>
>
> Slave:
>
> overlay chain
> chain-uri ldap://172.16.0.84:389
> chain-rebind-as-user TRUE
> chain-idassert-bind bindmethod=simple
> binddn="cn=replication,dc=test,dc=net"
> credentials="MyPasswd"
> mode="self"
> chain-return-error TRUE
>
> # Password Policy
> overlay ppolicy
> ppolicy_default "cn=default,ou=Policies,dc=test,dc=net
> ppolicy_use_lockout
> ppolicy_forward_updates
>
>
> # Slave Replication
> syncrepl rid=101
> provider=ldap://172.16.0.84:389
> type=refreshAndPersist
> interval=00:00:01:00
> retry="60 10 300 +"
> searchbase="dc=test,dc=net"
> schemachecking=off
> bindmethod=simple
> binddn="cn=replication,dc=test,dc=net"
> credentials="MyPasswd"
> updateref "ldap://172.16.0.84:389"
>
>
>
> I see the connection on the master but it gives a permission error:
>
>
> Mar 20 09:47:46 LDAP-RADIUS-1 slapd[14288]: conn=1124 op=3 MOD
> dn="cn=testuser,ou=People,dc=test,dc=net"
> Mar 20 09:47:46 LDAP-RADIUS-1 slapd[14288]: conn=1124 op=3 MOD
> attr=pwdFailureTime
> Mar 20 09:47:46 LDAP-RADIUS-1 slapd[14288]: conn=1124 op=3 RESULT tag=103
> err=50 text=
>
>
> I read that you maybe need authzTo added to the binddn for the chain? Or
> is this only for TLS?
>
> I tried adding this ldif:
>
> dn: cn=replication,dc=test,dc=net
> changetype: modify
> add: authzTo
> authzTo: *
>
> And even set the:
>
> chain-idassert-authzFrom "*"
>
> in the chain. But it always gives me the error code 50 not enough
> permissions. I believe it is supposed to give access to the user to MOD the
> pwdFailureTime tribute knowing it is coming from a relay. But I can't find
> very specific docs on this or see what is wrong. Any help apreciated.
>
> Thanks,
> Brad
>
>
>
7 years
