openldap-technical

openldap-technical@openldap.org

9804 discussions

slapo-chain + TLS = help
by Warren Howard 19 Jul '12

19 Jul '12

Hi, I'm not able to get slapo-chain + TLS to work. Slapo-chain without TLS works, syncrepl + TLS works, the ldapclients with TLS works, just slapo-chain + TLS does not work. "man slapo-chain" contains no information about the tls options for slapo-chain, but with I enable "chain-tls start" (as described in the OpenLDAP Admin Guide) I get the error : TLS negotiation failure. What TLS options for slapo-chain are available for me to configure to get this working? Note : I'm using Ubuntu 12.04 with slapd 2.4.28 provided by the distribution. Regards, Warren.

5 7

database ldap and acl-bind
by Nerijus Kislauskas 19 Jul '12

19 Jul '12

Hi everyone, As I understand from documentation, acl-bind is a technique to fetch acls from backend ldap to ldap proxy and apply them in there. Is this correct? I can't find any working example with shown logs to prove my idea nor i can get my configs to work. Maybe there is something i don't know? My configs: /etc/ldap/slapd.d/cn=config/olcDatabase={2}ldap.ldif: dn: olcDatabase={2}ldap objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {2}ldap structuralObjectClass: olcLDAPConfig entryUUID: da219748-6515-1031-9486-41b4d47f5b36 olcSuffix: dc=ktu,dc=lt olcDbURI: ldap://83.171.20.45 olcDbIdleTimeout: 60 olcDbACLBind: bindmethod=simple binddn="cn=test,dc=ktu,dc=lt" credentials="test" Logs: Jul 19 12:17:36 bijote slapd[1435]: => acl_mask: access to entry "dc=ktu,dc=lt", attr "entry" requested Jul 19 12:17:36 bijote slapd[1435]: => acl_mask: to all values by "cn=admin,dc=ktu,dc=lt", (=0) Jul 19 12:17:36 bijote slapd[1435]: <= check a_dn_pat: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth Jul 19 12:17:36 bijote slapd[1435]: <= check a_dn_pat: * Jul 19 12:17:36 bijote slapd[1435]: <= acl_mask: [2] applying +0 (break) Jul 19 12:17:36 bijote slapd[1435]: <= acl_mask: [2] mask: =0 Jul 19 12:17:36 bijote slapd[1435]: => dn: [2] Jul 19 12:17:36 bijote slapd[1435]: => dn: [3] cn=subschema Jul 19 12:17:36 bijote slapd[1435]: <= acl_get: done. Jul 19 12:17:36 bijote slapd[1435]: => slap_access_allowed: no more rules Clearly visible, that there is no ACL configs in database definition, and ACL's comes from frontend database (defaults): /etc/ldap/slapd.d/cn=config/olcDatabase\={2}ldap.ldif: ... olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth manage by * break olcAccess: {1}to dn.exact="" by * read olcAccess: {2}to dn.base="cn=Subschema" by * read .... As I understand, there should be ACL in ldap proxy (custom or defaults, tied to backends ACL's or not). Please help me to clear things out. -- Sincerely, Nerijus Kislauskas KTU ITPI, Litnet valdymo centras

1 0

openldap groups and roles
by Jignesh Patel 18 Jul '12

18 Jul '12

We are using OpenLDAP at present. But we are anticipating a huge growth in number of users. We are intented to support 300,000 users. Is that possible with openLDAP?Has any body tried it? Also can i define various roles inside openldap?Can I also define groups inside openldap? Jignesh Patel Chief Architect iCare.com LLC  Las Olas City Centre, Suite 2250 401 East Las Olas Boulevard Fort Lauderdale, Florida 33301 O: 954-616-5604 F: 954-616-5609 jignesh(a)icare.com CONFIDENTIALITY NOTE: The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, please immediately reply to the sender that you have received this communication in error and then delete it. Thank you. On Jul 18, 2012, at 2:57 PM, openldap-technical-request(a)OpenLDAP.org wrote: > openldap-technical(a)openldap.org

2 3

replicating accesslog
by Marvin Mundry 18 Jul '12

18 Jul '12

Hello everybody, I am trying to replicate an accesslog database (cn=accesslog) from a provider to 2 consumers. The replication works fine except that old accesslog entries that get removed via "logpurge 07+00:00 01+00:00" on the provider do not get removed from the replicas. over time the accesslog databases on the consumers get rather huge. a workaround seems to be running a script from time to time that identifies and removes old accesslog entries via ldap. deletions in cn=accesslog made via ldap get replicated correctly. is there a way to have the deletions by logpurge replicated as well? bests, Marvin

2 1

ACL syntax for delegating a subdomain to a group
by Brian Riffle 18 Jul '12

18 Jul '12

I am struggling to find documentation on how to use the cn=config syntax for delegating a subdomain to a group of users. In my situation, I have an OU setup for customer accounts. (ou=subdomain,ou=People,dc=example,dc=com). I can currently edit that if I log in as a user that is our admin OU, ou=admins,dc=example,dc=com. However, I don't want to give our front facing support that much access. basically, I want the following: - any user can update their info. - anyone in ou=admin can update anything - anybody in group cn=cust_support,ou=group,dc=example,dc=com can do anything to anyone in the ou=subdomain,ou=People OU. (create/edit/update/delete) However, I am struggling to get the syntax right. I have tried many permutations, and the most recent example was to use these rules for setting olcAccess in the o=config database: {0}to attrs=userPassword by self write by anonymous auth by dn.children="ou=admins,dc=example,dc=com" write by group.exact="cn=cust_support,ou=group,dc=example,dc=com" write by * none {1}to dn.subtree="ou=subdomain,ou=People,dc=example,dc=com" by self write by dn.children="ou=admins,dc=example,dc=com" write by group.exact="cn=cust_support,ou=group,dc=example,dc=com" write by * read {2}to * by self write by dn.children="ou=admins,dc=example,dc=com" write by * read I have tried making cn=cust_support,ou=group,dc=example,dc=com both a posixGroup, and a groupOfNames. Both of them, when I go to save a new users, I get "insufficient access" If anyone could guide me in the correct direction, it would be greatly appreciated.. thanks! Brian

2 1

syncrepl with mirrormode compatible with OpenLDAP version 2.3.43?
by Houston Ray 18 Jul '12

18 Jul '12

I have setup my slapd.conf file with the directives for syncrepl with mirrormode on. This seems to cause issues with any write operations that occur after setup. (syncrepl does work with the provider/consumer setup but so far not with mirrormode) I am now guessing that mirrormode is in fact NOT available in version prior to 2.4 I have searched for an answer, but have yet to find any clear statement saying that it is not supported. thanks in advance to anyone who can confirm or deny that syncrepl with * mirrormode* is or is not supported in version 2.3.43 -h

2 1

Glueing together backend databases - meta, glue or chain?
by Pieter Baele 18 Jul '12

18 Jul '12

Hi, I have several backend databases on my master servers, and need to present a combined view to clients on slaves (Unix authentication) I think this a common question/issue... Scenario: 5 backend DB's, 2 of these are needed on each slave server Each of these has an ou=Groups,ou=Nodes, ou=People etc. --- dc=common,dc=example,dc=org --- dc=shared,dc=example,dc=org --- dc=companyA,dc=example,dc=org --- dc=companyB,dc=example,dc=org --- dc=companyC,dc=example,dc=org So one of the slaves uses companyA, common and shared another one uses companyB, commmon and shared and the last one companyC, common and shared all slaves represent this as "dc=example,dc=org" The easiest way seems using meta backend, but I've the feeling this has drawbacks??? You can't use cn=config, performance? Maybe there is an approach with chain or glue? I can change my DIT if necessary. Sincerely, Pieter

3 5

Re: Glueing together backend databases - meta, glue or chain?
by Francois Gnu 18 Jul '12

18 Jul '12

Hello Aaron, You say that: > One method also worth putting on the table is hosting the single backend > "dc=example,dc=org" on your master and selectively replicating appropriate > portions of the DIT using appropriate filters. (Howard recently posted to > the list on the best practices to execute this.) Can you put the link of the Howard's post, please? Thank you very much. Librement, ------ Francois Trachez (kiko) Team Fedora|Lyon (France) http://stg.fedoraproject.org/fr/ http://stg.fedoraproject.org/es/

2 1

Private E-Mail Address
by chris_news＠arcor.de 18 Jul '12

18 Jul '12

Hi, whereis the best place to store the private e-mail address of an inetOrgPerson? Is the order of the attribute's values fixed? So I could save the business address as first value and the private as second? May the first value be empty? Would an auxiliary class be better? Which one? Thank you in advance. - Chris

2 1

syncrepl and attribute order
by Evgeniy Kosov 18 Jul '12

18 Jul '12

Hi there, First of all, I'm new to this list, so, please, forgive me if this is a wrong place for the questions below, and feel free to redirect me wherever is more appropriate. The issue I'm facing as stated above is regarding the syncrepl and attribute order. I'm writing a Perl module to be used with back_perl and noticed behaviour that seems strange. Making some modifications on the master server (provider) and looking on the relevant modifications on the slave I saw that they didn't quite match. There were some extra REPLACE operations made by syncrepl. Later investigation showed that the cause of those REPLACE's was different attribute order on the master and slave nodes. synrepl.c says that: /* We assume that attributes are saved in the same order * in the remote and local databases. So if we walk through * the attributeDescriptions one by one they should match in * lock step. If not, look for an add or delete. */ Which seems strange to me. As a result syncrepl makes a REPLACE for every attribute whuch is "misplaced" in the local object. This is probably not an issue if master and slave both use the same back-end module. Which is not true in my case. So, the questions are: Is that replacing of "misplaced" attributes by syncrepl is expected behaviour or just a side effect of its syncrepl_diff_entry diff'ing algorithm? Does attribute order matter? Is it specified somehow (sorted by modification time?)? Should this issue be reported as bug? Thank you. -- Regards, Evgeniy Kosov

3 8

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical