Passwords in DIT after MOD from Solaris Client
by Ben Rockwood
Hello,
I'm using pam_ldap on a Solaris 10 client and an OpenLDAP server.
Everything works great, with one little exception.
I can create new accounts from an LDIF specifying the password as
{SSHA} and everything works fine. Users can login, etc. However, if a
user changes their password from Solaris ('passwd -r ldap') the password
is now stored in the directory as plaintext. The user can still login,
change their password, etc, it works fine... but I don't want plaintext
passwords in the directory.
I tried adding "password-hash {SSHA}" to slapd.conf, but that didn't
do anything... nor would I expect it to because its the default setting.
Can anyone point me in the right direction?
benr.
12 years, 4 months
self signed certificate
by Márcio Luciano Donada
Hi list,
When using TLS, I have information that I'm using a self-signed
certificate, as shown below:
# ldapsearch -x -d5 -b 'ou=Usuarios,dc=xx,dc=com,dc=br' -H
ldaps://121.1.1.97/ '(objectclass=*)'
ldap_url_parse_ext(ldaps://121.1.1.97/)
ldap_create
ldap_url_parse_ext(ldaps://121.1.1.97:636/??base)
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP 121.1.1.97:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 121.1.1.97:636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
TLS trace: SSL_connect:before/connect initialization
TLS trace: SSL_connect:SSLv2/v3 write client hello A
TLS trace: SSL_connect:SSLv3 read server hello A
TLS certificate verification: depth: 0, err: 18, subject:
/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=ldap.xx.com.br, issuer:
-State/O=Internet Widgits Pty Ltd/CN=ldap.xx.com.br
TLS certificate verification: Error, self signed certificate
TLS trace: SSL3 alert write:fatal:unknown CA
TLS trace: SSL_connect:error in SSLv3 read server certificate B
TLS trace: SSL_connect:error in SSLv3 read server certificate B
TLS: can't connect: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (self
signed certificate).
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
My slapd.conf:
TLSRandFile /dev/random
TLSCipherSuite HIGH:MEDIUM:+SSLv2
TLSCertificateFile /usr/local/etc/openldap/ssl/cert.crt
TLSCertificateKeyFile /usr/local/etc/openldap/ssl/cert.key
TLSCACertificateFile /usr/local/etc/openldap/ssl/cert.crt
my ldap.conf
pam_login_attribute uid
base dc=xxxx,dc=com,dc=br
uri ldap://127.0.0.1/
PORT 636
HOST 127.0.0.1
TLS_REQCERT allow
TLS_CACERT /usr/local/etc/openldap/ssl/cert.crt
TLS_CACERTDIR /usr/local/etc/openldap/ssl
--
Márcio Luciano Donada <mdonada -at- auroraalimentos -dot- com -dot- br>
Aurora Alimentos - Cooperativa Central Oeste Catarinense
Departamento de T.I.
12 years, 4 months
HDB Index Corruption
by Alejandro Imass
Hi,
I searched the archives of openldap-software and openldap-technical
for the terms "hdb index corruption", "hdb index", and "idex" and got
zero results.
I have a simple master-slave setup and my indexes are getting
corrupted. We have software that ties RDBMS entries with the entryUUID
because the DN can change. Of course, we use moddn to avoid changing
the entryUUID. So here is the set-up:
old_ldap ----> new_ldap_master ------> new_ldap_slave
We run a cron that scans the old_ldap and updates information on all
the records on the new_ldap_master. The information is mostly the
same, but the structures of the DIT differ a lot. Ok, so the first
cron updates information (attributes) that have changed in the old
ldap and updates the ldap master entries. Another cron searches some
info in a database and may perform many moddns if people have moved
from departments, etc. The new_ldap_slave is just a replica of the
first, using the methods described in the docs for MirrorMode
replication. All writes AFAIK are always being done in the master.
Anyway, the problem is that the HDB indexes seem to be getting
corrupted. That is, if I query for and entryUUID I get a DN and if I
query the DN I may get another entryUUID. If I reconstruct the indexes
the problem is gone. Has anyone had a similar problem? What may be
causing these problems? Is it too many wirtes? Is it common pratice to
reconstruct the indexes after the massive updates? Any comments
greatly appreciated !
Thanks,
--
Alejandro Imass
12 years, 4 months
ACL short hand notation @objectClass has side effects
by Isaac Hailperin
I have again trouble understanding ACLs:
Consider the following schema:
objectclass ( acmeLDAP:4.2
NAME 'acmeUserLimits'
DESC 'Limits for acme Users'
SUP top AUXILIARY
MAY ( limitMaxUserProc $ limitMaxCpuTime $ limitMaxOpenFiles $
limitMaxCorefileSize $ limitMaxStackSize $ limitMaxMemorySize $
limitMaxVirtualMemory $ limitMaxDatasegSize $ limitMaxPipeSize $
limitMaxFileLocks $ userAttrChanged ) )
and the following ACL:
[...]
access to dn.subtree="ou=people,ou=unix,dc=acme,dc=org"
attrs=limitMaxUserProc,limitMaxCpuTime,limitMaxOpenFiles,limitMaxCorefileSize,limitMaxStackSize,limitMaxMemorySize,limitMaxVirtualMemory,limitMaxDatasegSize,limitMaxPipeSize,limitMaxFileLocks,userAttrChanged
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" write
by self read
by * none
[...]
This one works, it lets users authenticate, and restricts access to the
attributes mentioned. Now as the attribute list is a bit long, I thought
I could replace it with the short hand notation:
access to dn.subtree="ou=people,ou=unix,dc=acme,dc=org"
attrs=@acmeUserLimits
(since all listet attributes are only in acmeUserLimits).
Unfortunatly this does not work, it blocks users from loggin in (via
ssh). One time I got the message "Permissions on the password database
may be too restrictive."
Obviously the shorthand notation affects other attributes as well. But
looking at the object class definition, I don't see why. Can any one
enlighten me about this?
Isaac
12 years, 4 months
back-ldap core dump
by CHIROSSEL, Olivier
Hi
I have to migrate from a openldap 2.3.x to openldap 2.4. During this migration phase i want my openldap 2.3.x master replicate with slurpd to my new openldap 2.4.x master mirror mode architecture with some rewriting rules for split my big directory.
I configure a proxy ldap using back-ldap with slapo-rwm overlay, but operational attributes related to entry creation and modification are proxied, even when i put < lastmod off > in the conf, contrary of the man of slapd-ldap ...
So i put rw-map directives in the conf for strip operationnal attributes but this kind of operation generate a core dump ...
dn: neufDhcpIP=10.145.250.119,suffix=9,o=auth,dc=neuf,dc=fr
changetype: modify
delete: neufDhcpOption
neufDhcpOption: 1;255.255.255.0
-
replace: entryCSN
entryCSN: 20100511215647Z#000024#00#000000
-
replace: modifiersName
modifiersName: cn=manager,dc=neuf,dc=fr
-
replace: modifyTimestamp
modifyTimestamp: 20100511215647Z
dn: neufDhcpIP=10.145.250.119,suffix=9,o=auth,dc=neuf,dc=fr
changetype: modify
add: neufDhcpOption
neufDhcpOption: 1;255.255.255.128
-
replace: entryCSN
entryCSN: 20100511215647Z#000024#00#000000
-
replace: modifiersName
modifiersName: cn=manager,dc=neuf,dc=fr
-
replace: modifyTimestamp
modifyTimestamp: 20100511215647Z
Core was generated by `openldap-2.4.23/servers/slapd/slapd -F /etc/openldap/slapd-ldap.d -h ldap://10.'.
Program terminated with signal 6, Aborted.
[New process 7995]
[New process 7994]
[New process 7990]
[New process 7989]
#0 0x00007f01373f9ed5 in raise () from /lib/libc.so.6
(gdb) bt
#0 0x00007f01373f9ed5 in raise () from /lib/libc.so.6
#1 0x00007f01373fb3f3 in abort () from /lib/libc.so.6
#2 0x00007f0137436408 in __libc_message () from /lib/libc.so.6
#3 0x00007f013743b9a8 in malloc_printerr () from /lib/libc.so.6
#4 0x00007f013743dab6 in free () from /lib/libc.so.6
#5 0x000000000055b8e2 in ber_bvarray_free_x (a=0x26de840, ctx=0x0) at memory.c:737
#6 0x000000000046e3a1 in slap_mod_free (mod=0x26d07f0, freeit=0) at mods.c:461
#7 0x000000000046e42d in slap_mods_free (ml=0x26d07f0, freevals=1) at mods.c:481
#8 0x0000000000437960 in do_modify (op=0x25d02e0, rs=0x41d24cb0) at modify.c:187
#9 0x000000000041f6ef in connection_operation (ctx=0x41d24e00, arg_v=<value optimized out>) at connection.c:1109 #10 0x00000000004203dd in connection_read_thread (ctx=0x41d24e00, argv=<value optimized out>) at connection.c:1245
#11 0x0000000000534080 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685
#12 0x00007f0137f21fc7 in start_thread () from /lib/libpthread.so.0
#13 0x00007f013749764d in clone () from /lib/libc.so.6
#14 0x0000000000000000 in ?? ()
(gdb)
My conf :
database ldap
suffix "dc=neuf,dc=fr"
rootdn "cn=manager,dc=neuf,dc=fr"
rootpw secret
updatedn "cn=manager,dc=neuf,dc=fr"
uri "ldap://127.0.0.1/"
idassert-bind bindmethod=simple binddn="cn=manager,dc=neuf,dc=fr" credentials=secret
overlay rwm
rwm-rewriteEngine on
rwm-rewriteContext default
rwm-rewriteRule "neufDhcpIP=([0-9\\.]+)([0-9]{1}),ou=People,o=auth,dc=neuf,dc=fr$" "neufDhcpIP=$1$2,suffix=$2,o=auth,dc=neuf,dc=fr"
rwm-map attribute neufDhcpIP neufDhcpIP
rwm-map attribute neufDhcp82 neufDhcp82
rwm-map attribute neufDhcpOption neufDhcpOption
rwm-map attribute neufDhcp60 neufDhcp60
rwm-map attribute neufDhcpRelay neufDhcpRelay
rwm-map attribute neufDhcpComment neufDhcpComment
rwm-map attribute neufDhcpUnique neufDhcpUnique
rwm-map attribute neufDhcpProvider neufDhcpProvider
rwm-map attribute neufDhcpFQDN neufDhcpFQDN
rwm-map attribute neufDhcp82b neufDhcp82b
rwm-map attribute neufDhcpMac neufDhcpMac
rwm-map attribute neufDhcpSiaddr neufDhcpSiaddr
rwm-map attribute neufDhcpBootfilename neufDhcpBootfilename
rwm-map attribute neufBTID neufBTID
rwm-map attribute neufBTOption neufBTOption
rwm-map attribute neufTWINOption neufTWINOption
rwm-map attribute neufE28Option neufE28Option
rwm-map attribute circuitid circuitid
rwm-map attribute clientid clientid
rwm-map attribute device device
rwm-map attribute clientoffer clientoffer
rwm-map attribute ispid ispid
rwm-map attribute suspended suspended
rwm-map attribute neufDhcpIPb neufDhcpIPb
rwm-map attribute neufDhcpOptionb neufDhcpOptionb
rwm-map attribute idworkflow idworkflow
rwm-map attribute neufDhcpRelayIP neufDhcpRelayIP
rwm-map attribute interceptID interceptID
rwm-map attribute interceptEndpoint interceptEndpoint
rwm-map attribute neufDhcpRadiusOption neufDhcpRadiusOption
rwm-map attribute suffix suffix
rwm-map attribute dc dc
rwm-map attribute o o
rwm-map attribute ou ou
rwm-map attribute cn cn
rwm-map objectclass neufDhcpOption1 neufDhcpOption1
rwm-map objectclass neufDhcpOption5 neufDhcpOption5
rwm-map objectclass neufDhcpOption1R neufDhcpOption1R
rwm-map objectclass neufDhcpOption35 neufDhcpOption35
rwm-map objectclass neufBTOption neufBTOption
rwm-map objectclass neufDhcpOptionwifi neufDhcpOptionwifi
rwm-map objectclass Dhcp82 Dhcp82
rwm-map objectclass ClientDevice ClientDevice
rwm-map objectclass DhcpDevice DhcpDevice
rwm-map objectclass suffixobj suffixobj
rwm-map objectclass OrganizationalUnit OrganizationalUnit
rwm-map objectclass Organization Organization
rwm-map objectclass dcObject dcObject
rwm-map objectclass domain domain
rwm-map objectclass device device
rwm-map attribute *
rwm-map objectclass *
Thank's in avance for your help
Regards,
Olivier
12 years, 4 months
LDAP clients fail to connect with SSL enabled
by bluethundr
LDAP clients fail to connect with SSL enabled
I am attempting to setup SSL/TLS support on my openLDAP 2.4 server on FreeBSD.
LBSD2# pkg_info | grep openldap
openldap-sasl-client-2.4.23 Open source LDAP client implementation
with SASL2 support
openldap-sasl-server-2.4.23 Open source LDAP server implementation
I put my cert file, key file and CA certfile in a directory called
/usr/local/etc/openldap/cacerts
Here's how it looks:
[root@LBSD2:/usr/local/etc/openldap/cacerts]#ls -l
total 48
dr--r----- 2 root ldap 512 Nov 21 17:12 bak
-r--r----- 1 root ldap 1960 Nov 21 07:05 bsd2.summitnjhome.com.crt
-r--r----- 1 root ldap 4604 Nov 21 17:16 gd_bundle.crt
-r--r----- 1 root ldap 4689 Nov 21 18:59 sf_bundle.crt
-r--r----- 1 root ldap 1537 Nov 21 17:16 sf_issuing.crt
-r--r----- 1 root ldap 1090 Nov 21 12:29 slapd.csr
-r--r----- 1 root ldap 1743 Nov 21 12:26 slapd.key
-r--r----- 1 root ldap 1675 Nov 21 17:25 slapd.pem
My cert flie is a GoDaddy turbo-ssl certfile named
bsd2.summitnjhome.com.crt. slapd.key is the key file and slapd.pem is
the same thing only with the password removed.
I'm a little unsure of which CA file to use but I think that
sf_issuing.crt _should_ work as this is the CA file that I used to
setup a similar SSL enabled LDAP server for a client recently.
Although I have tried all three CA files in this directory:
(gd_bundle.crt, sf_bundle.crt, and sf_issuing.crt).
I put the various cert/key files into my slapd.conf file like this:
LBSD2# cat slapd.conf | grep -i tls
## TLS options for slapd
TLSCipherSuite HIGH:MEDIUM:+SSLv2
TLSCertificateFile /usr/local/etc/openldap/cacerts/bsd2.summitnjhome.com.crt
TLSCertificateKeyFile /usr/local/etc/openldap/cacerts/slapd.pem
TLSCACertificateFile /usr/local/etc/openldap/cacerts/sf_issuing.crt
Slapd restarts cleanly!
LBSD2# /usr/local/etc/rc.d/slapd restart
Stopping slapd.
Waiting for PIDS: 81924.
Starting slapd.
Then I attempt to setup a virtual instance of CentOS 5.5 on the client
side and that's where things fall apart...I attempt to ssh to
localhost as an LDAP account:
[root@VIRTCENT08:/etc/openldap/cacerts]#ssh bluethundr@localhost
[...tectonic plates drift, careers begin and end, babies learn to
walk, talk and grow to adulthood..]
Connection closed by 127.0.0.1
[root@VIRTCENT08:/etc/openldap/cacerts]#getent passwd | grep ldapAccount
[same interminable wait as above]
This is what my /etc/ldap.conf file looks like on the client:
[root@VIRTCENT08:/etc/openldap/cacerts]#cat /etc/ldap.conf
# Your LDAP server. Must be resolvable without using LDAP.
# Multiple hosts may be specified, each separated by a
# space. How long nss_ldap takes to failover depends on
# whether your LDAP client library supports configurable
# network or connect timeouts (see bind_timelimit).
#host 127.0.0.1
# The distinguished name of the search base.
base dc=summitnjhome,dc=com
# stored in /etc/ldap.secret (mode 600)
#rootbinddn cn=manager,dc=example,dc=com
# The port.
# Optional: default is 389.
#port 389
# Search timelimit
#timelimit 30
timelimit 120
# Bind/connect timelimit
#bind_timelimit 30
bind_timelimit 120
# Idle timelimit; client will close connections
# (nss_ldap only) if the server has not been contacted
# for the number of seconds specified below.
#idle_timelimit 3600
idle_timelimit 3600
# Netscape SDK LDAPS
#ssl on
# Netscape SDK SSL options
#sslpath /etc/ssl/certs
# OpenLDAP SSL mechanism
# start_tls mechanism uses the normal LDAP port, LDAPS typically 636
#ssl start_tls
#ssl on
# OpenLDAP SSL options
# Require and verify server certificate (yes/no)
# Default is to use libldap's default behavior, which can be configured in
# /etc/openldap/ldap.conf using the TLS_REQCERT setting. The default for
# OpenLDAP 2.0 and earlier is "no", for 2.1 and later is "yes".
#tls_checkpeer yes
# CA certificates for server certificate verification
# At least one of these are required if tls_checkpeer is "yes"
#tls_cacertfile /etc/ssl/ca.cert
#tls_cacertdir /etc/ssl/certs
# SSL cipher suite
# See man ciphers for syntax
#tls_ciphers TLSv1
# Client certificate and key
# Use these, if your server requires client authentication.
#tls_cert
#tls_key
# SASL mechanism for PAM authentication - use is experimental
# at present and does not support password policy control
uri ldap://ldap.summitnjhome.com/
ssl start_tls
tls_cacertdir /etc/openldap/cacerts
pam_password crypt
This is how my nsswitch on the client side is setup:
passwd: files ldap
shadow: files ldap
group: files ldap
And here is the cert dir on my CentOS client:
[root@VIRTCENT08:/etc/openldap/cacerts]#ls -l
total 72
lrwxrwxrwx 1 root root 13 Nov 21 09:44 97552d04.0 -> gd_bundle.crt
lrwxrwxrwx 1 root root 14 Nov 21 09:44 b737b221.0 -> sf_issuing.crt
dr--r--r-- 2 root root 4096 Nov 21 2010 bak
-r--r--r-- 1 root root 1960 Nov 21 07:05 bsd2.summitnjhome.com.crt
lrwxrwxrwx 1 root root 25 Nov 21 09:44 c75be861.0 -> bsd2.summitnjhome.com.crt
-r--r--r-- 1 root root 4604 Nov 21 2010 gd_bundle.crt
-r--r--r-- 1 root root 1537 Nov 21 2010 sf_issuing.crt
-r--r--r-- 1 root root 1090 Nov 21 12:29 slapd.csr
-r--r--r-- 1 root root 1743 Nov 21 12:26 slapd.key
-r--r--r-- 1 root root 1675 Nov 21 2010 slapd.pem
Back on the server side there is a lot of activity in the ldap logs
(here is an excerpt)
Nov 21 20:21:38 LBSD2 slapd[81972]: daemon: read activity on 11
Nov 21 20:21:38 LBSD2 slapd[81972]: daemon: select: listen=6
active_threads=0 tvp=NULL
Nov 21 20:21:38 LBSD2 slapd[81972]: daemon: select: listen=7
active_threads=0 tvp=NULL
Nov 21 20:21:38 LBSD2 slapd[81972]: connection_read(11): input
error=-2 id=1017, closing.
Nov 21 20:21:38 LBSD2 slapd[81972]: connection_closing: readying
conn=1017 sd=11 for close
Nov 21 20:21:38 LBSD2 slapd[81972]: daemon: activity on 1 descriptor
I've encloses a more complete log file as an attachment.
I then try to show the CA files with an openssl command.
First with sf_issuing.crt -
slapd.conf:
TLSCACertificateFile /usr/local/etc/openldap/cacerts/sf_issuing.crt
On the client:
[root@VIRTCENT08:/etc/openldap/cacerts]#openssl s_client -connect
ldap.summitnjhome.com:389 -showcerts -CAfile sf_issuing.crt
CONNECTED(00000003)
3143:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188
Next with sf_bundle.crt -
slapd.conf:
TLSCACertificateFile /usr/local/etc/openldap/cacerts/sf_bundle.crt
[root@VIRTCENT08:/etc/openldap/cacerts]#openssl s_client -connect
ldap.summitnjhome.com:389 -showcerts -CAfile sf_bundle.crt
3149:error:02001002:system library:fopen:No such file or
directory:bss_file.c:122:fopen('sf_bundle.crt','r')
3149:error:2006D080:BIO routines:BIO_new_file:no such file:bss_file.c:125:
3149:error:0B084002:x509 certificate
routines:X509_load_cert_crl_file:system lib:by_file.c:279:
CONNECTED(00000003)
3149:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
failure:s23_lib.c:188:
Next with gd_bundle.crt -
TLSCACertificateFile /usr/local/etc/openldap/cacerts/gd_bundle.crt
[root@VIRTCENT08:/etc/openldap/cacerts]#openssl s_client -connect
ldap.summitnjhome.com:389 -showcerts -CAfile gd_bundle.crt
CONNECTED(00000003)
3156:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
failure:s23_lib.c:188:
Disabling TLS on the client side authentication works again!
[root@VIRTCENT08:/etc/openldap/cacerts]#ssh bluethundr@localhost
bluethundr@localhost's password:
Last login: Sun Nov 21 09:41:34 2010 from 192.168.1.50
#########################################################
# SUMMITNJHOME.COM #
# TITLE: VIRTCENT08 BOX #
# LOCATION: SUMMIT BASEMENT #
# #
#########################################################
Any thought on how to resolve the current situation would be most
appreciated! ;)
--
Here's my RSA Public key:
gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9
Share and enjoy!!
12 years, 4 months
Re: ubuntu sudoers won't talk to LDAP
by bluethundr
> Why are you screwing with /etc/ldap/ldap.conf or /etc/ldap/conf? Neither of
> these files are used by sudo on debian/ubuntu.
>
> --Quana
root@ubuntu3:~# cat /etc/ldap.conf > /etc/sudo-ldap.conf
root@ubuntu3:~# su - bluethundr
bluethundr@ubuntu3:~$ sudo bash
That did it! Thank you for catching that.. this was a change from 8.04
to 9.10.. 8.04 looks to /etc/ldap/ldap.conf...
Best regards and I sincerely appreciate your input!
On Fri, Nov 19, 2010 at 7:43 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote:
> --On Friday, November 19, 2010 7:14 PM -0500 bluethundr
> <bluethundr(a)gmail.com> wrote:
>
>> This move had no effect:
>>
>> root@ubuntu3:~# mv /etc/ldap/ldap.conf /etc/ldap/ldap.conf.bak
>> root@ubuntu3:~# ln -s /etc/ldap.conf /etc/ldap/ldap.conf
>
> Your output from sudo on that box *clearly* states that sudo-ldap uses
> "/etc/sudo-ldap.conf".
>
> Why are you screwing with /etc/ldap/ldap.conf or /etc/ldap/conf? Neither of
> these files are used by sudo on debian/ubuntu.
>
> --Quanah
>
>
> --
>
> Quanah Gibson-Mount
> Principal Software Engineer
> Zimbra, Inc
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
>
--
Here's my RSA Public key:
gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9
Share and enjoy!!
12 years, 4 months
Re: ubuntu sudoers won't talk to LDAP
by bluethundr
>> --On Friday, November 19, 2010 6:35 PM -0500 bluethundr <bluethundr(a)gmail.com> wrote:
>> I check /etc/ldap/ldap.conf:
>> root@ubuntu3:~# cat /etc/ldap/ldap.conf
>> ldap.conf path: /etc/sudo-ldap.conf
> Hm, these two files don't match. Looks to me like you are editing the wrong file.
Thank you Quanah
This move had no effect:
root@ubuntu3:~# mv /etc/ldap/ldap.conf /etc/ldap/ldap.conf.bak
root@ubuntu3:~# ln -s /etc/ldap.conf /etc/ldap/ldap.conf
root@ubuntu3:~# su - bluethundr
bluethundr@ubuntu3:~$ sudo bash
sudo: no valid sudoers sources found, quitting
On Fri, Nov 19, 2010 at 7:12 PM, bluethundr <bluethundr(a)gmail.com> wrote:
> sorry meant that for the list..
>
> On Fri, Nov 19, 2010 at 7:12 PM, bluethundr <bluethundr(a)gmail.com> wrote:
>> Thank you Quanah
>>
>> This move had no effect:
>>
>> root@ubuntu3:~# mv /etc/ldap/ldap.conf /etc/ldap/ldap.conf.bak
>> root@ubuntu3:~# ln -s /etc/ldap.conf /etc/ldap/ldap.conf
>>
>>
>> root@ubuntu3:~# su - bluethundr
>> bluethundr@ubuntu3:~$ sudo bash
>> sudo: no valid sudoers sources found, quitting
>>
>>
>> :(
>>
>> On Fri, Nov 19, 2010 at 6:48 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote:
>>> --On Friday, November 19, 2010 6:35 PM -0500 bluethundr
>>> <bluethundr(a)gmail.com> wrote:
>>>
>>>> I check /etc/ldap/ldap.conf:
>>>>
>>>> root@ubuntu3:~# cat /etc/ldap/ldap.conf
>>>
>>>> ldap.conf path: /etc/sudo-ldap.conf
>>>
>>>
>>> Hm, these two files don't match. Looks to me like you are editing the wrong
>>> file.
>>>
>>> --Quanah
>>>
>>> --
>>>
>>> Quanah Gibson-Mount
>>> Principal Software Engineer
>>> Zimbra, Inc
>>> --------------------
>>> Zimbra :: the leader in open source messaging and collaboration
>>>
>>
>>
>>
>> --
>> Here's my RSA Public key:
>> gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9
>>
>> Share and enjoy!!
>>
>
>
>
> --
> Here's my RSA Public key:
> gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9
>
> Share and enjoy!!
>
--
Here's my RSA Public key:
gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9
Share and enjoy!!
12 years, 4 months
ubuntu sudoers won't talk to LDAP
by bluethundr
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!!
12 years, 4 months
Re: Replication Through A DMZ
by Anton Chu
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
>
12 years, 4 months
