openldap-technical October 2016

openldap-technical@openldap.org

44 participants
57 discussions

Problem with "force user to password reset at first login
by Rajagopal Rc 30 Oct '23

30 Oct '23

Hi, I am trying to force users to change their password at first login or after password reset by administrator. Tried following: 1)Password policy 'pwdMustChange TRUE' doesn't seems to be working as non of the users get prompt to change their password at first login. 2) used the 'pwdReset TRUE' attribute in users attributes, and it won't prompt to change the password and didn't allow to login i observe below messages in log "slapd[12684]: connection restricted to password changing only slapd[12684]: send_ldap_result: err=50 matched="" text="Operations are restricted to bind/unbind/abandon/StartTLS/modify password" slapd[12684]: conn=1053 op=1 SEARCH RESULT tag=101 err=50 nentries=0 text=Operations are restricted to bind/unbind/abandon/StartTLS/modify password" Please help me configure the option to force all users to change their password at first login or after pwd reset by administrator. Thanks & Regards Raj Tata Consultancy Services Mailto: rajagopal.rc(a)tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you

5 9

How to enable memberOf overlay with posixGroup?
by MegaBrutal 16 Aug '17

16 Aug '17

Hi all, I've spent days trying to figure out how could I enable the memberOf overlay, and it doesn't seem to be easy for an LDAP-noob. I've read like 50+ tutorials which didn't help me get it working. Use case: I want to have 2 main groups which control access to different services on my network. A "unixusers" which is a minimum to log in to Linux servers (having a hostObject entry for the user is another requirement, which is irrelevant to this question, as I already solved that problem); and a "cloudusers" group which enables log in to my ownCloud instance. The groups should enforce the following rules: – Only users in "cloudusers" should be allowed to log in to ownCloud. – Users in "unixusers" are allowed to log in to a set of Linux servers controlled by "host" (hostObject) entries. – Users not in the "unixusers" group may not log in to any Linux systems, even if they have "host" entries. Problems: – ownCloud complains that the memberOf overlay is not enabled, hence it doesn't let me restrict access to the "cloudusers" group. It would allow any users regardless of any group memberships, which is not acceptable. – I have a similar problem on Linux with PAM: I can't really get it to consider "unixusers" membership for user logins, although I got the "host" entries working correctly, so at least I can already restrict access with that. My guess is that it all boils down to the lack of memberOf overlay. I also figured that memberOf would need groupOfNames groups, while I need posixGroup type groups. I evaluated the possibility to use groupOfNames, but it lacks the necessary gidNumber attribute which is a requirement for Unix groups. But anyway, I can't enable memberOf even for groupOfNames. I can't enable memberOf by any means. My OpenLDAP uses the new configuration method and it completely ignores slapd.conf, so the config must be injected with ldapadd to cn=config. Could you please help me with this? Regards, MegaBrutal

5 6

[Q] "selective" ACL
by Zeus Panchenko 26 Jul '17

26 Jul '17

hi, I'm trying to configure a not complex (as I believe) ACL ... but have some difficulties I have two posixGroup groups cn=admins,ou=group,dc=foo cn=coadmins,ou=group,dc=foo my users resides in ou=People,dc=foo so, in subtree ou=People,dc=foo I need to allow anything to admins (and it is not difficult of course) for example this works for me: access to dn.subtree="ou=People,dc=foo" by set="[cn=admin,ou=group,dc=foo]/memberUid & user/uid" manage by self write by users read by * break but in addition I need to allow my coadmins to do the same things except manipulations upon the objects which belong to admins ( ...anyobject,uid=adminuser,ou=People,dc=foo ) so, the question is: how? (if it is possible at all) :( please, advise -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET)

2 2

Can't add "same" mail attribute with different cases.
by Patrick Zacharias 21 Nov '16

21 Nov '16

3 3

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: 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: 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

Re: Syncrepl only partially working
by Quanah Gibson-Mount 31 Oct '16

31 Oct '16

--On Sunday, October 30, 2016 11:16 AM +0100 Dieter Klünter <dieter(a)dkluenter.de> wrote: > It is a bit more complicated than that. > syncrepl is a client operation, which requires ldap client > configuration, specified in ldap.conf(5). You can set these specifically for the syncrepl client as a part of your syncrepl configuration stanza, rather than ldap.conf. See slapd.conf(5) or slapd-config(5), the section on syncrepl/olcSyncRepl, the sizelimit and timelimit parameters. But, regardless, the server limits on the master trump any client settings that are higher than the defaults, so as Dieter noted, they must be increased on the master to "unlimited" for at least the replicator DN. This is of course covered in the admin guide. For example, in section 18.3.2, we find: # Let the replica DN have limitless searches limits dn.exact="cn=replicator,dc=symas,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited as one example. etc. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Defining timeouts in slapd-ldap Backend
by Daniel Betz 31 Oct '16

31 Oct '16

Hi List, i have an problem with slapd-ldap backend and the timeouts. There are many timeouts to configure, but i think they dont work in the tls handshake phase. 5816f773 send_ldap_result: conn=-1 op=0 p=0 5816f773 backend_startup_one: starting "sid=3092,sec=webhosting,o=xxxxxx,c=de" 5816f773 ldap_back_db_open: URI=ldaps://sid3092.int.webslave.xxxxxxx ldap_create ldap_url_parse_ext(ldaps://sid3092.int.webslave.xxxxxxxx) 5816f773 =>ldap_back_getconn: conn=-1 op=0: lc=0x37c2880 inserted refcnt=1 rc=0 ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP sid3092.int.webslave.xxxxxxxxx:636 ldap_new_socket: 256 ldap_prepare_socket: 256 ldap_connect_to_host: Trying 10.xx.xx.xx:636 ldap_pvt_connect: fd: 256 tm: 5 async: 0 ldap_ndelay_on: 256 attempting to connect: connect errno: 115 ldap_int_poll: fd: 256 tm: 5 ldap_is_sock_ready: 256 ldap_ndelay_off: 256 ldap_pvt_connect: 0 TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A And then the slapd hangs and hangs. I know that the consumer ldap is running, but the server itself hangs with an error. In this slapd there are 250 more servers to serve via slapd-ldap, so this will cause an big problem when only one server hangs and the slapd stucks forever. Are there any other timeouts to configure in slapd-ldap backend ? Here´s the slapd.conf: database ldap hidden on suffix "sid=3092,sec=webhosting,o=xxxxxxxx,c=de" rootdn "cn=xxxxxxxx,sid=3092,sec=webhosting,o=xxxxxxxxx,c=de" uri ldaps://sid3092.int.webslave.xxxxxxxxx network-timeout 5 timeout bind=5 lastmod on restrict all acl-bind bindmethod=simple binddn="cn=xxxxxx,sid=3092,sec=webhosting,o=xxxxxx,c=de" credentials="PASSWORD" syncrepl rid=3092 provider=ldapi://%2Fvar%2Frun%2Fldapi binddn="cn=Manager,o=xxxxxxxxxxx,c=de" bindmethod=simple credentials=PASSWORD searchbase="sid=3092,sec=webhosting,o=xxxxxxxxxx,c=de" type=refreshAndPersist retry="10 6 30 +" overlay syncprov Regards, Daniel Freundliche Grüße, Daniel Betz System Design Engineer / Senior Systemadministration ___________________________________ domainfactory GmbH Oskar-Messter-Str. 33 85737 Ismaning Germany Telefon: +49 (0)89 / 55266-364 Telefax: +49 (0)89 / 55266-222 E-Mail: dbetz(a)df.eu<mailto:dbetz@df.eu> Internet: www.df.eu<http://www.df.eu/> Registergericht: Amtsgericht München HRB-Nummer 150294, Geschäftsführer: Tobias Mohr, Stephan Wolfram

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical October 2016