openldap-technical

openldap-technical@openldap.org

12 participants
9794 discussions

Re: Openldap and sssd: getting slapd to do TLS negotiation or getting sssd to NOT do TLS negotiation
by Quanah Gibson-Mount 29 Sep '17

29 Sep '17

--On Thursday, September 28, 2017 7:28 PM -0400 Robert Heller <heller(a)deepsoft.com> wrote: > 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. > > [heller@c764guest ~]$ ldapwhoami -x -ZZ -H ldap://c764guest:389 -D > cn=Manager,dc=deepsoft,dc=com -W ldap_start_tls: Connect error (-11) > additional info: TLS error -8157:Certificate extension not found. This may be of help: <https://serverfault.com/questions/640910/my-certificate-doesnt-work-on-all-…> > [heller@c764guest ~]$ ldapwhoami -x -H ldaps://c764guest:636 -D > cn=Manager,dc=deepsoft,dc=com -W Enter LDAP Password: > ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) This may mean slapd isn't listening on port 636 (With no -d -1 info, hard to know for sure). It may also simply be a different manifistation of the error above. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Openldap and sssd: getting slapd to do TLS negotiation or getting sssd to NOT do TLS negotiation
by Quanah Gibson-Mount 28 Sep '17

28 Sep '17

--On Thursday, September 28, 2017 11:26 PM +0200 Dieter Kluenter <dieter(a)dkluenter.de> wrote: > OK, back to basics, > 1. check whether sssd is compiled with openssl's libcrypto: RHEL uses MozNSS for everything, not openssl. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Openldap and sssd: getting slapd to do TLS negotiation or getting sssd to NOT do TLS negotiation
by Douglas Duckworth 28 Sep '17

28 Sep '17

What would you recommend as a replacement for SSSD? I am running it across Centos 6 and 7 clients without any issue using TLS. Thanks, Douglas Duckworth, MSc, LFCS HPC System Administrator Scientific Computing Unit Physiology and Biophysics Weill Cornell Medicine E: doug(a)med.cornell.edu O: 212-746-6305 F: 212-746-8690 On Thu, Sep 28, 2017 at 4:28 PM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Thursday, September 28, 2017 2:18 PM -0700 Quanah Gibson-Mount > <quanah(a)symas.com> wrote: > > > --On Thursday, September 28, 2017 4:41 PM -0400 Robert Heller > > <heller(a)deepsoft.com> wrote: > > > >> Will these spit out useful error messages? If I just get "TLS > >> Negotiation failure" it is not going to be helpful. > > However, you may have hit a known and unfixed bug in SSSD: > > <https://urldefense.proofpoint.com/v2/url?u=https- > 3A__pagure.io_SSSD_sssd_issue_2896-3Fcversion-3D0-26cnum- > 5Fhist-3D6&d=DwICAg&c=lb62iw4YL4RFalcE2hQUQealT9-RXrryqt9KZX2qu2s&r=2Fzhh_ > 78OGspKQpl_e-CbhH6xUjnRkaqPFUS2wTJ2cw&m=Ja4DjRR6Qj8_V_ > dfdMKRYjRAr1xpbNW8S-ZCeuu0wVU&s=LX7sB7YqYEcVA8ShS- > BKldCvsNEKG_FtNXsHvAu313g&e=> > > You may be better off using a better written piece of software. > > --Quanah > > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <https://urldefense.proofpoint.com/v2/url?u=http- > 3A__www.symas.com&d=DwICAg&c=lb62iw4YL4RFalcE2hQUQealT9- > RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-CbhH6xUjnRkaqPFUS2wTJ2cw&m= > Ja4DjRR6Qj8_V_dfdMKRYjRAr1xpbNW8S-ZCeuu0wVU&s=dEVYmbtnrd3EzH7Xm1Pk8GYotr6_ > kbuWkSoBh6UEV7I&e=> > > >

1 0

Re: Openldap and sssd: getting slapd to do TLS negotiation or getting sssd to NOT do TLS negotiation
by Quanah Gibson-Mount 28 Sep '17

28 Sep '17

--On Thursday, September 28, 2017 2:18 PM -0700 Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Thursday, September 28, 2017 4:41 PM -0400 Robert Heller > <heller(a)deepsoft.com> wrote: > >> Will these spit out useful error messages? If I just get "TLS >> Negotiation failure" it is not going to be helpful. However, you may have hit a known and unfixed bug in SSSD: <https://pagure.io/SSSD/sssd/issue/2896?cversion=0&cnum_hist=6> You may be better off using a better written piece of software. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Openldap and sssd: getting slapd to do TLS negotiation or getting sssd to NOT do TLS negotiation
by Quanah Gibson-Mount 28 Sep '17

28 Sep '17

--On Thursday, September 28, 2017 4:41 PM -0400 Robert Heller <heller(a)deepsoft.com> wrote: > Will these spit out useful error messages? If I just get "TLS > Negotiation failure" it is not going to be helpful. Sure, if you add "-d -1" to the parameters you pass in to ldapwhoami. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Openldap and sssd: getting slapd to do TLS negotiation or getting sssd to NOT do TLS negotiation
by Robert Heller 28 Sep '17

28 Sep '17

OK, I have narrowed things down to slapd and sssd not playing nice with each other. slapd is able to listen on ldaps (port 636) and accept SSL connections (eg from openssl s_client and other applications using straight SSL). slapd will also listen on ldap (port 389), but refuses to negotiate a TLS connection on port 389. It also refuses to negotiate TLS connection on port 636. sssd seems to *insist* on negotiating a TLS connection on port 636 or port 389 and won't just connect using ssl to port 636. (At least that is what I *think* is going on.) So, I either need to get slapd to do TLS negotiation on port 389 OR port 636, or get sssd to NOT do TLS negotiation on port 636 and just connect with SSL. How the hell do I get that to happen? here are my config files: [root@c764guest heller]# cat /etc/openldap/slapd.d/cn\=config.ldif # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 ba294eab dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/openldap/slapd.args olcPidFile: /var/run/openldap/slapd.pid olcTLSCACertificatePath: /etc/openldap/certs structuralObjectClass: olcGlobal entryUUID: 7e6a3298-30da-1037-9c4f-458bcc6c0ce0 creatorsName: cn=config createTimestamp: 20170918163057Z olcTLSCACertificateFile: /etc/openldap/certs/ca-cert.pem olcTLSCertificateFile: /etc/pki/tls/certs/c764guest.cert olcTLSCertificateKeyFile: /etc/pki/tls/certs/c764guestkey.pem entryCSN: 20170927144348.897441Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20170927144348Z [root@c764guest heller]# cat /etc/sssd/sssd.conf [domain/default] autofs_provider = ldap cache_credentials = True ldap_search_base = dc=deepsoft,dc=com id_provider = ldap auth_provider = ldap chpass_provider = ldap ldap_uri = ldaps://192.168.250.98/ ldap_id_use_start_tls = false ldap_tls_cacert = /etc/openldap/certs/ca-cert.pem ldap_default_bind_dn = uid=sssd,ou=People,dc=deepsoft,dc=com ldap_default_authtok = sssd [sssd] services = nss, pam, autofs domains = default [nss] homedir_substring = /home [pam] debug_level = 0x7770 ldap_id_use_start_tls = false [sudo] [autofs] [ssh] [pac] [ifp] [root@c764guest heller]# cat /etc/openldap/ldap.conf # # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. BASE dc=deepsoft,dc=com URI ldaps://192.168.250.98/ TLS_CACERT /etc/openldap/certs/ca-cert.pem TLS_CACERTDIR /etc/openldap/certs TLS_REQCERT demand #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never # Turning this off breaks GSSAPI used with krb5 when rdns = false SASL_NOCANON on TLS_REQCERT allow -- Robert Heller -- 978-544-6933 Deepwoods Software -- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services heller(a)deepsoft.com -- Webhosting Services

3 2

Re: Attribute map/substitution
by Quanah Gibson-Mount 28 Sep '17

28 Sep '17

--On Wednesday, September 27, 2017 11:53 AM +0200 Ervin Hegedüs <airween(a)gmail.com> wrote: > The problem is, that (for example) ntPassword and lmPassword attributes > are doesn't exists (sAMAccountName and objectSid also...). > > I thing that the ntPassword is the sambaNTPassword, which is part of the > samba.scheme. > > But how can I configure the OpenLDAP to server these attributes? The larger question is, does it actually need those attributes to function? If so, then you'll need to find schema defining them, add that schema to your OpenLDAP server, and then populate them. It may well not *require* them to be present in the entry (for example, it looks at all of: ntPassword, lmPassword, userPassword). My guess would be that as long as it can access one of those it is fine. However, the fact that it's trying to get a value back for a password shows that the piece of software is poorly written and should be avoided. There's zero reason for it to have read access to a password attribute. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: need an example of using "ldap_search_s" function using the "attr" parameter.
by Quanah Gibson-Mount 28 Sep '17

28 Sep '17

--On Monday, September 25, 2017 11:56 PM +0000 Don jessup <djessup72(a)yahoo.com> wrote: > To limit the information coming back from the server I only want the > values of the "sAMAccountName" attribute. Every time I try populating > the "attrs" parameter I get an error. I was wondering if I could be > pointed to an example or 2 that uses the parameter. ldap_search_s is deprecated, you should be using ldap_search_ext_s instead. However, libraries/libldap/sasl.c has a trivial example of using attrs with ldap_search_s: char *attrs[] = { "supportedSASLMechanisms", NULL }; rc = ldap_search_s( ld, "", LDAP_SCOPE_BASE, NULL, attrs, 0, &res ); --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

meta backend , rwm AD source , uppercase to lowercase
by Nicolas Renault 28 Sep '17

28 Sep '17

Hello, My question, I have a meta backend that work perfectly but on the dev team somebody ask me : Why on AD this organizationalUnit have these valuies on attrs : managedBy: CN=Surname Name,OU=Users,DC=domain,DC=fr seeAlso: CN=Sunrame2 Name2,OU=Users,DC=domain,DC=fr and on meta on the same OU : managedBy: cn=surname name,ou=Users,ou=meta,dc=domain,dc=fr seeAlso: cn=Surname2 Name2,ou=Users,ou=META,dc=domain,dc=fr the AD is "bind" to ou=META,dc=domain,dc=fr ( suffixemassage) all OU on meta have the same behavior so * why on managedBy attr all is modified in lowercase and only CN and OU on seeAlso ? * how work uppercase to lowercase with meta backend ? is overlay rwm implicated ? my meta backend config is very long but somme informations moduleload back_meta moduleload rwm moduleload valsort moduleload memberof moduleload dynlist moduleload sssvlv.so moduleload collect moduleload pcache moduleload back_monitor moduleload back_ldap moduleload back_mdb overlay rwm rwm-rewriteEngine on rwm-normalize-mapped-attrs yes ... lot of rewrite rules etc. version : @(#) $OpenLDAP: slapd 2.4.44 $ opensuse-buildservice(a)opensuse.org openSUSE Leap 42.2 thanks for your answers. Nicolas

1 0

Re: Locker killed to resolve a deadlock
by Quanah Gibson-Mount 27 Sep '17

27 Sep '17

--On Wednesday, September 27, 2017 3:05 PM +0900 Jorgen Lundman <lundman(a)lundman.net> wrote: > we have told it to syncrepl from scratch into an empty > directory. Catastrophically bad idea with OpenLDAP 2.4.36. You may want to read over the various sync issues that have been fixed since that release (Current release is 2.4.45). The only safe way for you to reload another server will be slapcat/slapadd. Generally, I'd strongly advise upgrading to a current release and switching to back-mdb, eliminating BDB entirely. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical