Search results for "starttls" - openldap-technical

AW: Re: AW: Re: AW: StartTLS is not working

by Hauke Coltzau

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 ------------------------------------

16 years, 1 month

Re: Openldap and sssd: getting slapd to do TLS negotiation or getting sssd to NOT do TLS negotiation

by brendan kearney

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 > >

7 years, 1 month

Re: ldap_sasl_interactive_bind_s failed (-2) using openldap v2.3.43 when trying to replicate via syncrepl.

by Kristian Kostecky

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-----

14 years, 7 months

Using supportedControl 1.3.6.1.4.1.4203.1.10.1 (Subentries) - critical extension is unavailable 12

by Gavin Henry

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.

3 years, 11 months

ACL not behaving as I would expect

by Scott Classen

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

4 years, 1 month

Openldap 2.3 syncrepl filter problem

by Lanfeust troy

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,

15 years, 5 months

Re: OpenLDAP + Kerberos on FreeBSD 7.2, close to working but not quite

by Dieter Kluenter

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

15 years, 3 months

Using TLS not seeing EXTERNAL as Using TLS not seeing EXTERNAL as supported SASL mechanism

by Bill MacAllister

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

8 years, 9 months

Strange TLS issue while upgrading from openldap 2.3 to 2.4

by Guillaume Rousse

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

12 years, 5 months

Replication Provider consumer

by arun.sasi1＠wipro.com

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

12 years, 2 months

openldap-technical search results for query "starttls"