Hello,
Based on this article: http://www.rexconsulting.net/ldap-protocol-uidNumber.html. I am trying to increment 'uidNumber'. For doing that, I am using this LDIF file:
--------------- autoinc.ldif ---------------------------
dn: cn=uidNext,dc=example,dc=com changetype: modify delete:uidNumber uidNumber: 610 - add: uidNumber uidNumber: 611
------------------- EOF --------------------------------
And this command; but produce an error:
$ ldapadd -x -D "cn=Admin,dc=example,dc=com" -wsecret -f ./autoinc.ldif
adding new entry "cn=uidNext,dc=example,dc=com" ldapadd: Undefined attribute type (17) additional info: add: attribute type undefined
$
This is the definition of the uidNext objectClass:
---------------------------------------------- objectClass ( 1.3.6.1.4.1.4203.666.599 NAME 'uidNext' SUP top STRUCTURAL MUST ( cn $ uidNumber ) ) ----------------------------------------------
Any idea of what I am doing wrong here?
Thanks in advance. Pablo.
Am Wed, 21 Dec 2011 09:37:10 -0300 schrieb Pablo paa.listas@gmail.com:
Hello,
Based on this article:
http://www.rexconsulting.net/ldap-protocol-uidNumber.html. I am trying to increment 'uidNumber'. For doing that, I am using this LDIF file:
--------------- autoinc.ldif ---------------------------
dn: cn=uidNext,dc=example,dc=com changetype: modify delete:uidNumber uidNumber: 610
add: uidNumber uidNumber: 611
------------------- EOF --------------------------------
And this command; but produce an error:
$ ldapadd -x -D "cn=Admin,dc=example,dc=com" -wsecret -f ./autoinc.ldif
adding new entry "cn=uidNext,dc=example,dc=com" ldapadd: Undefined attribute type (17) additional info: add: attribute type undefined
Use ldapmodify instead of ldapadd, and use replace instead of delete.
dn: cn=uidNext,dc=example,dc=com changetype: modify replace:uidNumber uidNumber: 611
-Dieter
Thank you very much. It works well now!
Pablo.
On 12/21/2011 10:04 AM, Dieter Klünter wrote:
Am Wed, 21 Dec 2011 09:37:10 -0300 schrieb Pablopaa.listas@gmail.com:
Hello,
Based on this article:
http://www.rexconsulting.net/ldap-protocol-uidNumber.html. I am trying to increment 'uidNumber'. For doing that, I am using this LDIF file:
--------------- autoinc.ldif ---------------------------
dn: cn=uidNext,dc=example,dc=com changetype: modify delete:uidNumber uidNumber: 610
add: uidNumber uidNumber: 611
------------------- EOF --------------------------------
And this command; but produce an error:
$ ldapadd -x -D "cn=Admin,dc=example,dc=com" -wsecret -f ./autoinc.ldif
adding new entry "cn=uidNext,dc=example,dc=com" ldapadd: Undefined attribute type (17) additional info: add: attribute type undefined
Use ldapmodify instead of ldapadd, and use replace instead of delete.
dn: cn=uidNext,dc=example,dc=com changetype: modify replace:uidNumber uidNumber: 611
-Dieter
According to http://tools.ietf.org/html/rfc4525 Yo can do simply this (with ldapmodify)
dn: cn=uidNext,dc=example,dc=com changetype: modify increment: uidNumber
On 12/21/2011 04:37 PM, Pablo wrote:
Hello,
Based on this article: http://www.rexconsulting.net/ldap-protocol-uidNumber.html. I am trying to increment 'uidNumber'. For doing that, I am using this LDIF file:
--------------- autoinc.ldif ---------------------------
dn: cn=uidNext,dc=example,dc=com changetype: modify delete:uidNumber uidNumber: 610
add: uidNumber uidNumber: 611
------------------- EOF --------------------------------
And this command; but produce an error:
$ ldapadd -x -D "cn=Admin,dc=example,dc=com" -wsecret -f ./autoinc.ldif
adding new entry "cn=uidNext,dc=example,dc=com" ldapadd: Undefined attribute type (17) additional info: add: attribute type undefined
$
This is the definition of the uidNext objectClass:
objectClass ( 1.3.6.1.4.1.4203.666.599 NAME 'uidNext' SUP top STRUCTURAL MUST ( cn $ uidNumber ) )
Any idea of what I am doing wrong here?
Thanks in advance. Pablo.
Thank you! This also works (with a minor change):
This is the LDIF that I use:
--- increment.ldif -------------------------------
dn: cn=uidNext,dc=example,dc=com changetype: modify increment:uidNumber uidNumber: 1 -
---- EOF ------------------------------------------
Pablo.
On 12/21/2011 10:27 AM, Andrey Konovalov wrote:
According to http://tools.ietf.org/html/rfc4525 Yo can do simply this (with ldapmodify)
dn: cn=uidNext,dc=example,dc=com changetype: modify increment: uidNumber
On 12/21/2011 04:37 PM, Pablo wrote:
Hello,
Based on this article: http://www.rexconsulting.net/ldap-protocol-uidNumber.html. I am trying to increment 'uidNumber'. For doing that, I am using this LDIF file:
--------------- autoinc.ldif ---------------------------
dn: cn=uidNext,dc=example,dc=com changetype: modify delete:uidNumber uidNumber: 610
add: uidNumber uidNumber: 611
------------------- EOF --------------------------------
And this command; but produce an error:
$ ldapadd -x -D "cn=Admin,dc=example,dc=com" -wsecret -f ./autoinc.ldif
adding new entry "cn=uidNext,dc=example,dc=com" ldapadd: Undefined attribute type (17) additional info: add: attribute type undefined
$
This is the definition of the uidNext objectClass:
objectClass ( 1.3.6.1.4.1.4203.666.599 NAME 'uidNext' SUP top STRUCTURAL MUST ( cn $ uidNumber ) )
Any idea of what I am doing wrong here?
Thanks in advance. Pablo.
I'm using TLS but would like to force clients to connect using TLS sans the loopback device or LDAP server itself.
I found this post from 2006 which suggests the following.
It doesn't work for me:
# first, make sure TLS or localhost
access to *
by tls_ssf=1 none break
by peername.ip="127.0.0.1" none break
by * none
# "real" ACL(s) go here, something like
access to *
by self write
by users read
by anonymous auth
My current real ACLS'
10.3.5.205 is the IP address of the system on the loopback interface. These settings still allow any system to connect without using TLS. If I change the line in the last ACL to "by users read" bthen i can't connect on the loopback anymore.. What am I doing wrong?
access to * by tls_ssf=1 none break by peername.ip="127.0.0.1" none break by peername.ip="10.3.5.205" none break by * none
access to dn.children="ou=people,dc=test,dc=lott" attrs=userPassword,sambaLMPassword,sambaNTPassword,shadowMax by self write by * auth break
access to dn.children="ou=people,dc=test,dc=lott" attrs=userPassword,sambaLMPassword,sambaNTPassword,shadowLastChange,sambaPwdMustChange,sambaPwdLastSet,pwdReset,pwdChangedTime,pwdPolicySubentry,shadowMax,mail,pwdAc countLockedTime,sambaKickoffTime,shadowExpire,shadowWarning,shadowFlag,sambaAcctFlags,sambaPasswordHistory,mail,givenName by dn.base="cn=root,dc=txcat,dc=lott" write by group.base="cn=infrastructure,ou=test,ou=groups,dc=test,dc=lott" write by dn.base="uid=ldapmgr,ou=people,dc=test,dc=lott" write by * read
access to dn.exact="cn=admins,ou=SUDOers,dc=test,dc=lott" attrs=sudoUser by dn.base="cn=root,dc=test,dc=lott" write by group.base="cn=infrastructure,ou=test,ou=groups,dc=test,dc=lott" write by * read
access to dn.subtree="ou=SUDOers,dc=test,dc=lott" attrs=sudoUser,sudoCommand,sudoHost,sudoOption by dn.base="cn=root,dc=test,dc=lott" write by group.base="cn=infrastructure,ou=test,ou=groups,dc=test,dc=lott" write by * read
access to * by dn.base="cn=root,dc=test,dc=lott" write by group.base="cn=infrastructure,ou=test,ou=groups,dc=test,dc=lott" read by group.base="cn=operations,ou=test,ou=groups,dc=test,dc=lott" read by dn.base="uid=ldapmgr,ou=people,dc=test,dc=lott" read by * read
--On Wednesday, December 21, 2011 4:11 PM -0500 Michael Starling mlstarling31@hotmail.com wrote:
My current real ACLS'
10.3.5.205 is the IP address of the system on the loopback interface. These settings still allow any system to connect without using TLS. If I change the line in the last ACL to "by users read" bthen i can't connect on the loopback anymore.. What am I doing wrong?
The example you used was bad to start with. I suggest reading the slapd.access man page, where the meaning of "break" is clearly described. The ACL as written will never do what you want. Based on how your ACLs are written, I'd suggest fully reading the entire slapd.access man page, as there's definitely some reworking of your ACLs that would make things more clearly defined in behavior as well for anyone else who may have to ever read them. ;)
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org