openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#6495) nssov patch to better emulate pam_ldap behaviour
by hyc＠symas.com 21 Mar '10

21 Mar '10

kean.johnston(a)gmail.com wrote: > Full_Name: Kean Johnston > Version: HEAD > OS: Linux (CentOS 5.3) > URL: ftp://ftp.openldap.org/incoming/kean-johnston-100321.patch > Submission from: (NULL) (196.210.34.161) > > > The nssov manual page states that some of it's options "duplicates the original > pam_ldap authorization behavior". However, they don't quite. pam_ldap has the > ability for you to use "wildcards" in a user's host: attribute. I say > "wildcards" in quotes because the pam_ldap implementation does not actually use > regex matching, but rather check for two special strings, "*" and "!". > > The ability to use actual wildcards, especially ones you can negate, on a per > user basis is extremely useful to an administrator of large networks. For > example you may want all developers to have access to the machines in > developers.mydomain.com but you want to disallow access to some of those > machines to contractors or interns. > > This patch allows such behaviour, so it serves the dual purpose of actually > implementing existing pam_ldap behaviour in case people already depend on that, > as well as extends it to be a more generally usable feature by using actual > regular expressions. The code is simple, and the man page change describes it > well enough. Please consider adding this code to nssov. Thank you. > Authorization is the job of the ACL engine. Putting ad-hoc rules into user entries is, in a word, stupid. It's also unscaleable and will become an administration nightmare. The user host attribute functionality is deprecated. I have no desire to make it even vaguely appear to be useful. -- -- 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: (ITS#6487) Nssov pam_authz authorizedUserService
by hyc＠symas.com 21 Mar '10

21 Mar '10

kean.johnston(a)gmail.com wrote: > I like what this offers administrators but I have a comment about how you > handle "wildcards". They aren't wild at all, but "magic strings" with only > one possible meaning: all users/services with the single magic character > "*". If you have a defined user naming convention like i_whatever for > interns and c_whatever for contractors, it would be useful to be able to > either include or exclude such users from using certain services. > > My patch at http://www.openldap.org/its/index.cgi?findid=6495 does this for > userhost and userservices attributes, and includes negation. Would you be > interested in working with me to expand this to support real wildcards? > Also I suggest you make this two patches, as the patch submission > guidelines clearly state that one patch for 1 feature, and the meaty parts > of this are obfuscated by increasing the buffer sizes which should probably > be in a separate patch. > > Regards, Kean This patch was rejected. The functionality it offered was already provided by the slapd ACL engine. -- -- 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: (ITS#6487) Nssov pam_authz authorizedUserService
by kean.johnston＠gmail.com 21 Mar '10

21 Mar '10

I like what this offers administrators but I have a comment about how you handle "wildcards". They aren't wild at all, but "magic strings" with only one possible meaning: all users/services with the single magic character "*". If you have a defined user naming convention like i_whatever for interns and c_whatever for contractors, it would be useful to be able to either include or exclude such users from using certain services. My patch at http://www.openldap.org/its/index.cgi?findid=6495 does this for userhost and userservices attributes, and includes negation. Would you be interested in working with me to expand this to support real wildcards? Also I suggest you make this two patches, as the patch submission guidelines clearly state that one patch for 1 feature, and the meaty parts of this are obfuscated by increasing the buffer sizes which should probably be in a separate patch. Regards, Kean

1 0

Re: (ITS#6495) nssov patch to better emulate pam_ldap behaviour
by kean.johnston＠gmail.com 21 Mar '10

21 Mar '10

ftp.openldap.org reports no space on the device, so the URL for the patch is at: http://64.34.163.232/openldap/kean-johnston-100321.patch

1 0

(ITS#6496) nssov patch to better emulate pam_ldap behaviour
by kean.johnston＠gmail.com 21 Mar '10

21 Mar '10

Full_Name: Kean Johnston Version: HEAD OS: Linux (CentOS 5.3) URL: ftp://ftp.openldap.org/incoming/kean-johnston-100321.patch Submission from: (NULL) (196.210.34.161) The nssov manual page states that some of it's options "duplicates the original pam_ldap authorization behavior". However, they don't quite. pam_ldap has the ability for you to use "wildcards" in a user's host: attribute. I say "wildcards" in quotes because the pam_ldap implementation does not actually use regex matching, but rather check for two special strings, "*" and "!". The ability to use actual wildcards, especially ones you can negate, on a per user basis is extremely useful to an administrator of large networks. For example you may want all developers to have access to the machines in developers.mydomain.com but you want to disallow access to some of those machines to contractors or interns. This patch allows such behaviour, so it serves the dual purpose of actually implementing existing pam_ldap behaviour in case people already depend on that, as well as extends it to be a more generally usable feature by using actual regular expressions. The code is simple, and the man page change describes it well enough. Please consider adding this code to nssov. Thank you.

1 0

(ITS#6495) nssov patch to better emulate pam_ldap behaviour
by kean.johnston＠gmail.com 21 Mar '10

21 Mar '10

1 0

(ITS#6494) replication doesn't works if directory contains more than one tree
by Ikonta＠yandex.ru 19 Mar '10

19 Mar '10

Full_Name: Sergey A. Starikov Version: 2.4.21 OS: FreeBSD 7.2-RELEASE-p4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.229.208.12) Also (currently the main OS) is FreeBSD 6.4-RELEASE-p9. Configuration stored in slapd.conf. Two servers in mirror mode. The slapd.conf is: <includes> serverID pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args # Load dynamic backend modules: modulepath /usr/local/libexec/openldap moduleload back_bdb <ACLs set (replicator user can read everything in replicated tree)> sizelimit 1024 # ####################################################################### # BDB database definitions ####################################################################### # db #1 (caotus userbase, main database) database bdb suffix "dc=mydomain,dc=ru" rootdn "uid=admin,dc=mydomain,dc=ru" rootpw {SSHA}<some hash> overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE logpurge 07+00:00 01+00:00 # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/db/openldap-data # Indices to maintain index cn,sn,uid pres,eq,approx,sub <and some other indexes> # syncprov specific indexing index entryCSN eq index entryUUID eq overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 syncrepl rid=002 provider=ldap://ldapN.mydomain.ru:389 type=refreshOnly interval=00:00:12:00 retry="64 16 256 4" searchbase="dc=mydomain,dc=ru" scope=sub sizelimit=unlimited timelimit=512 schemachecking=on bindmethod=simple binddn="uid=Replicator,ou=People,dc=mydomain,dc=ru" credentials=secret mirrormode on # db #2 (ESPP certs database accesslog) database bdb suffix "cn=accesslog" # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/log/openldap-accesslog # Indices to maintain index reqStart eq In described case accesslog overlay works normally. But overlay syncprov is _particularly_ inoperate (transferred only one of about 28 changes in source database). Both in refreshAndPersist and refreshOnly replication modes. If I remove the accesslog overlay from slapd.conf --- replication works as it should. Also, if I try to add instead the accesslog another tree, for example: slapd.conf: ... # db #2 database bdb suffix "dc=public,dc=org" directory /var/db/openldap-db2 # Indices to maintain index objectClass eq <other indexes> ... replication also doesn't works.

1 0

Re: (ITS#6477) Clarify ambiguous TLS/SSL Errors in libldap/tls2c.
by korvus＠comcast.net 18 Mar '10

18 Mar '10

On 3/17/2010 9:25 PM, Quanah Gibson-Mount wrote: > --On Wednesday, March 17, 2010 8:17 PM +0000 korvus(a)comcast.net wrote: > >> tjoen wrote: >>> On Mon, 2010-03-08 at 16:19 +0000, korvus(a)comcast.net wrote: >>>> After some chatter on the mailing list, the problem is now >>>> understood: >>>> - TLS error messages are indeed reported by OpenLDAP: >>>> TLS: could not use key file >>>> `/usr/local/etc/openldap/certs/ldap.key.pem'. >>> ... >>>> - The only way to see these error messages is to start the daemon >>>> with >>>> '-d stats' >>> ... >>>> My suggestions: print the TLS error messages out to syslog, or if >>>> that's not possible, print them to stdout regardless of whether the >>>> daemon is running in the foreground or not. >>> >>> Isn't it in local4.* ? >>> >> >> No, they do not get sent to local4.* - the only TLS message which makes >> it there in this scenario is: slapd[72041]: main: TLS init def ctx >> failed: -1 >> >> Like I said, the ONLY way to get the actual TLS error messages is to run >> the daemon by hand in the foreground with loglevel stats by way of >> 'slapd >> -d stats'. Per the manpage this also prevents slapd from forking: >> -d debug-level >> Turn on debugging as defined by debug-level. If this >> option is specified, even with a zero argument, slapd >> will not fork or disassociate from the invoking >> terminal. >> >> >> Let me know if I'm still not being clear. > > If you are trying to debug an issue, you most certainly should be > running slapd -d <level>... that's why it exists. > > --Quanah > That's a valid point. However, it does not explain why the TLS errors aren't (or "shouldn't be") logged via syslog.

1 0

Re: (ITS#6493) Broken link in online openldap administrator's guide
by ghenry＠OpenLDAP.org 18 Mar '10

18 Mar '10

----- "felix wolfsteller" <felix.wolfsteller(a)intevation.de> wrote: > Full_Name: Felix Wolfsteller > Version: n/a > OS: na/a > URL: http://www.openldap.org/doc/admin24/schema.html > Submission from: (NULL) (212.95.107.190) > > > In the online openldap administrator's guide, section 13.2.1 > ( http://www.openldap.org/doc/admin24/schema.html ) > , > > " http://www.alvestrand.no/harald/objectid/ " > > is referenced, where it should be > > " http://www.alvestrand.no/objectid/ " , i guess. Thanks, will fix. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

(ITS#6493) Broken link in online openldap administrator's guide
by felix.wolfsteller＠intevation.de 18 Mar '10

18 Mar '10

Full_Name: Felix Wolfsteller Version: n/a OS: na/a URL: http://www.openldap.org/doc/admin24/schema.html Submission from: (NULL) (212.95.107.190) In the online openldap administrator's guide, section 13.2.1 ( http://www.openldap.org/doc/admin24/schema.html ) , " http://www.alvestrand.no/harald/objectid/ " is referenced, where it should be " http://www.alvestrand.no/objectid/ " , i guess.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs