Hi Dat,
> I've added the below to /etc/openldap/ldap.conf on RHEL 5:
> TLS_CACERT /etc/openldap/cacerts/ServerCA.chain.pem
> TLS_REQCERT demand
>
> and still getting errors messages... below:
>
> TLS certificate verification: Error, self signed certificate
The LDAP server does not send a server certificate but
a self signed certificate. Are you sending the RootCA's
certificate? Create a server certificate as described in
the tutorial and let your LDAP server use this.
I assume that you will have to read a bit more about certificates
and openssl to understand all the steps of the mini tutorial.
Rergards,
Hauke
----- Original Message ----
From: Hauke Coltzau <hauke.coltzau(a)FernUni-Hagen.de>
To: openldap-software <openldap-software(a)openldap.org>
Cc: Dat Duong <datduong2000(a)yahoo.com>
Sent: Wednesday, October 8, 2008 2:09:11 AM
Subject: AW: Re: AW: StartTLS is not working
Hi Dat,
glad to see that the first problem has been solved now.
As Dieter already pointed out, we need to know how the
certificates have been created. As a rough overview, you
will need to run through following steps:
0. Understand the basic idea:
At the end of this MiniHowto, you will have three certification
authorities:
UserCA: For user certificates (usually password protected)
ServerCA: For server certificates (usually NOT password protected)
RootCA: The CA that everyone has to trust in the end. This CA
only exists to create and verify the UserCA and ServerCA.
For your LDAP server, you create a server certificate with your ServerCA.
The LDAP clients will accept the LDAP certificate as long as they trust the
ServerCA. They will trust the ServerCA because they trust the RootCA. To make
them do so, you will need the certificates of the ServerCA AND the RootCA
on each client. Just to make sure: We are not talking about copying the
LDAP certificate to the client. Instead, you will copy the CA
certificates to the client.
1. Create directory structure and files containing
random numbers (need to be root for this):
# Make sure uuencode is installed. On Debian based
# systems, type
#
# apt-get install sharutils
#
cd /usr/lib/ssl/
for i in RootCA ServerCA UserCA; do
mkdir -p $i/newcerts;
mkdir $i/certs;
mkdir $i/crl;
mkdir $i/private;
touch $i/index.txt;
echo 01 > $i/serial;
chmod -R g-rwx,o-rwx $i;
done
for i in `find /usr/lib/ssl/ -name private`
do cat /dev/urandom |
uuencode -m bla |
head -19 |
sed "s/begin.*//g" |
tail -18 | xargs |
sed "s/ //g" > $i/.rand
chmod 770 $i/.rand
ls -l $i/.rand
done
At the end of this step, you will have three subdirectories in
/usr/lib/ssl:
RootCA: Contains the root CA's self-signed certificate and private key
as well as the certificates created by the root CA.
ServerCA: Contains the CA which is used to create server certificates. Again,
the directory contains of the server CA's certificate and key as well
as the certificates created by the server CA.
UserCA: Contains the CA which is used to create user certificates.
2. openssl.cnf
Adapt your openssl.cnf (should be in /usr/lib/ssl, too) to have proper entries
for each of the CAs:
HOME = /usr/lib/ssl
[ RootCA ]
dir = /usr/lib/ssl/RootCA
certs = $dir/certs
crl_dir = $dir/crl
database = $dir/index.txt
new_certs_dir = $dir/newcerts
certificate = $dir/RootCA.cert.pem
serial = $dir/serial
crl = $dir/crl.pem
private_key = $dir/private/RootCA.key.pem
RANDFILE = $dir/private/.rand
policy = policy_match
x509_extensions = ca_cert
[ ServerCA ]
dir = /usr/lib/ssl/ServerCA
certs = $dir/certs
crl_dir = $dir/crl
database = $dir/index.txt
new_certs_dir = $dir/newcerts
certificate = $dir/ServerCA.cert.pem
serial = $dir/serial
crl = $dir/crl.pem
private_key = $dir/private/ServerCA.key.pem
RANDFILE = $dir/private/.rand
x509_extensions = usr_cert
(Same with [ UserCA ])
There are more options to be set, but they depend on your environment. Have
a look at the default_days, default_md, ... parameters.
1. Create a self signed certificate (RootCA):
cd /usr/lib/ssl/RootCA
# Create the private key first
# You will be asked for a new pasword here. Make it a good one and remember it ;-)
openssl genrsa -aes256 -out /usr/lib/ssl/RootCA/private/RootCA.key.pem -rand /usr/lib/ssl/RootCA/private/.rand 2048
chmod g-rwx,o-rwx /usr/lib/ssl/RootCA/private/RootCA.key.pem
# Now create a certification request. Because the cert is self-signed, this
# directly creates the RootCA's certificate. You will be asked for the
# password you just created.
#
# All in one line:
openssl req -new -x509 -days 1827 -key /usr/lib/ssl/RootCA/private/RootCA.key.pem
-out /usr/lib/ssl/RootCA/RootCA.cert.pem
# Copy the certificate to the certs directory and create a link named like
# the cert's hash value
cp RootCA.cert.pem certs/00.pem
cd certs
ln -s /usr/lib/ssl/RootCA/certs/00.pem `openssl x509 -hash -noout -in 00.pem`.0
Now you should have the cert (00.pem) and something like 1a2783e8.0 pointing to
/usr/lib/ssl/RootCA/00.pem
2. Create the ServerCA
cd /usr/lib/ssl/ServerCA
# Create the private key for the ServerCA
# You will be asked for a new password here. Do not make it the same as the RootCA's
# password, but still - make it a good one.
#
openssl genrsa -aes256 -out /usr/lib/ssl/ServerCA/private/ServerCA.key.pem
-rand /usr/lib/ssl/ServerCA/private/.rand 2048
chmod g-rwx,o-rwx /usr/lib/ssl/ServerCA/private/ServerCA.key.pem
# Create the certification request. You will be asked for the
# newly created password.
# (All in one line)
openssl req -new -days 1827 -key /usr/lib/ssl/ServerCA/private/ServerCA.key.pem
-out /usr/lib/ssl/ServerCA/ServerCA.req.pem
# Let the RootCA sign the request and create the certificate.
# You will need the RootCA's password for this.
#
openssl ca -name RootCA -in /usr/lib/ssl/ServerCA/ServerCA.req.pem
-out /usr/lib/ssl/ServerCA/ServerCA.cert.pem
# Copy and link the certificate.
#
mv /usr/lib/ssl/RootCA/newcerts/01.pem /usr/lib/ssl/RootCA/certs/
cd /usr/lib/ssl/RootCA/certs/
ln -s 01.pem `openssl x509 -in 01.pem -hash -noout`.0
# And copy the part neccessary for browser integration into
# another file (this is the part between BEGIN CERTIFICATE and END CERTIFICATE)
#
cd /usr/lib/ssl/ServerCA
sed -n '/-----BEGIN CERTIFICATE-----/,$p' ServerCA.cert.pem > ServerCA.crt
# Create the CACerts file used on the client side to verify a server cert
mkdir /usr/lib/ssl/cacerts/
cat /usr/lib/ssl/RootCA/RootCA.cert.pem /usr/lib/ssl/ServerCA/ServerCA.cert.pem > /usr/lib/ssl/cacerts/ServerCA.chain.pem
# The newly created file (ServerCA.chain.pem) is the CACertsFile which has to be copied
# to every client. Create a /usr/lib/ssl/cacerts/ directory on the client side and copy
# the file to that location.
3. Do the same with the User CA
4. Create your LDAP server certificate. As for the name in your cert, use the fqdn of
the machine you are running the server on.
cd /usr/lib/ssl/ServerCA
# You will NOT need a password here
#
openssl genrsa -out <fqdn-of-your-server>.key.pem -rand ./private/.rand 2048
openssl req -new -key <fqdn-of-your-server>.key.pem -out <fqdn-of-your-server>.req.pem
# But here, you will be asked for the ServerCA's password
openssl ca -name ServerCA -in <fqdn-of-your-server>.req.pem -out <fqdn-of-your-server>.cert.pem
Move and link the new certificate (in newcerts) as above.
5. Configure LDAP server and clients
Make sure that your ldap server can read its own private key. If your ldap server is
running as user openldap, make sure that this user owns the private key in
/usr/lib/ssl/ServerCA/private/
Normal users should never be allowed to read the key! This would break the whole security
mechanism.
In your slapd.conf, you will have
TLSCertificateFile /usr/lib/ssl/certs/<fqdn>.cert.pem
TLSCertificateKeyFile /usr/lib/ssl/private/<fqdn>.key.pem
And on client side ldap.conf:
TLS_CACERT /usr/lib/ssl/cacerts/ServerCA.chain.pem
TLS_REQCERT demand
Hope this helps,
Hauke
p.s.: The description is strongly influenced by Frank Steidl's tutorial as
it can be found at http://fra.nksteidl.de/Erinnerungen/OpenSSL.php
----- Ursprüngliche Mail -----
Von: "Dieter Kluenter" < dieter(a)dkluenter.de >
An: openldap-technical(a)openldap.org
Gesendet: Dienstag, 7. Oktober 2008 22:34:14 GMT +01:00 Amsterdam/Berlin/Bern/Rom/Stockholm/Wien
Betreff: Re: AW: StartTLS is not working
Dat Duong < datduong2000(a)yahoo.com > writes:
> Hi Hauke,
>
> I still can't get TLS to work. Here is the error message.
>
> TLS certificate verification: Error, self signed certificate
> tls_write: want=7, written=7
> 0000: 15 03 01 00 02 02 30 ......0
> 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
Please describe the parameters to create your certificate chain.
I presume you have not signed your certificates with a known
certificate authority.
-Dieter
--
Dieter Klünter | Systemberatung
http://www.dpunkt.de/buecher/2104.html
GPG Key ID:8EF7B6C6
53°08'09,95"N
10°08'02,42"E
--
------------------------------------
Fernuniversität in Hagen
Lehrgebiet Kommunikationsnetze
http://www.fernuni-hagen.de/kn
Fon/Fax: +49 2331 987 -1142 / -353
------------------------------------
--
------------------------------------
Fernuniversität in Hagen
Lehrgebiet Kommunikationsnetze
http://www.fernuni-hagen.de/kn
Fon/Fax: +49 2331 987 -1142 / -353
------------------------------------
SASL is a "glue" between LDAP and Kerberos, that translates an identity
established through Kerberos AuthN to an LDAP Distinguished Name (among
other possible uses). When communications between Kerberos and LDAP happen,
SASL also provides encryption.
I have setup Kerberos, SASL, OpenLDAP and SSSD all on Fedora and it all
works. I dont have to muck with SSL/TLS and the different implementations
with their specific nuances.
Though you dont know much about Kerberos, its not too difficult to
implement. You seem to have the aptitude to do so. Might just be a matter
of reading up on how to.
On Sep 29, 2017 10:00 AM, "Robert Heller" <heller(a)deepsoft.com> wrote:
> At Fri, 29 Sep 2017 07:52:34 -0400 brendan kearney <bpk678(a)gmail.com>
> wrote:
>
> >
> >
> > Late ti the thread, so forgive the stupid question, but why arent you
> using
> > SASL and forgoing all the OpenSSL vs MozNSS kerfuffle? If you have
> OpenLDAP
> > and SSSD going on, surely Kerberos is something you are able to setup.
>
> Does SASL replace TLS/SSL? I thought SASL had to do with password hashing
> and
> not anything to do with the connection protocol. I know basicly nothing
> about
> Kerberos.
>
> >
> > On Sep 29, 2017 2:20 AM, "Michael Wandel" <m.wandel(a)t-online.de> wrote:
> >
> > > On 28.09.2017 21:41, Robert Heller wrote:
> > > > Will these spit out useful error messages? If I just get "TLS
> > > Negotiation
> > > > failure" it is not going to be helpful.
> > > >
> > >
> > > You can make it a little bit more verbose with the option "-d -1"
> > >
> > > It is only a suggestion, but can you test the parameter
> > >
> > > TLS_REQCERT allow
> > >
> > > in your /etc/openldap/ldap.conf
> > >
> > > This ist not a good option for production systems, but it seems you
> come
> > > in trouble with your certificates.
> > >
> > > You have to set your
> > >
> > > TLS_CACERT
> > > xor
> > > TLS_CACERTDIR
> > >
> > > correctly in your /etc/openldap/slapd.conf to work stressless with your
> > > ssl/tls.
> > >
> > > best regards
> > > Michael
> > >
> > > > At Thu, 28 Sep 2017 12:29:19 -0700 Quanah Gibson-Mount <
> quanah(a)symas.com>
> > > wrote:
> > > >
> > > >>
> > > >> --On Thursday, September 28, 2017 3:34 PM -0400 Robert Heller
> > > >> <heller(a)deepsoft.com> wrote:
> > > >>
> > > >>
> > > >>> Slapd is reporting TLS Negotiation failure when SSSD tries to
> connect
> > > to
> > > >>> it. For both port 389 (ldap:///) and 636 (ldaps:///). So I guess
> > > >>> something is wrong with slapd's TLS configuration -- it is
> failing to
> > > do
> > > >>> TLS Negotiation, either it is just not doing it or it is doing it
> > > wrong
> > > >>> (somehow). Unless SSSD is not configured properly.
> > > >>
> > > >> You need to start with the following:
> > > >>
> > > >>>> ldapwhoami -x -ZZ -H ldap://myhost:389 -D binddn -w
> > > >>
> > > >> to test startTLS
> > > >>
> > > >> and
> > > >>
> > > >> ldapwhoami -x -H ldaps://myhost:636 -D binddn -w
> > > >>
> > > >> to test without startTLS
> > > >>
> > > >> If you can get those to work, then you can move on to SSSD.
> > > >>
> > > >> --Quanah
> > > >>
> > > >> --
> > > >>
> > > >> Quanah Gibson-Mount
> > > >> Product Architect
> > > >> Symas Corporation
> > > >> Packaged, certified, and supported LDAP solutions powered by
> OpenLDAP:
> > > >> <http://www.symas.com>
> > > >>
> > > >>
> > > >
> > >
> > >
> > > --
> > > Michael Wandel
> > > Braakstraße 43
> > > 33647 Bielefeld
> > >
> > >
> >
> >
>
> --
> Robert Heller -- 978-544-6933
> Deepwoods Software -- Custom Software Services
> http://www.deepsoft.com/ -- Linux Administration Services
> heller(a)deepsoft.com -- Webhosting Services
>
>
I should provide one more piece of information that might be important. I just noticed in /var/log/messages:
slapd: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Unknown code krb5 194)
Looking that error code up @ http://www.lineox.net/lineox/docs/HTML/info2html/krb5-admin/krb5-admin.info… yeilds:
194. KRB5_FCC_PERM: Credentials cache file permissions incorrect
However, the credential cache file has the appropriate perms. LDAP runs as user root. So, it should have no problems reading the /etc/krb5.keytab and the credential cache file under /tmp
ls -la /tmp/krb5cc_0
-rw------- 1 root root 569 Mar 31 18:11 krb5cc_0
Thanks again!
Kris.
PGP Key: 4CC63A18
PGP Server: pool.sks-keyservers.net
On 2010-03-31, at 6:20 PM, Kristian Kostecky wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi guys,
>
> I have a configuration that consists of 3 ldap servers. One is the provider and there are 2 consumers. I am using syncrepl to do the synchronization. simple and anonymous binds are totally disabled and Kerberos must be used via SASL (GSSAPI) and TLS to connect to the LDAP server.
>
> distro: centos 5.4
> openldap 2.3.43
> cyrus-sasl 2.1.22
>
> Other things:
> - - clocks are all in sync
> - - hostnames all have forward and reverse mappings and all dns servers in /etc/resolv.conf respond with proper entries on the consumer and both providers.
>
> Here's the catch, the two providers are configured the same (except for hostnames/ips) and the first one works perfect. What is really frustrating is the lack of logging that is available to tell me what the problem is. I've tried loglevel -1 and it gave me even less info in regards to the SASL authentication than leaving it off.
>
> The affected consumer is giving me:
>
> Mar 31 22:41:00 ZZZ slapd[2442]: slapd starting
> Mar 31 22:41:02 ZZZ slapd[2442]: do_syncrep1: rid 010 ldap_sasl_interactive_bind_s failed (-2)
> Mar 31 22:41:02 ZZZ slapd[2442]: do_syncrepl: rid 010 quitting
>
> On the "Provider":
>
> Mar 31 17:49:54 XXX slapd[3494]: conn=212 fd=21 ACCEPT from IP=10.130.1.230:60288 (IP=0.0.0.0:389)
> Mar 31 17:49:54 XXX slapd[3494]: conn=212 op=0 STARTTLS
> Mar 31 17:49:54 XXX slapd[3494]: conn=212 op=0 RESULT oid= err=0 text=
> Mar 31 17:49:54 XXX slapd[3494]: conn=212 fd=21 TLS established tls_ssf=256 ssf=256
> Mar 31 17:49:54 XXX slapd[3494]: conn=212 op=1 UNBIND
> Mar 31 17:49:54 XXX slapd[3494]: conn=212 fd=21 closed
>
> This is what's REALLY weird - from the affected/broken box, ZZZ, after I kinit, I can do an LDAP search or ldapwhoami, no problems! So, kerberos and GSSAPI via SASL is working fine. ie:
>
> ldapsearch -H ldaps://XXX/ -Y GSSAPI -> will dump the entries.
> or
> ldapwhoami -H ldaps://XXX/ -Y GSSAPI -> shows me that proper creds
>
> If I destroy the credentials, it doesn't work as would be expected.
>
> ON the working consumer, the behaviour is that I can ldapsearch and ldapwhoami properly after I kinit and when I start ldap it will authenticate properly with the provider via SASL GSSAPI and replicates the DB. If I kdestroy the credentials and start it, I get the same error that I'm struggling with on the box that doesn't work ->ldap_sasl_interactive_bind_s failed (-2) This behaviour leads me to believe that for some reason the ldap server on the box that doesn't work is having problems transmitting the kerberos credentials to the provider, whereas the ldapsearch and ldapwhoami binaries are not having problems.
>
> There are some suspicious differences between the consumer that works and the broken one. The provider and consumer that works both have TLDs that match - '.com' and the consumer whose synrepl process won't authenticate is part of the .eu TLD. However, as you can see below in the krb5.conf files, the .com and .eu TLDS are always mapped to the same authentication realm. PLUS, again, ldapsearch and ldapwhoami WORK. It's just the syncrepl process that isn't quite getting the auth right.
>
> This is the provider's pertinent configs:
>
> slapd.conf:
> overlay syncprov
> syncprov-checkpoint 100 10
> syncprov-sessionlog 100
>
> This is the consumer's pertinent configs (WORKS ON one, not on the other)
> slapd.conf:
> syncrepl rid=10
> provider=ldap://xxx.XXX.com
> starttls=yes
> type=refreshOnly
> interval=00:00:01:00
> searchbase="dc=XXX,dc=com"
> schemachecking=off
> bindmethod=sasl
> saslmech=GSSAPI
>
> krb5.conf [same as provider and kerb server]:
> [libdefaults]
> default_realm = BOUNCE.AAA.COM
> encrypt = true
> allow_weak_crypto = false
> clockskew = 600
> dns_lookup_realm = false
> dns_lookup_kdc = false
> ticket_lifetime = 8h
> forwardable = no
> proxiable = no
>
> [realms]
> BOUNCE.AAA.COM = {
> kdc = XXX.com
> kdc = YYY.com
> kdc = ZZZ.eu
> admin_server = XXX.com
> }
>
> [domain_realm]
> .com = BOUNCE.AAA.COM
> .eu = BOUNCE.AAA.COM
>
>
> All help is greatly appreciated! This has been going on for days and I've already yanked out most of my hair. Thank you.
>
> Kris.
>
> PGP Key: 4CC63A18
> PGP Server: pool.sks-keyservers.net
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
>
> iEYEARECAAYFAkuzyroACgkQ2C/J5/UUQWEuUACdH/BhiZgTXFWbNMXS7Q99k8Rg
> VY8An3YWKcpnkxVYvZMlelkT0TIpYuAP
> =O9KI
> -----END PGP SIGNATURE-----
Hi all,
I'm doing this for a supportControl subentry delete:
https://metacpan.org/pod/Net::LDAP::Control
like so:
my $subentry_ctrl = Net::LDAP::Control->new(
type => '1.3.6.1.4.1.4203.1.10.1',
value => 'Subentries',
critical => 1
);
my $deleted = $c->model('LDAPContacts')->delete(
q{ou=Contacts,} . $user_dn,
control => [ $subentry_ctrl ]
);
if ( $deleted->code ) {
$c->error( qq{Failed to delete LDAP contact entries for: $user_dn}
. $deleted->error
. q{ Code: }
. $deleted->code );
return 0;
}
and I'm getting:
Dec 22 12:53:57 gabriel slapd[31511]: conn=1110022 op=2 SRCH attr=dn
Dec 22 12:53:57 gabriel slapd[31511]: conn=1110022 op=2 ENTRY dn="xxxx"
Dec 22 12:53:57 gabriel slapd[31511]: conn=1110022 op=2 SEARCH RESULT
tag=101 err=0 qtime=0.000010 etime=0.001015 nentries=1 text=
Dec 22 12:53:57 gabriel slapd[31511]: conn=1110023 fd=435 ACCEPT from
IP=xxx:51082 (IP=0.0.0.0:389)
Dec 22 12:53:57 gabriel slapd[31511]: conn=1110023 op=0 EXT
oid=1.3.6.1.4.1.1466.20037
Dec 22 12:53:57 gabriel slapd[31511]: conn=1110023 op=0 STARTTLS
Dec 22 12:53:57 gabriel slapd[31511]: conn=1110023 op=0 RESULT oid=
err=0 qtime=0.000007 etime=0.000038 text=
Dec 22 12:53:57 gabriel slapd[31511]: conn=1110023 fd=435 TLS
established tls_ssf=256 ssf=256 tls_proto=TLSv1.3
tls_cipher=TLS_AES_256_GCM_SHA384
Dec 22 12:53:57 gabriel slapd[31511]: conn=1110023 op=1 BIND dn="xxx" method=128
Dec 22 12:53:57 gabriel slapd[31511]: conn=1110023 op=1 BIND dn="xxx"
mech=SIMPLE ssf=0
Dec 22 12:53:57 gabriel slapd[31511]: conn=1110023 op=1 RESULT tag=97
err=0 qtime=0.000017 etime=0.000116 text=
Dec 22 12:53:58 gabriel slapd[31511]: conn=1110023 op=2 RESULT tag=107
err=12 qtime=0.000014 etime=0.000274 text=critical extension is
unavailable
Dec 22 12:53:58 gabriel slapd[31511]: conn=1110023 op=2 do_delete:
get_ctrls failed
Any ideas? Using ldapdelete with -r works as the same user (so not my
ACLs), but I note in the logs that it is doing a base search for
subentries and deleting each one.
What am I misunderstanding here?
Thanks,
Gavin.
Hello,
I’m having trouble understanding why I can’t get a service account to reset a userPassword attribute.
ACLs are:
{0}to attrs=userPassword
by self write
by anonymous auth
by * none
{1}to *
by self write
by users read
by dn.base="uid=pwreset,dc=example,dc=com" write
by * none
But when the password reset utility attempts to modify the password I see the following 50 error, indicating that the ACL is somehow preventing the pwreset account from modifying userPassword
Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 fd=22 ACCEPT from IP=192.168.1.104:52888 (IP=0.0.0.0:389)
Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=0 STARTTLS
Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=0 RESULT oid= err=0 text=
Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 fd=22 TLS established tls_ssf=256 ssf=256
Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=1 BIND dn="uid=pwreset,dc=example,dc=com" method=128
Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=1 BIND dn="uid=pwreset,dc=example,dc=com" mech=SIMPLE ssf=0
Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=1 RESULT tag=97 err=0 text=
Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=2 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=username))"
Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text=
Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=3 MOD dn="uid=username,ou=People,dc=example,dc=com"
Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=3 MOD attr=userPassword
Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=3 RESULT tag=103 err=50 text=
Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=4 UNBIND
Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 fd=22 closed
I’ve also tried with this ACL combination:
{0}to attrs=userPassword
by self write
by anonymous auth
by dn.base="uid=pwreset,dc=example,dc=com" write
by * none
{1}to *
by self write
by users read
by * none
Any advice would be greatly appreciated.
Scott
Hi list,
In configuration of provider and consumer server with syncrepl is possible
to modify the replication filter for add new user in replica.
In fisrt time the replica is :
syncrepl rid=123
provider=ldap://rh-test3.kvm.rla:389
type=refreshOnly
interval=00:00:01:00
retry="30 10 600 20"
searchbase="dc=local"
filter="(|(objectClass=sambaGroupMapping)(uid=user1))"
scope=sub
schemachecking=off
bindmethod=simple
binddn="uid=syncrepl,ou=sysusers,dc=local"
credentials=pwdsyncrepl
# BEGIN Session TLS
starttls="critical"
tls_cacert=__CACERTFILE__
# End Session TLS
When start the replica server it doing an ldapsearch and retrieve my data in
replica.
So now we modify the filter as the following :
filter="(|(objectClass=sambaGroupMapping)(uid=user1)(uid=user2))"
Now when the replica doing the ldapsearch request it do with the new filter
but returning numentrie to 0
like this in the log of master LDAP server:
Jun 24 22:40:40 rh-test3 slapd[28012]: conn=83 op=1 BIND
dn="uid=syncrepl,ou=sysusers,dc=local" mech=SIMPLE ssf=0
Jun 24 22:40:40 rh-test3 slapd[28012]: conn=83 op=1 RESULT tag=97 err=0
text=
Jun 24 22:40:40 rh-test3 slapd[28012]: conn=83 op=2 SRCH base="dc=local"
scope=2 deref=0
filter="(|(objectClass=sambaGroupMapping)(uid=user1)(uid=user2))"
Jun 24 22:40:40 rh-test3 slapd[28012]: conn=83 op=2 SRCH attr=* +
Jun 24 22:40:40 rh-test3 slapd[28012]: conn=83 op=2 SEARCH RESULT tag=101
err=0 *nentries=0* text=
And when i do ldapsearch manually :
ldapsearch -x -b dc=local -H ldap://rh-test3.kvm.rla
"(|(objectClass=sambaGroupMapping)(uid=user1)(uid=user2))"
Jun 24 23:40:38 rh-test3 slapd[28012]: conn=133 op=1 BIND dn="" method=128
Jun 24 23:40:38 rh-test3 slapd[28012]: conn=133 op=1 RESULT tag=97 err=0
text=
Jun 24 23:40:38 rh-test3 slapd[28012]: conn=133 op=2 SRCH base="dc=local"
scope=2 deref=0
filter="(|(objectClass=sambaGroupMapping)(uid=user1)(uid=user2))"
Jun 24 23:40:38 rh-test3 slapd[28012]: conn=133 op=2 SEARCH RESULT tag=101
err=0 *nentries=13* text=
I don't understand why my new user is not sync !!
thanks for your help,
Allan <cr4z3d(a)gmail.com> writes:
> Hello, I've been reading around on OpenLDAP + Kerberos (FreeBSD 7.2) for
> authentication/authorization. I'm a bit confused on how to get it all working
> but I've gotten far enough that I can run getent passwd test.user and it pulls
> down the information from ldap (ran as root and non-root user). I can also
> successfully get a ticket with kinit from various users. Where I run into
> problems, is actually getting services to use GSSAPI. I am currently using
> nss_ldap and pam_ldap to authenticate during ssh login, if there's a better
> alternative please let me know.
>
> Here's the setup I've got:
> Services -> FQDN -> IP
> ldap/kdc -> frisbee.crazy.lan -> 192.168.1.5
> ssh -> cake.crazy.lan -> 192.168.1.6
[...]
> Aug 9 17:47:21 frisbee slapd[86935]: conn=15 fd=11 ACCEPT from IP=
> 192.168.1.6:56955 (IP=0.0.0.0:389)
> Aug 9 17:47:21 frisbee slapd[86935]: conn=15 op=0 EXT oid=
> 1.3.6.1.4.1.1466.20037
> Aug 9 17:47:21 frisbee slapd[86935]: conn=15 op=0 STARTTLS
> Aug 9 17:47:21 frisbee slapd[86935]: conn=15 op=0 RESULT oid= err=0 text=
> Aug 9 17:47:21 frisbee slapd[86935]: conn=15 fd=11 TLS established tls_ssf=
> 256 ssf=256
> Aug 9 17:47:21 frisbee slapd[86935]: conn=15 op=1 BIND dn="" method=163
> Aug 9 17:47:21 frisbee slapd[86935]: SASL [conn=15] Failure: Couldn't find
> mech GSSAPI
> Aug 9 17:47:21 frisbee slapd[86935]: conn=15 op=1 RESULT tag=97 err=7 text=
> SASL(-4): no mechanism available: Couldn't find mech GSSAPI
> Aug 9 17:47:21 frisbee slapd[86935]: conn=15 op=2 UNBIND
> Aug 9 17:47:21 frisbee slapd[86935]: conn=15 fd=11 closed
> ==============================================================
>
> This is where I get a bit confused, it tells me that there's no mechanism for
> GSSAPI.. So I try changing to no SASL options in the configuration file:
What is the output of
ldapsearch -x -H ldap://localhost -b "" -s base supportedSaslMechanisms
-Dieter
--
Dieter Klünter | Systemberatung
http://dkluenter.de
GPG Key ID:8EF7B6C6
53°08'09,95"N
10°08'02,42"E
I am working on using TLS on an OpenLDAP server and having issues.
Basically I can make a TLS connection, but I don't see EXTERNAL as
one of the supportedSASLMechanisms. (slapd 2.4.41+dfsg-1ubuntu2~dbp0
built with openssl)
Here is my ldapsearch:
$ ldapsearch -h ldap-test-master1.corp.dropbox.com -x -ZZ -b '' -s base supportedSASLMechanisms
# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: (objectclass=*)
# requesting: supportedSASLMechanisms
#
#
dn:
supportedSASLMechanisms: GS2-IAKERB
supportedSASLMechanisms: GS2-KRB5
supportedSASLMechanisms: SCRAM-SHA-1
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: NTLM
supportedSASLMechanisms: LOGIN
supportedSASLMechanisms: PLAIN
# search result
search: 3
result: 0 Success
# numResponses: 2
Here is what I see in the server log:
2016-02-09T02:40:00.797598+00:00 ldap-test-master1 slapd[22379]: conn=1008 fd=14 ACCEPT from IP=172.17.8.240:47231 (IP=0.0.0.0:389)
2016-02-09T02:40:00.797640+00:00 ldap-test-master1 slapd[22379]: conn=1008 op=0 EXT oid=1.3.6.1.4.1.1466.20037
2016-02-09T02:40:00.797646+00:00 ldap-test-master1 slapd[22379]: conn=1008 op=0 STARTTLS
2016-02-09T02:40:00.797686+00:00 ldap-test-master1 slapd[22379]: conn=1008 op=0 RESULT oid= err=0 text=
2016-02-09T02:40:00.804071+00:00 ldap-test-master1 slapd[22379]: conn=1008 fd=14 TLS established tls_ssf=256 ssf=256
2016-02-09T02:40:00.804540+00:00 ldap-test-master1 slapd[22379]: conn=1008 op=1 BIND dn="" method=128
2016-02-09T02:40:00.804590+00:00 ldap-test-master1 slapd[22379]: conn=1008 op=1 RESULT tag=97 err=0 text=
2016-02-09T02:40:00.804931+00:00 ldap-test-master1 slapd[22379]: conn=1008 op=2 SRCH base="" scope=0 deref=0 filter="(objectClass=*)"
2016-02-09T02:40:00.804941+00:00 ldap-test-master1 slapd[22379]: conn=1008 op=2 SRCH attr=supportedSASLMechanisms
2016-02-09T02:40:00.805056+00:00 ldap-test-master1 slapd[22379]: conn=1008 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text=
2016-02-09T02:40:00.805483+00:00 ldap-test-master1 slapd[22379]: conn=1008 op=3 UNBIND
2016-02-09T02:40:00.805587+00:00 ldap-test-master1 slapd[22379]: conn=1008 fd=14 closed
What should I be looking at? What am I missing?
Thanks in advance,
Bill
Hello list.
I recently faced a strange issue while upgrading from openldap 2.3 to
2.4 (from centos 5.7 to 6.2, actually): the change was transparent for
every applications excepted Zimbra, for which any authentication attempt
was suffering from an unexplained 30s additional delay. Just switching
from explicit TLS usage on port 389 to explicit SSL usage on port 636
was enough to fix the issue.
The logs shows than the delay occurs between the moment where the bind
operation succeed, and the moment the client connection get closed:
Jun 14 11:56:04 ildapslave2 slapd[16618]: conn=2787 fd=135 ACCEPT from
IP=128.93.142.13:41191 (IP=0.0.0.0:389)
Jun 14 11:56:04 ildapslave2 slapd[16618]: conn=2787 op=0 EXT
oid=1.3.6.1.4.1.1466.20037
Jun 14 11:56:04 ildapslave2 slapd[16618]: conn=2787 op=0 STARTTLS
Jun 14 11:56:04 ildapslave2 slapd[16618]: conn=2787 op=0 RESULT oid=
err=0 text=
Jun 14 11:56:04 ildapslave2 slapd[16618]: conn=2787 fd=135 TLS
established tls_ssf=256 ssf=256
Jun 14 11:56:04 ildapslave2 slapd[16618]: conn=2787 op=1 BIND
dn="uid=fauge00C,ou=people,dc=inria,dc=fr" method=128
Jun 14 11:56:04 ildapslave2 slapd[16618]: conn=2787 op=1 BIND
dn="uid=fauge00C,ou=people,dc=inria,dc=fr" mech=SIMPLE ssf=0
Jun 14 11:56:04 ildapslave2 slapd[16618]: conn=2787 op=1 RESULT tag=97
err=0 text=
...
Jun 14 11:56:34 ildapslave2 slapd[16618]: conn=2787 fd=135 closed
(connection lost)
Before the upgrade, the connection get closed immediatly, and there is
no such delay.
Using higher logging level doesn't provide additional useful details,
excepted maybe more details about connection termination:
Jun 14 12:53:21 ildapslave2 slapd[7156]: connection_read(109): checking
for input on id=1135
Jun 14 12:53:21 ildapslave2 slapd[7156]: ber_get_next on fd 109 failed
errno=0 (Success)
Jun 14 12:53:21 ildapslave2 slapd[7156]: connection_read(109): input
error=-2 id=1135, closing.
I'm aware than this behaviour change may actually come from underlying
libraries, such as bdb for instance, rather than openldap itself, but
that's still quite a curious issue. Does anyone have a clue about this
problem ?
--
The more cordial the buyer's secretary, the greater the odds that the
competition already has the order
-- Murphy's Laws on Technology n°38
Hello Team,
I have configured a set up in my infra as like below.
Provider in OpenLDAP 2.4.19
Consumer in OpenLDAP 2.4.28
When I replicate the data, it all get replicate properly but when I create any entry in consumer server, it is getting writes in master LDAP server.
What could be the problem.
Please find the below consumer configuration file.
cn\=config.ldif
# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 9fe00430
dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /var/run/slapd/slapd.args
olcPidFile: /var/run/slapd/slapd.pid
olcToolThreads: 1
structuralObjectClass: olcGlobal
entryUUID: 6b8092fc-9667-1031-8a5a-358a8bc96075
creatorsName: cn=config
createTimestamp: 20120919053426Z
olcAllows: bind_v2
olcServerID: 1 ldap://gb0135embldap01.emb.slb.com
olcTLSCACertificateFile: /etc/ssl/certs/Emb.slb.Com-CA.pem
olcTLSCACertificatePath: /etc/ssl/certs/
olcTLSCertificateFile: /etc/ldap/emb.slb.com.cert.pem
olcTLSCertificateKeyFile: /etc/ldap/emb.slb.com.key.pem
olcLogLevel: -1
entryCSN: 20120919053444.175373Z#000000#000#000000
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20120919053444Z
olcDatabase\=\{1\}hdb.ldif
# CRC32 b10d01be
dn: olcDatabase={1}hdb
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=emb,dc=slb,dc=com
olcLastMod: TRUE
olcRootDN: cn=admin,dc=emb,dc=slb,dc=com
olcRootPW:: e1NTSEF9b28vRlZuM0JnaEQzWVBDUi9OUGVPODJ0ZktrMzlPNlg=
olcDbCheckpoint: 512 30
olcDbConfig: {0}set_cachesize 0 2097152 0
olcDbConfig: {1}set_lk_max_objects 1500
olcDbConfig: {2}set_lk_max_locks 1500
olcDbConfig: {3}set_lk_max_lockers 1500
olcDbIndex: objectClass eq
olcDbIndex: entryUUID eq
structuralObjectClass: olcHdbConfig
entryUUID: 6b816632-9667-1031-8a64-358a8bc96075
creatorsName: cn=config
createTimestamp: 20120919053426Z
olcSyncrepl: {0}rid=365 provider=ldap://gb0135embldap01.emb.slb.com bindmethod
=simple binddn="cn=admin,dc=emb,dc=slb,dc=com" credentials=Bsl@121z searchbas
e="dc=emb,dc=slb,dc=com" type=refreshAndPersist retry="5 5 300 5" starttls=yes
olcUpdateRef: ldap://gb0135embldap01.emb.slb.com
entryCSN: 20120919053435.138086Z#000000#000#000000
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20120919053435Z
Thanks & Regards,
Arun Sasi Venmalassery
-------------------------------------------------------------------------------------------------------------------------------------
Sr. Engineer - Server Management (UNIX),
Wipro Ltd (Dubai) |Mob: +971 566489491 | E: arun.sasi1(a)wipro.com<mailto:koresh.dash@wipro.com>
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
www.wipro.com