openldap-technical

openldap-technical@openldap.org

9 participants
9902 discussions

Pverlay development documentation
by Geoff Swan 09 Nov '16

09 Nov '16

I have a need to write an overlay (openldap-2.4.44) and wondered if there was any documentation for overlay development? I have examined the sources in contrib/slapd-modules/ and was hoping to locate something a bit more descriptive and maybe any must-do's and gotchas for development. >From a development environment perspective, is it advisable to use the contrib/slapd-modules/ as a build location, using a Makefile based on one of the existing overlays and also the non-exposed header files (eg "portable.h") or not? - Geoff

2 1

slapd-meta
by Fr3ddie 07 Nov '16

07 Nov '16

Hello to the list, I'm trying to configure the slapd-meta OpenLDAP backend on an online cn=config configuration with no luck. Slapd version is 2.4.39 (the maximum I can achieve on the target machines building from vanilla source). The documentation is clear but too concise for me so I will try to explain what I'm trying to do to see if there is anybody that can help me. Currently I have 3 slapd servers that share a common root for the DIT, i.e.: dc=loc1,dc=root dc=loc2,dc=root dc=loc3,dc=root What I would like to achieve is to obtain a fourth server that contains the previous trees, along with its own tree, i.e. a server that contains: dc=loc0,dc=root (locally hosted data) dc=loc1,dc=root (coming from the first server, chasing referrals) dc=loc2,dc=root (coming from the second server, chasing referrals) dc=loc3,dc=root (coming from the third server, chasing referrals) this way, all the clients connecting to this server will be able to retrieve data also from the other three remote servers. As far as I understood, I only need to configure the "loc0" server to access the other three servers and get the data to serve to clients. I have already configured the fourth server with its local DIT and this is the configuration: # cat 'cn=config.ldif' dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcPidFile: /var/run/slapd/slapd.pid structuralObjectClass: olcGlobal creatorsName: cn=config olcServerID: 1 olcThreads: 32 olcToolThreads: 8 olcRequires: LDAPv3 olcConnMaxPendingAuth: 100 olcTLSCACertificateFile: /etc/ssl/certs/my_ca_cert.pem olcTLSCertificateFile: /etc/ssl/certs/this-host_x509_cert.pem olcTLSCertificateKeyFile: /etc/ssl/private/this-host_x509_key.key olcTLSVerifyClient: try olcTimeLimit: 600 olcLogLevel: stats2 sync [...] # cat 'cn=module{0}.ldif' dn: cn=module{0} objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib/ldap olcModuleLoad: {0}back_hdb olcModuleLoad: {1}syncprov olcModuleLoad: {2}accesslog structuralObjectClass: olcModuleList [...] Schema files are the following: cn={0}core.ldif cn={1}cosine.ldif cn={2}nis.ldif cn={3}inetorgperson.ldif cn={4}dyngroup.ldif cn={5}kerberos.ldif # cat 'olcDatabase={1}hdb.ldif' dn: olcDatabase={1}hdb objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {1}hdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=loc0,dc=root olcAccess: {0}to attrs=userPassword,shadowLastChange,krbPrincipalKey by dn="cn =admin,dc=loc0,dc=root" write by anonymous auth by self write by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by dn="cn=admin,dc=loc0,dc=root" write by * read olcLastMod: TRUE olcRootDN: cn=admin,dc=loc0,dc=root olcRootPW:: xxxxxxxxxxxxxxxxxxxx olcDbCacheSize: 10000 olcDbCheckpoint: 512 10 olcDbConfig: {0}set_cachesize 0 524288000 1 olcDbConfig: {1}set_lk_max_objects 1500 olcDbConfig: {2}set_lk_max_locks 1500 olcDbConfig: {3}set_lk_max_lockers 1500 olcDbConfig: {4}set_flags DB_LOG_AUTOREMOVE olcDbIDLcacheSize: 30000 olcDbIndex: default pres,eq [...] structuralObjectClass: olcHdbConfig olcSyncrepl: {0}rid=0 provider=ldap://second-host.loc0.root bindmethod=s imple binddn="cn=admin,dc=loc0,dc=root" credentials=xxxxxx searchbase="dc=loc0,dc=root" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObj ect)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="60 +" syn cdata=accesslog starttls=yes olcMirrorMode: TRUE [...] On top of this DB I have the "syncprov" and the "accesslog" overlays configured (these are two servers in "MirrorMode", configured following the OpenLDAP admin documentation). I believe this DB is the ones containing the actual "loc0" DIT data... Then I have the accesslog DB for the replica (with the syncprov overlay on top): # cat 'olcDatabase={2}hdb.ldif' dn: olcDatabase={2}hdb objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {2}hdb olcDbDirectory: /var/lib/ldap/accesslog olcSuffix: cn=accesslog olcRootDN: cn=admin,dc=loc0,dc=root olcDbConfig: {0}set_cachesize 0 524288000 1 olcDbConfig: {1}set_lk_max_objects 1500 olcDbConfig: {2}set_lk_max_locks 1500 olcDbConfig: {3}set_lk_max_lockers 1500 olcDbConfig: {4}set_flags DB_LOG_AUTOREMOVE olcDbIndex: default eq olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart [...] On top of this environment I start loading the needed modules with this LDIF file: version: 1 dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: back_ldap - add: olcModuleLoad olcModuleLoad: back_meta - add: olcModuleLoad olcModuleLoad: rwm and it seems I'm able to load the new modules without errors into the configuration, thus I obtain: # cat 'cn=module{0}.ldif' dn: cn=module{0} structuralObjectClass: olcModuleList objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib/ldap olcModuleLoad: {0}back_hdb olcModuleLoad: {1}syncprov olcModuleLoad: {2}accesslog olcModuleLoad: {3}back_ldap olcModuleLoad: {4}back_meta olcModuleLoad: {5}rwm [...] Now I try to load the slapd-meta directives into a new database using this LDIF: version: 1 dn: olcDatabase={3}meta,cn=config objectClass: olcDatabaseConfig objectClass: olcMetaConfig olcDatabase: {3}meta olcSuffix: dc=root olcDbURI: "ldap://server-loc1.loc1.root/dc=loc1,dc=root" olcDbIdAssertBind: bindmethod=simple binddn="cn=admin,dc=loc1,dc=root" credentials=xxxxxx starttls=yes tls_reqcert=demand olcDbURI: "ldap://server-loc2.loc2.root/dc=loc2,dc=root" olcDbIdAssertBind: bindmethod=simple binddn="cn=admin,dc=loc2,dc=root" credentials=xxxxxx starttls=yes tls_reqcert=demand olcDbURI: "ldap://server-loc3.loc3.root/dc=loc3,dc=root" olcDbIdAssertBind: bindmethod=simple binddn="cn=admin,dc=loc3,dc=root" credentials=xxxxxx starttls=yes tls_reqcert=demand but I obtain an error that sticks me trying various combinations without success: # ldapadd -Y EXTERNAL -H ldapi:/// -f slapd-META-DB-CREATION.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "olcDatabase={3}meta,cn=config" ldap_add: Object class violation (65) additional info: attribute 'olcDbURI' not allowed and: # tail /var/log/openldap/slapd.log Nov 9 19:47:17 server01 slapd[32392]: conn=1025 op=2 ENTRY dn="dc=loc0,dc=root" Nov 9 19:47:29 server01 slapd[32392]: conn=1052 op=2 INTERM oid=1.3.6.1.4.1.4203.1.9.1.4 Nov 9 19:49:47 server01 slapd[32392]: conn=1327 op=2 ENTRY dn="dc=loc0,dc=root" Nov 9 19:52:17 server01 slapd[32392]: conn=1628 op=2 ENTRY dn="dc=loc0,dc=root" Nov 9 19:54:46 server01 slapd[32392]: conn=1929 op=2 ENTRY dn="dc=loc0,dc=root" Nov 9 19:57:07 server01 slapd[32392]: Entry (olcDatabase={3}meta,cn=config), attribute 'olcDbURI' not allowed Into the slapd-meta documentation the "URI" directive is mentioned but the "DbURI" seems to raise a "better error", in fact if I try to modify the above LDIF file using "URI" I obtain: SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "olcDatabase={3}meta,cn=config" ldap_add: Undefined attribute type (17) additional info: olcUri: attribute type undefined Moreover, it is not stated into the slapd-meta docs that the slapd-ldap backend is needed by slapd-meta but, anyway, I think its needed because if I try to load the slapd-meta alone it raises an error (I don't remember exactly which one). At this point I'm stuck to this error and I wasn't able to find any hint on the web to solve this :( The examples I was able to find were related with the static slapd.conf configuration, I counldn't find any "full" configuration example using the cn=config. I'm wondering if I should create a "cn=root" actual DB first and then link the sub-DITs to it, or, maybe, add some other overlay... I really can't understand how it should work :( Can please anybody help me? Thank you very much

3 9

Re: slapo-smbk5pwd build fixes
by Quanah Gibson-Mount 05 Nov '16

05 Nov '16

--On Saturday, November 05, 2016 6:30 PM +0200 Emmanuel Dreyfus <manu(a)netbsd.org> wrote: > Hello > > slapo-smbk5pwd does not link with newer OpenSSL,because the old des_* > API was removed. This simple patch uses the new (but available for a > long time) DES_* API to fix that: > http://www.openldap.org/its/index.cgi/Incoming?id=8525;selectid=8525 Hi Emmanuel, The openldap-devel list would be the appropriate place to raise and discuss this. I will try and look into it further on Monday. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

slapo-smbk5pwd build fixes
by manu＠netbsd.org 05 Nov '16

05 Nov '16

Hello slapo-smbk5pwd does not link with newer OpenSSL,because the old des_* API was removed. This simple patch uses the new (but available for a long time) DES_* API to fix that: http://www.openldap.org/its/index.cgi/Incoming?id=8525;selectid=8525 -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: password sync issues
by Arun Gupta 04 Nov '16

04 Nov '16

Hi, Thanks Anirudh.. for response, as I am newbie in openldap, please let me know any already avaliabe script or some tutorial for the same. Regards, Arun and I think it may be also possible if On Thu, 3 Nov 2016, Anirudh Malhotra wrote: > Hi, > > You can write a custom script which whenever the password is set in samba it > sets it for the other tree as well, And you can attach this to the password > changing app also. > > BR, > Anirudh Malhotra > Mail: 8zero2.in(a)gmail.com > Facebook: www.facebook.com/8zero2 > Twitter: @8zero2_in > Blog: blog.8zero2.in > > On Tue, Nov 1, 2016 at 6:49 PM, Arun Gupta <arung(a)cdac.in> wrote: > Hi, > > I have configured 2 ldap tree, one for unix account (ou=User) > (below is sample ldif) > > > dn: uid=2011150,ou=User,dc=acer,dc=in > empID: 2011150 > username: test1 > cn: test1 > centre: PN > objectClass: inetOrgPerson > objectClass: posixAccount > objectClass: top > objectClass: shadowAccount > oldempid: 1150 > mail: test1(a)acer.in > givenName: test1 > uid: 2011150 > shadowLastChange: 15590 > loginShell: /bin/bash > uidNumber: 11150 > gidNumber: 11150 > homeDirectory: /mbox4.2/test1 > userPassword: {SHA}1SrgdEGUPa/U6KM43Kq9xTgnI7A= > > > and another for samba tree (ou=samba) - (below is sample tree) > > dn: uid=test1,ou=samba,dc=acer,dc=in > uid: test1 > sambaSID: S-1-5-21-4079184197-2446238136-3299756537-1005 > displayName: test1 > sambaAcctFlags: [UX ] > objectClass: sambaSamAccount > objectClass: account > sambaLMPassword: C2F63206FC9CF08A1AA818381E4E281B > sambaNTPassword: 0242A7FEC5CD294F916925766089E573 > > and I am able to authenticate with samba configuration. But I am > not able to find out how the password will sync means if user > change his password then how NT password will reflect (here two > different tree). Is it possible to sync, if yes please please > help me out. > > -- > > Thanks & Regards, > > Arun Kumar Gupta > > --------------------------------------------------------------------------- > ---------------------------------------------------- > [ C-DAC is on Social-Media too. Kindly follow us at: > Facebook: https://www.facebook.com/CDACINDIA & Twitter: > @cdacindia ] > > This e-mail is for the sole use of the intended recipient(s) and > may > contain confidential and privileged information. If you are not > the > intended recipient, please contact the sender by reply e-mail > and destroy > all copies and the original message. Any unauthorized review, > use, > disclosure, dissemination, forwarding, printing or copying of > this email > is strictly prohibited and appropriate legal action will be > taken. > --------------------------------------------------------------------------- > ---------------------------------------------------- > > > > > -- Thanks & Regards, Arun Kumar Gupta Mail Administrator HPC Infrastructure and Ecosystem Group Centre for Development of Advanced Computing Savitribai Phule Pune University Campus PUNE-Maharastra Phone : +91-20-25704347 WEB : http://www.cdac.in/ ------------------------------------------------------------------------------------------------------------------------------- [ C-DAC is on Social-Media too. Kindly follow us at: Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. -------------------------------------------------------------------------------------------------------------------------------

2 1

Re: delta-synrepl consumer randomly delete objects
by Quanah Gibson-Mount 03 Nov '16

03 Nov '16

--On Wednesday, October 26, 2016 10:07 AM +0200 Raffael Sahli <public(a)raffaelsahli.com> wrote: >> This is not delta-syncrepl, this is syncrepl. What triggered your >> system to fall back to syncrepl? > Tell me, I really don't know. I can't tell you, it would be in your logs. > Is this as designed? Syncrepl as fall back mechanism if delta-syncrepl > failed? (But I don't know why delta-synrepl failed, > how can I verify that delta-syncrepl does work properly) Correct, if there is an issue, things will fall back to syncrepl. Again, you'd have to look at your logs to determine why it fell back. > However this should not happen with syncrepl anyways. How can it be that > I have only 23 objects left on my consumer after > a full re sync with thousands of objects? Because syncrepl can be buggy? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Provider-Consumer replication 2.4 OLC (second attempt)
by Quanah Gibson-Mount 01 Nov '16

01 Nov '16

--On Friday, October 28, 2016 9:50 AM -0400 Ted Hyde <laserted(a)gmail.com> wrote: > Quanah - thanks for the response. Sorry to insult if I did - but thank > you, I DID read the admin guide. Which as you have also pointed out uses > slapd.conf examples. Since I am not knee-deep in commercial OpenLdap > configuration every day (I am just a lowly IT admin, not a > paid-to-openldap-person) I would disagree in that your comment that > "conversion to cn=config" process isn't trivial, personally I get quite > swamped by it, but push through as best I can. But if you're offering to > convert my sample configs for me, I'd be happy to share them with you. You can convert your sample configs via the slaptest command, as documented. > Or > perhaps you could help the community by providing some OLC config > examples for the admin guide, that way us peons would be able to use that > as our only official source instead of having to google to find "Random" > help. My point was more that converting examples in the admin guide from slapd.conf to cn=config is fairly trivial. For example, if we look at section 18.3.1.2 in the admin guide: database mdb maxsize 1073741824 suffix dc=Example,dc=com rootdn dc=Example,dc=com directory /var/ldap/db index objectclass,entryCSN,entryUUID eq overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 this is rather trivially converted to: dn: olcDatabase={1}mdb objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcSuffix: dc=example,dc=com olcRootDN: dc=example,dc=com olcDbDirectory: /var/ldap/db olcDbIndex: objectClass eq olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcSpCheckpoint: 100 10 olcSpSessionlog: 100 etc. Converting to cn=config from slapd.conf is not particularly difficult. > I *can* move to refreshAndPersist; but the service provides two > documented options (information I got from reading the admin guide), the > description for refreshOnly best fits my scenario and needs. I didn't > read any reason as to *not* use - perhaps you're aware of a bug report > that refreshOnly is broken? I'm aware that operating in refreshOnly is problematic, and it is advise not to use it. If you want to persist in using it, I certainly can't stop you. ;) If/when I find time to rewrite the admin guide, removing it from the examples will be one of the first steps I take. > Perhaps my research (which I'm sure isn't as broad as yours) just seemed > to point to the fact that openldap will/may be depreciating the > slapd.conf procedures, and that everyone should get on board with OLC as > soon as possible. While I can perform the setup with slapd.conf (as noted > in the admin guide), I was hoping to practice some useful technique I > could use in the future. Again, as noted in the documentation, you can set up one time with slapd.conf, and then move forward with converting it to cn=config via slaptest, and then just use cn=config from that point forward, using ldap* commands to make updates as necessary. If you want some further examples of cn=config, you may like the following: <https://git.zimbra.com/repos/zimbra-foss/ZimbraServer/conf/ldap/config/> Which has a basic cn=config layout for a standalone server with a suffix of "" and a few overlays loaded as a starting point. You may also be interested in the tools I wrote for manipulating cn=config to use as examples: <https://git.zimbra.com/repos/zimbra-foss/ZimbraServer/src/libexec/zmldapena…> <https://git.zimbra.com/repos/zimbra-foss/ZimbraServer/src/libexec/zmldapena…> <https://git.zimbra.com/repos/zimbra-foss/ZimbraServer/src/libexec/zmldaprep…> <https://git.zimbra.com/repos/zimbra-foss/ZimbraServer/src/libexec/zmldapmmr…> etc. While bits of it are specific to Zimbra, the ideas behind updating/modifying cn=config are universal. On the documentation, I would note that it is a community effort, and anyone can contribute updates, etc, via the ITS system. The sad fact is, many people complain about the documentation, but very few ever step up and contribute back, which means that it often languishes. I hope the above helps. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

password sync issues
by Arun Gupta 01 Nov '16

01 Nov '16

Hi, I have configured 2 ldap tree, one for unix account (ou=User) (below is sample ldif) dn: uid=2011150,ou=User,dc=acer,dc=in empID: 2011150 username: test1 cn: test1 centre: PN objectClass: inetOrgPerson objectClass: posixAccount objectClass: top objectClass: shadowAccount oldempid: 1150 mail: test1(a)acer.in givenName: test1 uid: 2011150 shadowLastChange: 15590 loginShell: /bin/bash uidNumber: 11150 gidNumber: 11150 homeDirectory: /mbox4.2/test1 userPassword: {SHA}1SrgdEGUPa/U6KM43Kq9xTgnI7A= and another for samba tree (ou=samba) - (below is sample tree) dn: uid=test1,ou=samba,dc=acer,dc=in uid: test1 sambaSID: S-1-5-21-4079184197-2446238136-3299756537-1005 displayName: test1 sambaAcctFlags: [UX ] objectClass: sambaSamAccount objectClass: account sambaLMPassword: C2F63206FC9CF08A1AA818381E4E281B sambaNTPassword: 0242A7FEC5CD294F916925766089E573 and I am able to authenticate with samba configuration. But I am not able to find out how the password will sync means if user change his password then how NT password will reflect (here two different tree). Is it possible to sync, if yes please please help me out. -- Thanks & Regards, Arun Kumar Gupta ------------------------------------------------------------------------------------------------------------------------------- [ C-DAC is on Social-Media too. Kindly follow us at: Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. -------------------------------------------------------------------------------------------------------------------------------

1 0

Re: Public LDAP server, what do I need to know?
by Quanah Gibson-Mount 31 Oct '16

31 Oct '16

--On Sunday, October 16, 2016 3:29 PM -0400 John Lewis <oflameo2(a)gmail.com> wrote: > I want to host a LDAP server that contains a directory that contains the > offices of local Representatives and Public Servants, the issues they > are responsible for, and their names. I would like anyone who wants to > to browse it or put up front ends. > > Is there anything in particular that I should keep in mind? Keep your tree as flat as possible, as deep as necessary, is the guiding wisdom. ;) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Antw: openldap 2.4.40 ppolicy module and shadowInactive equivalent
by Real, Elizabeth (392K) 31 Oct '16

31 Oct '16

Ulrich, Yes, I already have nis.ldif loaded. What else do you suggest? Thank you, Liz From: Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de> Date: Monday, October 24, 2016 at 11:17 PM To: "Real, Elizabeth (392K)" <Elizabeth.Real(a)jpl.nasa.gov>, "openldap-technical(a)openldap.org" <openldap-technical(a)openldap.org> Subject: Antw: openldap 2.4.40 ppolicy module and shadowInactive equivalent "Real, Elizabeth (392K)" <Elizabeth.Real(a)jpl.nasa.gov<mailto:Elizabeth.Real@jpl.nasa.gov>> schrieb am 24.10.2016 um 20:43 in Nachricht <0C90A104-2EF4-4AA6-8748-05B07154A54D(a)jpl.nasa.gov<mailto:0C90A104-2EF4-4AA6-8748-05B07154A54D@jpl.nasa.gov>>: Hello, I setup a password policy overlay on my openldap 2.4.40 servers running RHEL7. I need to enforce the following: disable accounts that have been inactive for 180 days. In the past we were able to do this by simply adding the shadowInactive attribute to each account: shadowInactive 180. But with the new openldap, it appears there is no equivalent attribute?? Why didn't you "grep shadowInactive /etc/openldap/schema/*"? It appears in nis.ldif, nis.schema, and rfc2307bis.schema. (I only have SLES11 SP4 here, but there shouldn't be a big difference) Ulrich http://www.openldap.org/doc/admin24/ http://www.zytrax.com/books/ldap/ch6/ppolicy.html Thank you, Liz

1 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical