openldap-technical

openldap-technical@openldap.org

9 participants
9868 discussions

Slapd permission issues
by Gary Slopsema 27 Sep '13

27 Sep '13

Hello, I'm trying to run slapd as a non-root user and am having difficulties. As part of a test suite for a library I'm working on, I'd like to automate starting and stopping slapd with various configs, with relatively-pathed config files, etc. I'm having an issue running slapd with a custom config "slapd.conf" that's not located at /etc/ldap/slapd.conf. Example: ==================== vagrant@lucid64:~/slapd$ pwd /home/vagrant/slapd vagrant@lucid64:~/slapd$ ls -l total 8 drwxr-xr-x 2 vagrant vagrant 4096 2013-09-27 21:14 schema -rw-r--r-- 1 vagrant vagrant 440 2013-09-27 21:15 slapd.conf vagrant@lucid64:~/slapd$ sudo slapd -h ldap://localhost:10000 -d 2048 -f slapd.conf @(#) $OpenLDAP: slapd 2.4.21 (Dec 19 2011 15:40:04) $ buildd@allspice:/build/buildd/openldap-2.4.21/debian/build/servers/slapd could not open config file "slapd.conf": Permission denied (13) slapd stopped. connections_destroy: nothing to destroy. ==================== The problem is with the "Permission denied": why can't slapd read slapd.conf? But if I copy the same slapd.conf to /etc/ldap, I get ==================== vagrant@lucid64:~/slapd$ ls -l /etc/ldap/ total 20 -rw-r--r-- 1 root root 245 2011-12-19 17:19 ldap.conf drwxr-xr-x 2 root root 4096 2011-12-19 17:19 sasl2 drwxr-xr-x 2 root root 4096 2013-09-27 20:26 schema -rw-r--r-- 1 root root 440 2013-09-27 21:21 slapd.conf drwxr-x--- 3 openldap openldap 4096 2013-09-27 20:26 slapd.d vagrant@lucid64:~/slapd$ sudo slapd -h ldap://localhost:10000 -d 2048 -f /etc/ldap/slapd.conf @(#) $OpenLDAP: slapd 2.4.21 (Dec 19 2011 15:40:04) $ buildd@allspice:/build/buildd/openldap-2.4.21/debian/build/servers/slapd could not stat config file "./core.schema": No such file or directory (2) slapd stopped. connections_destroy: nothing to destroy. ==================== which doesn't run (I have relative schema directives in the config file) but at least slapd can read the file. Note that using an absolute path in the first example has the same result; feeding in a non-existent file gives a different error ("could not stat"). Also, I'm using sudo above just to ease things along; eventually it'll run as a normal user. I'm running Ubuntu Lucid 64-bit. Am I missing something obvious? Thanks, Gary

2 1

cn=config chaining
by Jancewicz, Russell 26 Sep '13

26 Sep '13

Hello, I have been trying to configure my slave ldap servers to send changes to the master servers. >From what I have been able to understand from previous mailing lists and various google searches I need to configure and olcUpdateref on the salve and then add the chaining overlay (I think it should be on the olcDatabase{-1}frontend database from everything I have read however slaptest using openldap-2.4.36 slapd-chain2.conf as the seed generates the overlay atop of the declared database…) Everything I have been trying results in a failure: ldap_modify: Server is unwilling to perform (53) additional info: operation restricted I cannot for the life of me figure out what needs to be done to enable this. Any help would be appreciated, my ldifs are included below. -Russell J. Jancewicz University of Connecticut dn: olcDatabase={1}mdb,cn=config … olcUpdateref: ldap://master.example.com … dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {0}chain olcChainCacheURI: FALSE olcChainMaxReferralDepth: 1 olcChainReturnError: FALSE dn: olcDatabase=ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: ldap olcDbURI: "ldap://master.example.com" olcDbStartTLS: start starttls=no olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical bindmethod=simple timeout=0 network-timeout=0 binddn="cn=admin,dc=example,dc=com" credentials="<SECRET>" keepalive=0:0:0 olcDbIDAssertAuthzFrom: * olcDbRebindAsUser: FALSE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: FALSE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbSessionTrackingRequest: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbOnErr: continue olcDbKeepalive: 0:0:0

3 6

Other system use port 636 connect LDAP Server Error
by Tian Zhiying 26 Sep '13

26 Sep '13

Hi In ldap server(localhost) , I execute the below command , it ok. # ldapsearch -x -b 'ou=people,dc=mydomain,dc=com' -D "cn=interface,dc=mydomain,dc=com" -H ldaps://192.168.1.10 -W But in other linux system is not ok, below is the error info: # ldapsearch -x -b 'ou=people,dc=mydomain,dc=com' -D "cn=interface,dc=mydomain,dc=com" -H ldaps://192.168.1.10 -W ldap_bind: Can't contact LDAP server (-1) additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed LDAP Server is Centos 5.8 64 OS, iptables serverice is closed state. What is the cause? You have any Suggestions? Thanks. Tian Zhiying

5 7

contextCSN values and MMR
by Michael Ströder 26 Sep '13

26 Sep '13

HI! Are contextCSN values on all replicas really in sync if changes were correctly replicated? I've implemented a monitoring check used with normal MMR setup (OpenLDAP 2.4.35, own build on Debian Squeeze) which also checks the contextCSN values on all replicas compared by server-id. Sometimes we observe, even in isolated tests, that contextCSN values for a certain server-id differ for quite a while (up to hours) even though the changes coming from that server were definitely replicated to all other replicas. After a while the contextCSN values get suddenly updated. Unfortunately this does not always happen. Any hint is highly appreciated. Ciao, Michael.

4 19

RE: openldap-technical Digest, Vol 70, Issue 20
by Sotomayor, Vicente (ITD) 26 Sep '13

26 Sep '13

>Message: 12 >Date: Thu, 26 Sep 2013 16:35:38 +0800 >From: "Tian Zhiying" <tianzy1225(a)thundersoft.com> >To: openldap-technical <openldap-technical(a)openldap.org> >Cc: tianzy1225 <tianzy1225(a)thundersoft.com> >Subject: Other system use port 636 connect LDAP Server Error >Message-ID: <2013092616353831259123(a)thundersoft.com> >Content-Type: text/plain; charset="us-ascii" >Hi >In ldap server(localhost) , I execute the below command , it ok. ># ldapsearch -x -b 'ou=people,dc=mydomain,dc=com' -D "cn=interface,dc=mydomain,dc=com" -H ldaps://192.168.1.10 -W >But in other linux system is not ok, below is the error info: ># ldapsearch -x -b 'ou=people,dc=mydomain,dc=com' -D "cn=interface,dc=mydomain,dc=com" -H ldaps://192.168.1.10 -W >ldap_bind: Can't contact LDAP server (-1) > additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed >LDAP Server is Centos 5.8 64 OS, iptables serverice is closed state. What is the cause? >You have any Suggestions? Thanks. Because the telnet test worked then I would look at your client config files on that hosts in addition to seeing if the file size/permission of the cert matches the size on the other client that is working. Also try ldapsearch -x -d 1 and see what the output shows.

1 0

Re: SSL replication deadlocks slapd
by Chad Scott 26 Sep '13

26 Sep '13

Message definitely received. =) I've actually discovered http://ltb-project.org/... Any thoughts on how reputable their build is? On Wed, Sep 25, 2013 at 3:24 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > --On Wednesday, September 25, 2013 2:32 PM -0700 Chad Scott < > cscott(a)appdynamics.com> wrote: > > >> Definitely not an entropy problem. I see "ACCEPT" in the logs, but >> nothing else. >> >> >> I hadn't realized RedHat was so damn behind. I'm going to generate a >> custom package with the latest version and see if the problem goes away. >> > > Note that RedHat links to its own broken SSL implementation MozNSS. I > don't know if Scientific linux went the same route or not, which is why I > (again) recommend linking (sanely) to a current version of OpenSSL. > > > --Quanah > > -- > > Quanah Gibson-Mount > Lead Engineer > Zimbra Software, LLC > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

2 1

SSL replication deadlocks slapd
by Chad Scott 26 Sep '13

26 Sep '13

I'm having a lot of trouble with replication when using SSL. If I configure everything exactly the same without SSL, it works flawlessly. The instant I try to encrypt traffic, one or both servers will deadlock, even after restart. I'm configuring according to the instructions at http://www.openldap.org/doc/admin24/replication.html#N-Way Multi-Master, except using ldaps:// instead of ldap://. In cn=config, I've setup: olcTLSCACertificateFile: /etc/openldap/certs/Operations_CA_Certificate.pem olcTLSCertificateFile: /etc/openldap/certs/ldap.pem olcTLSCertificateKeyFile: /etc/openldap/certs/ldap.key I've also tried using STARTTLS over ldap:// and it seems to make no difference. Permissions are right and I can connect via SSL from clients without issue. I'm completely stumped as to what might be going on. Has anyone seen this before? This is running on Scientific Linux 6 with the following packages: openldap-2.4.23-32.el6_4.x86_64 openldap-clients-2.4.23-32.el6_4.x86_64 openldap-servers-2.4.23-32.el6_4.x86_64

3 4

Schema With Multi Part Attribute
by Bram Cymet 26 Sep '13

26 Sep '13

Hi, I am wondering if it is possible to create a schema with a multi part attribute. In other words I want the value of the attribute to be a dictionary. For example I would have an attribute called "Application" which would have a value of: {"name" : "Application Name", "active" : <True or False>} The other way I was thinking about doing this was to just have a multi value string attribute that would be the names of the "applications" and if there was an entry then that "application" is active but the dictionary way just seems cleaner to me. If this is possible an example of how to define the schema entry or a link to an RFC would be helpful. Thanks, -- Bram Cymet Software Developer Canadian Bank Note Co. Ltd. 613-608-9752

2 3

Access being denied.
by espeake＠oreillyauto.com 24 Sep '13

24 Sep '13

I know this has to be super simple in what I am missing. My ldapadmin account cannot write to the database due to insufficient privileges.. This is the ACL part of the ldif file. Version 2.4.31 and this is from olcDatabase={1}hdb.ldif olcAccess: {0}to attrs=userPassword by dn="uid=admin,dc=oreillyauto,dc=com" wr ite by anonymous auth by self write by * none olcAccess: {1}to dn.subtree="" by * read olcAccess: {2}to * by dn="uid=admin,dc=oreillyauto,dc=com" write by dn="uid=ld apadmin,ou=System,dc=oreillyauto,dc=com" write by * read olcAccess: {2} for ldap admin actually be 'dn.base="uid=ldapadmin,ou-System, dc=<domain>,dc=com" write'? Thanks Eric Speake Web Systems Administrator O'Reilly Auto Parts This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS � 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.

2 4

Fw: Access being denied.
by espeake＠oreillyauto.com 24 Sep '13

24 Sep '13

Eric Speake Web Systems Administrator O'Reilly Auto Parts ----- Forwarded by Eric Speake/OReilly on 09/24/2013 06:31 AM ----- From: Eric Speake/OReilly To: Jason Brandt <jbrandt(a)fsmail.bradley.edu> Cc: openlda-technical(a)openldap.org Date: 09/24/2013 06:16 AM Subject: Re: Access being denied. From: Jason Brandt <jbrandt(a)fsmail.bradley.edu> To: espeake(a)oreillyauto.com Cc: "openldap-technical(a)OpenLDAP.org" <openldap-technical(a)openldap.org> Date: 09/23/2013 03:26 PM Subject: Re: Access being denied. I hope this doesn't confuse you too much... First off... Your admin account will be dn="cn=admin,dc=oreillyauto,dc=com", if you are talking about the default admin account. You also want manage instead of write. I would also recommend securing your admin account with access lists, only allowing access from specific manager IP addresses. In order to restrict the cn=admin account as I do below, you have to set the userPassword attribute for the admin account, and blank the olcRootPW. set admin password: dn: cn=admin,dc=bradley,dc=edu changeType: modify add: userPassword userPassword: {SSHA}<passwordhash> blank old olcRootPW dn: olcDatabase={1}hdb,cn=config changetype: modify delete: olcRootPW This allows use of the normal authentication process and will look at your access lists. Otherwise, it will always bypass access lists and use the olcRootPW to authenticate. Here's how I handle access restrictions, which I would suggest you evaluate. This is a positive security model as well (meaning the default action is deny), which I highly recommend (ie no one can access any field, unless it's specifically defined). The downside to the positive security model is that it's less flexible, you have to whitelist any new attributes you wish users to access, but it provides you with the best security. Another note in this, is that my user accounts are all shadowAccounts, and setting shadowInactive to 1 disables the account. (handled by the 3rd section with password fields). Here is my access list in a template form: dn: olcDatabase={1}hdb,cn=config changetype: modify replace: olcAccess # limit access to directory manager to local host only and specific manager ip's olcAccess: to dn.base="cn=admin,dc=,dc=" by peername.ip=127.0.0.1 auth by sockurl=ldapi:/// auth by peername.ip=<manager IP> auth by users none by anonymous none #Allow admin users full access to all attrs #Allow OpenLDAP2 Sync User read access to all #Everyone else, continue olcAccess: to * by peername.ip=172.16.0.0%255.255.0.0 dn="uid=adminuser,dc=,dc=" manage by peername.ip=<secondary ldap server ip> dn="uid=syncuser,ou=Service_Logins,dc=,dc=" read by peername.ip=<third ldap server ip> dn="uid=syncuser,ou=Service_Logins,dc=,dc=" read by * break #Handle password fields, for all possible entities. No further processing for these attributes olcAccess: to attrs=userPassword,shadowLastChange filter= (&(objectClass=shadowAccount)(!(shadowInactive=1))) by self =w by sockurl=ldapi:/// auth by peername.ip=172.16.0.0%255.255.0.0 auth by peername.ip=127.0.0.1 group.exact="cn=localadmingroup,dc=,dc=" manage by group.exact="cn=admingroup,dc=,dc=" write by * none #Specific processing for an Account #Everyone else, continue olcAccess: to attrs=attr1,attr2 by dn="uid=account1,ou=Service_Logins,dc=,dc=" read by * break #Specific processing for a Group #Everyone else, continue olcAccess: to attrs=attr3,attr4 by group.exact="cn=group1,out=Group,dc=,dc=" manage by * break #Handle SELF writable fields #Everyone else, continue olcAccess: to attrs=loginShell,mailRoutingAddress,additionalattrs by self write by * break #Handle more restrictive fields #Stop processing on match olcAccess: to attrs=audio,attr5,attr6,attr7 filter=(&(matchTrue=1)(objectClass=Person)) by * none #Handle Anonymous Allowed fields #Stop Processing on Match olcAccess: to attrs=attr8,attr9,attr10 by * read #Handle User Allowed Fields #Stop Processing on Match olcAccess: to dn.subtree="dc=,dc=" attrs=audio by users read #Hide additional superuser accounts in directory olcAccess: to attrs=entry filter=(|(ou=Service_Logins)(uid=logins)) by * none #Allow access to specific objectclasses olcAccess: to filter=(| (objectClass=nisDomainObject)(objectClass=nisNetGroup)(objectClass=posixGroup)(objectClass=groupOfUniqueNames)(objectClass=organizationalUnit)) by * read #Allow access to directory entries. Required to query directory when using default deny policy olcAccess: to dn.subtree="dc=,dc=" attrs=entry,objectClass by * read #Default Deny olcAccess: to * by * none Jason, Thanks for the layout and I will take this to my bosses. I might have to group the servers because we have several servers that access the out LDAP servers and by IP address would be a little cumbersome to manage. We use somewhere in the range of 140 different applications on our internal network and accessed by our stores across the country. so we use different accounts to do different types of access depending on the application so we don't use just one admin account and this works on the old LDAP server running 2.4.21 But when I try to replicate the ACL's it has, nothing works. so for the time being I have simplified as recommended by this community and then I will work on tightening down the reigns. Right now I need to figure out why my ldapadmin account doesn't have write permissions in accordance with my ACL on the servers. Is it as simple as a syntax issue. The other issue I mentioned is starting to get a little annoying in the fact that I cannot seem to modify my config. The changes don't happen but the modify timestamp changes. I can deal with that issue later. Right now I need to get this user working. Thanks, Eric Speake Web Systems Administrator O'Reilly Auto Parts. On Mon, Sep 23, 2013 at 12:08 PM, <espeake(a)oreillyauto.com> wrote: I know this has to be super simple in what I am missing. My ldapadmin account cannot write to the database due to insufficient privileges.. This is the ACL part of the ldif file. Version 2.4.31 and this is from olcDatabase={1}hdb.ldif olcAccess: {0}to attrs=userPassword by dn="uid=admin,dc=oreillyauto,dc=com" wr ite by anonymous auth by self write by * none olcAccess: {1}to dn.subtree="" by * read olcAccess: {2}to * by dn="uid=admin,dc=oreillyauto,dc=com" write by dn="uid=ld apadmin,ou=System,dc=oreillyauto,dc=com" write by * read olcAccess: {2} for ldap admin actually be 'dn.base="uid=ldapadmin,ou-System, dc=<domain>,dc=com" write'? Thanks Eric Speake Web Systems Administrator O'Reilly Auto Parts This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS § 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you. -- Jason K. Brandt Systems Administrator Bradley University (309) 677-2958 -- This message has been scanned for viruses and dangerous content, and is believed to be clean. Message id: A1B06600D64.A7776 This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS § 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical