openldap-technical

openldap-technical@openldap.org

3 participants
9898 discussions

role based authorization -> dynacl module?
by Daniel Tröder 11 Oct '18

11 Oct '18

Hello everyone, I am in the process of implementing a role concept via ACLs and hope for a hint so that I don't invent the wheel a second time. Specifically, it is about identity management for schools. A user (object) can have several roles in multiple schools. Permissions on other LDAP objects can thus differ depending on the role(s) the user and the object have in the same school(s). For example, a user could have been assigned the following roles that are scattered over several schools: → "Teacher" in school 1 → "School admin" in school 2 → "Parent" in school 3 → both "Teacher" and "Staff" in school 4 ACLs should now be defined accordingly, e.g. → the role "teacher" at school X can reset the password for the role "student" at school X → the role "teacher" at school X *cannot* reset the password for the role "student" of school Y → the role "school administrator" at school X can reset the password for the roles "student" and "teacher" at school X → ... So far I have not seen any way to map such a construct via groups or sets without including a separate ACL for each group, which is a performance issue. Is there another way to map the role concept besides implementing an own dynacl module? Greetings, Daniel

4 13

Fwd: ppolicy and logging
by Maurice Barlow 10 Oct '18

10 Oct '18

Greetings, using 2.4.45 on Solaris 11 ( shipped with the distro ) with ppolicy. Working on the locking out of the accounts and want to configure detailed messages pumped into syslog to track lockout activity. At the moment what i see is only "errorno=49". Any ideas or a secure log_level ? cheers MB

1 0

Using ppolicy and autogroup to apply policy to a group a users
by Clément OUDOT 08 Oct '18

08 Oct '18

Hello, we often have the question on this list: how apply a policy to a branch or a group of users? I was thinking we could use autogroup we this kind of configuration: dn: olcOverlay={9}autogroup,olcDatabase={1}mdb,cn=config objectClass: top objectClass: olcConfig objectClass: olcAutomaticGroups objectClass: olcOverlayConfig olcOverlay: {9}autogroup olcAGattrSet: pwdPolicy memberUrl seeAlso olcAGmemberOfAd: pwdPolicySubentry The goal is to have a memberUrl inside a pwdPolicy object, that can target accounts that need to have this policy. For example: dn: cn=default,ou=ppolicies,dc=example,dc=com changetype: modify replace: memberURL memberURL: ldap:///ou=users,dc=example,dc=com??one?(uid=user*) The autogroup "olcAGattrSet" is working well, I can see the seeAlso values. But the "olcAGmemberOfAd" does not seem to be applied. I don't know if this is a conflict with ppolicy overlay, or other overlays (dynlist, memberof). I join a full debug log, maybe you can find what is going wrong. We see that "autogroup_member_search_modify_cb" function is called, but user entry is not modified. Do you think this configuration could work? -- Clément Oudot | Identity Solutions Manager clement.oudot(a)worteks.com Worteks | https://www.worteks.com

1 0

oracle user authentication through OpenLDAP
by appana anil 04 Oct '18

04 Oct '18

We have recently replaced OID with OpenLDAP and looking to see if the Oracle db user can authenticate through OpenLDAP. Appreciate your help. -- Regards, A.Anil Kumar

1 0

RE24 testing call (2.4.47) LMDB RE0.9 testing call (0.9.23)
by Quanah Gibson-Mount 04 Oct '18

04 Oct '18

This is expected to be the only testing call for 2.4.47, with an anticipated release, depending on feedback, during the week of 2018/10/15. Generally, get the code for RE24: <http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs/h…> Configure & build. Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite. Thanks! OpenLDAP 2.4.47 Engineering Added slapd-sock DN qualifier for subtrees to be processed (ITS#8051) Added slapd-sock ability to send extended operations to external listeners (ITS#8714) Fixed libldap dn to domain parsing with bad input (ITS#8842) Fixed slapd slapcat to correctly honor -g option (ITS#8667) Fixed slapd cn=config when modifying slapo-syncprov config (ITS#8616) Fixed slapd sasl authz-policy "all" behavior (ITS#8909) Fixed slapd sasl minor typo (ITS#8918) Fixed slapd to correctly hide hidden DBs in the rootDSE (ITS#8912) Fixed slapd domainScope control to match Microsoft specification (ITS#8840) Fixed slapd-bdb/hdb/mdb to not convert certain IDLs to ranges (ITS#8868) Fixed slapo-memberof cn=config modifications (ITS#8663) Fixed slapo-syncprov with NULL modlist (ITS#8843) Build Environment Fixed missing includes with OpenSSL 1.0.2 (ITS#8809) LMDB 0.9.23 Engineering ITS#8756 Fix loose pages in dirty list ITS#8831 Fix mdb_load flag init ITS#8844 Fix mdb_env_close in forked process Documentation ITS#8857 mdb_cursor_del doesn't invalidate cursor ITS#8908 GET_MULTIPLE etc don't change passed in key Warm regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Making contextCSN, entryCSN visible only to sync user?
by Karsten Heymann 02 Oct '18

02 Oct '18

Hi, I wonder if it would be harmful to modify our slapd acls so that only the user used for syncrepl replication can view the contextCSN/entryCSN attributes on the master servers. We're considering this to prevent unintended partial replication (for example without password fields) in case there is a misconfiguration and the slave comes as another user/anomymous. Ideally I would block anonymous access to our database completely but we have to update a lot of services until this can be achieved. Does this idea make sense or am I missing something? Best regards Karsten

2 1

Q: Renewing certificates online
by Ulrich Windl 02 Oct '18

02 Oct '18

Hi! I have a question: I updated the contents of certificate and key file (same location and file name) while slapd was running. Is it expected that slapd will recognize (and use) the new certificates, or is a restart or reload needed? Out certificates will expire soon... Regards, Ulrich

4 3

Re: slapo-memberof and Replication
by Meike Stone 02 Oct '18

02 Oct '18

Hello Quanah, Thanks for clarification. > > That confuses me a little bit. > > All replication on openLDAP are based on syncreplication (slurpd is > > vanished a long time ago) > > So what kind of replication means the manual page (-> "Replica servers")? > > It means that you run it in a replicated environment at your own risk. > Unfortunately, there is no defined standard for the "memberOf" > functionality (it's a MS hack) and so there's nothing that details how it > should or shouldn't behave with replication. In general, things work fine > as long as: > > a) The server(s) never go into REFRESH > and > b) You never bring up a new replica with an empty database (which then does > a full REFRESH) That means, if I run in mirrormode, I can turn on the memberOf overlay on the active openLDAP server and off on the slave. Then REFESH ist supported?! In emegency case (hardware error) I can make the mirror (manual) aktive an turn the overlay on?! Thanks Meike

2 1

Program of the Silver Jubilee Open LDAP Developper's Day
by Peter 01 Oct '18

01 Oct '18

please find attached the program of the Silver Jubilee Open LDAP Developper's Day. Last minute registration at odd-silverjubilee(a)daasi.de ist still possible. Cheers Peter -- _______________________________________________________________________ Peter Gietz (CEO) DAASI International GmbH phone: +49 7071 407109-0 Europaplatz 3 Fax: +49 7071 407109-9 D-72072 Tübingen mail: peter.gietz(a)daasi.de Germany Web: www.daasi.de DAASI International GmbH, Tübingen Geschäftsführer Peter Gietz, Amtsgericht Stuttgart HRB 382175 Directory Applications for Advanced Security and Information Management _______________________________________________________________________

1 0

issues with equality matching and slapd death
by Christopher Paul 28 Sep '18

28 Sep '18

Hello Fellow OpenLDAP Techs, I'm having an issue with equality matching and slapd death (just another day in the life of an LDAP guy...). version info: OpenLDAP: slapd 2.4.44 Red Hat Enterprise Linux Server release 7.5 (Maipo) RH package: openldap-servers-2.4.44-15.el7_5.x86_64 While planning for a migration, I ran into the following error: $ ldapmodify -x -y ~/.ldappw dn: uid=cs5555,ou=testPrimary,ou=mailhosts,dc=test,dc=com changetype: modify add: mailAlternateAddress mailAlternateAddress: cs5555(a)test.com [CTRL-D] modifying entry "uid=cs5555,ou=testPrimary,ou=mailhosts,dc=test,dc=com" ldap_modify: Inappropriate matching (18) additional info: modify/add: mailAlternateAddress: no equality matching rule I tried to fix this by updating the schema to add "EQUALITY caseIgnoreMatch" to the attribute definition for mailAlternateAddress. dn: cn={5}inetLocalMailRecipient,cn=schema,cn=config objectClass: olcSchemaConfig cn: {5}inetLocalMailRecipient olcAttributeTypes: {0}( 2.16.840.1.113730.3.1.24 NAME 'mailRoutingAddress' DES C 'iPlanet defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORI GIN 'iPlanet Messaging Server' ) olcAttributeTypes: {1}( 2.16.840.1.113730.3.1.18 NAME 'mailHost' DESC 'iPlanet defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'iPlan et Messaging Server' ) olcAttributeTypes: {2}( 2.16.840.1.113730.3.1.13 NAME 'mailAlternateAddress' D ESC 'iPlanet defined attribute type'EQUALITY caseIgnoreMatchSYNTAX 1.3.6.1. 4.1.1466.115.121.1.15 X-ORIGIN 'iPlanet Messaging Server' ) olcObjectClasses: {0}( 2.16.840.1.113730.3.2.4 NAME 'inetLocalMailRecipient' D ESC 'iPlanet defined objectclass' AUXILIARY MAY ( mailAlternateAddress $ mail Host $ mailRoutingAddress ) X-ORIGIN 'iPlanet Messaging Server' ) Now, after the schema change, the same ldapmodify kills slapd. $ ldapmodify -x -y ~/.ldappw dn: uid=cs5555,ou=testPrimary,ou=mailhosts,dc=test,dc=com changetype: modify add: mailAlternateAddress mailAlternateAddress: cs5555(a)test.com modifying entry "uid=cs5555,ou=testPrimary,ou=mailhosts,dc=test,dc=com" ldap_result: Can't contact LDAP server (-1) Trying this with slapd running with olcLogLevel=-1, I get the following output before slapd death: Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: connection_get(11) Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: connection_get(11): got connid=1008 Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: connection_read(11): checking for input on id=1008 Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: op tag 0x60, time 1537906659 Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: conn=1008 op=0 do_bind Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: >>> dnPrettyNormal: <cn=manager,dc=test,dc=com> Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: <<< dnPrettyNormal: <cn=manager,dc=test,dc=com>, <cn=manager,dc=test,dc=com> Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: conn=1008 op=0 BIND dn="cn=manager,dc=test,dc=com" method=128 Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: do_bind: version=3 dn="cn=manager,dc=test,dc=com" method=128 Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: ==> hdb_bind: dn: cn=manager,dc=test,dc=com Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: conn=1008 op=0 BIND dn="cn=manager,dc=test,dc=com" mech=SIMPLE ssf=0 Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: do_bind: v3 bind: "cn=manager,dc=test,dc=com" to "cn=manager,dc=test,dc=com" Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: send_ldap_result: conn=1008 op=0 p=3 Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: send_ldap_result: err=0 matched="" text="" Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: send_ldap_response: msgid=1 tag=97 err=0 Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: conn=1008 op=0 RESULT tag=97 err=0 text= Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: daemon: activity on 1 descriptor Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: daemon: activity on: Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: daemon: epoll: listen=9 active_threads=0 tvp=NULL Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal systemd[1]: slapd.service: main process exited, code=killed, status=6/ABRT Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal systemd[1]: Unit slapd.service entered failed state. Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal systemd[1]: slapd.service failed. Does anyone have any insight into this issue? somehow I've never run into this one before. Many thanks, CP -- Rex ConsultingChris Paul Rex Consulting, Inc 5652 Florence Terrace, Oakland, CA 94611 email: chris.paul(a)rexconsulting.net web: http://www.rexconsulting.net phone, toll-free: +1 (888) 403-8996 ext 1 The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. Rex Consulting, Inc. has been a California Corporation since 2001.

6 22

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical