openldap-technical

openldap-technical@openldap.org

20 participants
9802 discussions

Replication Through A DMZ
by Anton Chu 18 Nov '10

18 Nov '10

I have a provider server in the intranet and I want to add a consumer server in a DMZ for replication. The problem is that a connection can only be initiated from the intranet to the DMZ. I've read both refreshandpersist and refesh-only replications both require an initial connection from the consumer server which will be in the DMZ. Should I put the provider server in the DMZ instead? TIA Regards..

3 4

Authenticating with an alias entry
by Angel L. Mateo 18 Nov '10

18 Nov '10

Hi, Is it possible to authenticate with openldap (version 2.4.21) using an entry that is actually an alias to another entry? -- Angel L. Mateo Martínez Sección de Telemática Área de Tecnologías de la Información _o) y las Comunicaciones Aplicadas (ATICA) / \\ http://www.um.es/atica _(___V Tfo: 868887590 Fax: 868888337

2 1

RE: Pass-Through authentication
by Paulo Jorge N. Correia (paucorre) 17 Nov '10

17 Nov '10

Jonathan and all, Need your support ..... what should be the configuration of saslauthd.conf in the case where I have a slapd.conf configuration where I use a back-meta to aggregate different hdb databases that are synchronized against AD Domain Controllers. Paulo -----Original Message----- From: Paulo Jorge N. Correia (paucorre) Sent: Tuesday, November 16, 2010 7:01 PM To: Jonathan Clarke; openldap-technical(a)openldap.org Subject: RE: Pass-Through authentication Johanathan, I decide to follow both of the options, and test which one is better :) : 1 - back-meta 2 - change the saslauthd from ldap to Kerberos Regarding back meta I need help :( In the slapd.conf I have an database created for back-meta..... ( strange thing is that it didn't worked when I create a separate conf file per each database "include /etc/openldap/slapd_domain1.conf", only working if I add all the database in the same file as showed below ) No what should I configure in the saslauthd.conf file..... if I direct ldap_servers how does it know which AD is associated with each user ? ________________________________________________________________________ ___ [root@openam-ldap openldap]# more ../saslauthd.conf ldap_servers: ldap://localhost ldap_search_base: dc=cisco,dc=com ldap_timeout: 10 ldap_filter: uid=%u ldap_bind_dn: cn=admin,dc=cisco,dc=com ldap_password: Cisco,123 ldap_deref: never ldap_restart: yes ldap_scope: sub ldap_use_sasl: no ldap_start_tls: no ldap_version: 3 ldap_auth_method: bind ____________________________________________________________________ [root@openam-ldap openldap]# more slapd.conf # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/java.schema include /etc/openldap/schema/openldap.schema allow bind_v2 pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args sasl-host localhost sasl-secprops none database meta suffix "dc=cisco,dc=com" uri "ldap://localhost/ou=domain1,dc=cisco,dc=com" suffixmassage "ou=domain1,dc=cisco,dc=com" "ou=domain1" uri "ldap://localhost/ou=domain2,dc=cisco,dc=com" suffixmassage "ou=domain2,dc=cisco,dc=com" "ou=domain2" database hdb suffix "ou=domain1" directory "/var/lib/ldap/domain1" rootdn "cn=admin,ou=domain1" rootpw "Cisco,123" index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uid eq,pres,sub database hdb suffix "ou=domain2" directory "/var/lib/ldap/domain2" rootdn "cn=admin,ou=domain2" rootpw "Cisco,123" index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uid eq,pres,sub _______________________________________________________________ Thank you, Paulo -----Original Message----- From: openldap-technical-bounces(a)OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Jonathan Clarke Sent: Monday, November 15, 2010 12:13 PM To: openldap-technical(a)openldap.org Subject: Re: Pass-Through authentication On 14/11/10 18:29, Paulo Jorge N. Correia (paucorre) wrote: > Hi all, > > I'm just starting with openLDAP and saslauth, and I'm trying to > replicate what I can achieve with ADAM/AD LDS in Windows platform. > > > > I'm trying to use openldap to aggregate user information from several > AD servers under different forests. > > > > So single point of contact from an LDAP perspective for an > organization, and then openldap should pass-through the authentication > request that receives to the AD DC of the respective user. > > > > This works well with /saslauthd /for a single domain/, but if I need > to do this with multiple domains, I don't know how to configure > saslauthd./ saslauthd can only launch one LDAP search to find a user and check his password. So if you're using several AD domains, you need to be able to perform a single search over all those domains : set up a back-meta with all the AD forests under it, and point saslauthd at that. Jonathan

1 0

RE: Problems Enabling Authentication using Cyrus SASL
by Fernando Torrez 17 Nov '10

17 Nov '10

Hi all Thanks for all your suggestions I tried the suggested command (thanks Moorthi): ldapwhoami -U proxyuser -X u:test -Y digest-md5 -I with no success. I got this error: firewall:~ # ldapwhoami -U proxyuser -X u:test -Y digest-md5 -I SASL/DIGEST-MD5 authentication started SASL Interaction Default: u:test Please enter your authorization name: test Default: proxyuser Please enter your authentication name: proxyuser Please enter your password: ldap_sasl_interactive_bind_s: Insufficient access (50) additional info: SASL(-14): authorization failure: unable authorization ID (Logs are at the bottom of this mail for details) I also realized that the logs changed almost nothing either the command below is running or not: saslauthd -d -V -a ldap -r -O /etc/saslauthd.conf so I can say that unfortunately there's no comunication between SASLAUTHD and LDAP. Now I will try the suggestion to separate saslauthd and ldapdb (thanks Dieter) But I'm still wondering if there's a way to work ldap server and cyrus-sasl together. Let's be more accuratte 1.- Connect to ldap server throught cyrus-sasl (let's say authenticated/authorized proxyuser connected to ldap server) 2.- Once connected to the ldap server, authenticate/authorize other user (or any object ) saved on ldap server using previous connection done in step 1 Is that posible? Or, Am I driving crazy for nothing? Thanks in advance Fernando Torrez LDAP LOGS Nov 17 10:10:44 firewall slapd[2901]: daemon: activity on 1 descriptor Nov 17 10:10:44 firewall slapd[2901]: daemon: activity on: Nov 17 10:10:44 firewall slapd[2901]: Nov 17 10:10:44 firewall slapd[2901]: slap_listener_activate(8): Nov 17 10:10:44 firewall slapd[2901]: daemon: epoll: listen=7 active_threads=0 tvp=zero Nov 17 10:10:44 firewall slapd[2901]: daemon: epoll: listen=8 busy Nov 17 10:10:44 firewall slapd[2901]: >>> slap_listener(ldap://) Nov 17 10:10:44 firewall slapd[2901]: daemon: listen=8, new connection on 13 Nov 17 10:10:44 firewall slapd[2901]: daemon: added 13r (active) listener=(nil) Nov 17 10:10:44 firewall slapd[2901]: conn=1002 fd=13 ACCEPT from IP=[::1]:39399 (IP=[::]:389) Nov 17 10:10:44 firewall slapd[2901]: daemon: activity on 1 descriptor Nov 17 10:10:44 firewall slapd[2901]: daemon: activity on: Nov 17 10:10:44 firewall slapd[2901]: Nov 17 10:10:44 firewall slapd[2901]: daemon: epoll: listen=7 active_threads=0 tvp=zero Nov 17 10:10:44 firewall slapd[2901]: daemon: epoll: listen=8 active_threads=0 tvp=zero Nov 17 10:10:44 firewall slapd[2901]: daemon: activity on 1 descriptor Nov 17 10:10:44 firewall slapd[2901]: daemon: activity on: Nov 17 10:10:44 firewall slapd[2901]: 13r Nov 17 10:10:44 firewall slapd[2901]: Nov 17 10:10:44 firewall slapd[2901]: daemon: read active on 13 Nov 17 10:10:44 firewall slapd[2901]: daemon: epoll: listen=7 active_threads=0 tvp=zero Nov 17 10:10:44 firewall slapd[2901]: daemon: epoll: listen=8 active_threads=0 tvp=zero Nov 17 10:10:44 firewall slapd[2901]: connection_get(13) Nov 17 10:10:44 firewall slapd[2901]: connection_get(13): got connid=1002 Nov 17 10:10:44 firewall slapd[2901]: connection_read(13): checking for input on id=1002 Nov 17 10:10:44 firewall slapd[2901]: op tag 0x60, time 1290003044 Nov 17 10:10:44 firewall slapd[2901]: conn=1002 op=0 do_bind Nov 17 10:10:44 firewall slapd[2901]: >>> dnPrettyNormal: <> Nov 17 10:10:44 firewall slapd[2901]: <<< dnPrettyNormal: <>, <> Nov 17 10:10:44 firewall slapd[2901]: conn=1002 op=0 BIND dn="" method=163 Nov 17 10:10:44 firewall slapd[2901]: do_bind: dn () SASL mech DIGEST-MD5 Nov 17 10:10:44 firewall slapd[2901]: ==> sasl_bind: dn="" mech=DIGEST-MD5 datalen=0 Nov 17 10:10:44 firewall slapd[2901]: SASL [conn=1002] Debug: DIGEST-MD5 server step 1 Nov 17 10:10:44 firewall slapd[2901]: send_ldap_sasl: err=14 len=182 Nov 17 10:10:44 firewall slapd[2901]: send_ldap_response: msgid=1 tag=97 err=14 Nov 17 10:10:44 firewall slapd[2901]: conn=1002 op=0 RESULT tag=97 err=14 text=SASL(0): successful result: Nov 17 10:10:44 firewall slapd[2901]: <== slap_sasl_bind: rc=14 Nov 17 10:10:44 firewall slapd[2901]: daemon: activity on 1 descriptor Nov 17 10:10:44 firewall slapd[2901]: daemon: activity on: Nov 17 10:10:44 firewall slapd[2901]: Nov 17 10:10:44 firewall slapd[2901]: daemon: epoll: listen=7 active_threads=0 tvp=zero Nov 17 10:10:44 firewall slapd[2901]: daemon: epoll: listen=8 active_threads=0 tvp=zero Nov 17 10:10:44 firewall ldapwhoami: DIGEST-MD5 client step 2 Nov 17 10:11:02 firewall ldapwhoami: DIGEST-MD5 client step 2 Nov 17 10:11:02 firewall slapd[2901]: daemon: activity on 1 descriptor Nov 17 10:11:02 firewall slapd[2901]: daemon: activity on: Nov 17 10:11:02 firewall slapd[2901]: 13r Nov 17 10:11:02 firewall slapd[2901]: Nov 17 10:11:02 firewall slapd[2901]: daemon: read active on 13 Nov 17 10:11:02 firewall slapd[2901]: daemon: epoll: listen=7 active_threads=0 tvp=zero Nov 17 10:11:02 firewall slapd[2901]: daemon: epoll: listen=8 active_threads=0 tvp=zero Nov 17 10:11:02 firewall slapd[2901]: connection_get(13) Nov 17 10:11:02 firewall slapd[2901]: connection_get(13): got connid=1002 Nov 17 10:11:02 firewall slapd[2901]: connection_read(13): checking for input on id=1002 Nov 17 10:11:02 firewall slapd[2901]: op tag 0x60, time 1290003062 Nov 17 10:11:02 firewall slapd[2901]: conn=1002 op=1 do_bind Nov 17 10:11:02 firewall slapd[2901]: >>> dnPrettyNormal: <> Nov 17 10:11:02 firewall slapd[2901]: <<< dnPrettyNormal: <>, <> Nov 17 10:11:02 firewall slapd[2901]: conn=1002 op=1 BIND dn="" method=163 Nov 17 10:11:02 firewall slapd[2901]: do_bind: dn () SASL mech DIGEST-MD5 Nov 17 10:11:02 firewall slapd[2901]: ==> sasl_bind: dn="" mech=<continuing> datalen=294 Nov 17 10:11:02 firewall slapd[2901]: SASL [conn=1002] Debug: DIGEST-MD5 server step 2 Nov 17 10:11:02 firewall slapd[2901]: SASL Canonicalize [conn=1002]: authcid="proxyuser" Nov 17 10:11:02 firewall slapd[2901]: slap_sasl_getdn: conn 1002 id=proxyuser [len=9] Nov 17 10:11:02 firewall slapd[2901]: slap_sasl_getdn: u:id converted to uid=proxyuser,cn=DIGEST-MD5,cn=auth Nov 17 10:11:02 firewall slapd[2901]: >>> dnNormalize: <uid=proxyuser,cn=DIGEST-MD5,cn=auth> Nov 17 10:11:02 firewall slapd[2901]: <<< dnNormalize: <uid=proxyuser,cn=digest-md5,cn=auth> Nov 17 10:11:02 firewall slapd[2901]: ==>slap_sasl2dn: converting SASL name uid=proxyuser,cn=digest-md5,cn=auth to a DN Nov 17 10:11:02 firewall slapd[2901]: [rw] authid: "uid=proxyuser,cn=digest-md5,cn=auth" -> "uid=proxyuser,ou=people,dc=plainjoe,dc=org" Nov 17 10:11:02 firewall slapd[2901]: slap_parseURI: parsing uid=proxyuser,ou=people,dc=plainjoe,dc=org Nov 17 10:11:02 firewall slapd[2901]: >>> dnNormalize: <uid=proxyuser,ou=people,dc=plainjoe,dc=org> Nov 17 10:11:02 firewall slapd[2901]: <<< dnNormalize: <uid=proxyuser,ou=people,dc=plainjoe,dc=org> Nov 17 10:11:02 firewall slapd[2901]: <==slap_sasl2dn: Converted SASL name to uid=proxyuser,ou=people,dc=plainjoe,dc=org Nov 17 10:11:02 firewall slapd[2901]: slap_sasl_getdn: dn:id converted to uid=proxyuser,ou=people,dc=plainjoe,dc=org Nov 17 10:11:02 firewall slapd[2901]: SASL Canonicalize [conn=1002]: slapAuthcDN="uid=proxyuser,ou=people,dc=plainjoe,dc=org" Nov 17 10:11:02 firewall slapd[2901]: => bdb_search Nov 17 10:11:02 firewall slapd[2901]: bdb_dn2entry("uid=proxyuser,ou=people,dc=plainjoe,dc=org") Nov 17 10:11:02 firewall slapd[2901]: => access_allowed: auth access to "uid=proxyuser,ou=people,dc=plainjoe,dc=org" "entry" requested Nov 17 10:11:02 firewall slapd[2901]: daemon: activity on 1 descriptor Nov 17 10:11:02 firewall slapd[2901]: daemon: activity on: Nov 17 10:11:02 firewall slapd[2901]: Nov 17 10:11:02 firewall slapd[2901]: daemon: epoll: listen=7 active_threads=0 tvp=zero Nov 17 10:11:02 firewall slapd[2901]: daemon: epoll: listen=8 active_threads=0 tvp=zero Nov 17 10:11:02 firewall slapd[2901]: => acl_get: [2] attr entry Nov 17 10:11:02 firewall slapd[2901]: => acl_mask: access to entry "uid=proxyuser,ou=people,dc=plainjoe,dc=org", attr "entry" requested Nov 17 10:11:02 firewall slapd[2901]: => acl_mask: to all values by "", (=0) Nov 17 10:11:02 firewall slapd[2901]: <= check a_dn_pat: * Nov 17 10:11:02 firewall slapd[2901]: <= acl_mask: [1] applying read(=rscxd) (stop) Nov 17 10:11:02 firewall slapd[2901]: <= acl_mask: [1] mask: read(=rscxd) Nov 17 10:11:02 firewall slapd[2901]: => slap_access_allowed: auth access granted by read(=rscxd) Nov 17 10:11:02 firewall slapd[2901]: => access_allowed: auth access granted by read(=rscxd) Nov 17 10:11:02 firewall slapd[2901]: base_candidates: base: "uid=proxyuser,ou=people,dc=plainjoe,dc=org" (0x00000011) Nov 17 10:11:02 firewall slapd[2901]: => test_filter Nov 17 10:11:02 firewall slapd[2901]: PRESENT Nov 17 10:11:02 firewall slapd[2901]: => access_allowed: auth access to "uid=proxyuser,ou=people,dc=plainjoe,dc=org" "objectClass" requested Nov 17 10:11:02 firewall slapd[2901]: => acl_get: [2] attr objectClass Nov 17 10:11:02 firewall slapd[2901]: => acl_mask: access to entry "uid=proxyuser,ou=people,dc=plainjoe,dc=org", attr "objectClass" requested Nov 17 10:11:02 firewall slapd[2901]: => acl_mask: to all values by "", (=0) Nov 17 10:11:02 firewall slapd[2901]: <= check a_dn_pat: * Nov 17 10:11:02 firewall slapd[2901]: <= acl_mask: [1] applying read(=rscxd) (stop) Nov 17 10:11:02 firewall slapd[2901]: <= acl_mask: [1] mask: read(=rscxd) Nov 17 10:11:02 firewall slapd[2901]: => slap_access_allowed: auth access granted by read(=rscxd) Nov 17 10:11:02 firewall slapd[2901]: => access_allowed: auth access granted by read(=rscxd) Nov 17 10:11:02 firewall slapd[2901]: <= test_filter 6 Nov 17 10:11:02 firewall slapd[2901]: => access_allowed: auth access to "uid=proxyuser,ou=people,dc=plainjoe,dc=org" "userPassword" requested Nov 17 10:11:02 firewall slapd[2901]: => acl_get: [1] attr userPassword Nov 17 10:11:02 firewall slapd[2901]: => acl_mask: access to entry "uid=proxyuser,ou=people,dc=plainjoe,dc=org", attr "userPassword" requested Nov 17 10:11:02 firewall slapd[2901]: => acl_mask: to all values by "", (=0) Nov 17 10:11:02 firewall slapd[2901]: <= check a_dn_pat: self Nov 17 10:11:02 firewall slapd[2901]: <= check a_dn_pat: anonymous Nov 17 10:11:02 firewall slapd[2901]: <= acl_mask: [2] applying auth(=xd) (stop) Nov 17 10:11:02 firewall slapd[2901]: <= acl_mask: [2] mask: auth(=xd) Nov 17 10:11:02 firewall slapd[2901]: => slap_access_allowed: auth access granted by auth(=xd) Nov 17 10:11:02 firewall slapd[2901]: => access_allowed: auth access granted by auth(=xd) Nov 17 10:11:02 firewall slapd[2901]: slap_ap_lookup: str2ad(cmusaslsecretDIGEST-MD5): attribute type undefined Nov 17 10:11:02 firewall slapd[2901]: send_ldap_result: conn=1002 op=1 p=3 Nov 17 10:11:02 firewall slapd[2901]: send_ldap_result: err=0 matched="" text="" Nov 17 10:11:02 firewall slapd[2901]: SASL Canonicalize [conn=1002]: authzid="test" Nov 17 10:11:02 firewall slapd[2901]: slap_sasl_getdn: conn 1002 id=test [len=4] Nov 17 10:11:02 firewall slapd[2901]: SASL [conn=1002] Failure: Inappropriate authentication Nov 17 10:11:02 firewall slapd[2901]: SASL [conn=1002] Failure: unable authorization ID Nov 17 10:11:02 firewall slapd[2901]: send_ldap_result: conn=1002 op=1 p=3 Nov 17 10:11:02 firewall slapd[2901]: send_ldap_result: err=50 matched="" text="SASL(-14): authorization failure: unable authorization ID" Nov 17 10:11:02 firewall slapd[2901]: send_ldap_response: msgid=2 tag=97 err=50 Nov 17 10:11:02 firewall slapd[2901]: daemon: activity on 1 descriptor Nov 17 10:11:02 firewall slapd[2901]: daemon: activity on: Nov 17 10:11:02 firewall slapd[2901]: 13r Nov 17 10:11:02 firewall slapd[2901]: Nov 17 10:11:02 firewall slapd[2901]: daemon: read active on 13 Nov 17 10:11:02 firewall slapd[2901]: daemon: epoll: listen=7 active_threads=0 tvp=zero Nov 17 10:11:02 firewall slapd[2901]: daemon: epoll: listen=8 active_threads=0 tvp=zero Nov 17 10:11:02 firewall slapd[2901]: connection_get(13) Nov 17 10:11:02 firewall slapd[2901]: connection_get(13): got connid=1002 Nov 17 10:11:02 firewall slapd[2901]: connection_read(13): checking for input on id=1002 Nov 17 10:11:02 firewall slapd[2901]: ber_get_next on fd 13 failed errno=0 (Success) Nov 17 10:11:02 firewall slapd[2901]: connection_read(13): input error=-2 id=1002, closing. Nov 17 10:11:02 firewall slapd[2901]: connection_closing: readying conn=1002 sd=13 for close Nov 17 10:11:02 firewall slapd[2901]: connection_close: deferring conn=1002 sd=13 Nov 17 10:11:02 firewall slapd[2901]: daemon: activity on 1 descriptor Nov 17 10:11:02 firewall slapd[2901]: daemon: activity on: Nov 17 10:11:02 firewall slapd[2901]: Nov 17 10:11:02 firewall slapd[2901]: daemon: epoll: listen=7 active_threads=0 tvp=zero Nov 17 10:11:02 firewall slapd[2901]: daemon: epoll: listen=8 active_threads=0 tvp=zero Nov 17 10:11:02 firewall slapd[2901]: conn=1002 op=1 RESULT tag=97 err=50 text=SASL(-14): authorization failure: unable authorization ID Nov 17 10:11:02 firewall slapd[2901]: <== slap_sasl_bind: rc=50 Nov 17 10:11:02 firewall slapd[2901]: connection_resched: attempting closing conn=1002 sd=13 Nov 17 10:11:02 firewall slapd[2901]: connection_close: conn=1002 sd=13 Nov 17 10:11:02 firewall slapd[2901]: daemon: removing 13 Nov 17 10:11:02 firewall slapd[2901]: conn=1002 fd=13 closed (connection lost) Nov 17 10:11:13 firewall sshd[2983]: Accepted keyboard-interactive/pam for root from 192.168.0.2 port 1622 ssh2 Nov 17 10:11:13 firewall sshd[2983]: subsystem request for sftp

3 2

understanding ACLs: dn.subtree vs. attrs=@something
by Isaac Hailperin 17 Nov '10

17 Nov '10

Hi, I am trying to build acls suitable to my setup: I have posix accounts in ou=people,ou=unix,dc=acme,dc=org and some more information about users (defined in an object class called "acmeUserAccount") in ou=people,ou=useradm,dc=acme,dc=org. Each posix account has a corresponding record in ou=useradm. These record pairs are connected by having the uid attribute defined equally. Now I want to restrict access to the ou=useradm tree, but not the ou=unix tree. As far as I can understand, there are at least two ways to do so: 1. using something like access to dn.subtree="ou=useradm,dc=acme,dc=org" by group="cn=useradmins,ou=group,ou=unix,dc=acme,dc=org" write by group="cn=consultants,ou=group,ou=unix,dc=acme,dc=org" read by * none This works as expected - giving write access to members of useradmins, and read access to members of consultants. 2. using something like access to attrs=@acmeUserAccount by group="cn=useradmins,ou=group,ou=unix,dc=acme,dc=org" write by group="cn=consultants,ou=group,ou=unix,dc=acme,dc=org" read by * none This also works as expected with regards to acmeUserAccount, but has funny side effects on ou=unix. To my understanding these two methods should have the same effect, as I only have records of type acmeUserAccount underneth ou=useradm. But: if I use 2), users don't have access to their data underneth ou=unix. Only the two groups mentioned have access to ou=unix as defined for acmeUserAccount. I read that using attrs=@someObjectClass affects also attributes that are defined in object classes that someObjectClass inherits from. My object class is defined as follows: objectclass ( managementOC:1 NAME 'acmeUserAccount' DESC 'Attributes needed for acme user management' SUP top STRUCTURAL MUST ( uid $ email ) MAY ( $ givenName $ surname $ federalState ) ) So it should inherit only from top, which I thought of as some abstract class without any attributes. Can someone explain this behaviour to me? Regards, Isaac

2 4

ITS#6459 syncprov memory leak work-around question
by Aaron Bennett 17 Nov '10

17 Nov '10

Hi, I'm bitten by the syncprov memory leak in ITS#6459. I'm hoping that the Ubuntu server team will backport this from upstream -- if they don't, I'll rebuild the package. In the meantime I'm wondering if switching from RefreshAndPersist to RefreshOnly would prevent this leak. Does this seem possible? Thanks, Aaron --- Aaron Bennett Manager of Systems Administration Clark University ITS

1 0

Debian 5 x OpenLDAP
by Márcio Luciano Donada 17 Nov '10

17 Nov '10

I'm using debian 5 (Linux ldap 2.6.26-2-686 #1 SMP Thu Sep 16 19:35:51 UTC 2010 i686 GNU/Linux) e OpenLDAP (2.4.11-1+lenny2), but I have had problems at times for the same, and always at dawn, I find nothing in the logs that can help me and it has to happen one day, is very variable. The only message I got in the logs is: Nov 17 05:36:19 ldap slapd[5728]: connection_read(50): no connection! Nov 17 05:53:50 ldap slapd[5728]: connection_read(27): no connection! Nov 17 08:04:19 ldap slapd[21558]: @(#) $OpenLDAP: slapd 2.4.11 (Jul 24 2010 08:14:20) $#012#011@murphy:/build/buildd-openldap_2.4.11-1+lenny2-i386-H5BDjb/openldap-2.4.11/debian/build/servers/slapd Nov 17 08:04:20 ldap slapd[21559]: slapd starting -- Márcio Luciano Donada <mdonada -at- auroraalimentos -dot- com -dot- br> Aurora Alimentos - Cooperativa Central Oeste Catarinense Departamento de T.I.

2 1

Role Based Attribute
by Anton Chu 16 Nov '10

16 Nov '10

Hi, I'm trying to find a way to setup ROLES instead of GROUPS. Roles are needed for certain applications access with additional permissions. Thanks in advance. Regards

2 1

Newly configured replication (master / slave) on 2.3 not quite working..
by Michael March 16 Nov '10

16 Nov '10

Entries are taking a LONG time to propagate (if they do at all).. I'm getting a TON of entries in the log like this on the slave side (continuously): Nov 16 21:03:54 sfo-dns-01 slapd[11864]: <= root access granted Nov 16 21:03:54 sfo-dns-01 slapd[11864]: <= test_filter 5 Nov 16 21:03:54 sfo-dns-01 slapd[11864]: bdb_search: 2629 does not match filter Nov 16 21:03:54 sfo-dns-01 slapd[11864]: entry_decode: "uid=mwatson,ou=People,dc=acme,dc=com" Nov 16 21:03:54 sfo-dns-01 slapd[11864]: <= entry_decode(uid=mwatson,ou=People,dc=acme,dc=com) Nov 16 21:03:54 sfo-dns-01 slapd[11864]: => test_filter Nov 16 21:03:54 sfo-dns-01 slapd[11864]: EQUALITY Nov 16 21:03:54 sfo-dns-01 slapd[11864]: => access_allowed: search access to "uid=mwatson,ou=People,dc=acme,dc=com" "entryUUID" requested Nov 16 21:03:54 sfo-dns-01 slapd[11864]: <= root access granted Nov 16 21:03:54 sfo-dns-01 slapd[11864]: <= test_filter 5 Nov 16 21:03:54 sfo-dns-01 slapd[11864]: bdb_search: 2630 does not match filter Nov 16 21:03:54 sfo-dns-01 slapd[11864]: entry_decode: "cn=mwatson,ou=Group,dc=acme,dc=com" Nov 16 21:03:54 sfo-dns-01 slapd[11864]: <= entry_decode(cn=mwatson,ou=Group,dc=acme,dc=com) Nov 16 21:03:54 sfo-dns-01 slapd[11864]: => test_filter Nov 16 21:03:54 sfo-dns-01 slapd[11864]: EQUALITY Nov 16 21:03:54 sfo-dns-01 slapd[11864]: => access_allowed: search access to "cn=mwatson,ou=Group,dc=acme,dc=com" "entryUUID" requested Nov 16 21:03:54 sfo-dns-01 slapd[11864]: <= root access granted Nov 16 21:03:54 sfo-dns-01 slapd[11864]: <= test_filter 5 Nov 16 21:03:54 sfo-dns-01 slapd[11864]: bdb_search: 2631 does not match filter Nov 16 21:03:54 sfo-dns-01 slapd[11864]: entry_decode: "ou=Contacts,uid=mwatson,ou=People,dc=acme,dc=com" Nov 16 21:03:54 sfo-dns-01 slapd[11864]: <= entry_decode(ou=Contacts,uid=mwatson,ou=People,dc=acme,dc=com) Nov 16 21:03:54 sfo-dns-01 slapd[11864]: => test_filter Nov 16 21:03:54 sfo-dns-01 slapd[11864]: EQUALITY Nov 16 21:03:54 sfo-dns-01 slapd[11864]: => access_allowed: search access to "ou=Contacts,uid=mwatson,ou=People,dc=acme,dc=com" "entryUUID" request ed Here's the slave config: include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/ldapab.schema include /etc/openldap/schema/ppolicy.schema allow bind_v2 pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args modulepath /usr/lib64/openldap moduleload ppolicy.la TLSCertificateFile /etc/openldap/ldap.cert TLSCertificateKeyFile /etc/openldap/ldap.key database bdb suffix "dc=acme,dc=com" rootdn "uid=helpdesk,ou=People,dc=acme,dc=com" rootpw {SHA}FOOOOOO+pZB93s06zAM1vQo= directory /var/lib/ldap overlay ppolicy ppolicy_default "cn=default,ou=policies,dc=acme,dc=com" ppolicy_use_lockout sizelimit 2500 loglevel -1 directory /var/lib/ldap index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub syncrepl rid=123 provider=ldap://ldap-stage.acme.com:389 #type=refreshAndPersist type=refreshOnly interval=00:00:02:00 searchbase="dc=acme,dc=com" # filter="(objectClass=organizationalPerson)" filter="(objectClass=*)" updatedn "uid=helpdesk,ou=People,dc=acme,dc=com" scope=sub schemachecking=off bindmethod=simple binddn="uid=helpdesk,ou=People,dc=acme,dc=com" credentials=FOOOBAR updateref ldap://ldap-stage.acme.com -- <cowmix>

1 0

Problems with ppolicy_forward_updates and starttls with certificate-based auth
by Kartik Subbarao 16 Nov '10

16 Nov '10

I'm trying to get a consumer server to forward ppolicy-related updates to its provider server, and to use certificate-based authentication (SASL EXTERNAL) over STARTTLS when authenticating to the provider. This is with 2.4.23 on a Debian 5.0.5 system (I've seen similar issues reported elsewhere so I doubt this is platform specific). I'm running into multiple problems here. The core problem seems to be that enabling ppolicy_forward_updates breaks the chaining overlay such that it binds anonymously instead of with SASL EXTERNAL. Another problem is that bind operations to the consumer server start to return two result messages -- one with the error code of the chained operation, and one with the error code of the bind operation. This latter problem seems to the cause of the (still unresolved?) errors from this message thread earlier this year: http://www.mail-archive.com/openldap-technical@openldap.org/msg01215.html To simplify reproducing the problem, I've worked with test022-ppolicy in the openldap test framework. I've submitted ITS 6711 based on this. Here, I ran into another issue. I can't seem to be able to configure sasl external/starttls chaining properly with the cn=config style configuration that test022-ppolicy applies. The self-signed cert that I'm using works fine with replication, but it doesn't seem to work with chaining. This may or may not be another issue that needs to be resolved. In any case, with the attached files in the ITS, I hope that what I'm trying to do and the results that I'm getting should be as clear and unambiguous as possible. I'd appreciate any feedback on whether there is something else I need to configure or if there are bugs here that need to be fixed. Thanks, -Kartik

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