openldap-technical

openldap-technical@openldap.org

9 participants
9868 discussions

"GSSAPI Error: No credentials were supplied ... unknown mech-code 0 for mech unknown"
by Braiam 15 May '20

15 May '20

Hi, I'm trying to get slapd to use heimdal kerberos to provide a single authentication backend for my network. I've followed the Administrator's Guide on SASL[1] and cyrus faq entry about connecting OpenLDAP with GSSAPI[2]. I'm stuck at the what I believe is a misunderstanding from my part. I believe when I use -Y GSSAPI I should be using my braiam/admin credentials, but according to SASL facility in slapd I'm not providing any. strace confirms that it reads the /tmp/krb5cc_1000 file correctly. I'm very confused as to how to proceed since most of the relevant results point to having not kinit'd. I'm using Debian stable, slapd=2.4.47+dfsg-3+deb10u1, libsasl2-modules-gssapi-heimdal=2.1.27+dfsg-1+deb10u1. debian@ldap01:~$ sudo ktutil -k /etc/krb5.keytab list /etc/krb5.keytab: Vno Type Principal Aliases 4 aes256-cts-hmac-sha1-96 host/ldap01.example.com(a)EXAMPLE.COM 4 des3-cbc-sha1 host/ldap01.example.com(a)EXAMPLE.COM 4 arcfour-hmac-md5 host/ldap01.example.com(a)EXAMPLE.COM 9 aes256-cts-hmac-sha1-96 ldap/ldap01.example.com(a)EXAMPLE.COM 9 des3-cbc-sha1 ldap/ldap01.example.com(a)EXAMPLE.COM 9 arcfour-hmac-md5 ldap/ldap01.example.com(a)EXAMPLE.COM debian@ldap01:~$ klist Credentials cache: FILE:/tmp/krb5cc_1000 Principal: braiam/admin(a)EXAMPLE.COM Issued Expires Principal May 12 20:34:05 2020 May 13 20:34:05 2020 krbtgt/EXAMPLE.COM(a)EXAMPLE.COM May 12 20:34:11 2020 May 13 20:34:05 2020 ldap/ldap01.example.com(a)EXAMPLE.COM debian@ldap01:~$ ldapsearch -LLL -Y GSSAPI -s "base" -b "" supportedSASLMechanisms -H $ldap_host SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) additional info: SASL(-1): generic failure: GSSAPI Error: No credentials were supplied, or the credentials were unavailable or inaccessible. (unknown mech-code 0 for mech unknown) [1]: http://www.openldap.org/doc/admin24/sasl.html [2]: https://www.cyrusimap.org/sasl/sasl/faqs/openldap-sasl-gssapi.html -- Braiam

3 4

Help for setting-up an ldap-proxy
by lists＠zxt10d.de 14 May '20

14 May '20

Hello, I'm pretty new to this list, and maybe/hopefully someone could help ... I work at a chair at a german university, and we would like to use the central AD of theat university for our chair - by using a ldap-proxy system, so that there's only one connection to the central AD, and not ~70 (all of our computers, etc.). I can search the AD by using this (modified) command: ldapsearch -LLL "(cn=FIRSTNAME LASTNAME)" -H ldaps://ldap.UNIVERSITY.de -b dc=university,dc=de -D cn=special,ou=group,dc=university,dc=de -W For locally installed applications I can use this /etc/pam_ldap.conf: uri ldaps://ldap.university.de host ldap.university.de base ou=group,ou=hosts,dc=university,dc=de ldap_version 3 binddn cn=special,ou=group,dc=university,dc=de bindpw password pam_password crypt ssl start_tls ssl on To set-up the local ldap-proxy, I tried to follow this description, but it won't work (and I guess its not realy correct, as the config-file is there twice): https://doc.owncloud.com/server/admin_manual/configuration/ldap/ldap_proxy_… When running "slaptest -f /etc/ldap/slapd.conf" I get these errors: 5ebd3ec5 /etc/ldap/slapd.conf: line 102: warning, source attributeType 'dn' should be defined in schema 5ebd3ec5 PROXIED attributeDescription "DN" inserted. 5ebd3ec5 hdb_db_open: warning - no DB_CONFIG file found in directory /var/lib/ldap: (2). Expect poor performance for suffix "ou=group,ou=hosts,dc=university,dc=de". 5ebd3ec5 hdb_db_open: database "ou=lsafp,ou=hosts,dc=university,dc=de": db_open(/var/lib/ldap/id2entry.bdb) failed: No such file or directory (2). 5ebd3ec5 backend_startup_one (type=hdb, suffix="ou=group,ou=hosts,dc=university,dc=de"): bi_db_open failed! (2) 5ebd3ec5 backend_startup_one (type=ldap, suffix="ou=group,ou=hosts,dc=university,dc=de"): bi_db_open failed! (2) slap_startup failed (test would succeed using the -u switch) Now my questions: - where and how to put the data to do a query versus the central AD? (binddn & bindpw part) - where to define the local ldap-database? (I guess that has to be created an will be filled automatically...?) The system I'm using is a Debian 10.4 one. slapd -V: @(#) $OpenLDAP: slapd (Apr 20 2020 18:19:54) $ Debian OpenLDAP Maintainers <pkg-openldap-devel(a)lists.alioth.debian.org> Sorry, english is not my native language ... Thanks a lot for reading! ;) Cheers, Torsten

1 0

Can't get LDAPS connection with OpenLDAP as a Proxy working (error:14090086)
by a.leurs＠consense-gmbh.de 13 May '20

13 May '20

Hello, I'm farely now to OpenLDAP. I have successfully build a connection to an Windows Active Directory with LDAP over Port 389. But when I switch to LDAPS and Port 636 and try a connection via the Softerra LDAP Browser I get the following error: TLS certificate verification: Error, unable to get local issuer certificate TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (unable to get local issuer certificate). I have installed the certificate of the Server I want to connect to on my machine. But I still get this error. Does anyone have an idea why this error happens? Here is my slapd.conf-File: # MDB Backend configuration file # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. ucdata-path ./ucdata include ./schema/core.schema include ./schema/cosine.schema include ./schema/nis.schema include ./schema/inetorgperson.schema #include ./schema/openldap.schema #include ./schema/dyngroup.schema pidfile ./run/slapd.pid argsfile ./run/slapd.args loglevel 256 sizelimit unlimited timelimit unlimited ####################################################################### # mdb database definitions ####################################################################### database meta suffix "dc=example,dc=com" uri "ldaps://dc001.example.com:636/DC=example,DC=com"

2 1

Ldap attribute error
by Technology Server 11 May '20

11 May '20

Dear, After trying to reset LDAP user password , we are getting the following error. main[9834]: conn=4965799 op=1 MOD dn="uid=########################################" main[9834]: conn=4965799 op=1 MOD attr=userPassword [9834]: conn=4965799 op=1 RESULT tag=103 err=17 text=entry update failed [9834]: conn=4965799 fd=16 closed (connection lost) error 17 is receiving for other attribute also which are already defined. Can you please suggest on this issue?

3 2

ldapmodify: ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80)
by nisgopee＠gmail.com 07 May '20

07 May '20

Commad: ldapmodify -Y external -H ldapi:/// -f enable-ldap-log.ldif Returns: SASL/EXTERNAL authentication started ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) # cat enable-ldap-log.ldif dn: cn=config changeType: modify add: olcLogLevel olcLogLevel: stats # ldapmodify -Y external -H ldapi:/// -f enable-ldap-log.ldif -d1 ldap_url_parse_ext(ldapi:///) ldap_create ldap_url_parse_ext(ldapi:///??base) ldap_sasl_interactive_bind_s: user selected: external ldap_int_sasl_bind: external ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_path ldap_new_socket: 4 ldap_connect_to_path: Trying /var/run/ldapi ldap_connect_timeout: fd: 4 tm: -1 async: 0 ldap_ndelay_on: 4 ldap_ndelay_off: 4 ldap_int_sasl_open: host=mgo-lab-openldap SASL/EXTERNAL authentication started ldap_sasl_bind_s ldap_sasl_bind ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({i) ber: ber_flush2: 26 bytes to sd 4 ldap_result ld 0x1306570 msgid 1 wait4msg ld 0x1306570 msgid 1 (infinite timeout) wait4msg continue ld 0x1306570 msgid 1 all 1 ** ld 0x1306570 Connections: * host: (null) port: 0 (default) refcnt: 2 status: Connected last used: Thu May 7 02:59:55 2020 ** ld 0x1306570 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x1306570 request count 1 (abandoned 0) ** ld 0x1306570 Response Queue: Empty ld 0x1306570 response count 0 ldap_chkResponseList ld 0x1306570 msgid 1 all 1 ldap_chkResponseList returns ld 0x1306570 NULL ldap_int_select read1msg: ld 0x1306570 msgid 1 all 1 ber_get_next ber_get_next: tag 0x30 len 40 contents: read1msg: ld 0x1306570 msgid 1 message type bind ber_scanf fmt ({eAA) ber: read1msg: ld 0x1306570 0 new referrals read1msg: mark request completed, ld 0x1306570 msgid 1 request done: ld 0x1306570 msgid 1 res_errno: 80, res_error: <SASL(0): successful result: >, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 ldap_parse_sasl_bind_result ber_scanf fmt ({eAA) ber: ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree ldap_err2string ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80)

2 1

Re: Remove duplicate ppolicy overlay
by Côme Chilliet 07 May '20

07 May '20

Le mercredi 6 mai 2020, 08:16:35 CEST Quanah Gibson-Mount a écrit : > You need to provide the -F option so it knows where to write the data out > to. Thank you very much, that works! -- Côme Chilliet FusionDirectory - https://www.fusiondirectory.org

1 0

Antw: [EXT] Remove duplicate ppolicy overlay
by Ulrich Windl 07 May '20

07 May '20

>>> Côme Chilliet <come.chilliet(a)fusiondirectory.org> schrieb am 06.05.2020 um 17:07 in Nachricht <19295_1588777992_5EB2D407_19295_51_1_3360663.6gdB8VmVdU@mcmic-probook>: > Hello, > > I have a duplicated ppolicy overlay. > If I try to delete it using an LDAP operation on the node under cn=config, I > get a 53 error. > > After searching I found an email on this list ( > https://www.openldap.com/lists/openldap‑technical/201811/msg00077.html ) which > suggest the following procedure: > > a) slapcat ‑n 0 ‑l /tmp/config.ldif > b) Remove the duplicate entries from /tmp/config.ldif > c) mv /path/to/current/config /path/to/current/config.old;mkdir ‑p > /path/to/current/config > d) slapadd ‑n 0 ‑l /tmp/config.ldif > > But this does not work, because when calling slapadd at the end, it > complains that there is no slapd.conf. > Is there some way to tell slapadd what to do? Did you try adding " -F confdir"? > > Or do I need to create a slapd.conf file that I remove after? > > ‑‑ > Côme Chilliet > FusionDirectory ‑ https://www.fusiondirectory.org

1 0

Remove duplicate ppolicy overlay
by Côme Chilliet 06 May '20

06 May '20

Hello, I have a duplicated ppolicy overlay. If I try to delete it using an LDAP operation on the node under cn=config, I get a 53 error. After searching I found an email on this list ( https://www.openldap.com/lists/openldap-technical/201811/msg00077.html ) which suggest the following procedure: a) slapcat -n 0 -l /tmp/config.ldif b) Remove the duplicate entries from /tmp/config.ldif c) mv /path/to/current/config /path/to/current/config.old;mkdir -p /path/to/current/config d) slapadd -n 0 -l /tmp/config.ldif But this does not work, because when calling slapadd at the end, it complains that there is no slapd.conf. Is there some way to tell slapadd what to do? Or do I need to create a slapd.conf file that I remove after? -- Côme Chilliet FusionDirectory - https://www.fusiondirectory.org

2 1

slapd not running, not producing useful messages
by Uwe Falke 06 May '20

06 May '20

Hi, I am new to openldap. I've been searching the internet and this list, but have not found a match for my issue (though there are several failures of slapd to run reported, they all appear to differ from my case in that there were some side infos provided by slapd). I've built slapd (fairly plain: --enable-bdb=no --enable-hdb=no --with-tls) , installed it and tried to start it following the instructions in the admin guide ( chapter 2. A Quick-Start Guide, for that matter). modified /usr/local/etc/openldap/slapd.ldif ran [root@...]# /usr/local/sbin/slapadd -n 0 -F /usr/local/etc/openldap/slapd.d -l /usr/local/etc/openldap/slapd.ldif _#################### 100.00% eta none elapsed none fast! Closing DB... [root@...]# chown -R slapd.slapd /usr/local/etc/openldap/ [root@...]# chown -R slapd.slapd /usr/local/var/openldap-data Then, attempting to start slapd: # /usr/local/libexec/slapd -u slapd -g slapd -F /usr/local/etc/openldap/slapd.d -VVVVV -d65535 ldap_url_parse_ext(ldap://localhost/) ldap_init: trying /usr/local/etc/openldap/ldap.conf ldap_init: using /usr/local/etc/openldap/ldap.conf ldap_init: HOME env is /root ldap_init: trying /root/ldaprc ldap_init: trying /root/.ldaprc ldap_init: trying ldaprc ldap_init: LDAPCONF env is NULL ldap_init: LDAPRC env is NULL @(#) $OpenLDAP: slapd 2.4.49 (May 4 2020 11:30:05) $ root@xcat2.meteo:/usr/local/src/openldap-2.4.49/servers/slapd Included static overlays: syncprov Included static backends: config ldif monitor mdb relay 5eb2c445 slapd stopped. 5eb2c445 connections_destroy: nothing to destroy. I've tried to strace the slapd start, but that gave me no clue ... What can I further do to get useful hints to the cause o slapd's failure to run? Why, albeit I submit -F /usr/local/etc/openldap/slapd.d, does slapd / ldap_init report "using /usr/local/etc/openldap/ldap.conf"? Mit freundlichen Grüßen / Kind regards Dr. Uwe Falke IT Specialist Global Technology Services / Project Services Delivery / High Performance Computing +49 175 575 2877 Mobile Rathausstr. 7, 09111 Chemnitz, Germany uwefalke(a)de.ibm.com IBM Services IBM Deutschland Business & Technology Services GmbH Geschäftsführung: Dr. Thomas Wolter, Sven Schooss Sitz der Gesellschaft: Ehningen Registergericht: Amtsgericht Stuttgart, HRB 17122

3 2

2.4.45 on ubuntu replication issues between peers
by Malcolm Herbert 06 May '20

06 May '20

Apologies if this is not the correct forum for this problem, however I'm having replication issues with a two-node multi-provider setup which I'm trying to diagnose and any help would be appreciated (if there is a replication troubleshooting guide available that I can follow to diagnose these issues myself, I'm more than happy to work through that, please let me know) I have the following: two ubuntu 18.04 hosts (alpha, bravo); each has 2.4.45+dfsg-1ubuntu1.4; ldaps:// is configured and visible from the other; queries by clients work fine; time is in sync between them; the memberof overlay is present and appears to work; the active configuration is in olc (cn=config) form Summary: The replication issue manifests itself this way: * ldapmodify of a user record attribute on bravo replicates ok to alpha, but the user record there loses the memberof attributes * ldapmodify of a user record attribute on alpha never replicates to bravo I can "repair" the memberof attribute for a user across both hosts by removing them from a group and then re-instating them - these ldapmodify changes must occur to bravo however Other observations are that the root node on each server seems to have different entryuuid attributes but the contextcsn from each server is present and is replicated (as shown at the bottom of this email) ... I'm also wondering whether I might have the layering of these overlays wrong - I have them in order {0}back_mdb, {1}memberof, {2}refint, {3}syncprov ... should those instead be {0}back_mdb, {1}syncprov, {2}memberof, {3}refint? Background: This setup was initially just alpha with a nis/rfc2307 schema, but I copied out all of that data, converted it to rfc2307bis, configured bravo from scratch with an rfc2307bis schema, imported my converted data and successfully migrated my clients to use bravo. Once the clients (or as many of them as I could) were looking to bravo, I dropped all the data out of alpha and then configured it from scratch to match that on bravo. Unfortunately I know I got bits of this part of the process wrong and this may have soured my result: * olcServerID was missing on both hosts * initially olcSyncrepl was explicitly excluding memberof from replication with 'exattr="memberof"' * because I couldn't get replication working, I eventually manually added the same data to alpha as I'd used to populate bravo * at some point replication *did* kind of work and my users immediately lost memberof across the board Since then, I've gradually remediated the config and data across both hosts, but replication still refuses to cooperate (as summarised above). This is the bits of the config that appear to be relevant, and as far as I can tell, they look OK to me: alpha (slightly edited for brevity) - bravo differs only in the value for olcServerID, olcRootPW hash and olcSyncrepl peer uri: dn: cn=config cn: config objectClass: olcGlobal olcArgsFile: /var/run/slapd/slapd.args olcLogLevel: none olcPidFile: /var/run/slapd/slapd.pid olcServerID: 2 olcTLSCACertificateFile: /etc/ldap/sasl2/ca-certificates.crt olcTLSCertificateFile: /etc/ldap/sasl2/server.crt olcTLSCertificateKeyFile: /etc/ldap/sasl2/server.key olcTLSVerifyClient: never olcToolThreads: 1 dn: cn=module{0},cn=config cn: module{0} objectClass: olcModuleList olcModuleLoad: {0}back_mdb olcModuleLoad: {1}memberof olcModuleLoad: {2}refint olcModuleLoad: {3}syncprov olcModulePath: /usr/lib/ldap : (omitting pages of schema definitions) : dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * none olcAccess: {1}to attrs=shadowLastChange by self write by * read olcAccess: {2}to * by * read olcAccess: {3}to * by dn.base="cn=admin,dc=domain,dc=com" read by * break olcDatabase: {1}mdb olcDbCheckpoint: 512 30 olcDbDirectory: /var/lib/ldap olcDbIndex: cn,uid eq olcDbIndex: member,memberUid eq olcDbIndex: objectClass eq olcDbIndex: uidNumber,gidNumber eq olcDbMaxSize: 1073741824 olcLastMod: TRUE olcMirrorMode: TRUE olcRootDN: cn=admin,dc=domain,dc=com olcRootPW:: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy olcSuffix: dc=domain,dc=com olcSyncrepl: {0}rid=000 provider=ldaps://bravo.domain.com:636 type=refreshAndPersist retry="5 5 300 +" searchbase="dc=domain,dc=com" attrs="*,+" bindmethod=simple binddn="cn=admin,dc=domain,dc=com" credentials=xxxxxxxxxxxx dn: olcOverlay={0}memberof,olcDatabase={1}mdb,cn=config objectClass: olcConfig objectClass: olcMemberOf objectClass: olcOverlayConfig objectClass: top olcMemberOfDangling: ignore olcMemberOfGroupOC: groupOfNames olcMemberOfMemberAD: member olcMemberOfMemberOfAD: memberOf olcMemberOfRefInt: TRUE olcOverlay: {0}memberof structuralObjectClass: olcMemberOf dn: olcOverlay={1}refint,olcDatabase={1}mdb,cn=config objectClass: olcConfig objectClass: olcOverlayConfig objectClass: olcRefintConfig objectClass: top olcOverlay: {1}refint olcRefintAttribute: memberof member manager owner structuralObjectClass: olcRefintConfig dn: olcOverlay={2}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcSyncProvConfig olcOverlay: {2}syncprov olcSpCheckpoint: 100 10 structuralObjectClass: olcSyncProvConfig The root dc=domain,dc=com entry on both hosts, for comparison: # alpha dn: dc=domain,dc=com contextCSN: 20200504085236.014362Z#000000#002#000000 contextCSN: 20200504090305.772541Z#000000#001#000000 createTimestamp: 20200429092623Z creatorsName: cn=admin,dc=domain,dc=com dc: internal entryCSN: 20200429092623.624698Z#000000#000#000000 entryUUID: 3cd3ddfe-1e47-103a-9b7c-636addc89a1e modifiersName: cn=admin,dc=domain,dc=com modifyTimestamp: 20200429092623Z o: domain.com objectClass: dcObject objectClass: organization objectClass: top structuralObjectClass: organization # bravo dn: dc=domain,dc=com contextCSN: 20200504085236.014362Z#000000#002#000000 contextCSN: 20200504090303.909881Z#000000#001#000000 createTimestamp: 20200406074258Z creatorsName: cn=admin,dc=domain,dc=com dc: internal entryCSN: 20200406074258.475068Z#000000#000#000000 entryUUID: fac4ec88-0c25-103a-80b5-470686e83bfd modifiersName: cn=admin,dc=domain,dc=com modifyTimestamp: 20200406074258Z o: domain.com objectClass: dcObject objectClass: organization objectClass: top structuralObjectClass: organization Regards, Malcolm -- Malcolm Herbert mjch(a)mjch.net

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical