openldap-technical

openldap-technical@openldap.org

9 participants
9876 discussions

ubuntu sudoers won't talk to LDAP
by bluethundr 19 Nov '10

19 Nov '10

Hello Ubuntu On our network we have our sudoers stored in LDAP. This works fine on the CentOS 5.4 clients by placing into /etc/ldap.conf sudoers_base ou=sudoers,ou=Services,dc=example,dc=net and in /etc/nsswitch.conf we have the entry: sudoers: ldap (setting this setting to just 'ldap' instead of 'files ldap' does not render the machine unbootable as happens if you set passwd and group this way). However I am attempting to set this up on an Ubuntu 9.10 client and getting no joy so far. I have the same settings in /etc/ldap.conf and /etc/nsswitch.conf and cannot get sudoers to work. On the Ubuntu box, I can get LDAP entries by typing in getent passwd | grep ldapAccount, however when you attempt to sudo it fails: bluethundr@ubuntu3:~$ sudo bash >>> /etc/sudoers: syntax error near line 0 <<< sudo: parse error in /etc/sudoers near line 0 sudo: no valid sudoers sources found, quitting We leave our sudoers file blank intentionally in order to manage this via LDAP. Again, this problem is ONLY happening under Ubuntu and not under Centos 5.4. The only real difference that I see between the two clients is the sudo version. Could it be that under ubuntu LDAP sudo support isn't compiled in? if so how to recompile it so that it does? CentOS 5.4 sudo version: [root@ldap2 ~]# sudo -V Sudo version 1.7.2p1 Ubuntu 9.10 sudo version: root@ubuntu3:~# sudo -V Sudo version 1.7.0 [root@ldap2 ~]# sudo -V Sudo version 1.7.2p1 And here are the linkages: CentOS 5.4: [root@ldap2 ~]# ldd $(which sudo) libselinux.so.1 => /lib64/libselinux.so.1 (0x00002aaaaacc8000) libcap.so.1 => /lib64/libcap.so.1 (0x00002aaaaaee0000) libpam.so.0 => /lib64/libpam.so.0 (0x00002aaaab0e4000) libdl.so.2 => /lib64/libdl.so.2 (0x00002aaaab2f0000) libldap-2.3.so.0 => /usr/lib64/libldap-2.3.so.0 (0x00002aaaab4f4000) libc.so.6 => /lib64/libc.so.6 (0x00002aaaab72e000) libaudit.so.0 => /lib64/libaudit.so.0 (0x00002aaaaba86000) liblber-2.3.so.0 => /usr/lib64/liblber-2.3.so.0 (0x00002aaaabc9e000) libsepol.so.1 => /lib64/libsepol.so.1 (0x00002aaaabeac000) /lib64/ld-linux-x86-64.so.2 (0x00002aaaaaaab000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00002aaaac0f3000) libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x00002aaaac308000) libssl.so.6 => /lib64/libssl.so.6 (0x00002aaaac521000) libcrypto.so.6 => /lib64/libcrypto.so.6 (0x00002aaaac76e000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00002aaaacabf000) libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00002aaaaccf7000) libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00002aaaacf26000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00002aaaad1bb000) libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00002aaaad3bd000) libz.so.1 => /usr/lib64/libz.so.1 (0x00002aaaad5e3000) libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00002aaaad7f7000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00002aaaad9ff000) Ubuntu 9.10 bluethundr@ubuntu3:~$ ldd $(which sudo) linux-gate.so.1 => (0x00914000) libpam.so.0 => /lib/libpam.so.0 (0x00753000) libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0x00223000) libldap_r-2.4.so.2 => /usr/lib/libldap_r-2.4.so.2 (0x00fa1000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x004f1000) liblber-2.4.so.2 => /usr/lib/liblber-2.4.so.2 (0x00f35000) /lib/ld-linux.so.2 (0x00d75000) libresolv.so.2 => /lib/tls/i686/cmov/libresolv.so.2 (0x00345000) libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x008d0000) libgnutls.so.26 => /usr/lib/libgnutls.so.26 (0x00b77000) libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0x002e3000) libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0x001df000) libz.so.1 => /lib/libz.so.1 (0x007d6000) libgcrypt.so.11 => /lib/libgcrypt.so.11 (0x003f3000) libgpg-error.so.0 => /lib/libgpg-error.so.0 (0x00110000) Thanks for any input you may have! -- Here's my RSA Public key: gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9 Share and enjoy!!

5 7

Re: Replication Through A DMZ
by Anton Chu 19 Nov '10

19 Nov '10

I'm having a hard time understanding it. I'm using the latest openldap on ubuntu 10.10 and I can't pinpoint the exact master configuration syntax that sets up the provider to push changes to the consumers. On Fri, Nov 19, 2010 at 2:40 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > --On Friday, November 19, 2010 2:31 PM -0800 Anton Chu < > anton.chu(a)telecommand.com> wrote: > > FYI, I've installed a conumser server in the dmz today using refreshOnly >> replication and it didn't work. >> > > Why would it? You need to set up the provider to push changes, as detailed > in the Admin guide section I sent to you yesterday. > > > --Quanah > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

2 1

Re: Replication Through A DMZ
by Anton Chu 19 Nov '10

19 Nov '10

FYI, I've installed a conumser server in the dmz today using refreshOnly replication and it didn't work. On Thu, Nov 18, 2010 at 11:31 AM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > --On Thursday, November 18, 2010 11:14 AM -0800 Anton Chu < > anton.chu(a)telecommand.com> wrote: > > Thanks I've read the replication section many times at the site and >> logically it doesn't make sense when you look at the configuration. My >> Master has this configuration: >> > > Then apparently you haven't read it closely. Plase read < > http://www.openldap.org/doc/admin24/replication.html#Syncrepl%20Proxy> > > > --Quanah > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

2 1

Want interesting restrictions to ldap auth on different servers to different users
by c0re 18 Nov '10

18 Nov '10

Hey all! I made simple ldap auth on my servers via pam_ldap. It's ok. Now I want to add users that can auth on several servers. BUT. I want to control on what servers user can login only on ldap server. I mean user user1 can must login only on server1,server2 and server3. And user2 can login only on server5 and server2. Theoretically It's possible to do with "pam_groupdn", set it it ldap.conf to server name and create as many groups as I have servers in openldap. Then I add users to some groups that they has to have access. I can group servers in some group like "city1_group" that contain all servers in city1 and add user to that group and it will have access to all servers in city1. May be anyone know another practice? Looking for best practice or something like it. Share your experience please. Thanks!!!

2 2

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical