Re: Loading LDAP schema files into cn=config
Nick Milas wrote:
On 3/7/2011 2:18 πμ, Howard Chu wrote:
We've been discussing this problem for quite a while. My current
thinking is that somehow we can use attribute options to help.
Visually it might be better to associate the option with the original
attribute, e.g.
olcAccess:
olcAccess;x-comment:
This would require defining a new (and strange) type of attribute
option though, since the value with the option has no relation
(syntactically) to the original attribute type.
Thank you for this discussion.
I think it might not matter which of the two is the implementation, as
long as the description (either olcWhatever;x-comment: or
description;x-olcWhatever:) is available and multi-valued for each and
every attribute and if it can easily stay together with the entry
concerned, and easily displayed in relation to it as well (yes, visual
behavior for comments is important!). For example, for olcAccess,
modifying an example from:
http://www.openldap.org/doc/admin24/access-control.html, if we create
the attribute values:
olcAccess: to attrs=member,entry
by dnattr=member selfwrite
description;x-olcAccess: (0) Access rules for attrs: member,entry
description;x-olcAccess: (0) Entered by Nick on 7/12/2012
olcAccess: to dn.children=dc=example,dc=com
by * search
description;x-olcAccess: (1) Allow search on children of example.com
description;x-olcAccess: (1) Entered by Nick on 7/12/2012
olcAccess: to dn.children=dc=com
by * read
description;x-olcAccess: (2) Allow only read on children of com
description;x-olcAccess: (2) Entered by Nick on 7/12/2012
Interleaved values such as above may never be returned by an LDAP Search
operation. Whether it's desirable for a client to reorganize the data to
display as such, I have no opinion.
I note that the accesslog overlay already allows you to track the history of
individual changes to attributes, so recording an Entered by name on
date comment seems both redundant and vague.
we should be able to easily display:
olcAccess: {0}to attrs=member,entry
by dnattr=member selfwrite
description;x-olcAccess: (0) Access rules for attrs: member,entry
description;x-olcAccess: (0) Entered by Nick on 7/12/2012
olcAccess: {1}to dn.children=dc=example,dc=com
by * search
description;x-olcAccess: (1) Allow search on children of example.com
description;x-olcAccess: (1) Entered by Nick on 7/12/2012
olcAccess: {2}to dn.children=dc=com
by * read
description;x-olcAccess: (2) Allow only read on children of com
description;x-olcAccess: (2) Entered by Nick on 7/12/2012
I assume, all the above should be easier and more intuitive to achieve
using the olcAccess;x-comment: approach (even if it's more difficult -
as you say - to implement).
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Status of support for draft-wahl-ldap-session
HI! It seems there is support for draft-wahl-ldap-session in OpenLDAP's source since 2007 but it seems not to be enabled in a default build. Is it sufficient to compile with -DSLAP_CONTROL_X_SESSION_TRACKING or do I also have to use -DLDAP_DEVEL (because of ifdef in ldap.h). The latter does not work with 2.4.26... Should I file an ITS for it? Ciao, Michael.
problem with pwdReset
I have a problem with OpenLDAP 2.4.24 and ApacheDirectoryStudio 1.5.3. I connect to OpenLDAP with a usual user account for who pwdReset is set to TRUE. And I have the following default password policy: dn: cn=default,ou=policies,dc=. cn: default objectClass: top objectClass: person objectClass: pwdPolicy pwdAllowUserChange: TRUE pwdAttribute: userPassword pwdCheckQuality: 2 pwdExpireWarning: 0 pwdFailureCountInterval: 0 pwdGraceAuthNLimit: 0 pwdInHistory: 0 pwdMaxAge: 0 pwdMaxFailure: 0 pwdMinAge: 0 pwdMinLength: 8 pwdMustChange: TRUE pwdSafeModify: FALSE sn: policy When opening the connection, I see the following messages in the ApacheDirectoryStudio logs window: #!SEARCH RESULT DONE (95) ERROR #!CONNECTION ldap://rhvtq:389 #!DATE 2011-07-04T13:55:42.026 #!ERROR [LDAP: error code 50 - Operations are restricted to bind/unbind/abandon/StartTLS/modify password] # numEntries : 0 I can see the Root DSE entry and I can not browse the DIT, but I don't have any popup to explain me that the user account I use to connect must change his password. In the OpenLDAP access log, I see the following: SRCH base="" scope=0 deref=3 filter="(objectClass=*)" Jul 4 13:55:42 rhvtq slapd[19581]: conn=1075 op=1 SRCH attr=subschemaSubentry Jul 4 13:55:42 rhvtq slapd[19581]: conn=1075 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= When testing against a Sun Directory Server 6 with the same data and the same password policy, I get a popup window on the client side, with the following error, when I try to see the root DSE entry : [LDAP: error code 53 - Password was reset and must be changed.] In the Sun DS access log, I have the following: SRCH base="" scope=0 filter="(objectClass=*)" attrs="subschemaSubentry" [04/Jul/2011:14:17:53 +0200] conn=51 op=1 msgId=2 - RESULT err=53 tag=101 nentries=0 etime=0, Password was reset and must be changed. Of course, in both cases, the access control rules are the same and allow access to the root DSE entry at least. Also, when testing against OpenLDAP with an ldapsearch client with the "-e ppolicy " option, I get the following result: ldap_bind: Success (0); Password must be changed Insufficient access (50) Additional information: Operations are restricted to bind/unbind/abandon/StartTLS/modify password Is there a way I can configure OpenLDAP or my data to get the same behaviour with ApacheDirectoryStudio ? That is, I'd like to be clearly notified the user password must be changed. Since I get a 50 error code, has something to be changed in the OpenLDAP access control rules ? If you think it's a client side problem, when using my own custom client applications, what request(s) must be sent to OpenLDAP ?
Re: Loading LDAP schema files into cn=config
On 04/07/2011 00:32, Nick Milas wrote:
olcAccess: to attrs=member,entry
by dnattr=member selfwrite
description;x-olcAccess: (0) Access rules for attrs: member,entry
description;x-olcAccess: (0) Entered by Nick on 7/12/2012
olcAccess: to dn.children=dc=example,dc=com
by * search
description;x-olcAccess: (1) Allow search on children of example.com
description;x-olcAccess: (1) Entered by Nick on 7/12/2012
olcAccess: to dn.children=dc=com
by * read
description;x-olcAccess: (2) Allow only read on children of com
description;x-olcAccess: (2) Entered by Nick on 7/12/2012
we should be able to easily display:
olcAccess: {0}to attrs=member,entry
by dnattr=member selfwrite
description;x-olcAccess: (0) Access rules for attrs: member,entry
description;x-olcAccess: (0) Entered by Nick on 7/12/2012
olcAccess: {1}to dn.children=dc=example,dc=com
by * search
description;x-olcAccess: (1) Allow search on children of example.com
description;x-olcAccess: (1) Entered by Nick on 7/12/2012
olcAccess: {2}to dn.children=dc=com
by * read
description;x-olcAccess: (2) Allow only read on children of com
description;x-olcAccess: (2) Entered by Nick on 7/12/2012
I use comments to clarify things, so to be easy readable is a major
requirement. This doesn't seems so readable to me (personal opinion).
Simone
--
Simone Piccardi Truelite Srl
picca...@truelite.it (email/jabber) Via Monferrato, 6
Tel. +39-347-103243350142 Firenze
http://www.truelite.it Tel. +39-055-7879597Fax. +39-055-736
Re: Loading LDAP schema files into cn=config
On 03/07/2011 14:21, Howard Chu wrote: What you call a deficiency(sp) is sheer nonsense. Tell me how you expect to provide read/write database access to a file included from any arbitrary filesystem location? Think about the safety of such a proposition as well; not everybody has AppArmor or other security mechanisms on their machines. You cry that it can't do X when in fact it would be irresponsible to ever allow it to do X. You haven't thought it through, you're just babbling. In my use cases I don't need read/write database access to a file for configuration. I can afford to restart slapd to make it reload the configuration file, as it always did until now. What I'm advocating is not losing this feature. Simone -- Simone Piccardi Truelite Srl picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597Fax. +39-055-736
cannot access entries
Hi list members, i am trying to configure accesses to my ldap server, but i am doing some wrong i am not aware about. The access list is below: access to dn.one=ou=appsrv,dc=ufv,dc=br attrs=userpassword by self read by anonymous auth by * none access to dn.one=ou=appsrv,dc=ufv,dc=br by self read by * none access to dn.one=ou=people,dc=ufv,dc=br attrs=userpassword by self read by anonymous auth by * none access to dn.one=ou=people,dc=ufv,dc=br by self read by dn.exact=cn=ypldap,ou=appsrv,dc=ufv,dc=br read by * none access to dn.one=ou=group,dc=ufv,dc=br by dn.base=cn=ypldap,ou=appsrv,dc=ufv,dc=br read by * none === The command i am executing and its output is below sioux@gustav$ ldapsearch -x -w ypldapA4esuopdV -D cn=ypldap,ou=appsrv,dc=ufv,dc=br -b ou=people,dc=ufv,dc=br -s one # extended LDIF # # LDAPv3 # base ou=people,dc=ufv,dc=br with scope oneLevel # filter: (objectclass=*) # requesting: ALL # # search result search: 2 result: 32 No such object # numResponses: 1 sioux@gustav$ Why am i not getting a list of entries below ou=people,dc=ufv,dc=br ? Thanks in advance.
Re: cannot access entries
The ypldap access should be before the one that limits more - the more restrictive one will match first. If that account is intended as you main 'root'-ish account, it should probably be granted access to all right off the bat. Also: change your ldap password now. (I've done this; sent a password to the mailing list - dumb). - chris Chris Jacobs, Systems Administrator, Technology Services Group Apollo Group | Apollo Marketing Product Development | Aptimus, Inc. 2001 6th Ave | Ste 3200 | Seattle, WA 98121 phone: 206.839-8245 | cell: 206.601.3256 | Fax: 208.441.9661 email: chris.jac...@apollogrp.edu - Original Message - From: openldap-technical-boun...@openldap.org openldap-technical-boun...@openldap.org To: openldap-technical@openldap.org openldap-technical@openldap.org Sent: Mon Jul 04 11:19:45 2011 Subject: cannot access entries Hi list members, i am trying to configure accesses to my ldap server, but i am doing some wrong i am not aware about. The access list is below: access to dn.one=ou=appsrv,dc=ufv,dc=br attrs=userpassword by self read by anonymous auth by * none access to dn.one=ou=appsrv,dc=ufv,dc=br by self read by * none access to dn.one=ou=people,dc=ufv,dc=br attrs=userpassword by self read by anonymous auth by * none access to dn.one=ou=people,dc=ufv,dc=br by self read by dn.exact=cn=ypldap,ou=appsrv,dc=ufv,dc=br read by * none access to dn.one=ou=group,dc=ufv,dc=br by dn.base=cn=ypldap,ou=appsrv,dc=ufv,dc=br read by * none === The command i am executing and its output is below sioux@gustav$ ldapsearch -x -w ypldapA4esuopdV -D cn=ypldap,ou=appsrv,dc=ufv,dc=br -b ou=people,dc=ufv,dc=br -s one # extended LDIF # # LDAPv3 # base ou=people,dc=ufv,dc=br with scope oneLevel # filter: (objectclass=*) # requesting: ALL # # search result search: 2 result: 32 No such object # numResponses: 1 sioux@gustav$ Why am i not getting a list of entries below ou=people,dc=ufv,dc=br ? Thanks in advance. This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
Re: cannot access entries
This is for learning purposes, the password will not be that one on a production system. ypldap access is just before any other more restrictive. My questions still remains: how may i have a listing of entry directly below (one level only) a given base ? Searching with a filter is interest too. But i am being prevented. Does anybody here know how it could be done given my access rules on the prior email ? Thanks once more. On Mon, Jul 4, 2011 at 4:01 PM, Chris Jacobs chris.jac...@apollogrp.edu wrote: The ypldap access should be before the one that limits more - the more restrictive one will match first. If that account is intended as you main 'root'-ish account, it should probably be granted access to all right off the bat. Also: change your ldap password now. (I've done this; sent a password to the mailing list - dumb). - chris Chris Jacobs, Systems Administrator, Technology Services Group Apollo Group | Apollo Marketing Product Development | Aptimus, Inc. 2001 6th Ave | Ste 3200 | Seattle, WA 98121 phone: 206.839-8245 | cell: 206.601.3256 | Fax: 208.441.9661 email: chris.jac...@apollogrp.edu - Original Message - From: openldap-technical-boun...@openldap.org openldap-technical-boun...@openldap.org To: openldap-technical@openldap.org openldap-technical@openldap.org Sent: Mon Jul 04 11:19:45 2011 Subject: cannot access entries Hi list members, i am trying to configure accesses to my ldap server, but i am doing some wrong i am not aware about. The access list is below: access to dn.one=ou=appsrv,dc=ufv,dc=br attrs=userpassword by self read by anonymous auth by * none access to dn.one=ou=appsrv,dc=ufv,dc=br by self read by * none access to dn.one=ou=people,dc=ufv,dc=br attrs=userpassword by self read by anonymous auth by * none access to dn.one=ou=people,dc=ufv,dc=br by self read by dn.exact=cn=ypldap,ou=appsrv,dc=ufv,dc=br read by * none access to dn.one=ou=group,dc=ufv,dc=br by dn.base=cn=ypldap,ou=appsrv,dc=ufv,dc=br read by * none === The command i am executing and its output is below sioux@gustav$ ldapsearch -x -w ypldapA4esuopdV -D cn=ypldap,ou=appsrv,dc=ufv,dc=br -b ou=people,dc=ufv,dc=br -s one # extended LDIF # # LDAPv3 # base ou=people,dc=ufv,dc=br with scope oneLevel # filter: (objectclass=*) # requesting: ALL # # search result search: 2 result: 32 No such object # numResponses: 1 sioux@gustav$ Why am i not getting a list of entries below ou=people,dc=ufv,dc=br ? Thanks in advance. This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
Re: Status of support for draft-wahl-ldap-session
Michael Ströder wrote: It seems there is support for draft-wahl-ldap-session in OpenLDAP's source since 2007 but it seems not to be enabled in a default build. Is it sufficient to compile with -DSLAP_CONTROL_X_SESSION_TRACKING or do I also have to use -DLDAP_DEVEL (because of ifdef in ldap.h). The latter does not work with 2.4.26... This seems to work for HEAD: Jul 4 21:29:06 nb2 slapd-schulung-1[4984]: conn=1002 op=1 [IP=192.0.2.1 NAME=app.example.com USERNAME=bloggs] SRCH base= scope=1 deref=0 filter=(objectClass=*) Jul 4 21:29:06 nb2 slapd-schulung-1[4984]: conn=1002 op=1 [IP=192.0.2.1 NAME=app.example.com USERNAME=bloggs] SRCH attr=* Jul 4 21:29:06 nb2 slapd-schulung-1[4984]: conn=1002 op=1 [IP=192.0.2.1 NAME=app.example.com USERNAME=bloggs] SEARCH RESULT tag=101 err=32 nentries=0 text= Filed ITS#6984 for that... Ciao, Michael.
Re: Loading LDAP schema files into cn=config
Howard Chu wrote: I note that the accesslog overlay already allows you to track the history of individual changes to attributes, so recording an Entered by name on date comment seems both redundant and vague. I really like slapo-accesslog and the audit trail it provides. Feature request: Sometimes it would be handy to send along a extended control which notes *why* a certain modification was done. Ciao, Michael.
Re: slapd vs. db_archive
On 24.06.2011 at 14:05 Peter Palmreuther wrote: On Thu, Jun 23, 2011 at 17:01, Buchan Milne bgmi...@staff.telkomsa.net wrote: On Thursday, 23 June 2011 16:19:45 Peter Palmreuther wrote: I tried to use 'db_archive' to figure, which of those many log.* files already accumulated I can safely remove. Unluckily it didn't print any name, albeit there're 170 file and according to 'fuser log.*' only the last one is held open by a process (the slapd one). What is your 'checkpoint' or 'olcDbCheckPoint' setting for this OpenLDAP database ? Thanks for pointing this out. It's not set at all, so according to 'man slapd-hdb' it should be zero and therefore disabled, right? I'll set it and see if this solves my problem. Changing the mentioned setting did in fact help. Thanks a lot!!! -- Best regards, Peter
