openldap-technical

openldap-technical@openldap.org

3 participants
9990 discussions

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

ldap dump filter
by val john 23 Sep '13

23 Sep '13

Hi guys i have openldap server with base url dc=ldap,dc=company,dc=com and our all the users are under ou=users,dc=ldap,dc=company,dc=com within that user base we have users with mail different mail address domains (gmail, yahoo.com , company.com ) by using command "slapcat -l user.ldiff" we can get entire dump of the openldap Is there any way to filter the slapcat dump so the i can get the dump file , only with users with "company.com" mail domain Please advice Thanks John

2 1

OpenLdap 2.4.28 accesslogs
by Steve Herrera 23 Sep '13

23 Sep '13

Hello, I have 2 openldap servers running on Ubuntu 12.04. One is the primary and the other is a slave. My problem is that ldap keeps dumping files into that directory log.00000000001 then log.000000002 and so on thus filling up the drive. Is it safe to remove these logs? How do i know which one it is still using. Ideally it would be great for the server to automatically remove the log once it was done using it. I could set up a cronjob to prune it but I don't know how far back it needs to the logs to be. Any ideas? Thanks

4 4

Wrong certificate being presented
by espeake＠oreillyauto.com 23 Sep '13

23 Sep '13

The authentication works on the single server we have which is running an older version of openLDAP (2.4.21). In my packet captures it appears that the older version of openLDAP is presenting the certificate we want it to present. The new version (2.4.31), although it has the same cert installed in the same place it is presenting an older self signed cert that has been removed. The new servers have been rebooted since this change so where could this possibly be cached at? This is from my slapcat of the new servers. dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcAuthzPolicy: any olcPidFile: /var/run/slapd/slapd.pid olcServerID: 1 ldap://tntest-ldap-3.example.com olcServerID: 2 ldap://tntest-ldap-1.example.com olcServerID: 3 ldap://tntest-ldap-2.example.com olcThreads: 8 olcTLSCACertificateFile: /etc/ldap/gd_bundle.crt olcTLSCertificateFile: /etc/ldap/wildcard.example.com.crt olcTLSCertificateKeyFile: /etc/ldap/wildcard.example.com.key olcToolThreads: 1 structuralObjectClass: olcGlobal creatorsName: cn=config entryUUID: 91cc0ae0-9e13-1032-84b5-0151b658a842 createTimestamp: 20130820183919Z olcLogLevel: config acl stats conns olcTLSCipherSuite: NORMAL olcTLSCRLCheck: none olcTLSVerifyClient: never entryCSN: 20130923150907.574575Z#000000#001#000000 modifiersName: uid=admin,dc=oreillyauto,dc=com modifyTimestamp: 20130923150907Z contextCSN: 20130923150907.574575Z#000000#001#000000 contextCSN: 20130923150843.855673Z#000000#002#000000 contextCSN: 20130919185322.242639Z#000000#003#000000 I tried doing an ldapmodify and delete the olcTLSCipherSuite and olcTLSCRLCheck that I added and they will not disappear. 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.

1 1

Re: Invalid DN
by Justin Brown 19 Sep '13

19 Sep '13

Quanah, Thanks for the reply. That ended up being the problem. I figured the olcAccess line would allow anonymous searches, but I changed it to "to * by users read by users write" and actually created the cn=admin,dc=appName,dc=app simpleSecurityObject. Cheers, J On Thu, Sep 19, 2013 at 3:07 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Thursday, September 19, 2013 2:35 PM -0500 Justin Brown > <justin.brown(a)fandingo.org> wrote: > >> The problem is that I can't locate these objects using the ldap tools >> (ldapsearch and python-ldap). > > > You are doing anonymous searches. Likely you haven't granted anonymous > access to read these entries. > > Try ldapsearch -x -b "..." -D "..." -W > > with the values that are correct for your installation. > > --Quanah > > > -- > > Quanah Gibson-Mount > Lead Engineer > Zimbra Software, LLC > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

Invalid DN
by Justin Brown 19 Sep '13

19 Sep '13

Hello, I'm struggling to setup my Hdb database in OpenLDAP. I'm trying to create the entire directory from ldif files with cn=config. I have two initialization ldifs. The first one creates all the cn=config stuff, and also creates my Hdb database. The first file is too long to completely list here (I included core, cosine, nis, and inetorgperson schema ldifs.), but I'll put some excerpts here. dn: cn=config objectClass: olcGlobal cn: config ... dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema ... dn: cn={0}core,cn=schema,cn=config objectClass: olcSchemaConfig cn: {0}core ... (There are lots more for the other included schemas. I also have three custom objectClasses in cn=schema,cn=config, and one custom attributeType there, too.) The file finishes with the database configurations. dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend ... dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by * none olcRootDN: cn=config olcRootPW: secret ... dn: olcDatabase={1}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {1}hdb olcSuffix: dc=appName,dc=app olcDbDirectory: /var/lib/ldap olcRootDN: cn=admin,dc=appName,dc=app olcRootPW: secret olcAccess: to * by * write by * read ... This file runs successfully with slapadd: sudo -u ldap slapadd -l init.ldif -F /etc/openldap/slapd.d -n0 The second file is very simple and just sets up the root objects in my database. dn: dc=appName,dc=app objectClass: top objectClass: dcObject objectclass: domain dc: addressbook dn: dc=directory,dc=appName,dc=app objectClass: top objectClass: domain dc: directory This also runs successfully with sudo -u ldap slapadd -l init2.ldif -F /etc/openldap/slapd.d -n1 Now if I use slapcat to view the directory, I see those objects: sudo slapcat 523b5022 hdb_monitor_db_open: monitoring disabled; configure monitor database to enable dn: dc=appName,dc=app objectClass: top objectClass: dcObject objectClass: domain dc: addressbook structuralObjectClass: domain entryUUID: 37f1bd06-b5ad-1032-824f-6ffc71c73dcf creatorsName: cn=admin,dc=appName,dc=app createTimestamp: 20130919192708Z entryCSN: 20130919192708.309183Z#000000#000#000000 modifiersName: cn=admin,dc=appName,dc=app modifyTimestamp: 20130919192708Z dn: dc=directory,dc=appName,dc=app objectClass: top objectClass: domain dc: directory structuralObjectClass: domain entryUUID: 37f4023c-b5ad-1032-8250-6ffc71c73dcf creatorsName: cn=admin,dc=appName,dc=app createTimestamp: 20130919192708Z entryCSN: 20130919192708.324059Z#000000#000#000000 modifiersName: cn=admin,dc=appName,dc=app modifyTimestamp: 20130919192708Z The problem is that I can't locate these objects using the ldap tools (ldapsearch and python-ldap). ldapsearch -xb 'dc=addressbook,dc=app' gives result: 34 Invalid DN syntax text: invalid DN If I don't specify a base DN, then I get 32: No such object: ldapsearch -x '(objectClass=*)' # extended LDIF # # LDAPv3 # base <> (default) with scope subtree # filter: (objectClass=*) # requesting: ALL # # search result search: 2 result: 32 No such object Does anyone know why I cannot see my objects through the LDAP "interface?" My configuration seems entirely consistent with http://www.openldap.org/doc/admin24/slapdconf2.html. Thanks, J

2 1

PFS Ciphers
by manu＠netbsd.org 19 Sep '13

19 Sep '13

Hi I tried to use ciphers that bring PFS for OpenLDAP, but it did not work. I used this cipher specification: TLSCipherSuite ECDH:DH:!SHA:!MD5:!aNULL:!eNULL I test it this way: for i in `openssl ciphers ALL|tr ':' '\n'` ; do echo ''|openssl s_client -cipher $i -connect server:636 \ 2>/dev/null |awk '/ Cipher/{print }' ; done I get nothing. I understand ECDH needs some support code, but why aren't DH ciphers available? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

4 4

TLS negation failure
by espeake＠oreillyauto.com 19 Sep '13

19 Sep '13

We have a client server that is failing on the ssl handshake using TLS. The following is from the server log when the client is trying to connect. Sep 19 09:12:49 tntest-ldap-3 slapd[18796]: conn=3534 fd=28 ACCEPT from IP=172.17.1.10:55469 (IP=0.0.0.0:389) Sep 19 09:12:49 tntest-ldap-3 slapd[18796]: conn=3534 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Sep 19 09:12:49 tntest-ldap-3 slapd[18796]: conn=3534 op=0 STARTTLS Sep 19 09:12:49 tntest-ldap-3 slapd[18796]: conn=3534 op=0 RESULT oid= err=0 text= Sep 19 09:12:50 tntest-ldap-3 slapd[18796]: conn=3534 fd=28 closed (TLS negotiation failure) On the client when I run the following: openssl s_client -showcerts -connect tntest-ldap.oreillyauto.com:389 I get this on the client CONNECTED(00000003) 139669033973408:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:177: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 226 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE If I do the same command on port 636 I can see the certificate. All of our applications that use ldap are all set for TLS. Even if I force them to port 636 they fail. Any ideas to look at are appreciated. 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 2

auditing failed login attempts
by Paul B. Henson 18 Sep '13

18 Sep '13

Our security group is hassling us because we don't currently provide them an audit log of failed login attempts on our LDAP servers. For most of our other systems, we simply provide them a syslog feed with this information. However, openldap doesn't appear to have a logging level that provides detail about login attempts on a single line, but rather across many lines that would need to be correlated. It seems more like connection debugging logging as opposed to authentication logging. It looks like we might need to set up an accesslog overlay to log all of the attempted binds and then have a separate process that runs through that and generates the syslog feed to our ISO group's central logging server? That's a bit more overhead than I would like. Are there any other simpler ways of generating failed login logs? Thanks much.

5 8

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical